DE60318244T2 - 802.11-standard benutzung eines komprimierten reassoziationsaustauschs für schnelles weiterreichen - Google Patents

802.11-standard benutzung eines komprimierten reassoziationsaustauschs für schnelles weiterreichen Download PDF

Info

Publication number
DE60318244T2
DE60318244T2 DE60318244T DE60318244T DE60318244T2 DE 60318244 T2 DE60318244 T2 DE 60318244T2 DE 60318244 T DE60318244 T DE 60318244T DE 60318244 T DE60318244 T DE 60318244T DE 60318244 T2 DE60318244 T2 DE 60318244T2
Authority
DE
Germany
Prior art keywords
key
scm
request
node
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60318244T
Other languages
English (en)
Other versions
DE60318244D1 (de
Inventor
Robert Cuyahoga Falls MEIER
Richard D. North Royalton REBO
Victor J. North Canton GRISWOLD
Douglas A. Stouffvile SMTIH
Nancy Mountain View CAM WINGET
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Application granted granted Critical
Publication of DE60318244D1 publication Critical patent/DE60318244D1/de
Publication of DE60318244T2 publication Critical patent/DE60318244T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H04L9/0836—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key using tree structure or hierarchical structure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99948—Application of database or data structure, e.g. distributed, multimedia, or image

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Reduction Or Emphasis Of Bandwidth Of Signals (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft allgemein die drahtlose Vernetzung, insbesondere betrifft sie Verfahren und Systeme zur Authentifizierung und Bereitstellung von drahtlosen Vorrichtungen, während die Vorrichtungen zwischen Zugriffspunkten roamen.
  • Die meisten aktuellen 802.11 Netzebenen-Authentifizierungsprotokolle benötigen einen beträchtlichen Betrag an Zeit für den erneuten Aufbau der Konnektivität einer drahtlosen Station zu dem Netz, nachdem diese Station von einem Zugriffspunkt (AP; access point) zu einem anderen Zugriffspunkt roamt. Typischerweise muß dann, wenn sich eine Station mit einem ersten Zugriffspunkt verbindet, diese durch einen zentralen Authentifizierungsserver authentifiziert werden. Wenn die Station zu einem neuen Zugriffspunkt roamt, verliert die Station die Sitzung mit dem Netz und muß sich selber wieder durch den Authentifizierungsserver authentifizieren, was typischerweise eine vollständige Authentifizierungsabfrage- und -antwort zur Folge hat. Eine neue Abrechnungssitzung muß dann aufgebaut werden. Dieses Verfahren führt eine neue Schlüsselhierarchie ein, die bei der anfänglichen Authentifizierung beginnt und es dem Authentifizierungsschlüssel erlaubt, über die Dauer einer Sitzung zu dem Netz über eine 802.11-Verbindung bestehen zu bleiben. Außerdem basiert diese neue Schlüsselhierarchie auf einer Gegenmodus-Schlüsselgenerierung, um die Vorabberechnung des 802.11-Schlüssels zu erlauben, wodurch die Notwendigkeit für einen unnötigen Sitzungsabbruch und -neustart beseitigt wird.
  • Diese Verzögerung bei der erneuten Einrichtung der Konnektivität beeinträchtigt in großem Maße den 802.11-Dienst bis zu dem Punkt, dass einige Protokolle der höheren Ebenen, wie etwa Voice-over-IP (VoIP), tatsächlich versagen. Des Weiteren benötigt jedes Roaming im Allgemeinen eine Interaktion mit den Authentifizierungs-, Abrechnungs- und Autorisierungs-Servern (AAA-Servern) einer Serverstation, was zu einer beträchtlichen Steigerung der Serverbelastung führt, und zwar bis zu dem Punkt, an dem einige Server bei der Bereitstellung der notwendigen Rate an Authentifizierungsanfragen für die 802.11-Stationen versagen. Noch wichtiger ist, dass, nachdem die Authentifizierung geglückt ist, die 802.11-Station dann den Schlüssel verwenden muß, der bei der Authentifizierung bereitgestellt worden ist, um einen neuen Schlüssel zu erstellen, der dann verwendet wird, um die 802.11-Verbindung mit dem Zugriffspunkt zu sichern.
  • Deshalb besteht ein Bedarf an einem schnellen, sicheren und zuverlässigen Verfahren zur Authentifizierung und Bereitstellung einer Station, wenn die Station von einem Zugriffspunkt zu einem anderen roamt, das den Verkehr zu dem Authentifizierungsserver vermindert und die Generierung eines neuen 802.11-Schlüssels optimiert. Bei der Entwicklung eines schnellen, sicheren und zuverlässigen Verfahrens für das nahtlose Roaming einer Station zwischen Zugriffspunkten sind die folgenden zugrunde liegenden Voraussetzungen und Bedingungen erwünscht:
    • 1) Ein schnelles Weiterreichen (Handoff) muß die Nachrichtentransaktionen und Berechnungen zwischen einem MN und einem AP minimieren
    • 2) Ein schnelles Weiterreichen wird nur in der teilnetzinternen Mobilität bewirkt, obwohl eine Infrastruktur aufgebaut ist, um eine zukünftige Unterstützung der Mobilität zwischen Teilnetzen zu erlauben
    • 3) Das Weiterreichen muß sicher sein
    • 4) Das Gesamtdesign muß existierende Standards bis zu dem möglichen Ausmaß verstärken
    • 5) Das Gesamtdesign darf existierende Protokolle nicht beeinträchtigen
    • 6) Der Weiterreichungsmechanismus basiert auf einer Schlüsselverwaltung und ist somit unabhängig von dem Authentifizierungsmechanismus. Es sei aber angemerkt, dass jeder Schlüsselverwaltungsmechanismus Kenntnis von dem ausgewählten Authentifizierungstyp haben muß, da er wissen muß, wie er den NSK richtig abrufen und interpretieren muß.
    • 7) Der Weiterreichungsmechanismus baut auf einen zentralisierten Dienst auf, um sichere Schlüsselverteilungsdienste bereitzustellen
  • Aktuelle Authentifizierungsprotokolle wie etwa PEAP oder TLS erfordern eine Interaktion mit dem Authentifizierungszustand. PEAP propagiert die Fähigkeit, die Roaming-Zeit zu verkürzen, indem es einem MN erlaubt, einen vollständigen Authentifizierungsabfrage- und -antwort-Authentifizierungsaustausch zu umgehen, indem eine Wiederaufnahmeopera tion bewirkt wird. Die IEEE 802.11-Sicherheitsarbeitsgruppe (i) z. B., kurz TGi (Task Group (i)) genannt, hat die Einrichtung für eine Vorabauthentifizierung aufgenommen. Diese beiden Mechanismen setzen eine Notwendigkeit für eine Neuerstellung des Netz-Sitzungsschlüssels (NSK; network session key) voraus, bevor die Verbindung zwischen dem AP und dem MN einen paarweisen Übergangsschlüssel (PTK; pairwise transient key) für den Schutz von 802.11- und 802.1X-Verkehr erstellen kann. Aber mit einer definierten Schlüsselhierarchie bezieht sich auch die TGi auf die Fähigkeit des Transferierens des NSK von einem AP zu einem anderen. Dieses Design verwendet auch die Vorstellung der Beibehaltung des NSK und verlässt sich nur auf die Schlüsselverwaltungsmechanismen, um eine schnelle Weiterreichung während eines Roaming zu bewirken. Aber zur Bereitstellung einer Neuheit und Einzigartigkeit eines Sitzungsschlüssels für jeden Zugriffspunkt definiert die CCKM einen anfänglichen Austausch eines authentifizierten Schlüssels, durch den der MN und der erste verbundene AP Material zum Ableiten von neuen Schlüsseln für die Authentifizierung von Schlüsselanfragen, KRK, und eines Basis-Übergangsschlüssels, BTK, für die Ableitung von PTKs beitragen.
  • Das Folgende ist eine Liste von Akronymen und ihren entsprechenden Definitionen, wie sie in der ganzen vorliegenden Patentschrift verwendet werden:
    • AKM
    – Authenticated Key Management; authentifizierte Schlüssel-Verwaltung
    AP
    – Access Point; Zugriffspunkt
    AS
    – Authentication Server; Authentifizierungsserver
    BSSID
    – Basic Service Set Identifier; Basis-Dienstsatz-Kennung
    BTK
    – Base Transient Key; Basis-Übergangsschlüssel
    CCKM
    – Central Key Management; zentrale Schlüsselverwaltung
    CCM
    – Campus Context Manager; Campus-Kontextmanager
    CCX
    – Client Enablement
    CTK
    – Context Transfer Key; Kontexttransferschlüssel
    GTK
    – Group Transient Key; Gruppen-Übergangsschlüssel
    KRK
    – Key Request Key; Haupt-Anfrageschlüssel
    MN
    – Mobile Node; mobiler Knoten
    MN-ID
    – Mobile Node Identifier; Kennung des mobilen Knotens
    NSK
    – Network Session Key; Netz-Sitzungsschlüssel
    PRF
    – PseudoRandom Funktion; Pseudo-Random-Funktion
    PMK
    – Pairwise Master Key; paarweiser Master-Schlüssel
    PTK
    – Pairwise Transient Key; paarweiser Übergangsschlüssel
    RN
    – Rekey Request Sequence Number; erneute Schlüssel-Anfrage-Sequenznummer
    SCM
    – Subnet Context Manager; Teilnetz-Kontextmanager
    SSID
    – Service Set Identifier; Dienstsatzkennung
    SSN
    – Simple Security Network
    VLAN
    – Virtual Local Area Network; virtuelles lokales Netz
    WLCCP
    – Wireless Local Context Control Protocol; drahtloses lokales Kontextkontrollprotokoll
  • Zusammen mit den oben genannten Akronymen wird unten eine Definition von Begriffen definiert, die durch die ganze vorliegende Patentschrift hindurch immer wieder auftauchen:
    IEEE – Institute of Electrical and Electronics Engineers, Inc.
    IEEE 802.11 – Das 802.11-Protokoll und die 802.11-Begriffe sind in dem
    IEEE Std 802.11, Ausgabe 1999 definiert
    IEEE 802.11 TGi – eine Arbeitsgruppe in IEEE 802.11, die sich im Augenblick darauf konzentriert, ihre Anstrengungen auf die 802.11-Sicherheit zu richten.
    802-Adresse – Eine kanonische IEEE-48-Bit-"Ethernet"-Adresse. 802.11- und Ethernet-Adressen sind 802-Adressen.
    802.11-Brücke – Eine 802.11-Brücke ist eine transparente Brücke mit einem Ethernet-Brückenport und einem oder mehreren 802.11-Brückenports. Eine Vater-802.11-Brücke weist einen sekundären 802.11-Port auf, der eine Verbindung zu einem primären 802.11-Port in einer Sohn-802.11-Brücke herstellt.
    802.11-Station – Ein MN oder ein AP.
    802.1X – Das IEEE 802.1X-Protokoll und die 802.1X-Begriffe sind in [] definiert. 802.1X definiert ein Protokoll, bei dem sich ein 802.1X-Supplicant (Bittsteller) wechselseitig mit einem 802.1X-Authentifikator über einen Authentifizierungsserver authentifiziert.
    AAA – Authentifizierung Autorisierung Abrechnung. Ein Knoten wird einen Netzzugriff anfordern, indem er ein Protokoll zu einem (typischerweise) Authentifizierungsserver ausführt, der Protokolle und Dienste für die Bereitstellung der Authentifizierung, der Autorisierung und der Sitzungsabrechnung bereitstellt.
    AKM – Authenticated Key Management/Authentifizierte Schlüsselverwaltung. Ein neuer Selektor in dem ausgehandelten SSN-Element sowie auch in dem ausgehandelten TGi-Element, der in Beacons, Probe-Antwort- und erneuten Verbindungsanfrage-/-antwort-Nachrichten vorhanden ist. Dieser Selektor erlaubt die Definition eines Authentifizierungstyps und der Schlüsselverwaltung.
    AP – Zugriffspunkt. In dem vorliegenden Dokument wird "AP" als ein allgemeiner Begriff verwendet, der sich auf beliebige 802.11-zu-Ethernet- oder 802.11-zu-802.11-Weitergabevorrichtungen bezieht.
    Verbindungsnachricht – Eine 802.11-Station sendet eine Verbindungsanfragenachricht, um sich anfänglich mit einem Vater-AP zu verbinden. Der Vater-AP antwortet mit einer Verbindungsantwortnachricht.
    AS – Authentifizierungsserver. Ein Knoten, der AAA-Dienste (vor allem Authentifizierungsdienste) bereitstellt.
    BDPU (Bridge Protocol Data Unit) – Eine 802.1D-Brückenprotokoll-Dateneinheit.
    BSS (Basic Service Set) – Ein 802.11-Basisdienstsatz. Ein BSS ist der Satz von 802.11-Stationen, die mit einem einzigen 802.11-AP verbunden sind. Ein logischer "BSS-Port" in einem AP wird verwendet, um auf Stationen in dem BSS zuzugreifen.
    Basis-Übergangsschlüssel (BTK; basic transient key) – Der Basis-Übergangsschlüssel, der gegenseitig zwischen dem MN und dem SCM abgeleitet wird, um als der Schlüssel für die Erzeugung von PTKs zu dienen.
    Campus-Netz – eine gesamter "nahtloser Roaming-Bereich", der eine geographische Lokalität impliziert, die einen oder mehrere 802.11 Extended Service Sets umfassen kann. Ein physikalisches Campus-Netz kann mehrere "Campus-Netze" enthalten.
    Zentrale Schlüsselverwaltung (CCKM) – das Schlüsselverwaltungsschema der vorliegenden Erfindung. Es verwendet einen zentralen Knoten, einen AP, als den Schlüsselverteiler, um geschützte Kommunikationen zwischen einer Verbindung (z. B. einem AP und einem MN) zu ermöglichen.
    Kontexttransferschlüssel (CTK) – Ein Schlüssel, der von zwei Knoten gemeinsam verwendet wird, um einen Schutz ihrer Datenpakete zu erstellen. Der CTK kann aus einem Paar von Schlüsseln bestehen, wenn der Schutzmechanismus einen einzigartigen Schlüssel für jede Verschlüsselung und Paketauthentifizierung benötigt (z. B. eine MIC).
    Korrespondenz-Host (CH; correspondent host) – Ein mobiler oder nicht mobiler Knoten, der aktiv mit einem MN kommuniziert.
    Nachfolger (Descendant) – Ein Knoten, der sich in dem Unterbaum eines Topologiebaums befindet, der in einem Vorgängerknoten wurzelt.
    DRR – Descendant Registration Record; (Nachfolgerregistrierungsaufzeichnung). Eine DRR enthält Zustandsinformationen für Nachfolgerknoten. Eine MN-DRR ist eine DRR für einen mobilen Knoten. Eine AP-DRR ist eine DRR für einen AP.
    DPR – Descendant Path Record (DPR); (Nachfolgerpfadaufzeichnung). Eine DPR enthält Pfadzustandsinformationen für Nachfolgerknoten.
    Downlink – Der logische Funkpfad von einem 802.11-AP-Funk zu einer Sohn-802.11-Station.
    ESS – Ein 802.11 Extended Service Set (erweiterter Dienstsatz). Ein ESS umfasst eine oder mehrere BSSs und kann ein oder mehrere Teilnetze überspannen. MNs können zwischen APs in dem ESS roamen. Ein SWAN-Campusnetz kann mehrere ESSs umfassen.
    FA (Foreign Agent) – Ein mobiler IPv4-Fremdagent.
    Group Transient Key (GTK) (Gruppen-Übergangsschlüssel) – Ein Schlüssel, der von einem AP besessen und verwaltet wird. Er wird verwendet, um Multicast- und Broadcast-Verkehr zu schützen.
    HA (Home Agent) – Ein mobiler IPv4-Heimatagent.
    Hopwise Routing – Das "Hopwise Routing" (etappenweises Routing) wird verwendet, wenn eine eingehende oder abgehende WLCCP-Nachricht zu Zwischen-APs auf dem Pfad von dem Absender (Originator) zu dem Antwortenden (Responder) weitergeleitet werden muß.
    IA – Infrastructure Node Authenticator (Infrastrukturknoten-Authentifikator). In einem selbständigen Modus (standalone mode) ist der SCM der IA; in einer vollständigen SWAN-Konfiguration ist der CCM der IA.
    IGMP – Internet Group Management Protocol. Das IGMP wird verwendet, um die IP-Multicast-Gruppenmitgliedschaft zu bestimmen.
    IGMP Snooping – Switches und APs "belauschen" IGMP-Nachrichten, die an einem Port empfangen wurden, um festzustellen, welche IP-Multicast-Adressen auf dem Port übertragen werden müssen.
    Eingehend (inbound) – Ein "eingehender Rahmen" wird in dem SWAN-Topologiebaum zu dem CCM weitergeleitet. Auf einen "eingehenden Knoten" wird über den "primären Port" zugegriffen. (Ein "eingehender Knoten" ist nicht notwendigerweise ein "Vorgängerknoten".)
    IN – Infrastructure Node (Infrastrukturknoten). Ein IN ist ein AP, SCM, LCM oder CCM.
    IRR – Inbound Registration Record (eingehende Registrierungsaufzeichnung).
    KDC – Key Distribution Center (Schlüsselverteilungscenter). Dies ist ein Dienst, der von dem IN-Authentifikator bereitgestellt wird, um die CTKs zu verteilen, die von registrierten Infrastrukturknoten konsumiert werden sollen.
    Key Request Key (KRK) (Haupt-Anfrageschlüssel) – der Abschnitt des erweiterten NSK, der verwendet wird, um Schlüsselauffrischungs-Anfrage-/Antwort-Handshakes zu authentifizieren.
    Lager 2 (Schicht 2) – Die Datenverbindungsschicht, wie sie in dem OSI-7-Schichten-Modell definiert ist.
    L-CTK – Lateral Context Transfer Key (lateraler Kontexttransferschlüssel).
    Link (Verbindung) – die logische Verbindung zwischen zwei direkten Nachbarn in dem SWAN-Topologiebaum.
    Link State (Verbindungszustand) – Jeder SWAN-Knoten ist verantwortlich dafür, die Verbindung zu jedem seiner direkten Nachbarn zu überwachen. Der Verbindungszustand kann "Verbunden" oder "Getrennt" sein.
    MIP – Mobiles IPv4, wie es in RFC 2002 definiert ist.
    MN – ein mobiler 802.11-Knoten.
    MN-ID – 802.11-Mobilknotenkennung, die als die MAC-Adresse des Knotens repräsentiert wird.
    Network Session Key (NSK) (Netz-Sitzungsschlüssel) – der Schlüssel, der durch eine erfolgreiche Authentifizierung zwischen einem Knoten und seinem Authentifikator erstellt wird. Dabei ist der CCM der Authentifikator für alle Infrastrukturknoten, und der LCM ist der Authentifikator für alle MNs. In dem Fall, bei dem ein SCM in einem selbständigen Modus arbeitet, ist der SCM der Authentifikator für alle Knoten.
    MNR – Mobile Node Record (Aufzeichnung des mobilen Knotens). Eine Mobilknotenaufzeichnung enthält Zustandsinformationen für die MNs.
    Mobility Bindings (Mobilitätsbindungen) – Die "Mobilitätsbindungen" für eine Station werden verwendet, um den aktuellen Pfad zu der Station zu bestimmen. APs, Kontextmanager und MIP-Agenten verwalten Mobilitätsbindungen für 802.11-Stationen.
    MSC – Message Sequence Counter (Nachrichtensequenzzähler). Dies ist effektiv der RC4 IV- und Wiedergabe-Protektor.
    Native VLAN ID – Ein Switch-Port und/oder ein AP können mit einer "nativen VLAN ID" konfiguriert sein. Rahmen ohne Tags oder mit Prioritäts-Tags sind implizit mit der nativen VLAN ID verbunden.
    Network Access Identifier (NAI) (Netzzugangskennung) – Eine NAI wird verwendet, um einen Benutzer in einem Netzbereich zu identifizieren. Zum Beispiel ist "joe@cisco.com" eine typische NAI.
    NSK – Network Session Key (Netz-Sitzungsschlüssel). Ein NSK ist der Schlüssel, der durch eine erfolgreiche Authentifizierung zwischen einem Knoten und seinem "Authentifikator" erstellt wird. (In einem Campusnetz ist der CCM der Authentifikator für alle Infrastrukturknoten, und der LCM ist der Authentifikator für alle MNS. In einem selbständigen Teilnetz-Bereich ist der SCM der Authentifikator für alle Knoten in dem Teilnetz.)
    Absender (Originator) – Der Knoten, der eine WLCCP-"Anfrage"-Nachricht "hervorbringt".
    Abgehend (Outbound) – Ein "abgehender Rahmen" wird in dem SWAN-Topologiebaum von dem CCM weg weitergeleitet. Ein "abgehender Knoten" ist ein "Nachfolger"-Knoten, der von dem CCM in dem SWAN-Topologiebaum verhältnismäßig weiter entfernt ist.
    OMNR – Outbound Mobile Node Record (abgehende Mobilknotenaufzeichnung)
    Pairwise Master Key (PMK) (paarweiser Master-Schlüssel) – der Schlüssel, der durch eine erfolgreiche Authentifizierung erstellt wird. Dies ist der Begriff, der sowohl in der TGi-Entwurfsspezifikation als auch in der SSN-Entwurfsspezifikation verwendet wird, und dies ist ein Schlüssel, der zur Ableitung von PTKs verwendet wird.
    Pairwise Transient Key (PTK) (paarweiser Übergangsschlüssel) – der Schlüssel, der von dem AP und dem MN gegenseitig abgeleitet wird, und der eine Funktion von BTK und RN ist.
    Pfadauthentifizierung – Die Pfadauthentifizierung bezieht sich auf den Prozess, bei dem sich ein AP oder ein Sohn-CM wechselseitig authentifiziert und einen Pfad-CTK mit jedem seiner Vorgänger erstellt. Pfad-Init- und (optional) Anfangs-Registrierungs-Nachrichten werden für die Pfadauthentifizierung verwendet.
    Port – Die logische Entität, die den Zugang zu einer SWAN-Topologiebaum-"Verbindung" bereitstellt. Mehrere logische Ports können an einer einzigen Hardware-Schnittstelle existieren.
    PNR – Parent Node Record (Vaterknotenaufzeichnung)
    Primary LAN (primäres LAN) – Das verdrahtete Ethernet-LAN, das direkt an dem SCM angeschlossen ist. Jedes Teilnetz weist ein einziges primäres Ethernet-LAN auf. Das primäre LAN kann mehrere Ethernet-Segmente und drahtgebundene transparente Brücken/Switches enthalten.
    Primary Port (primärer Port) – Der Port, der für den Anschluss an den SWAN-Topologiebaum verwendet wird. In einem SCM ist dies derjenige Port, der verwendet wird, um auf den Vater-LCM oder -CCM zuzugreifen. In einem AP ist dies der Port, der verwendet wird, um Rahmen zu dem primären LAN zu übertragen. Ein primärer Port eines AP kann ein Ethernet-Port oder ein 802.11-Port sein. Der primäre Port des AP ist der "Standardport" für Unicast-Flooding-Zwecke. [Wenn ein AP mit einem SCM zusammen angeordnet ist, dann existiert eine logische interne Verbindung zwischen dem AP und dem SCM. Ein logischer "interner primärer Port" des AP stellt einen Zugang zu dem SCM bereit; aber der Ethernet-Port ist immer noch der "primäre Port" für Rahmenweiterleitungszwecke.]
    PTK – Pairwise Transient Key (paarweiser Übergangsschlüssel). Dieser Schlüssel wird verwendet, um 802.1X- und 802.11-Datenpakete zwischen einem MN und einem AP zu schützen. PTKs werden von jedem Knoten in der Verbindung auf der Basis einer vordefinierten starken Pseudo-Random-Funktion, einer BSSID, RN und BTK gegenseitig abgeleitet.
    Reassociation Message (Erneute Verbindungsnachricht) – Eine 802.11-Station sendet eine 802.11-Anfragenachricht bezüglich einer erneuten Verbindung, um sich mit einem neuen Vater-AP zu verbinden, nachdem sie geroamt ist. Der Vater-AP antwortet mit einer erneuten Verbindungs-Antwortnachricht (reassociation response message).
    Rekey Request Number (RN) (erneute Schlüssel-Anfrage-Nummer) – der Zähler, der verwendet wird, um PTK-Schlüsselauffrischungen vor Replay-Attacken (Wiedergabeattacken) zu schützen. Der Zähler wird auch als ein Teil des PTK-Schlüsselgenerators verwendet.
    Repeater – Ein Repeater ist ein "drahtloser AP", der an einem Vater-AP an einem primären 802.11-Port angeschlossen ist.
    RN – Request Number (Anfragenummer). Ein Sequenzwert, der verwendet wird, um PTKs zu rotieren, die zwischen einem authentifizierten MN und einem Wurzel-AP verwendet werden.
    Root AP (Wurzel-AP) – Ein "Wurzel-AP" ist direkt an dem primären LAN an seinem primären Ethernet-Port angeschlossen.
    Root CM (Wurzel-CM) – Der CM, der sich an der Wurzel des aktiven SWAN-Topologiebaums befindet. Der CCM ist der Wurzel-CM in einem Campus-Netz. Der SCM ist der Wurzel-CM in einem "selbständigen" Teilnetzkontrollbereich.
    Antwortender (Responder) – Das Ziel einer WLCCP-Anfragenachricht bzw. der Knoten, der eine WLCCP-Antwortnachricht hervorbringt.
    SARpM – SCM Advertisement Reply Message (SCM-Bekanntmachungs-Antwortnachricht)
    SCM – Subnet Context Manager (Teilnetz-Kontextmanager). Ein SCM stellt einen zentralen Steuerpunkt für jedes Teilnetz dar. Der SCM erstellt das "primäre LAN" für jedes Teilnetz. Aus der Perspektive eines MN ist ein Heimat-SCM der SCM des Heimat-Teilnetzes für den MN, und ein fremder SCM ist ein SCM in irgendeinem anderen "fremden Teilnetz".
    Seamless Roaming (Nahtloses Roaming) – Man sagt, dass ein MN "nahtlos" roamt, wenn er zwischen APs in unterschiedlichen Teilnetzen ohne eine Änderung seiner "Heimat-IP-Adresse" roamt.
    Sekundäres LAN – Jedes drahtgebundene Ethernet-LAN, das an dem primären Ethernet-LAN durch eine drahtlose Verbindung angeschlossen ist. Ein sekundäres LAN kann mehrere Ethernet-Segmente und verdrahtete transparente Brücken/Switches enthalten.
    Sekundärer Port – Ein sekundärer Port ist jeder aktive AP- oder CM-Port mit Ausnahme des primären Ports.
    SSID – 802.11 Service Set Identifier (Dienstsatzkennung). Authentifizierungsparameter werden global per SSID definiert. In jedem AP kann eine SSID lokal an ein "Heimat-Teilnetz" oder ein VLAN gebunden sein.
    Simple Security Network (SSN) – Die Spezifikation von Microsoft für ein System, das zur Bereitstellung einer 802.11-Sicherheit verwendet wird. Es erfordert die Verwendung einer 802.1X-EAP-Authentifizierung, des TKIP und eines 802.1X 4-Wege-Handshake gemäß Microsoft zur Verwaltung von Unicast-Schlüsseln und eines 802.1X 2-Wege-Handshake gemäß Microsoft für die Verwaltung von Broadcast- und Multicast-Schlüsseln.
    STP (Spanning Tree Protocol) – IEEE 802.1D Spannbaumprotokoll. Ein "STP AP" führt das 802.1D STP aus, und das 802.1D STP wird in einer "STP-Verbindung" betrieben. Ein "Nicht-STP-AP" führt das 802.1D STP nicht aus.
    Subnet (Teilnetz) – Ein IP-Teilnetz. Ein MN ist mit einem einzigen "Heimat-Teilnetz" zu jedem gegebenen Zeitpunkt verbunden. Jedes andere Teilnetz ist aus der Perspektive des MN ein "fremdes Teilnetz"
    Supplicant – Der IEEE 802.1X-Standard definiert den Begriff "Supplicant". Ein Supplicant ist ein Knoten, der sich gegenseitig mit einem "802.1X-Authentifikator" über einen Authentifizierungsserver authentifiziert.
    SWAN – Smart Wireless Architecture for Networking, eine Architektur für das Funk-, Netz- und Mobilitätsmanagement in einer sicheren Umgebung.
    SWAN-Topologiebaum – Die logische Struktur eines SWAN-Netzes, wie dies von den SWAN-Vater/Sohn-Beziehungen bestimmt wird. Der SWAN CCM befindet sich an der Wurzel des Topologiebaumes.
    VLAN – Ein "virtuelles LAN", wie es in dem IEEE 802.1Q Standard definiert ist.
    TLV – Typ, Länge, Wert. "TLVs" enthalten optionale Parameter in WLCCP-Nachrichten.
    Uplink – Der logische Funkpfad von einer 802.11-Sohnstation zu seinem Vater-AP-Funk.
    URR – Unbound Registration Record (nicht gebundene Registrierungsaufzeichnung).
    VLAN – Ein "virtuelles LAN" wie es in dem IEEE 802.1Q Standard definiert ist. Mit VLAN-Tags versehene Rahmen werden auf einer VLAN-Verbindungsleitung übertragen.
    Drahtlose Station – Ein MN, ein Repeater, eine WGB oder eine Sohn-802.11-Brücke.
    WGB – Eine Work Group Bridge (Arbeitsgruppenbrücke) ist ein Nicht-STP-AP mit einem primären 802.11-Port und einem sekundären Ethernet-Port, der den Zugang zu einem sekundären Nicht-STP-Ethernet-LAN-Segment bereitstellt.
    WLAN – Drahtloses LAN.
    WLCCP – Wireless LAN Context Control Protocol (drahtloses LAN-Anwendungskontextmanagement-Protokoll)
  • Neben den oben erwähnten Akronymen sollen Akronyme aus der 802.11 Spezifikation ihre gewöhnliche und gebräuchliche Bedeutung erhalten, wie sie durch die 802.11-Spezifikation definiert ist, außer sie sind anders definiert.
  • Der "IEEE Standard for Local and Metropolitan Area Networks-Port Based Access Control", American National Standard (amerikanischer nationaler Standard), 13. Juli 2001, USA, offenbart einen Standard für die Authentifizierung und die Autorisierung von Vorrichtungen, die an einem LAN-Port angeschlossen sind, der Punkt-zu-Punkt-Verbindungscharakteristiken aufweist. Der Standard beschreibt ferner Techniken zur Verhinderung eines Zugriffs auf den Port, wenn der Authentifizierungs- und Autorisierungsprozess fehlschlägt.
  • DeCleene et al., "Secure Group Communications for Wireless Networks", IEEE Military Communications Conference, New York, USA, 28. Oktober 2001, offenbart und analysiert eine Vielzahl von Rekeying-Strategien in einer hochmobilen drahtlosen Vernetzungsumgebung.
  • Die US 2002/0061748 offenbart ein Verfahren zur Registrierung und Authentifizierung eines drahtlosen Endgeräts in einem Heimatnetz, in dem ein Benutzer die drahtlose Basisstation direkt betätigen muß, um einen externen Benutzer daran zu hindern, ein externes drahtloses Endgerät mit der Basisstation zu verbinden.
  • KURZE ZUSAMMENFASSUNG DER ERFINDUNG
  • Angesichts der oben erwähnten Bedürfnisse zieht die Erfindung ein Design in Betracht, das sowohl Nachrichten- als auch Berechnungsbelastungen reduziert, indem es eine Schlüsselhierarchie verwendet, die die Authentifizierungssitzungszeit von der Schlüsselverwaltung abkoppelt. Augenblickliche 802.11-Implementierungen binden die Authentifizierung und das Schlüsselmanagement eng aneinander und erzwingen vollständige (erneute) Backend-Authentifizierungen, weil sie an die Cipher-Suite-Auswahl gebunden sind. Für die Wired Equivalent Privacy (WEP)-Methode kann dies auf Grund der Rekey-Anforderungen (Anforderungen bezüglich neuer Schlüssel) der WEP-Methode zu sehr häufigen (erneuten) Authentifizierungen führen. Für das Roaming erzwingen aktuelle Implementierungen auch eine vollständige (erneute) Authentifizierung.
  • Die Schlüsselhierarchie definiert Schlüssel, die nach einer erfolgreichen Authentifizierung als Netz-Sitzungsschlüssel (NSKs) erstellt werden, die von der 802.11-Cipher-Suite-Auswahl unabhängig sind. Der NSK wird verwendet, um einen Hauptauffrischungsschlüssel (KRK; key refresh key) zur Authentifizierung von Schlüsselauffrischungs-Anfragen und einen Basis-Übergangsschlüssel (BTK) zu generieren, der als der Basisschlüssel dient, von dem paarweise Übergangsschlüssel (PTK) abgeleitet werden.
  • Nur PTKs sind an die ausgewählte 802.11 Cipher Suite gebunden und müssen somit auf der Grundlage der Cipher Suite Sicherheitspolitik verwaltet werden. Die Langlebigkeit des NSK wird von dem Authentifizierungsserver (AS) als ein Sitzungs-Timeout definiert, der nun als eine Funktion der NSK-Entropie gegenüber der ausgehandelten 802.11 Cipher Suite definiert werden kann. Es ist erwünscht, nachdrücklich die Verwendung von Authentifizierungstypen zu fördern, die zu einer Generierung eines dynamischen NSK mit einem noch größeren Anteil guter Entropie führen.
  • Schlüssel werden von einem zentralisierten Knoten verwaltet, der ein Teilnetz-Kontext-Management (SCM) bereitstellt. Vorzugsweise ist der SCM der 802.1X-Authentifikator für alle MNs und APs, der alle MN-Knoten zwingt, sich implizit zu registrieren. Der Registrierungsprozess gewährleistet, dass sich alle Knoten in dem Register erfolgreich verbunden haben, authentifiziert sind und Sicherheits-Berechtigungsnachweise (security credentials) aufweisen, die in einem Cachespeicher aufgenommen sind. Die in diesem Vorschlag beschriebenen Mechanismen sind als zentrale Schlüsselverwaltung (CCKM) definiert und werden als ein proprietärer Wert in dem authentifizierten Schlüssel-Verwaltungs-(AKM)-Informationselement ausgehandelt, wie es in den SSN-/TGi-Entwürfen definiert ist.
  • Während der Authentifizierungsmechanismus unverändert bleibt, z. B. die 802.1X Extensible Authentication Protocol(EAP)-Authentifizierung, führt dieses Design ein neues Schlüsselverwaltungsschema ein: die zentrale Schlüsselverwaltung (CCKM). Diese neue Fähigkeit wird unter Verwendung der SSN IE oder RSN IE bekannt gegeben und ausgehandelt, wie dies hier weiter unten beschrieben wird.
  • Gemäß einer Ausführungsform ist ein Verfahren zum Aufbau einer sicheren Verbindung für einen mobilen Knoten mit einem Netz, das eine Vielzahl von Zugriffspunkten aufweist, mit den folgenden Schritten bereitgestellt: Verbinden mit einem ersten Zugriffspunkt; Authentifizieren des mobilen Knotens mittels eines erweiterbaren Authentifizierungsprotokolls durch den ersten Zugriffspunkt; Erstellen eines Netz-Sitzungsschlüssels; und Registrieren des mobilen Knotens in der Netz-Infrastruktur; wobei der Netz-Sitzungsschlüssel verwendet wird, um einen Haupt-Anfrageschlüssel und einen Basis-Übergangsschlüssel zu erstellen; wobei der Basis-Übergangsschlüssel als Gegenmodus-Schlüsselgenerator verwendet wird, um neue paarweise Übergangsschlüssel bereit zu stellen; wobei der Haupt-Anfrageschlüssel von dem mobilen Knoten verwendet wird, um zu belegen, dass er eine ordnungsgemäße Autorisierung für eine Sitzung aufweist; wobei das Roaming zu einem zweiten Zugriffspunkt einen komprimierten Satz von Nachrichtenaustausch mit einbezieht, um den Besitz eines neuen Übergangsschlüssels sowie das Liefern eines Gruppen-Übergangsschlüssels durch den zweiten Zugriffspunkt zu belegen.
  • Gemäß einer weiteren Ausführungsform ist ein mobiler Knoten bereitgestellt mit: einer Einrichtung zur Verbindung mit einem ersten Zugriffspunkt; einer Einrichtung zum Authentifizieren des mobilen Knotens mittels eines erweiterbaren Authentifizierungsprotokolls durch den ersten Zugriffspunkt; einer Einrichtung zur Erstellung eines Netz-Sitzungsschlüssels; und einer Einrichtung zum Registrieren des mobilen Knotens in der Netz-Infrastruktur; wobei der Netz-Sitzungsschlüssel verwendet wird, um einen Haupt-Anfrageschlüssel und einen Basis-Übergangsschlüssel zu erstellen; wobei der Basis- Übergangsschlüssel als ein Gegenmodus-Schlüsselgenerator verwendet wird, um neue paarweise Übergangsschlüssel bereit zu stellen; wobei der Haupt-Anfrageschlüssel von dem mobilen Knoten verwendet wird, um zu belegen, dass er eine ordnungsgemäße Autorisierung für eine Sitzung aufweist; wobei das Roaming zu einem zweiten Zugriffspunkt einen komprimierten Satz von Nachrichtenaustausch mit einbezieht, um den Besitz eines neuen Übergangsschlüssels sowie das Liefern eines Gruppen-Übergangsschlüssels durch den zweiten Zugriffspunkt zu belegen.
  • Gemäß einer noch weiteren Ausführungsform ist eine Vorrichtung zum Antworten auf einer erneute Schlüsselsequenz bereitgestellt, die aufweist: eine Einrichtung zum Empfangen einer erneuten Schlüssel-Anfrage, wobei die erneute Schlüssel-Anfrage eine erneute Schlüssel-Anfrage-Nummer und ein Authentifizierungselement aufweist, das die Lieferung des Gruppen-Übergangsschlüssels enthält; eine Einrichtung zum Berechnen eines neuen Paars von Übergangsschlüsseln; und eine Einrichtung zum Senden eines Bereit-zum-Senden-und-Empfangen mit der Nachricht mit dem neuen Paar von Übergangsschlüsseln.
  • Bevorzugte Merkmale der Ausführungsformen sind in den Unteransprüchen dargelegt.
  • Es ist auch ein Computerprogramm, ein Computerprogramm-Erzeugnis oder ein computerlesbares Medium bereitgestellt, das Schritte zum Ausführen eines Verfahrens gemäß den oben genannten Verfahrensausführungsformen oder irgendwelcher ihrer bevorzugten Merkmale umfasst.
  • Im vorliegenden Dokument wird auch ein Verfahren zur Authentifizierung eines mobilen Knotens mit einem Netz beschrieben, wobei die Schritte das Verbinden mit einem Zugriffspunkt, das Authentifizieren des mobilen Knotens mittels eines erweiterbaren Authentifizierungsprotokolls durch den Zugriffspunkt und das Erstellen eines Netz-Sitzungsschlüssels und das Registrieren des mobilen Knotens in der Netz-Infrastruktur umfassen. Der Netz-Sitzungsschlüsse) wird dazu verwendet, einen Haupt-Anfrageschlüssel und einen Basis-Übergangsschlüssel zu erstellen.
  • Nach der anfänglichen Authentifizierung wird der Netz-Sitzungsschlüssel zu einem Subnet Context Manager gesendet. Die vorliegende Erfindung zieht außerdem die Authentifizierung von Schlüsselauffrischungen unter Verwendung des Netz-Sitzungsschlüssels in Betracht. Es wird weiterhin in Betracht gezogen, dass paarweise Übergangsschlüssel unter Verwendung des Netz-Sitzungsschlüssels abgeleitet werden.
  • In dem vorliegenden Dokument wird auch ein Verfahren zur erneuten Verbindung durch einen mobilen Knoten beschrieben, wobei die Schritte das Senden einer erneuten Verbindungsanfrage von einem mobilen Knoten an einen Zugriffspunkt, wobei die erneute Verbindungsanfrage eine Identifizierung des mobilen Knotens, eine erneute Schlüssel-Anfrage-Nummer und ein Authentifizierungselement aufweist, das Validieren der erneuten Verbindungsanfrage, wobei der Validierungsschritt das Berechnen eines neuen paarweisen Übergangsschlüssel, das Senden einer Antwort, wobei die Antwort ein Authentifizierungselement umfasst, zu dem mobilen Knoten, wobei das Authentifizierungselement den neuen paarweisen Übergangsschlüssel und einen erweiterbaren Authentifizierungsprotokoll über den Local Area Network Schlüssel umfasst, und das Bestätigen der Antwort durch Verifizieren des neuen paarweisen Übergangsschlüssels auf einen zweiten berechneten paarweisen Übergangsschlüssel umfassen.
  • Typischerweise wird die Antwort validiert, indem der neue paarweise Übergangsschlüssel verifiziert wird. Die Antwort kann auch durch das Verifizieren eines Zeitstempels verifiziert werden, der in der Antwort enthalten ist. Das Authentifizierungselement verwendet vorzugsweise einen aktuellen paarweisen Übergangsschlüssel. Der Validierungsschritt wird entweder von einem Subnet Context Manager (SCM), einem Authentifizierungsserver (AS) oder von dem Zugriffsserver (AAA-Server) durchgeführt. Andere Verfahren zur Validierung der Anfrage umfassen, sind aber nicht begrenzt auf das Verifizieren, dass der Zeitstempel der erneuten Verbindungsanfrage innerhalb eines konfigurierbaren Werts liegt, das Verifizieren, dass die Sequenznummer größer als ein vorhergehender Wert ist, das Senden einer Anfrage an den Subnet Context Manager, um die erneute Verbindungsanfrage zu validieren, wobei der Zugriffspunkt (AP) eine erneute Schlüssel-Anfrage-Nummer und einen Basis- Übergangsschlüssel von dem Subnet Context Manager erhält und einen paarweisen Übergangsschlüssel (PTK) erzeugt.
  • Im vorliegenden Dokument wird auch eine erneute Schlüsselsequenz beschrieben, wobei die Schritte umfassen: Berechnen eines Authentifizierungselements, wobei das Authentifizierungselement eine erneute Schlüssel-Anfrage-Nummer und ein neues Paar Übergangsschlüssel aufweist; Senden eines Anrufs für einen neuen paarweisen Übergangsschlüssel an einen Antwortenden; Empfangen eines Antwort-Authentifizierungselements von dem Antwortenden; und Verifizieren des Antwort-Authentifizierungselements, wobei das Antwort-Authentifizierungselement das neue Paar Übergangsschlüssel enthält. Die erneute Schlüssel-Sequenz kann des Weiteren das Senden eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüssel-Bestätigungsnachricht umfassen. Vor dem Berechnen des Authentifizierungselements wird die erneute Schlüssel-Anfrage-Nummer inkrementiert.
  • Im vorliegenden Dokument wird auch eine erneute Schlüssel-Sequenz (rekey sequence) beschrieben, wobei die Schritte Folgendes umfassen: Empfangen einer erneuten Schlüssel-Anfrage, wobei die erneute Schlüssel-Anfrage eine erneute Schlüssel-Anfrage-Nummer und ein Authentifizierungselement enthält, Berechnen eines neuen Paars Übergangsschlüssel; und Senden einer Bereit-zum-Senden-und-Empfangen mit der Nachricht mit dem neuen Paar von Übergangsschlüsseln. Die erneute Schlüssel-Sequenz kann des Weiteren das Empfangen einer erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüssel-Bestätigungsnachricht, das Verifizieren, dass die erneute Schlüssel-Anfrage-Nummer größer ist als eine in den Cachespeicher aufgenommene erneute Schlüssel-Anfrage-Nummer, das Verifizieren aller Attribute eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüsselanfrage, das Aktualisieren einer in den Cachespeicher aufgenommenen erneuten Schlüssel-Anfrage-Nummer oder eine Kombination davon umfassen. Außerdem kann das Authentifizierungselement ein neues Initiator-Paar von Übergangsschlüsseln aufweisen, und die Schritte können des Weiteren das Vergleichen des neuen Paars von Übergangsschlüsseln mit dem neuen Initiator-Paar von Übergangsschlüsseln umfassen.
  • Noch weitere Aufgaben des vorliegenden Systems werden den Fachleuten auf diesem Gebiet aus der nachfolgenden Beschreibung ohne weiteres offensichtlich werden, in der ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung gezeigt und beschrieben ist, einfach anhand der Veranschaulichung eines der besten Modi, die zur Ausführung der Erfindung am besten geeignet sind. Wie realisiert werden wird, ist die Erfindung zu anderen unterschiedliche Ausführungsbeispielen in der Lage, und ihre einzelnen Details können in den verschiedenen offensichtlichen Ausführungsformen modifiziert werden. Dem gemäß werden die Zeichnungen und die Beschreibungen so betrachtet, dass sie von veranschaulichender Natur sind und keine Beschränkung darstellen.
  • KURZE BESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNG
  • Die beigefügten Zeichnungen, die hier aufgenommen sind und einen Teil der Beschreibung bilden, veranschaulichen mehrere Ausführungsformen der vorliegenden Erfindung, und zusammen mit der Beschreibung dienen sie dazu, die Prinzipien der Erfindung zu erläutern, wobei in den Zeichnungen:
  • 1 ein Blockdiagramm ist, das eine Schlüsselhierarchie veranschaulicht, wie sie von der vorliegenden Erfindung in Betracht gezogen wird;
  • 2 eine Tabelle der Subnet Context Manager Akquisition von Netz-Sitzungsschlüsseln ist;
  • 3 eine Tabelle ist, die authentifizierte Schlüsselverwaltungs-Selektorwerte veranschaulicht;
  • 4 eine Tabelle ist, die in den Cachespeicher aufgenommene Berechtigungsnachweise eines Subnet Context Managers veranschaulicht;
  • 5 eine Tabelle ist, die die von einem Zugriffspunkt in den Cachespeicher aufgenommenen Berechtigungsnachweise veranschaulicht;
  • 6 ein Blockdiagramm ist, das die Schlüssel veranschaulicht, die zur Sicherung von Nachrichten zwischen Verbindungen verwendet werden;
  • 7 ein Ablaufdiagramm ist, das die Schritte für die Registrierung eines AP bei einem SCM veranschaulicht;
  • 8 ein Beispiel einer erfolgreichen Lightweight Extensible Authentication Protocol Authentifizierung und -Registrierung eines mobilen Knotens zeigt;
  • 9 ein Beispiel einer erfolgreichen Non-Lightweight Extensible Authentication Protocol Authentifizierung und -Registrierung eines mobilen Knotens zeigt;
  • 10 ein Ablaufdiagramm ist, das die Sequenz veranschaulicht, die ausgelöst wird, um eine Schlüsselerstellung nach einer erfolgreichen Authentifizierung zu vollenden;
  • 11 ein beispielhafter Schlüsseldeskriptor für eine erneute Schlüssel-Sequenz ist;
  • 12 ein Blockdiagramm ist, das eine erneute Schlüssel-Sequenz zeigt;
  • 13 ein Beispiel für das Authentifizierungselement ist, das in einer erneuten Verbindungsanfrage enthalten ist, die von einem mobilen Knoten gesendet wird;
  • 14 ein Beispiel des Formats der Antwort auf die erneute Verbindungsanfrage durch den Zugriffspunkt ist;
  • 15 ein Blockdiagramm ist, das die Kommunikationen veranschaulicht, die zwischen den verschiedenen Netzkomponenten für eine erfolgreiche erneute Verbindung des mobilen Knotens mit einem neuen Zugriffspunkt stattfinden;
  • 16 ein Blockdiagramm ist, das ein Verfahren zur Übertragung von Schlüsseln für alte mobile Knoten oder mobile SSN-Knoten zeigt;
  • 17 ein Blockdiagramm ist, das einen Topologiebaum für eine volle Implementierung einer Ausführungsform der vorliegenden Erfindung beispielhaft darstellt;
  • 18 eine Tabelle ist, die das Format einer WLCCP-Knoten-ID veranschaulicht;
  • 19 ein Blockdiagramm ist, das die interne Überbrückungsstruktur in einem Zugriffspunkt zeigt;
  • 20 ein Beispiel eines Ethernet-eingekapselten WLCCP-Kontextmanagement-Rahmens ist;
  • 21 ein Beispiel eines WLCCP-Nachrichten-Header ist;
  • 22 ein Beispiel eines TLV-Formats ist;
  • 23 ein Blockdiagramm ist, das zeigt, wie ein Hopwise Routing verwendet wird;
  • 24 ein Blockdiagramm ist, das eine Weiterreichung von einem ersten Zugriffspunkt zu einem zweiten Zugriffspunkt für einen mobilen Knoten in einer Campus-Topologie veranschaulicht;
  • 25 ein Beispiel der Nachrichtensequenzen für eine anfängliche Verbindung des mobilen Knotens ist;
  • 26 ein Beispiel der Nachrichtensequenzen für einen mobilen Knoten ist, der von einem ersten Zugriffspunkt zu einem zweiten Zugriffspunkt roamt;
  • 27 ein Blockdiagramm ist, das eine Weiterreichung eines Repeater-Zugriffspunkts von einem ersten Zugriffspunkt zu einem zweiten Zugriffspunkt veranschaulicht;
  • 28a ein Beispiel der Nachrichtensequenzen für eine anfängliche Repeater-Zugriffspunkt-Verbindung ist;
  • 28b ein Beispiel der Nachrichtensequenzen für das Roaming eines Repeater-Zugriffspunkts von einem ersten Zugriffspunkt zu einem zweiten Zugriffspunkt ist;
  • 29 ein Beispiel einer Wurzel-Zugriffspunkt-Authentifizierung ist;
  • 30 ein Blockdiagramm ist, das definierte CTKs veranschaulicht;
  • 31 ein beispielhaftes Blockdiagramm einer AP-Authentifizierung und -Registrierung bei der Infrastruktur ist;
  • 32 ein beispielhaftes Blockdiagramm einer alternativen Sequenz ist, die für eine Pfadaktualisierung verwendet wird, die keine Registrierung benötigt;
  • 33 ein Beispiel einer Erstellung (Auffrischung) von CTKs zwischen einem Zugriffspunkt und einem Subnet Context Manager ist;
  • 34 ein Blockdiagramm ist, das eine beispielhafte Nachrichtensequenz für eine erfolgreiche Authentifizierung und Registrierung eines mobilen Knotens bei einer vollen Topologie veranschaulicht;
  • 35 ein Blockdiagramm eines WLAN-Spannbaums für ein einzelnes Teilnetz ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • Durch die gesamte vorliegende Beschreibung hindurch sollen die gezeigten bevorzugten Ausführungsbeispiele und gezeigten Beispiele als Muster beispiele für die vorliegende Erfindung und nicht als Beschränkungen derselben betrachtet werden.
  • Die vorliegende Erfindung reduziert die Belastungen sowohl bezüglich der Nachrichten als auch bezüglich der Berechnungen, indem sie eine Schlüsselhierarchie verwendet, die die Authentifizierungssitzungszeit von der Schlüsselverwaltung abkoppelt. Aktuelle 802.11-Implementierungen binden die Authentifizierung und die Schlüsselverwaltung eng zusammen und erzwingen vollständige (erneute) Backend-Authentifizierungen, weil sie an die Cipher-Suite-Auswahl gebunden sind. Für das WEP kann dies bedingt durch die erneuten Schlüssel-Anforderungen des WEP zu sehr häufigen (erneuten) Authentifizierungen führen.
  • Die Schlüsselhierarchie definiert Schlüssel, die nach einer erfolgreichen Authentifizierung als Netz-Sitzungsschlüssel (NSKs) erstellt werden, die unabhängig von der 802.11-Cipher-Suite-Auswahl sind. Der NSK wird verwendet, um einen Haupt-Auffrischungsschlüssel (KRK) zur Authentifizierung von Schlüsselauffrischungsanfragen und einen Basis-Übergangsschlüssel (BTK) zu erzeugen, der als der Basisschlüssel dient, von dem paarweise Übergangsschlüssel (PTK) abgeleitet werden.
  • Nur PTKs sind an die ausgewählte 802.11 Cipher Suite gebunden und müssen somit auf der Grundlage der Cipher Suite Sicherheitspolitik verwaltet werden. Die Langlebigkeit des NSK wird von dem Authentifizierungsserver (AS) als ein Sitzungs-Timeout definiert, der nun als eine Funktion der NSK-Entropie gegenüber der ausgehandelten 802.11 Cipher Suite definiert werden kann. Das Ziel liegt darin, die Verwendung von Authentifizierungstypen nachdrücklich zu unterstützen, die zu einer Erzeugung eines dynamischen NSK mit einem noch größeren Teil an guter Entropie führen. Die neue Schlüsselhierarchie 100 ist in 1 dargestellt. Schlüssel (wie sie in 1 definiert sind) werden von einem zentralisierten Knoten verwaltet, der ein Subnet Context Management (SCM) (ein Teilnetz-Kontextmanagement) bereitstellt. Der SCM ist der 802.1X-Authentifikator für alle MNs und APs, der es erzwingt, dass sich alle MN-Knoten implizit registrieren. Der Registrierungsprozess gewährleistet, dass sich alle Knoten in dem Register erfolgreich verbunden haben, authentifiziert sind und Sicherheits-Berechtigungsnachweise aufweisen, die in einem Cachespei cher aufgenommen sind. Die Mechanismen, die in diesem Vorschlag beschrieben sind, sind als zentrale Schlüsselverwaltung (CCKM) definiert und werden als ein proprietärer Wert in dem authentifizierten Schlüsselverwaltungs-(AKM)-Informationselement ausgehandelt, wie dies in den aktuellen SSN- und TGi-Entwürfen definiert ist.
  • Unter Bezugnahme auf 1 ist die Spitze der Hierarchie der NSK 102. Der NSK 102 wird implizit als ein Resultat einer erfolgreichen EAP-Authentifizierung abgeleitet. Aus dem NSK 102 wird der KRK und der BTK erzeugt, wie dies in Block 104 gezeigt ist. Der KRK und der BTK werden unter Verwendung einer PRF mit dem NSK, der BSSID, der STA-ID, der NonceSTA und der NonceSCM als Parameter generiert. Der 128-Bit-NRK 106a und der 256-Bit-BTK 106b werden aus dem NSK abgeleitet. Aus dem BTK 106b wird der PTKSN, unter Verwendung einer PRF mit dem BTK, der RN und der BSSID als Parameter erzeugt. Von dem PTK werden der 802.1X-Verschlüsselungsschlüsel 110 (16 Bytes), der 802.1X-MIC-Schlüssel 112 (16 Bytes), der 802.11-Verschlüsselungsschlüssel 114 (16 Bytes) und die AP-MIC-Schlüssel 116 (nur TKIP) abgeleitet. Die AP-MIC-Schlüssel 16 umfassen des Weiteren einen Tx-Schlüssel 118a, 8 Bytes, und einen Rx-Schlüssel 118b, ebenfalls 8 Bytes.
  • Während der Authentifizierungsmechanismus, z. B. die 802.1X EAP-Authentifizierung, unverändert bleibt, führt die vorliegende Erfindung ein neues Schlüsselverwaltungsschema ein: die CCKM. Diese neue Fähigkeit wird unter Verwendung der SSN IE oder der RSN IE bekannt gegeben und ausgehandelt, was hier weiter unten beschrieben wird.
  • Eine Implementierungserwägung der vorliegenden Erfindung ist die Gewährleistung der Unabhängigkeit von den Authentifizierungsmechanismen. Wie TGi und SSN, so setzt auch die vorliegende Erfindung das Vorhandensein eines (NSK) Schlüssels nach einer erfolgreichen Authentifizierung voraus. Aus Sicherheitsgründen sollte dieser Schlüssel im Allgemeinen dynamisch konfiguriert und verwaltet werden. Die vorliegende Erfindung stellt kurze NSKs bereit und stellt eine Einrichtung zur Streckung dieser Schlüssel auf die benötigte Länge von 384 Bits bereit. Obwohl davon stark abgeraten wird, kann dieses Design auch die Verwendung von vorab gemeinsam genutzten Schlüsseln, die als die NSKs definiert werden sollen, zulassen.
  • Die CCKM muß Kenntnis von dem Authentifizierungstyp haben, der verwendet wird, um den NSK interpretieren und abrufen zu können. 2 ist eine Tabelle 200, die beschreibt, wie der NSK durch den SCM abgeleitet und abgerufen wird. Die Spalte 202 beschreibt den 802.1X-Authentifizierungstyp. Die Spalte 204 beschreibt die NSK-Berechnung. Die Spalte 206 zeigt die Länge des NSK in Bytes, und die Spalte 208 beschreibt, wie der SCM den NSK erlangt.
  • Authentifizierungstypen, die nicht gegenseitig dynamische Schlüssel ableiten, wie etwa EAP-MD5, beruhen darauf, dass sie einen statischen Schlüssel aufweisen, der in einer ähnlichen Weise konfiguriert wird, wie ältere Systeme die Preshared Key Authentication unterstützen. Diese statischen Konfigurationen werden herkömmlicherweise an dem AP verwaltet. Um eine Rückwärtskompatibilität zu erlauben, müssen diese Konfigurationen fortbestehen. Auf diese Weise wird die CCKM diese NSK-Typen von dem ersten verbundenen AP als den Sitzungs-NSK anfordern.
  • Die vorliegende Erfindung zieht ein schnelles Weiterreichungssystem und Weiterreichungsverfahren in Betracht (die hier als CCKM bezeichnet werden), die auf einem zentralisierten Dienst, einem Subnet Context Manager (SCM) basieren, um einen nahtlosen sicheren Kontexttransfer zu ermöglichen, der für den Übergang eines MN von einem AP zu einem neuen benötigt wird. Zur Absicherung solcher Transfers verlässt sich der SCM darauf, dass sich sowohl die APs als auch die MNs in jedem Knoten gegenseitig mit dem SCM authentifizieren. Nach einer erfolgreichen Authentifizierung muß ein gemeinsames Geheimnis (shared secret) erstellt werden: ein Netz-Sitzungsschlüssel (NSK).
  • Die Verwendung des NSK weicht von der Verwendung des bei der Authentifizierung erstellten Schlüssels in der IEEE 802.11 TGi (sowie auch SSN) ab. TGi/SSN beziehen sich auf diesen Schlüssel als einen PMK, der wiederum als Schlüsselmaterial verwendet wird, um sowohl die paarweisen 802.1X-Übergangsschlüssel (PTKs) als auch die paarweisen 802.11-Übergangsschlüssel (PTKs) abzuleiten. Obwohl die CCKM auch weiteres Schlüsselmaterial von dem NSK ableitet, werden die abgeleiteten Schlüssel dazu verwendet, Über gangsschlüsselanfragen zu authentifizieren und PTKs abzuleiten. Die Schlüsselhierarchie ist in 1 dargestellt.
  • Durch das Definieren eines Schlüsselrotationsschemas erlaubt die CCKM dem MN, den neuen PTK vor der erneuten Verbindung abzuleiten. Der MN kann den PTK für den neuen AP ableiten, wenn er einmal die neue BSSID bestimmt hat, zu der er roamt, und bevor die erneute Verbindungsanfrage übertragen wird. Auf diese Weise kann der MN nach einer erneuten Verbindungsanfrage bereit sein, Unicast-Kommunikationen zu dem neuen AP zu schützen, muß aber die erneute Verbindungsantwort des AP als Bestätigung abwarten, dass beide Parteien nun Unicast-Kommunikationen absichern können. Die erneute Verbindungsantwort des AP enthält auch die Lieferung der Broadcast-Schlüssel (GTK), um vollständig geschützte Kommunikationen zu ermöglichen.
  • Für das allgemeine PTK-Rekeying führt die CCKM EAPOL-Schlüsseldeskriptor-Verbesserungen ein, die denen ähnlich sind, die in SSN/TGi definiert sind, um ein CCKM-Rekey zu bewirken.
  • Unter Verwendung jeweils entweder der SSN- oder der TGi-Informationselemente SSN IE und RSN IE können die CCKM-Fähigkeiten ausgehandelt werden. Im Augenblick erlauben beide Spezifikationen die Aushandlung bezüglich einer authentifizierten Schlüsselverwaltungs-Suite. Der Suite-Selektor kapselt sowohl einen Authentifizierungs- als auch einen Schlüsselverwaltungsmechanismus ein, die zugewiesenen Werte werden in der Tabelle 300 in 3 beschrieben. Die Spalte 302 ist der Organization Unique Identifier (OUI), die Spalte 304 ist der Typ, der dem OUI in Spalte 302 entspricht, und die Spalte 306 ist die Beschreibung für den OUI in der Spalte 302.
  • Sowohl der AP als auch der MN müssen für die Interoperabilität die CCKM unterstützen. Der AP muß die CCKM-Fähigkeit bekannt geben, indem er einen neuen Wert in dem Authenticated Key Management Suite Selector (authentifizierten Schlüsselverwaltungs-Suite-Selektor) verwendet, die dies in SSN v 0.21 und in dem TGi-Entwurf 2.3 definiert ist.
  • Die CCKM-Fähigkeit muß in Beacons bekannt gegeben werden und während einer Probe-Antwort und einer Verbindungsanfrage ausgehandelt werden. Eine erfolgreiche Aushandlung der CCKM ermöglicht die zentralisierte Schlüsselverwaltung, die in der vorliegenden Patentschrift definiert wird. Das Ermöglichen der CCKM impliziert auch die Aktivierung des SCM.
  • Der SCM ist so ausgelegt, dass er eine Kontextsteuerung für ein Teilnetz bereitstellt und Client-Kontextransfers bei einem Roaming bewirkt. Der SCM ist ein Modul, das in einem AP koexistieren kann, ein selbständiger Server sein kann, oder in einem AS koexistieren kann. Obwohl der SCM so ausgelegt ist, dass er eine vollständige Mobilität zwischen Teilnetzen bewirkt, verwendet dieses Design lediglich die Komponenten, die benötigt werden, um die teilnetzinterne Mobilität zu bewirken. Diese Elemente umfassen:
    • – ein Repositorium, das Sicherheits-Berechtigungsnachweise des authentifizierten Knotens aufbewahrt, die den NSK, den Sitzungs-Timeout und die Sicherheitspolitik des Knotens enthalten.
    • – die Sicherheits-Berechtigungsnachweise eines MN umfassen einen NSK, eine SSID, ein VLAN, einen Sitzungs-Timeout, eine assoziierte BSSID und möglicherweise auch den Authentifizierungsmechanismus, den Schlüsselverwaltungsmechanismus und die Cipher Suite, die bei der Verbindung ausgehandelt wurden. Die Berechtigungsnachweise werden verwendet, um die Sitzung vor einem Kontexttransfer zu validieren und bevor der PTK geliefert werden kann.
    • – die Sicherheits-Berechtigungsnachweise eines AP umfassen einen NSK, einen Sitzungs-Timeout und eine Liste der verbundenen MNs
    • – ein Kontextrepositorium, das Sicherheits-Berechtigungsnachweise für alle registrierten Knoten enthält
    • – Dienste, die benötigt werden, um das Kontextrepositorium für registrierte MNs und APs zu verwalten
    • – Dienste zur Identifizierung und Aktivierung des SCM als den Authentifikator für alle APs und MNs
    • – der SCM stellt Dienste bereit, um den neuen AP automatisch mit den Sicherheits-Berechtigungsnachweisen der MNs ohne eine Client-Interaktion zu versorgen
    • – Dienste zur Erzeugung und Sicherung der Lieferung von PTKs auf der Basis der Sicherheitspolitik.
  • Der SCM unterhält einen Cachespeicher aller registrierter MN-Kontexte innerhalb eines gegebenen Teilnetzes, einschließlich der NSKs der MNs (gezeigt in 4). Die im Cachespeicher aufgenommenen Berechtigungsnachweise für einen AP sind geringfügig anders und sind in 5 beschrieben. Unter Bezugnahme auf 4 listet die Spalte 402 den SCM-Cachespeicher der MN-Berechtigungsnachweise auf und umfasst die Felder Zustand 408, STA Adr 410, Authentifizierungstyp 412, Schlüsselverwaltungstyp 414, Sitzungs-Timeout 416, KRK 418, BTK 420, RN 422, SSID 424, VLAN ID 426, BSSID 428, Cipher 430, NSK-Schlüssellänge 432, NSK 434, Tx-Schlüssellänge 436 und Tx-Schlüssel 438. Die Länge in Bytes und eine Beschreibung dieser Felder ist jeweils in den Spalten 404 und 406 gegeben. Unter Bezugnahme auf 5 umfassen die in dem Cachespeicher aufgenommenen AP-Berechtigungsnachweise den Zustand 508, die Knoten-ID 510, den NSK 512, den Sitzungs-Timeout 514, den CTK 516 und den Schlüsselsequenzzähler 518, wie in Spalte 502 gezeigt ist. Die Länge und eine Beschreibung dieser Felder ist jeweils in den Spalten 504 und 506 bereitgestellt.
  • Der SCM erstellt gemeinsame Geheimnisse (Shared Secrets) sowohl mit dem MN als auch mit den APs. Er verwendet den Haupt-Anfrageschlüssel (KRK) als das gemeinsame Geheimnis mit den MNs, um Schlüsselanfragen zu authentifizieren. Der Kontexttransferschlüssel (CTK) ist das gemeinsame Geheimnis mit den APs, um Kommunikationen zwischen dem SCM und dem AP zu schützen. Die Vertrauensbeziehung ist in 6 veranschaulicht.
  • CTKs werden von dem SCM an den AP für den Schutz von Verbindungskommunikationen verteilt. Es sei angemerkt, dass zwar vorgeschlagen worden ist, dass NSKs für den Schutz von Kommunikationen von einem AP zu einem SCM verwendet werden sollen, dass dies aber einen kürzeren Sitzungs-Timeout und vollständige erneute Authentifizierungen zu dem AS erzwingen würde, wenn Verbindungsschlüssel aktualisiert werden müssen.
  • 6 zeigt die Schlüssel, die benutzt werden, um eine Kommunikation zwischen zugewiesenen Verbindungen zu schützen. Es sei angemerkt, dass BTKs nicht verwendet werden, um Nachrichten direkt zu schützen, sondern statt dessen dazu verwendet werden, PTKs abzuleiten, die verwendet werden, um Kommunikationen zwischen einem AP und einem MN zu schützen. Wie in 6 gezeigt ist, verwendet der AS 602 NSK0 606, um mit dem SCM 604 zu kommunizieren. Der SCM 604 kommuniziert mit dem AP1 608 und dem AP2 610 jeweils unter Verwendung der Schlüssel CTK1 612 und CTK2 614. Der AP1 608 kommuniziert mit dem MN3 616 und dem MN4 618 jeweils unter Verwendung des PTK3 622 und PTK4 624, während der AP2 610 mit dem MN5 mit PTK5 628 kommuniziert. Der SCM 604 kann auch direkt mit den mobilen Knoten MN3 616, NM4 618 und MN5 620 jeweils unter Verwendung des KRK6 630, KRK7 632 und KRK8 634 kommunizieren.
  • PTKs werden auf der Grundlage eines erneuten Schlüssel-Sequenz-Zählers und BTKs abgeleitet und aufgefrischt, wie sie auf der Grundlage des NSK definiert oder aufgefrischt werden, wie dies hier weiter unten beschrieben wird.
  • Durch das Verwenden der Beringschen SCM-Fähigkeiten stellt das schnelle Weiterreichungsdesign eine skalierbare Infrastruktur bereit, die benötigt wird, um ein Roaming zwischen Teilnetzen in einer nachfolgenden Freigabe bereitzustellen.
  • Die SCM-Dienste koexistieren in jedem AP, und somit kann ein Auswahlmechanismus so definiert werden, dass er die Auswahl eines AP als den SCM-Provider erlaubt.
  • Obwohl es keine anfängliche Unterstützung für eine Kommunikation von SCM zu SCM (z. B. lateral) geben wird, um Warmstarts zu ermöglichen, ermöglicht der Auswahlmechanismus immer noch einen Cold Standby. Zur Sicherung von Kommunikationen mit den MNs muß sich der AP zuerst bei seinem SCM authentifizieren und registrieren. Die Authentifizierung wird benötigt, um einen NSK zu erstellen, und die Registrierung erlaubt sichere Kommunikationen zwischen dem SCM und dem AP. Der NSK des AP wird von dem AP als ein Ergebnis einer erfolgreichen 802.1X-LEAP-Authentifizierung mit dem SCM abgeleitet; der Authentifizierungsserver liefert den NSK zu dem SCM über das Radius-MS-MPPE-Attribut ebenfalls als ein Ergebnis einer erfolgreichen Authentifizierung. Der AP identifiziert seinen SCM, indem er auf die SCM-Bekanntmachungs-Nachrichten lauscht.
  • Nach einer erfolgreichen Authentifizierung mit dem SCM muß sich der AP dann selber bei dem SCM als ein gültiger AP registrieren. Nach der Vorabregistrierung liefert der SCM einen Satz von CTKs zu dem AP, der verwendet wird, um WLCCP-Nachrichten zwischen dem SCM und dem AP sowohl zu verschlüsseln als auch zu authentifizieren.
  • Eine Nachrichtendarstellung, wie ein AP den benötigten NSK und die benötigten CTKs erstellt, ist in 7 gezeigt. Der AP muß auch den CTK erstellen, um zu gewährleisten, dass kein bösartiger AP eingeführt wird und entweder den NSK oder den CTK preisgibt. Der Authentifizierungsmechanismus ist demjenigen ähnlich, der für Brücken verwendet wird, wobei der Konfigurations-LEAP-Benutzername und das -Passwort für die Authentifizierung bei dem AS verwendet werden. Aufgaben, die von dem AP durchgeführt werden, sind in Spalte 702 aufgelistet, Aufgaben, die von dem SCM durchgeführt werden, sind in der Spalte 704 aufgelistet, und Aufgaben, die von dem AS durchgeführt werden, sind in der Spalte 706 aufgelistet.
  • Bei einigen Ausführungsbeispielen ist der SCM der 802.1X-Authentifikator für alle Knoten. Infolgedessen muß die CTK-Erstellung zwischen dem AP und SCM gegenseitig abgeleitet werden.
  • Zur Sicherung von Kommunikationen muß sich ein MN zuerst bei dem Netzwerk über eine 802.1X-EAP-Authentifizierung authentifizieren. Das Ergebnis einer erfolgreichen Authentifizierung erstellt einen NSK, der verwendet wird, um den KRK und den BTK zu erstellen, die verwendet werden, um jeweils Schlüsselauffrischungen zu authentifizieren und PTKs abzuleiten.
  • Ähnlich wie der SSN, so initiiert auch die CCKM eine Sitzung mit einem 4-Wege-Handshake, um den KRK und den BTK zu erstellen, um einen Schutz von Unicast-Verkehr zu ermöglichen. Diese Handshakes werden nur nach einer erfolgreichen Authentifizierung benötigt. Neue Schlüssel-Anfragen entweder nach einer erneuten Verbindung oder auf Grund eines allgemeinen Schlüsselverwaltungs-Rekeying (wie Cipher-Suite-Gegenmaßnahmen) benötigen nur einen authentifizierten 3-Wege-Handshake. 8 veranschaulicht eine erfolgreiche MN-LEAP-Authentifizierung und -Registrierung mit dem SCM.
  • Ein Mechanismus wird benötigt, um den NSK von den EAP-Supplicants weiterzureichen, die unabhängig von dem CCKM-Modul sind. Zum Beispiel wird bei einer Nicht-LEAP-EAP-Authentifizierung auf Windows-Plattformen der NSK der MNs für Gewöhnlich in dem EAP-Supplicant erzeugt und zu dem EAP-System weitergereicht. Das EAP-System wird dann den NSK zu dem CCKM-Modul weiterreichen. Da das gegenwärtige SSN-fähige EAP-System die CCKM als nicht-SSN-konform behandelt, wird es nur die 802.1X-EAP-Authentifizierung verarbeiten und den NSK nach einem EAP-Authentifizierungserfolg abwärts senden. In ähnlicher Weise werden Nicht-SSN-EAP-Supplicants einfach die 802.1X-EAP-Authentifizierung verarbeiten und den NSK nach einem EAP-Authentifizierungserfolg abwärts senden.
  • Aber es ist wahrscheinlich, dass der NSK erst dann geliefert werden wird, wenn die Gruppenschlüssel-Lieferungs-EAPOL-Schlüssel-Nachricht von dem AP empfangen worden sein wird. Deshalb muß, wie in 8 gezeigt ist, für eine Nicht-LEAP-EAP-Authentifizierung der AP eine zusätzliche 802.1X-EAPOL-Schlüssel-Nachricht mit einem Blind-Gruppenschlüssel direkt nach dem Senden einer EAP-Erfolgsnachricht zu der Station senden.
  • Es liegt bei der Implementierung in dem CCKM-Modul, dem AP anzuzeigen, dass er eine zusätzliche EAPOL-Schlüssel-Nachricht senden muß. Diese Information könnte während dem Verbindungsanfrage-RSNIE ausgehandelt werden. Eine alternative Lösung liegt darin, nach der EAP-Erfolgsnachricht immer die Blind-EAPOL-Schlüssel-Nachricht zu senden. Das CCKM-Modul kann den Blindschlüssel ignorieren, wenn es den NSK bereits besitzt, und kann die wirklichen Schlüssel nach dem Vier-Wege-Handshake erstellen.
  • Aber bei älteren Systemen (Legacy-Systemen) werden die Verbindungsaustausche immer eine vollständige Authentifizierung und einen 4-Wege-Handshake auslösen. Der Empfang der CCKM-Rekey-Elemente wird ignoriert werden.
  • Ein zusätzlicher 2-Wege-Handshake wird verwendet, um die Multicast-/Broadcast-Schlüssel (GTK) schlüsselmäßig erneut auszuhandeln (rekey). Das Rekey-Protokoll für die GTK-Verwaltung ist gleich dem, das in TGi und SSN spezifiziert ist. Der 2-Nachrichten-Handshake wird von dem AP initiiert, um den GTK über eine verschlüsselte EAPOL-Schlüssel-Nachricht zu liefern. Der aktuelle PTK wird verwendet, um diese EAPOL-Schlüssel-Nachrichten zu schützen.
  • In einem CCKM-fähigen System wird ein AP von dem SCM Sicherheits-Berechtigungsnachweise immer während einer Vorabregistrierungsanfrage/-antwort anfordern. Verbindungen implizieren eine Sitzungsinitiierung, und infolgedessen kann nach einer Verbindung, wenn Sicherheits-Berechtigungsnachweise in einem SCM gültig sind und die CCKM ausgehandelt ist, eine 802.1X-Authentifizierung umgangen werden. Aber ein neuer KRK und neue BTKs müssen erstellt werden. Wenn keine Sicherheits-Berechtigungsnachweise existieren, dann muß der AP eine vollständige Authentifizierung zwischen dem MN und dem AS erwarten.
  • Nach einer erfolgreichen Authentifizierung wird die Sequenz, die in 10 gezeigt ist, ausgelöst, um die Schlüsselerstellung zu vervollständigen, und sie ergibt die notwendigen PTKs, die verwendet werden, um Pakete zwischen dem AP und dem MN zu beschützen.
  • Da dem AP auch der Sitzungs-Timeout des MN bereitgestellt wird, wird dem AP eine Verhaltensregel zur Verwaltung von (erneuten) Authentifizierungen zugewiesen. Ähnlich wie bei aktuellen Implementierungen können die APs (erneute) Authentifizierungen auslösen, bevor der Sitzungs-Timeout abläuft, und können auch die Aktualisierung der KRK- und BTK-Auffrischung verwalten, wie dies hier definiert ist.
  • Entweder der MN oder der AP können einen PTK-Rekey auslösen. Bedingungen, unter denen jeder Knoten einen Rekey anfordern kann, umfassen: TKIP-Versagen, vor allem in Michael-Gegenmaßnahmen; Erschöpfung von IV (hauptsächlich bei WEP) und Gegenmaßnahmen, wenn der Knoten das Gefühl hat, dass der PTK preisgegeben worden ist.
  • Der Rekey-Austausch bzw. der erneute Schlüssel-Austausch ist ein 3-Nachrichten-EAPOL-Schlüssel-Handshake. Ein neuer Schlüsseldeskriptor wird definiert, um einen sicheren erneuten Schlüssel-Austausch zuzulassen, der in 11 gezeigt ist. Die Felder sind wie folgt definiert:
    Schlüsselinformation (Key Information) 1102: läßt erkennen, ob es sich um eine Anfrage (Request) (0), eine Antwort (Response) (1) oder eine Bestätigung (Confirm) (3) handelt;
    Status 1104: wird von dem Antwortenden und dem Bestätigenden (Confirmer) verwendet. Ein Null-Wert bedeutet Erfolg; Nicht-Null bedeutet, dass der Rekey fehlgeschlagen ist und entweder eine vollständige KRK-, BTK- oder Beendigung der Authentifizierung aufgerufen werden muß;
    EAPOL-Wiedergabe-Zähler (EAPOL Replay Counter) 1106: dies ist der EAPOL-Schlüssel-Nachrichten-Zähler, der auch dazu verwendet wird, vor Nachrichtenwiedergaben zu schützen;
    Reserviertes Feld 1108: ein Extra-Byte wird hinzugefügt, um das Element besser auszurichten;
    Schlüssel-ID (Key ID) 1110: 1-Byte-Feld, das die Zuweisung der Schlüsselkennung (0, 1, 2 oder 3) gespeichert hat, es muß mit der augenblicklich zugewiesenen Schlüssel-ID übereinstimmen;
    MN-ID 1112: die MAC-Adresse des Client;
    BSSID 1114: Die MAC-Adresse des AP;
    RN 1116: die erneute Schlüssel-Anfrage-Nummer;
    MIC 1118: Authentifizierungselement, das den aktuellen PTK verwendet. Die MIC ist definiert als:
    MICreques = HMAC-MD5(PTK,
    Key Info ∥ EAPOL Replay Ctr ∥ Key ID ∥ MN-ID ∥ BSSID ∥ RN),
    MICresponse = HMAC-MD5(PTK,
    Key Info ∥ EAPOL Replay Ctr ∥ Key ID ∥ MN-ID ∥ BSSID ∥ RN ∥ Status),
    MICconfirm = HMAC-MD5(PTK,
    Key Info ∥ EAPOL Replay Ctr ∥ Key ID ∥ MN-ID ∥ BSSID ∥ RN ∥ Status).
  • Die Rekey-Sequenz bzw. erneute Schlüsselsequenz 1200 ist in 12 gezeigt. Die linke Spalte 1202 zeigt Aufgaben, die von dem Initiator durchgeführt werden, während die rechte Spalte 1204 Aufgaben zeigt, die von dem Antwortenden durchgeführt werden.
  • Beim Block 1206 verlangt der Zustandsübergang nach einem neuen PTK. Der Initiator setzt RN = RN + 1, den neuen PTK = PTKRN+1 und die Berechne MICrequest. Die Übertragung zu dem Antwortenden wird angehalten, bis eine gültige Antwort oder ein Timeout erreicht wird. Der Empfang mit PTKRN muß zugelassen werden. Die Anfrageverwendung von PTKRN+1 in der Schlüssel-ID wird gesendet.
  • Der Antwortende empfängt die Anfrage. Wenn, wie bei Block 1208 gezeigt ist, die neue RN der MICrequest nicht größer als die im Cachespeicher aufgenommene RN ist, oder wenn irgendein Attribut in der EAPOL-Schlüssel-Anfrage ungültig ist, aktualisiert der Antwortende den PTK nicht oder sendet eine Antwort mit einem Nicht-Null-Status. Aber wenn, wie im Block 1210 gezeigt ist, die MICrequest-RN und die EAPOL-Schlüsselattribute gültig sind, wird der Antwortende die RN aktualisieren und PTKRN+1 berechnen, die MN-Sendewarteschlange leeren, PTKRN+1 installieren und ein Bereit-zum-Senden-und-Empfangen mit dem PTKRN+1 antworten (wenn die Antwort gesendet ist, werden empfangene Pakete von dem MN, der den PTKRN verwendet, nicht richtig entschlüsselt werden).
  • Der Initiator empfängt dann die Antwort des Antwortenden. Wie im Block 1212 gezeigt ist, wird dann, wenn die MICresponse oder irgendein EAPOL-Schlüsselattribut ungültig ist, der Rekey abgebrochen, und der Initiator wird es erneut versuchen. Aber wenn, wie in Block 1214 gezeigt ist, die MICresponse und die EAPOL-Schlüsselattribute gültig sind, dann installiert der Initiator PTKRN+1 und ist bereit für das Senden und Empfangen mit dem PTKRN+1. Der Initiator sendet dann eine EAPOL-Schlüssel-Bestätigungsnachricht.
  • Der Antwortende empfängt dann die EAPOL-Bestätigungsnachricht. Wie in Block 1216 gezeigt ist, wird der Antwortende dann, wenn die MICconfirm oder irgendein Attribut in der EAPOL-Schlüssel-Bestätigung ungültig ist, entweder einen weiteren Rekey auslösen, feststellen, dass es sich um eine Manipulation handelt, und wird die Verbindung beenden oder deren Authentifizierung auflösen. Wie in Block 1218 gezeigt ist, wird die Verbindung dann, wenn die EAPOL-Bestätigung gültig ist, nun durch die Verwendung des PTKRN+1 geschützt.
  • Im Falle eines erfolgreichen Rekey muß der AP den RN-Wert des SCM für den MN synchronisieren. Es wird empfohlen, dass die Synchronisation bei jedem Rekey durchgeführt wird. Um den SCM zu aktualisieren, wird eine WLCCP_CONTEXT-Nachricht (WLCCP-Kontext-Nachricht) mit einer WTLV_UPDATE_RN (WTLV-Aktualisierungs-RN) zu dem SCM gesendet.
  • Die obige Beschreibung setzt voraus, dass weder die Anfrage, noch der Antwortende in der Lage ist, mehrere Schlüssel-IDs zu verwenden, um PTKs zwischenzuspeichern. Aber das Protokoll der vorliegenden Erfindung lässt diese Funktion zu und ermöglicht somit einen glatteren Übergang während einer Rekey-Operation. Das heißt, der Anfragende kann den PTKRN+1 in einer neuen Schlüssel-ID installieren und infolgedessen den Empfang von Paketen unter entweder PTKRN oder PTKRN+1 ermöglichen. In ähnlicher Weise könnte der Antwortende den Schlüssel in der alternativen spezifizierten Schlüssel-ID installieren und ebenfalls eine Übertragung und einen Empfang unter beiden Schlüsseln erlauben. Die endgültige Bestätigung ist, die Übertragung und den Empfang unter dem aktuellen (alten) PTKRN anzuhalten.
  • Die CCKM verwendet den SSN- und TGi-Stil des Rekeying für die Aktualisierung von Multicast-(GTK)-Schlüsseln und wird deshalb in der vorliegenden Patentschrift nicht definiert. Bezüglich Einzelheiten von Gruppen-/Brodcast-Schlüssel-Aktualisierungen wird Bezug auf den neuesten TGi-Entwurf genommen.
  • Um den erneuten Verbindungs-Handshake zu verkürzen, minimiert das vorliegende Design die Anzahl an Paketen, die zwischen der Client-Station und dem AP ausgetauscht werden, auf zwei Pakete – erneute Verbindungsanfrage und erneute Verbindungsantwort. Unter Bezugnahme auf 13 wird ein neues proprietäres Element 1300 eingeführt, um die Weiterreichung in den erneuten Verbindungs-Nachrichten zu ermöglichen. Das Element in der erneuten Verbindungs-Anfrage umfasst die erneute Schlüssel-Anfrage-Nummer (RN) und ein authentifiziertes Element, wobei:
    MICMN 1314 = HMAC-MD5(KRK, MN-ID ∥ BSSID ∥ RSNIEMN ∥ Timestamp ∥ RN) und
    die Element ID 1302 ein von Cisco definiertes Element ist, dessen Wert 0x9c ist
    die Länge 1304 die Länge der CCKM-Element-Anfrage sein sollte (z. B. 24 Bytes)
    OUI 1306 00:40:96 sein sollte
    der OUI 1308 Typ 0 sein sollte
    die MN-ID (nicht gezeigt) die MAC-Adresse des MN ist,
    die BSSID (nicht gezeigt) die MAC-Adresse des AP ist,
    der Timestamp (Zeitstempel) 1310 der aktuelle TSF-Timer-Wert ist,
    RN 1312 die erneute Schlüssel-Anfrage-Nummer ist,
    RSNIEMN (nicht gezeigt) die anfragende Sicherheitspolitik des MN ist (z. B. AKM und Cipher-Suite-Aushandlung);
    CCKM (nicht gezeigt) in dem AKM-Selektor der RSNIEMN spezifiziert sein muß.
  • Die erneute Verbindungs-Antwort umfassen ein neues Element 1400, das die Anfrage authentifiziert, die Verwendung von PTKRN bestätigt und den Multicast-Schlüssel liefert, wie dies in 14 gezeigt ist.
  • Dabei ist:
    EGTK = RC4(RN ∥ PTKRN, GTK)
    MICAP 1402 = HMAC-MD5(PTKRN, MN-ID ∥ RSNIEAP ∥ RN ∥ KeyIDunicast ∥ Key-IDmulticast ∥ Key length ∥ EGTK)
  • Nun wird Bezug auf 15 genommen, in der ein Beispiel einer erfolgreichen erneuten Verbindung eines MN mit einem neuen AP gezeigt ist. Die Weiterreichung findet in dem erneuten Verbindungs-Anfrage/-Antwort-Austausch statt. Der MN 1502 muß eine CCKM 1528 in der RSNIE 1530 enthalten, um die schnelle Weiterreichung verwenden zu können. Noch wichtiger ist, dass die Sicherheitspolitik, die von dem MN 1502 bei der erneuten Verbindung ausgehandelt worden ist, mit derjenigen übereinstimmen muß, die bei der anfänglichen Verbindung spezifiziert worden ist. Der SCM 1506 muß validieren, dass der Wert der anfragenden RN 1532 größer als der vorhergehende Wert ist. Der Zeitstempel, der in der Anfrage bereitgestellt ist, muß ebenfalls innerhalb eines konfigurierbaren Werts des TSF-Timers (nicht gezeigt) des AP liegen; der Zeitstempel ist enthalten, um zu gewährleisten, dass diese Anfrage neu ist. In einer Antwort muß der AP 1504 auch seinen TSF-Timer-Wert in dem CCKM-Antwortelement bereitstellen, um dem MN 1502 zu gewährleisten, dass die Antwort ebenfalls neu ist.
  • Wenn der AP 1504 eine erneute Verbindungs-Anfrage empfängt und die CCKM ausgehandelt ist, muß er den SCM 1506 um eine Validierung der Sicherheits-Berechtigungsnachweise bitten und die RN und den BTK erfassen, bevor er den PTKRN erzeugen kann. Die Anfrage wird mittels einer WTLV_SECURE_CONTEXT-Anfrage an den SCM 1506 gestellt. Wenn der SCM 1506 die Berechtigungsnachweise nicht validieren kann, dann wird er nichts liefern und wird einen Nicht-Null-Status bereitstellen, der einen Fehlschlag anzeigt. Bei einem erfolgreichen Transfer wird der SCM 1506 die RN und den BTK in einer verschlüsselten und authentifizierten WTLV_SECURE_CONTEXT-Antwort liefern. Die Validierung der Sicherheits-Berechtigungsnachweise verhindert, dass sich ein Insider mit einer anderen SSID schnell erneut verbinden kann.
  • Bei einem erfolgreichen Kontexttransfer geht der AP 1504 weiter, um den PTK so zu erzeugen, wie dies hier weiter unten beschrieben ist. Er wird dann den PTK verwenden, um das neue Informationselement zu verschlüsseln und zu authentifizieren, um den PTK zu bestätigen und den Multicast-Schlüssel GTK sicher zu liefern.
  • Wenn die CCKM ausgehandelt ist, aber kein proprietäres Element bereitgestellt wird, kann der AP 1504 immer noch eine Anforderung bezüglich Sicherheits-Berechtigungsnachweisen stellen. Wenn die Berechtigungsnachweise gültig sind, dann wird eine vollständige WTLV_INIT_SESSION-Erstellung eines neuen KRK und eines neuen BTK ausgelöst, und nach einem erfolgreichen 4-Wege-Austausch werden der KRK und der BTK gegenseitig von dem SCM 1506 und dem MN 1502 abgeleitet, und RN wird auf 1 zurückgesetzt. Wenn keine Berechtigungsnachweise vorhanden sind oder die Anfrage an den SCM fehlschlägt, dann hat der AP die Wahl, eine vollständige (erneute) Authentifizierung zu erzwingen.
  • Durch die Verwendung einer Sequenz des PTK ist die Client-Station bereit, Unicast-Pakete zu entschlüsseln, bevor der Client die erneute Verbindungsanfrage initiiert. Der Client bestätigt seine Identität in der erneuten Ver bindungsanfrage, indem er einen inkrementierenden Authentifikator (Anfragenummer) und eine entsprechende Authentifizierung (MIC) verwendet. Der AP 1504 verwendet die erneute Verbindungsantwort, um seine Identität zu bestätigen, und um die Multicast-Schlüsselinformation (GTK) zu der Client-STA huckepack zu nehmen.
  • Für jeden schnellen erneuten Verbindungsversuch wird eine einzigartige Anfragenummer (RN) verwendet werden. Bei jedem schellen erneuten Verbindungsversuch wird der Client die RN inkrementieren. Der SCM verhindert eine Wiedergabe (Replay) einer schnellen erneuten Verbindungsanfrage, indem er die letzte RN, die von dem Client verwendet wurde, im Cachespeicher speichert, und indem er jegliche Anfrage zurückweist, für die die RN kleiner oder gleich der letzten, in den Cachespeicher aufgenommenen RN ist.
  • Es sei angemerkt, dass die Ableitung der Berechtigungsnachweise und der Schlüsselinformationen die BSSID umfasst, um Wiedergabeversuche quer durch unterschiedliche APs zu verhindern. Zum Beispiel könnte es ein Hacker ohne die BSSID versuchen, eine schnelle erneute Verbindungsanfrage für einen AP wiederzuverwenden, um sich mit einem zweiten AP zu verbinden. Welcher Versuch den SCM zuerst erreichen wird – der Hacker oder der wirkliche Client – hängt von den Verzögerungen durch das Netz ab.
  • In einem anderen Ausführungsbeispiel kann die Fähigkeit enthalten sein, Sicherheits-Berechtigungsnachweise zu den registrierten APs weiterleiten zu können. Bei Netzen mit einer großen Latenzzeit zwischen dem AP 1504 und dem SCM 1506 können die SCM-1506-Informationen auch bei dem AP 1504 in einen Cachespeicher aufgenommen werden. In diesem Fall könnte der AP 1504 alle Berechnungen durchführen, die normalerweise an dem SCM 1506 durchgeführt würden. Der AP 1504 kann die Authentifizierung eines Client verifizieren, ohne dass er den SCM 1506 bitten muß, die neueste RN zu erhalten, da die letzte RN, die für eine bestimmte BSSID verwendet wurde, ausreichend ist, um eine Wiedergabe zu verhindern. Der AP 1504 sollte eine Aktualisierung zu dem SCM 1506 senden, um zu gewährleisten, dass der SCM 1506 die neuesten RN-Informationen besitzt – dies ist vor allem dann wichtig, wenn der AP die Informationen veralten lassen und die Informationen von dem SCM später anfordern soll.
  • Der Prozess für die erneute Verbindung startet bei 1510, wobei ein MN 1502 eine RN zustellt und einen neuen PTKRN erzeugt. Wie bei 1512 gezeigt ist, sendet der MN 1502 die erneute Verbindungsanfrage (Re-Assoc Req) zu dem AP 1512, die die RN 1532, die RSNIEMN 1530 mit der CCKM 1528 als dem ausgehandelten Schlüsselverwaltungswert enthält. Der AP 1504 sendet dann eine WLCCP(MN, Pre-Reg Req (Vorabregistrierungsanfrage), WTLV_SECURE_CONTEXT, MN-ID, BSSID, RN, VLAN, MICKRK) an den SCM 1506, wie dies durch 1514 gezeigt ist. Der SCM 1506 antwortet mit einer WLLCP(MN Pre-Reg Reply (Vorabregistrierungsantwort), WTLV_SECURE_CONTEXT, MN-ID, BSSID, RN, VLAN, BTK), wie dies durch 1516 gezeigt ist. Wie in Block 1518 gezeigt ist, authentifiziert und entschlüsselt der AP 1504 den BTK für den MN 1502 mittels seines AP-CTK und leitet den PTKRN ab. Bei 1520 sendet der AP 1504 eine erneute Verbindungsantwort Re-Assoc Resp(RN, RSNIEAP NonceGTK E(PTK, GTK), MIC(PTK, MN-ID, BSSID, RN, RSNIEAP, NonceGTK E(PTK, GTK)), die die Lebendigkeit des PTKRN und die Lieferung des GTK vollendet. Dann authentifiziert und entschlüsselt der MN 1502 den GTK für diese STA mittels des PTK, wie in Block 1522 gezeigt ist. Wenn der AP 1504 den Aufbau einer sicheren Kommunikationsverbindung mit dem MN 1502 fertig gestellt hat, registriert er den MN 1502 so, dass er mit dem AP 1504 aktiv ist. Dies wird durch die Schritte 1524 und 1526 erreicht. Beim Schritt 1524 wird eine WLCCP(MN, Reg Req (Registrierungsanfrage)) von dem AP 1504 zu dem SCM 1506 gesendet, und die Antwort wird beim Schritt 1526 als WLCCP(MN Reg Reply (Registrierungsantwort) gesendet.
  • Obwohl dieses Design die Verwendung der CCKM propagiert, können auch andere Typen der authentifizierten Schlüsselverwaltung (ATM; Authenticated Key Management) unterstützt werden. Da CCKM-fähige MNs die einzigen MN-Typen sind, bei denen ihre Berechtigungsnachweise bei dem SCM in einem Cachespeicher gespeichert sind, benötigen sie somit eine Registrierung. Aber um die Berechtigungsnachweise auf korrekte Weise zu dem AP zu übertragen, benötigen alle MNs eine Vorabregistrierung. Egal, ob nun ein Legacy-Client oder ein SSN-fähiger Client unterstützt wird, sind die Berechtigungsnachweisübertragung und die Vorabregistrierung die gleichen, wie sie in 16 gezeigt ist.
  • Eine Schlüsselhierarchie wird definiert, um ein Stretching der Schlüssel sowie auch eine Ableitung von neuen Schlüsseln zu erlauben. Dieser Abschnitt beschreibt die Funktionen, die verwendet werden, um die Schlüssel abzuleiten. Ein Kommentar muß jedoch noch gegeben werden, um die Angelegenheit der Schlüsselentropie zu behandeln.
  • Die CCKM gewährleistet zwar eine Schlüsselneuheit, beruht aber auf der Bereitstellung von starken Schlüsseln, die zum Beispiel eine gute Entropie aufweisen. Wenn angenommen wird, dass Implementierungen wie etwa LEAP, die Passwort-basiert sind, eine geringe Entropie aufweisen, dann können weitere Verschlüsselungs-Tools verwendet werden, um die Entropie des Schlüssels zu verbessern. TGi hat bereits eine Variante von PKCS#5 als eine Einrichtung zur Verbesserung der Schlüsselentropie aufgenommen, die das vorliegende Design problemlos übernehmen kann. Es sei aber angemerkt, dass dies weit mehr Berechnungen erfordert, als dies einige NICs bereitstellen können.
  • KRK- und BTK-Ableitung:
  • Zur Gewährleistung von neuen KRK- und BTK-Schlüsseln nehmen der AP und der MN einen 4-Wege-Handshake auf sich, um Schlüsselmaterial bereitzustellen, das für die Ableitung des KRK und des BTK benötigt wird. Jeder Knoten muß 16-Byte-Noncen bereitstellen, die im Wesentlichen mit dem NSK verwendet werden, um die benötigten Schlüssel abzuleiten. Die Funktion ist wie folgt definiert:
    GK = PRF-384(NSK, "Cisco Key Management Base Key Generator" | BSSID | STA-ID | NonceSTA | NonceSCM)
    KRK = GK[0:127]
    BTK = GK[128:383]
    PRF-384 ist im Abschnitt 0 definiert.
  • Da die gleiche PRF-XXX-Funktion verwendet wird, um mehrere Schlüsseltypen zu erzeugen, wird die Zeichenkette (String) "Cisco's Key Management Base Key Generator" bei dieser Schlüsselableitungsfunktion eingeführt, um zu gewährleisten, dass diese Schlüssel einzigartig aus anderen Schlüsseltypen konstruiert werden.
  • Sichern von WLLCP-Nachrichten:
  • Um WLCCP-Nachrichten vor dem Lauschen und Mittelmann-Angriffen zu schützen, werden die meisten WLCCP-Nachrichten mittels RC4 verschlüsselt und mittels HMAC-MD5 authentifiziert. Ein AP erstellt einen CTK mit dem SCM während der Vorabregistrierung, so dass er den Schutz von WLCCP-Nachrichten starten kann.
  • Der CTK ist ein 256-Bit-Schlüssel, der verwendet wird, um WLCCP-Nachrichten wie folgt zu schützen:
    • • Die niederwertigen 128 Bits des CTK werden als der RC4-Schlüssel verwendet.
    • • Die höherwertigen 128 Bits des CTK werden als der HMAC-MD5-Schlüssel verwendet.
  • CTK-Schlüssel-Ableitung:
  • Kontexttransferschlüssel, die zwischen dem AP und dem SCM verwendet werden, werden von dem SCM erzeugt und verteilt. Jeder Knoten in der Verbindung muß eine 16-Byte-Nonce bereitstellen, um einen neuen Schlüssel zu gewährleisten:
    CTK = PRF-256(NSK, "SWAN IN – IA link Context Transfer Key Derivation (Verbindungs-Kontexttransferschlüssel-Ableitung)" AP-ID | SCM-ID | NonceAP | NonceSCM | KSC)
  • Der CTK wird von dem SCM berechnet und zu dem AP für den Schutz von nachfolgenden WLCCP-Nachrichten geliefert. Die Lieferung des CTK wird durch Verschlüsseln und Authentifizieren des Schlüssels mittels des NSK durchgeführt.
  • PTK-Schlüssel-Ableitung
  • PTKs umfassen maximal 512 Bytes, da sie verwendet werden, um sowohl 802.1X- als auch 802.11-Kommunikationen zu schützen. Ihre Länge hängt von der 802.11-Cipher-Suite-Aushandlung ab, die bei der Verbindung erstellt worden ist.
  • PTKs werden durch die Verwendung einer Ein-Wege-Hashfunktion: SHA-1 abgeleitet und basieren auf dem BTK, der RN und der BSSID:
    PTK = PRF-Len(BTK, RN | BSSID)
    wobei Len (Länge) = 384 für WRAP oder CCMP,
    512 für TKIP oder CKIP
  • Während die vorliegende Erfindung den PTK liberal verwendet, wird der erzeugte PTK in mehrere Schlüssel partitioniert, die verwendet werden, um Folgendes zu schützen (auch in 1 gezeigt):
    • – EAPOL-Schlüssel-Verschlüsselung zwischen dem AP und dem MN
    • – EAPOL-Schlüssel-Authentifizierung zwischen dem AP und dem MN
    • – 802.11-Verschlüsselung
    • – Für 802.11-TKIP und -CKIP: Datenpaketauthentifizierung zwischen dem AP und dem MN
  • Die Schlüsselzuweisung für den PTK ist wie folgt:
    EAPOL-Schlüssel-MIC-Schlüssel = PTK[0:127]
    EAPOL-Schlüssel-ENC-Schlüssel = PTK[128:255]
    802.11-Verschlüsselungsschlüssel = PTK[256:383]
    TKIP Michael Authentifikator Tx-Schlüssel = PTK[384:447]
    TKIP Michael Authentifikator Rx-Schlüssel = PTK[448:511]
  • Die Definition und der Pseudocode für die Erzeugung von Schlüsseln willkürlicher Länge auf der Grundlage des gegebenen Schlüsselmaterials ist wie folgt (extrahiert aus dem TGi-Entwurf 2.3):
    H-SHA-1(K, A, B, X) = HMAC-SHA-1(K, A | Y | B | X), wobei Y ein einzelnes Achtbitzeichen ist, das 0x00 (null) enthält
    PRF-384(K, A, B) = PRF(K, A, B, 384)
    PRF-512(K, A, B) = PRF(K, A, B, 512)
    PRF(K, A, B, Len)
    {
    Achtbitzeichen i;
    für (i = 0; i < (Len+159)/160; i++) {
    R = R | H-SHA-1(K, A, B, i)
    }
    L(R, 0, Len)
    }
  • Der Schlüssel, der in SHA-1 verwendet wird, ist einer, der unabhängig von dem SCM erzeugt worden ist und nicht mit irgendeiner anderen Partei geteilt werden muß.
  • HMAC-SHA 1 Referenzcode
    • #include "stdafx.h"
    • #define ULONG unsigned long
    • #include <sha.h>
    • void hmac_sha1(
    • unsigned char *text, int text_len,
    • unsigned char *key, int key_len,
    • unsigned char *digest)
    • {
    • A_SHA_CTX context;
    • unsigned char k_ipad[65];/* inneres Padding – Schlüssel mit ipad einem Exklusiv-ODER unterziehen*/
    • unsigned char k_opad[65];/* äußeres Padding – Schlüssel mit opad einem Exklusiv-ODER unterziehen*/
    • int i;
    • /* if Schlüssel länger als 64 Bytes, dann diesen zurücksetzen auf key=SHA1(key) */
    • if (key_len > 64) {
    • A_SHA_CTX tctx;
    • A_SHAInit(&tctx);
    • A_SHAUpdate(&tctx, key, key_len);
    • A_SHAFinal(&tctx; key);
    • key_len = 20;
    • }
    • /*
    • *die HMAC SHA1 Transformierte sieht aus wie:
    • *
    • *SHA1(K XOR opad, SHA1(K XOR ipad, text))
    • *
    • *wobei K ein n-Byte-Schlüssel ist
    • *ipad das Byte 0x36 64 mal wiederholt ist
    • *opad das Byte 0x5c 64 mal wiederholt ist
    • * und text die Daten ist, die geschützt werden
    • */
    • /* Anfangen mit dem Speichern von Schlüsseln in Stopfbits (Pads) */
    • memset(k_ipad, 0, sizeof k_ipad);
    • memset(k_opad, 0, sizeof k_opad);
    • memcpy(k_ipad, key, key_len);
    • memcpy(k_opad, key, key_len);
    • /* Schlüssel mit ipad- und opad-Werten einem Exklusiv-ODER unterziehen*/
    • für (i = 0; i < 64; i++) {
    • k_ipad[i]∧= 0x36;
    • k_opad[i]∧= 0x5c;
    • }
    • /* inneren SHA1 durchführen*/
    • A_SHAInit(&context);/* init Kontext für 1. Pass. */
    • A_SHAUpdate(&context, k_ipad, 64);/* mit innerem Pad starten */
    • A_SHAUpdate(&context, text, text_len);/* Dann Text des Datagramms */
    • A_SHAFinal(&context, digest);/* 1. Pass. beenden */
    • /* äußeren SHA1 durchführen */
    • A_SHAInit(&context);/* init Kontext für 2. Pass. */
    • A_SHAUpdate(&context, k_opad, 64);/* mit äußerem Pad starten */
    • A_SHAUpdate(&context, digest, 20);/* Dann Ergebnisse des 1. Hash */
    • A_SHAFinal(&context, digest);/* 2. Pass. beenden */
    • }
    • HMAC-SHA1 Testvektoren (extrahiert aus dem SSN-Entwurf): Die Testvektoren für HMAC_SHA1 stammen aus rfc2202 und sind gegenüber dem obigen Referenzcode überprüft worden. Die PRF-Testvektoren sind gegenüber zwei anderen Implementierungen geprüft worden.
  • test_case = 1
    key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
    key_len = 20
    data = "Hi There"
    data_len = 8
    difest = 0xb617318655057264e28bc0b6fb378c8ef146be00
    PRF = 0xbcd4c650b30b9684951829e0d75f9d54b862175ed9f00606e
    17d8da35402ffee75df78c3d31e0f889f012120c0862beb6775
    3e7439ae242edb8373698356cf5a
    test_case = 2
    key = "Jefe"
    key_len = 4
    data = "what do ya want for nothing?"
    data_len = 28
    digest = 0xeffcdf6ae5eb2fa2d27416d5f184df9c259a7c79
    PRF = 0x51f4de5b33f249adf81aeb713a3c20f4fe631446fabdfa58
    244759ae58ef9009a99abf4eac2ca5fa87e692c440eb40023e
    7babb206d61de7b92f41529092b8fc
    test_case = 3
    key = 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    key_len = 20
    data = 0xdd 50 mal wiederholt
    data_len = 50
    digest = 0x125d7342b9ac11cd91a39af48aa17b4f63f175d3
    PRF = 0xe1ac546ec4cb636f9976487be5c86be17a0252ca5d8d8df12c
    fb0473525249ce9dd8d177ead710bc9b590547239107aef7b4ab
    d43d87f0a68f1cbd9e2b6f607
  • Zusätzlich zu dem oben erwähnten Verfahren ist eine andere Ausführungsform der vorliegenden Erfindung ein drahtloses LAN Kontextkontrollprotokoll (WLCCP; Wireless LAN Context Control Protocol), das verwendet wird, um eine Netztopologie zu erstellen und zu verwalten, die hier als die Smart Wireless Architecture for Networking (SWAN) bezeichnet wird, und es wird hier verwendet, um den "betrieblichen Kontext" für mobile Stationen in einem SWAN-"Campusnetz" sicher zu verwalten.
  • Ein WLCCP-Registrierungsprotokoll a) erzeugt und löscht automatisch Verbindung in der SWAN-Topologie, b) verteilt sicher betrieblichen Kontext, und c) errichtet (optional) zuverlässig Schicht-2-Weiterleitungspfade in drahtlosen Verbindungen.
  • Ein WLCCP-SCM-Bekanntmachungs-/Auswahl-Protokoll erstellt automatisch einen einzelnen SCM als den zentralen Kontrollpunkt für jedes Teilnetz und ermöglicht es den APs und MNs, den Vaterknoten auszuwählen, der den "kostengünstigsten Pfad" zu dem Backbone-LAN bereitstellt.
  • WLCCP-"Kontext"-Nachrichten stellen einen Allzwecktransport für Kontext- und Verwaltungsinformationen bereit. WLLCP-"Ablaufverfolgungs"-Nachrichten ermöglichen Netzwerkdiagnosetools.
  • Das WLCCP ist ein transaktionsorientiertes "Anfrage-/Antwort"-Protokoll. Alle WLCCP-Anfrage- und -Antwort-Nachrichten weisen einen Header mit einer festen Länge auf, der Felder enthält, die vom Nachrichtentyp abhängig sind. Optionale Typ-Länge-Wert-Paare folgen dem Header mit der festen Länge; deshalb ist das WLCCP erweiterbar.
  • Die Ethernet- oder UDP/IP-Einkapselung kann für WLCCP-Nachrichten verwendet werden. Die Ethernet-Einkapselung ist auf WLCCP-Nachrichten in nerhalb eines Teilnetzes (z. B. AP zu AP oder AP zu SCM) beschränkt. Die IP-Einkapselung muß für WLCCP-Nachrichten zwischen Teilnetzen verwendet werden und kann auch für WLCCP-Nachrichten innerhalb eines Teilnetzes verwendet werden.
  • Wie die Fachleute auf diesem Gebiet ohne Weiteres erkennen werden, muß eine spezifische WLCCP-Implementierung nicht alle der hier beschriebenen Komponenten enthalten.
  • Ein "verteiltes" Kontexttransferprotokoll kann verwendet werden, um Kontext direkt von einem "alten AP" zu einem "neuen AP" zu transferieren, wenn ein MN roamt. Das IEEE 802.11f Entwurfsprotokoll definiert zum Beispiel ein verteiltes Kontexttransferprotokoll. Es gibt eine Anzahl von inhärenten Problemen bei einem solchen verteilten Lösungsweg. Die bemerkenswertesten Probleme sind: 1) Ein sicherer Kontexttransfer erfordert eine Vertrauensbeziehung von vielen zu vielen zwischen APs (oder benötigt irgendeine zusätzliche Hierarchie). 2) Ein Protokoll wird benötigt, um es dem "neuen AP" zu ermöglichen, den "alten AP" zu bestimmen, wenn ein MN roamt. (Das Feld der erneuten 802.11-Verbindung für den "alten AP" ist nicht ausreichend.) Kontext wird von AP zu AP weitergereicht, wenn eine Station roamt; deshalb kann kritischer Kontext verloren gehen (z. B. wenn die Verbindung zu einem alten AP verloren geht). 4) Ein verteiltes Protokoll ist anfällig für eine inhärente Wettlaufsituation, bei der "Weiterreichungsnachrichten" für das schnelle Roaming von Stationen außerhalb der richtigen Reihenfolge ankommen können.
  • Das SWAN-Netz, das hier offenbart ist, ist als ein hierarchischer "Topologiebaum" organisiert. Wenn eine Station von einem "alten AP" zu einem "neuen AP" roamt, wird der Kontext im Allgemeinen über den "am nächsten liegenden gemeinsamen Vorgänger" in dem Topologiebaum sowohl der alten als auch der neuen APs transferiert. Die WLCCP-Registrierung umfasst die notwendige Routing-Logik, um automatisch den am nächsten liegenden gemeinsamen Vorgänger zu finden. Im Cachespeicher aufgenommene Konfigurations- und Kontextinformationen werden in der Netzinfrastruktur gespeichert. Der gemeinsame Vorgänger leitet die im Cachespeicher gespeicherten Informationen sicher auf dem neuen Topologiebaumzweig für eine Station weiter, die geroamt ist. Deshalb wird der Kontexttransfer automatisch "lokalisiert" und die Kontextinformationen gehen nicht verloren, wenn die Verbindung zu einem alten AP verloren geht. Der gemeinsame Vorgänger leitet auch die "alten AP-Bindungen" zu dem neuen AP weiter.
  • Eine Sicherheitsbeziehung von vielen zu vielen zwischen 802.11-APs wird für einen sicheren Kontexttransfer in einem SWAN-Netz nicht benötigt. Statt dessen wird eine Vertrauenshierarchie aufgebaut, die dem SWAN-Topologiebaum entspricht. Der betriebliche Kontext wird im Allgemeinen auf Topologiebaumzweigen weitergeleitet; deshalb werden WLCCP-Kontexttransferschlüssel zwischen allen SWAN-Knoten in dem gleichen Topologiebaumzweig vorab erstellt. Wenn es notwendig ist, Kontext "lateral" zwischen zwei Knoten auf unterschiedlichen Topologiebaumzweigen zu transferieren, dann kann der nächste gemeinsame Vorgänger der 2 Knoten als eine vertrauenswürdige dritte Partei funktionieren, um schnell eine gegenseitige Authentifizierung und einen Übergangs-Kontexttransferschlüssel zu erstellen.
  • Der hierarchische Topologiebaum ermöglicht eine zentrale Verwaltung und Kontrollpunkte. Zum Beispiel können die netzweiten Parameter zentral konfiguriert und verteilt werden. Ein zentraler WLCCP-Kontrollpunkt erstellt und löscht Topologieverbindungen; deshalb ist es möglich, eine konsistente Netztopologie aufrecht zu erhalten, selbst wenn Weiterreichungsnachrichten für schnell roamende Stationen nicht sequentiell ankommen.
  • Eine lokal oder global verwaltete 48-Bit-IEEE 802-Adresse wird als eine interne WLCCP-Netzknotenadresse verwendet. Eine IP-Adresse wird nicht als eine Knotenadresse verwendet, weil: a) Ein Knoten seine IP-Adresse ändern kann. b) WLCCP verwendet wird, um die Schicht-2-Mobilität zu verwalten; sie sollte im Allgemeinen unabhängig von jeglichem Netzschichtprotokoll sein.
  • Eine WLCCP-Knotenadresse ist eine interne WLCCP-Knotenkennung und sollte NICHT zur Identifizierung von APs und CMs gegenüber Benutzern in Netzverwaltungsanwendungen verwendet werden. Statt dessen kann eine Netzzugangskennung (NAI) oder ein Domainname als eine Benutzer-WLCCP-Knotenkennung verwendet werden.
  • Das Design des WLCCP der vorliegenden Erfindung zieht die folgenden zugrunde liegenden Voraussetzungen und Erfordernisse in Betracht:
    • 1) Die Zielumgebung ist ein Unternehmens-"Campusnetz".
    • 2) 802.11 ist eine Ethernet-Zugangs-Technologie, die verwendet wird, um verdrahtete Ethernet Backbone LANs auf mobile Knoten zu erweitern und "sekundäre LANs" auszuwählen.
    • 3) Ein 802.11 AP ist effektiv gesehen eine Schicht-2-"Ethernet"-Brücke.
    • 4) Ein 802.11 Mobilknoten (MN) ist effektiv gesehen ein mobiler "Ethernet"-Knoten.
    • 5) WLCCP ist im Allgemeinen unabhängig von der zugrunde liegenden Funktechnologie.
    • 6) Ein MN sollte in der Lage sein, nahtlos in einem einzigen Teilnetz oder zwischen Teilnetzen innerhalb eines "Campusnetz" roamen zu können und so arbeiten zu können, als ob er an einem Ethernet-Switch-Port angeschlossen ist; deshalb ist es notwendig, einen standortspezifischen betrieblichen Kontext zu transferieren, wenn ein MN roamt.
    • 7) Der Pfad zwischen einem MN und jedem Korrespondenz-Host (CH) muß zuverlässig erneut aufgebaut werden, wenn der MN roamt. [Einfaches Rückwärtslernen ist nicht ausreichend und unterliegt "Wettlaufsituationen".]
    • 8) Nicht-WLCCP-Ethernet-Brücken und -Switches müssen das Rückwärtslernen unterstützen, wie dies in dem 802.1D-Standard definiert ist.
    • 9) Das WLCCP muß Kontextverwaltungsdienste für eine integrierte, nahtlose Proxy-MIP/VLAN-Inter-Teilnetz-Mobilitätslösung bereitstellen. Die nahtlose Mobilitätslösung muß sowohl IP- als auch Nicht-IP-Anwendungen unterstützen; sie darf keine Client-Unterstützung benötigen; und sie darf es nicht erfordern, dass Benutzer ihre existierenden verdrahteten Topologien beträchtlich ändern müssen.
    • 10) Das WLCCP darf das nahtlose Roaming zwischen Teilnetzen an unterschiedlichen geographischen Orten NICHT ermöglichen (oder ausschließen).
    • 11) Ein Campusnetz kann eine große Population von Stationen enthalten, die häufig roamen; deshalb muß der Overhead für das Roaming minimal sein.
    • 12) Das WLCCP muß ein sehr schnelles Roaming für QoS-Anwendungen unterstützen.
    • 13) Das WLCCP muß bestehende WLAN-Merkmale unterstützen, die drahtlose (d. h., Repeater-)APs, drahtlose Brücken und mobile APs und Brücken umfassen.
    • 14) Das Unicast- und Multicast-Rahmen-Flooding muß in drahtlosen Verbindungen minimiert sein.
    • 15) Das WLCCP muß einen schnellen, sicheren Kontexttransfer unterstützen, ohne eine Notwendigkeit bezüglich Sicherheitsbeziehungen von vielen zu vielen zwischen APs einzuführen.
    • 16) Das WLCCP muß unabhängig von jedem zugrunde liegenden Spannbaumprotokoll arbeiten.
    • 17) Das WLCCP darf die Benutzerkonfigurationserfordernisse nicht beträchtlich erhöhen; deshalb muß die zugrunde liegende Topologie zum großen Teil selbstkonfigurierend sein.
    • 18) Das WLCCP darf keine einzelnen Ausfallspunkte einführen. Das Netz muß weiterarbeiten, möglicherweise mit verringerten Merkmalen, wenn ein SWAN-Knoten oder eine SWAN-Verbindung ausfällt.
    • 19) Das WLCCP muß existierende Standards so weit wie möglich wirksam einsetzen.
    • 20) Das WLCCP darf nicht störend in existierende Protokolle eingreifen. Insbesondere darf das WLCCP Standard-Mobile-IP-Clienten nicht ausschließen.
    • 21) Es darf von den Client-MNs NICHT gefordert werden, dass sie WLCCP direkt unterstützen. Statt dessen können die MNs das WLCCP indirekt über 802.11-Elemente unterstützen.
    • 22) Das WLCCP muß Bausteine für WLAN-Verwaltungs- und -Diagnose-Tools bereitstellen.
    • 23) Der Funkversorgungsbereich der APs in unterschiedlichen Teilnetzen kann sich überlappen.
    • 24) Die sichere Kontexttransfer- und Nachrichtenauthentifizierung des WLCCP ist unabhängig von der zugrunde liegenden Sicherheitsinfrastruktur, mit der Ausnahme, dass es möglich sein muß, SWAN-Knoten gegenseitig zu authentifizieren und geheime Sitzungsschlüssel zu erstellen.
    • 25) Das WLCCP stellt KEINE MN-Authentifizierung bereit; aber es muß eine schnelle erneute Authentifizierung ermöglichen, indem es sicher dynamische MN-Sicherheits-Berechtigungsnachweise transferiert.
  • So, wie es hier verwendet wird, ist ein SWAN-Netz eine "Baumtopologie", die an einem SWAN CM wurzelt. Das WLCCP wird verwendet, um den Topologiebaum zu erstellen und zu verwalten. Ein beispielhafter Topologiebaum für eine volle WLCCP-Implementierung ist in 17 gezeigt. 17 zeigt eine "Campus-Topologie" mit zwei lokalen Kontrollbereichen (LCM; local control domain) 1706 und 1706 und drei Teilnetz-Kontrollbereichen (SCM) 1708, 1710 und 1712. Das Beispielnetz umfasst eine Work-Group Brücke (WGB-1) 1714 und ihre angeschlossenen Ethernet-Knoten (EN-1 und EN-2, jeweils 1716 und 1718). Topologiezweige, die über 802.11-Verbindungen existieren, sind als gestrichelte Linien 1720a–f gezeigt.
  • Mögliche Teilnetz-Topologie-Komponenten sind spezifisch für die WLCCP-Implementierung. Eine beispielhafte Teilnetz-Topologie für eine Implementierung, die Schicht 2-Pfadaktualisierungen und drahtlose Brücken unterstützt, wird hier weiter unten veranschaulicht werden.
  • SWAN CMs und APs sind innere Knoten (INs), und MNs und sekundäre Ethernet-Knoten (ENs) sind in dem SWAN Topologiebaum die Blätter. Der SWAN CCM 1702 befindet sich an der Wurzel des Campus-Topologiebaums. Der CCM 1702 ist der Wurzel-CM in einem Campusnetz. Ein LCM 1704, 1706 befindet sich an der Wurzel des Unterbaums, der in einem lokalen Steuerbereich enthalten ist. Ein SCM 1708, 1710, 1712 befindet sich an der Wurzel des Unterbaums, der in jedem Netz-Teilnetz enthalten ist. Ein "Vater-AP" 1722, 1724, 1726 und 1728 befindet sich an der Wurzel eines Unterbaums, der Sohn-MNs 1730, 1732 und 1734 und irgendwelche Sohn-APs 1736 und 1738 enthält.
  • Das Format einer WLCCP-Knoten-ID ist in Tabelle 1800 von 18 gezeigt. Eine 64-Bit-WLCCP-Knoten-ID identifiziert jeden Knoten in einem SWAN-Netz. Eine Knoten-ID ist eine Verkettung aus einem 16-Bit-WLCCP-Knotentyp 1802 und einer 48-Bit-WLCCP-Knotenadresse 1804. Die Knotenad resse 1804 für einen MN, EN, AP oder SCM ist eine globale 48-Bit-IEEE 802-Adresse. Die Knotenadresse 1804 für einen LCM oder CCM kann eine globale oder eine lokal verwaltete 48-Bit-IEEE 802-Adresse sein. In einem Ausführungsbeispiel wird in Betracht gezogen, dass der CCM automatisch "lokale" 48-Bit-Adressen sich selber und anderen LCMs zuweisen kann. Eine Knotenadresse mit "lauter Nullen" wird verwendet, um den "lokalen WLCCP-Knoten" in einem WLCCP-CM oder -AP zu identifizieren. Der Knotentyp ist CCM, LCM, SCM, AP, MN oder EN.
  • Jede physikalische AP-(z. B. Ethernet und 802.11)-Kommunikationsschnittstelle wird von einer 48-Bit-IEEE 802-Portadresse identifiziert. Eine LAN-Kommunikationsschnittstelle eines SCM wird ebenfalls durch eine 48-Bit-IEEE 802-Portadresse identifiziert. Eine 802-Portadresse kann als die WLCCP-Knotenadresse wiederverwendet werden. Jeder WLCCP-CM muß eine IP-Kommunikationsschnittstelle aufweisen, die von einer IP-Portadresse identifiziert wird. Eine IP-Portadresse wird nicht als eine CM-Knotenadresse verwendet, weil sich eine IP-Adresse eines CM ändern kann.
  • AP-Kommunikationsschnittstellen arbeiten im Allgemeinen in einem "gemischten Modus"; deshalb kann ein AP WLCCP-Rahmen, die für seine Knotenadresse bestimmt sind, auf jeder physikalischen Schnittstelle empfangen. In einer einfachen Implementierung kann die AP-Knotenadresse dazu verwendet werden, eine "interne WLCCP-Schnittstelle" in einem AP zu identifizieren.
  • 19 zeigt die interne Überbrückungsstruktur in einem AP. Die Ethernet-802-Portadresse ist auch die WLCCP-Knotenadresse. Ein Rahmen, der für die Knotenadresse bestimmt ist und entweder an der Ethernet-Schnittstelle oder der 802.11-Schnittstelle empfangen wird, wird intern zu der WLCCP-Protokollschnittstelle "überbrückt"; deshalb kann die Knotenadresse auch als die WLCCP-"Hop-Adresse" an jedem AP-Port verwendet werden. [WLCCP und DDP sind zusammen gezeigt, weil sie den gleichen Ethernet-DIX-Typ gemeinsam benutzen.]
  • Jeder WLCCP-AP und -CM sollte mit einem permanenten "Knotennamen" konfiguriert sein [z. B. Network Access Identifier (NAI) (Netzzugangskennung) oder einem DNS-Domainnamen]. Ein LCM muß mit einem Knotenna men konfiguriert sein, um eine lokal verwaltete Knotenadresse von dem CCM anzufordern.
  • Eine Knoten-ID ist KEINE permanente Knotenkennung und sollte nicht als solche verwendet werden. Eine NAI kann verwendet werden, um Netzknoten Benutzern zu repräsentieren.
  • Eine Instanzkennung und ihre Knoten-ID identifizieren jede "Instanz" eines "angeschlossenen" AP oder CM. Im WLCCP wird ein Instanzalterals die Instanzkennung verwendet, wie unten beschrieben werden wird.
  • Jeder WLCCP CM muß Tabellen mit Querverweisen verwalten, die verwendet werden, um eine WLCCP Knoten-ID zu einem Knotennamen oder einer IP-Adresse zuzuordnen oder umgekehrt.
  • Unter erneuter Bezugnahme auf 17 ist in einem Campusnetz jeder SWAN AP 1722, 1724, 1726 und 1728 und CM 1704, 1706, 1708, 1710, 1712 anders als der SWAN CCM 1702 an einen einzigen "Vaterknoten" und einen einzigen "Vater-CM" gebunden. Der Vater-CM für einen LCM ist der CCM. Der Vater-CM für einen SCM ist ein LCM. [Es sei angemerkt, dass eine einzige Vorrichtung mehrere logische CMs enthalten kann. Die Vorrichtung, die den CCM enthält, enthält immer einen logischen LCM.] In 17 sind der Vaterknoten und der Vater-CM für den AP 1720 jeweils der AP 1728 und der SCM 1712.
  • Der SCM für jedes Teilnetz ist der Vater-CM für alle APs in seinem Teilnetz und für alle MNs, die mit diesen APs verbunden sind. Es sei angemerkt, dass ein MN ein Sohn des SCM für das "native" Teilnetz des Vater-AP ist, selbst wenn der MN an ein anderes "Heimat-Teilnetz" über ein VLAN-Trunking oder eine Proxy-MIP-Tunnelung gebunden ist. Zum Beispiel gehören in der 17 der SCM 1708, der AP 1722 und der AP 1724 alle zu dem gleichen Teilnetz. Der MN 1730 ist ein Sohn des AP 1722; deshalb ist er ein Sohn des SCM 1708. Aber der MN 1730 kann zu einem anderen Teilnetz gehören, wenn AP-1 an einer VLAN-Verbindungsleitung angeschlossen ist.
  • Der "Vaterknoten" für einen LCM oder SCM ist der Vater-CM. Der Vaterknoten für einen MN ist der 802.11-Vater-AP. Der Vaterknoten für einen "Wurzel-AP" ist ein SCM. Der Vaterknoten für einen Nicht-Wurzel-AP ist der 802.11-Vaterknoten. Ein Knoten wird als ein "Sohn" seines Vaters betrachtet. Ein "Nachbar" ist ein Vater- oder Sohnknoten.
  • Eine logische "Verbindung" existiert zwischen einem Knoten und jedem seiner Nachbarn. Ein "Port" bzw. "Anschluss" ist die logische Entität, die den Zugang zu einer Verbindung bereitstellt. Jeder CM und AP weist einen einzigen primären Port und einen oder mehrere sekundäre Ports auf. Ein Knoten ist an dem Netz an seinem primären Port angeschlossen. Mehrere logische Ports können auf einer einzigen physikalischen Kommunikations-Schnittstelle existieren. Zum Beispiel kann in 17 der AP 1728 die gleiche physikalische 802.11-Schnittstelle für den Zugang zu der Verbindung zu dem AP 1736 und den AP 1738 verwenden; aber der AP 1728 weist einen separaten logischen Port für jede Verbindung auf.
  • Ein "Zweig" des Topologiebaums besteht aus einem Satz von Knoten und Verbindungen, die den kürzesten Pfad zwischen einem "Vorgänger"-Knoten und einen "Nachfolger"-Knoten bereitstellen. Ein eingehender bzw. nach innen gerichteter Knoten ist ein Vorgänger und ein abgehender bzw. nach außen gerichteter Knoten ist ein Nachfolger. Alle Knoten sind Nachfolger des Wurzel-CM 1702. Ein abgehender Pfad entspringt aus einem Vorgänger-Knoten und endet an einem Nachfolger-Knoten. Ein eingehender Pfad entspringt an einem Nachfolger-Knoten.
  • SWAN CMs befinden sich NICHT in dem Weiterleitungspfad für Nicht-WLCCP-Nachrichten; deshalb ist eine SWAN-"Pfadinstanz" eines Knotens NICHT identisch mit dem Datenweiterleitungspfad des Knotens.
  • Eine Topologiebaum-"Verbindung" existiert zwischen jedem SWAN-Knoten und jedem seiner Nachbarn. Eine Verbindung wird eingerichtet, wenn ein "Sohnknoten" einen "Vaterknoten" auswählt und sich bei der SWAN-Infrastruktur über seinen Vaterknoten registriert. Eine Verbindung von einem SCM zu einem AP ist immer eine Ethernet-Verbindung. Eine Verbindung von einem AP zu einem AP kann eine Ethernet-Verbindung oder eine 802.11- Verbindung sein. Eine Verbindung von einem AP zu einem MN ist (im Augenblick) immer eine 802.11-Verbindung. Eine Verbindung von einem CM zu einem CM kann konzeptuell jede Verbindung sein, die IP unterstützt.
  • Ein Knoten ist verantwortlich für die Aufrechterhaltung des "Verbindungszustands" zu jedem seiner Nachbarn. Eine aktive Verbindung befindet sich in einem "verbundenen" Zustand. Eine Verbindung geht in einen "getrennten" Zustand über, wenn die zugrunde liegende physikalische Kommunikationsverbindung verloren geht oder wenn ein Sohn zu einem anderen Vaterknoten roamt. Ein Knoten muß in der Lage sein, Verbindungszustandsänderungen in seinen Nachbarn zu erfassen; ansonsten können Verbindungen in einem "halbverbundenen" Zustand existieren. [Der 802.11-Verbindungszustand von AP zu AP ist transparent für WLCCP-Implementierungen, bei denen das WLCCP nicht für Schicht-2-Pfadaktualisierungen verwendet wird.]
  • Die IP-Adresse oder der Domainname des CCM muß in jedem LCM und in jedem SCM-Kandidaten statisch konfiguriert sein. Es wird in Betracht gezogen, dass in einem Ausführungsbeispiel ein LCM oder SCM den CCM über ein CCM-Bekanntmachungsprotokoll automatisch entdecken kann.
  • Die Liste der Teilnetze, die an jeden LCM gebunden sind, ist in dem CCM konfiguriert. Ein SCM sendet am Anfang und immer dann, wenn ein Vater-LCM verloren geht, eine Anfragenachricht zu dem CCM, um seine Vater-LCM-Zuweisung zu erhalten.
  • Ein SCM wird automatisch für jedes Teilnetz ausgewählt. Ein AP entdeckt automatisch seinen Vater-SCM über ein SCM-Bekanntmachungsprotokoll. Ein Nicht-Wurzel-"Sohn-AP" ist ebenfalls an einen "Vater-AP" gebunden, wie unten beschrieben ist. Ein MN ist an einem Vater-AP über das 802.11-Verbindungsprotokoll gebunden.
  • Ein Knoten befindet sich entweder in einem "angeschlossenen" oder "nicht angeschlossenen" Zustand. Ein Knoten befindet sich anfänglich in dem nicht angeschlossenen Zustand. Ein CCM-Kandidat geht in den angeschlossenen Zustand über, wenn er der aktive CCM wird. Ein CCM geht in den nicht angeschlossenen Zustand über, wenn er die CCM-Rolle aufgibt. Ein Nicht- CCM-Knoten geht in den angeschlossenen Zustand über, wenn er sich anfänglich bei der SWAN-Infrastruktur registriert. Ein angeschlossener Nicht-CCM-Knoten geht in den nicht angeschlossenen Zustand über, wenn er a) entdeckt, dass sein Vaterknoten nicht angeschlossen ist, oder b) nicht in der Lage ist, mit seinem Vaterknoten zu kommunizieren.
  • Jeder CM muß ein internes Instanzalter verwalten, das die abgelaufene Zeit in Sekunden enthält, seit der Knoten zum letzten Mal in den angeschlossenen Zustand übergegangen ist. Das Instanzalter wird jedes Mal dann auf 0 initialisiert und auf 0 zurückgesetzt, wenn sich der Knoten anfänglich bei einem neuen Vater-CM registriert. Das Instanzalter eines SCM wird in das Instanzalter-Feld in SCM-Bekanntmachungs-Antwortnachrichten kopiert, so dass ein Sohn-AP eine neue Instanz seines Vater-SCM erfassen kann. Ein Sohn-AP geht in den nicht angeschlossen Zustand über, wenn er eine Bekanntmachungs-Nachricht mit einem niedrigeren Instanzalter empfängt. In einem Ausführungsbeispiel braucht ein AP kein Instanzalter zu verwalten, wenn das WLCCP nicht für Schicht-2-Pfadaktualisierungen verwendet wird.
  • Ein SWAN-Netz arbeitet im Allgemeinen in einem "Campus-Infrastruktur-Modus" mit einem einzigen CCM und einem entsprechenden Campus-Kontrollbereich (Campus Control Domain). Ein LCM und sein entsprechender lokaler Kontrollbereich müssen in einem "lokalen selbständigen Modus" arbeiten, wenn der LCM mit dem CCM nicht kommunizieren kann. Ein LCM muß auch in einem selbständigen Modus arbeiten, wenn er keinem CCM zugewiesen ist. In ähnlicher Weise müssen jeder SCM und das entsprechende Teilnetz in einem "selbständigen Teilnetz-Modus" arbeiten, wenn der SCM nicht einem Vater-LCM zugewiesen ist.
  • In dem selbständigen Modus arbeitet ein lokaler Kontrollbereich oder ein Teilnetz-Kontrollbereich auf eine sehr ähnliche Weise wie ein SWAN-Campusnetz. Ein LCM, der in einem lokalen selbständigen Modus arbeitet, nimmt CCM-Funktionen an. Der LCM oder SCM an der Wurzel eines selbständigen Bereichs funktioniert als der 802.1X-Authentifikator für sowohl Infrastrukturknoten als auch MNs. Ein lokaler oder Teilnetz-Kontrollbereich muß in der Lage sein, ruhig den Übergang zwischen dem Infrastrukturmodus und dem selbständigen Modus zu vollziehen.
  • Ein LCM ist mit der IP-Adresse des CCM konfiguriert, um im Infrastrukturmodus zu arbeiten. Wenn ein LCM in einem selbständigen Modus arbeitet, weil er die Verbindung zu seinem zugeordneten CCM verloren hat, dann muß er periodisch versuchen, die Kommunikationen mit dem CCM erneut aufzubauen.
  • Ein SCM ist mit der IP-Adresse oder dem Domainnamen des CCM konfiguriert, um in einem Infrastrukturmodus zu arbeiten. Der CCM ist verantwortlich dafür, jeden SCM einem LCM zuzuweisen, wie dies unten in dem Abschnitt mit dem Titel "W2 – Vater-LCM-Zuweisung" beschrieben werden wird.
  • Ein AP muß in einem "verteilten Ersatz"-Modus" (distributed fallback mode) arbeiten, wenn er keinen SCM für sein Teilnetz entdecken kann. Ein AP muß in der Lage sein, ruhig einen Übergang zwischen dem Infrastrukturmodus und dem verteilten Modus vollziehen zu können. Zum Beispiel kann ein AP das existierende Cisco Datagram Delivery Protocol in einem verteilten Modus verwenden. Es sei angemerkt, dass ein Benutzer APs zwingen kann, in einem verteilten Modus zu arbeiten, indem er einfach keine SCM-Kandidaten konfiguriert.
  • Im Allgemeinen kann ein LCM oder SCM einen Übergang von dem Infrastrukturmodus in den selbständigen Modus (d. h., wenn die Verbindung zu seinem Vater verloren gegangen ist) ruhig vollziehen, ohne dass Knoten in seinem Unterbaum abgetrennt werden. Knoten in einem "neuen" selbständigen Bereich können weiterhin existierende Registrierungsinformationen und Sicherheits-Berechtigungsnachweise verwenden, die vorher in einem Infrastrukturmodus erstellt wurden.
  • Der Unterbaum, der an einem LCM oder SCM wurzelt, muß neu aufgebaut werden, wenn der LCM oder der SCM von dem selbständigen Modus in den Infrastrukturmodus übergeht. Ein SCM oder LCM erstellt eine neue Instanz-ID, wenn er von dem selbständigen Modus in den Infrastrukturmodus übergeht. Ein SCM erstellt auch eine neue Instanz-ID, wenn sich sein Vater-LCM ändert. Der Unterbaum, der an dem SCM oder LCM wurzelt, wird automatisch ge löscht, wenn Knoten in dem Unterbaum die neue SCM- oder LCM-Instanz entdecken.
  • WLCCP-"Kontextverwaltungs"-Nachrichtentypen sind unten aufgelistet. Ein "Anfrage-" und "Antwort"-Untertyp ist für jeden Nachrichtentyp definiert. Ein optionaler "Bestätigungs"- und "Quittungs"-Untertyp ("confirm" and "ack" subtype) ist für ausgewählte Nachrichtentypen definiert, die ein zusätzliches Handshaking benötigen.
    SCM-Bekanntmachung
    CCM-Bekanntmachung
    Registrierung
    Vorabregistrierung
    Deregistrierung (Beendigung der Registrierung)
    Abtrennen (Detach)
    Kontext
    Pfadaktualisierung
    Pfadüberprüfung
    Ablaufverfolgung
    AAA
    Pfad-Initialisierung (Pfad-Init)
  • WLCCP-Nachrichtenformate sind in dem Abschnitt definiert, der den Titel "WLCCP-Protokolldefinitionen" trägt.
  • Ein "Response-Req"-Flag (Antwort-Anfrage-Flag) wird in einer Anfragenachricht auf EIN gesetzt, um eine Antwortnachricht abzurufen. Im Allgemeinen wird eine Antwortnachricht verwendet, um eine Anfragenachricht zu quittieren und um Status- und/oder Kontextinformationen zu dem Absender zurückzusenden. Eine Antwort-"Nachrichten-Kennung" wird in die entsprechende Antwortnachricht kopiert, um zu Anfrage-/Antwortpaaren zu "passen". Dieselbe Nachrichtenkennung wird in erneut gesendeten Anfragenachrichten verwendet, um alle Anfrage-/Antwortnachrichten zu identifizieren, die zu einer einzigen Transaktion gehören.
  • Eine optionale "Bestätigungs"-Nachricht (confirm message) kann verwendet werden, um eine Antwortnachricht zu quittieren und Status- und/oder Kontextinformationen zu dem Antwortenden zurückzusenden. Das Response-Req-Flag wird in einer Antwortnachricht auf EIN gesetzt, um eine Bestätigungs-Nachricht abzurufen.
  • Eine optionale "Ack"-Nachricht (Quittierungsnachricht) kann verwendet werden, um eine Bestätigungsnachricht zu quittieren und Status- und/oder Kontextinformationen zu dem Absender zurückzuschicken. Das Response-Req Flag wird in einer Bestätigungsnachricht auf EIN gesetzt, um eine Ack-Nachricht abzurufen.
  • WLCCP-Nachrichten enthalten einen Header mit einer festen Länge, gefolgt von optionalen TLVs variabler Länge.
  • Ein SCM sendet periodisch SCM-Bekanntmachungs-Antwort-Nachrichten, um in jedem "nativen" Teilnetz eines AP Netzparameter und die Verfügbarkeit bekannt zu geben und um das SCM-Auswahlprotokoll zu ermöglichen. APs entdecken automatisch den aktiven SCM für das lokale Teilnetz, indem sie SCM-Bekanntmachungen überwachen. APs empfangen SCM-Bekanntmachungen an einem "primären Port" und leiten SCM-Bekanntmachungen auf "sekundären Ports" weiter, um SCM- und Teilnetzinformationen zu Nachfolgerknoten in der SWAN-Topologie weiter zu verbreiten.
  • Ein Knoten kann eine SCM-Bekanntmachungs-Anfrage-Nachricht senden, um eine SCM-Bekanntmachungs-Antwort-Nachricht zu erbitten (z. B. um den Entdeckungszeitraum zu verkürzen).
  • Ein CCM kann optional periodische CCM-Bekanntmachungs-Antwort-Nachrichten senden, um Netzparameter und die Verfügbarkeit bekannt zu geben und um ein CCM-Auswahlprotokoll zu ermöglichen. LCMs und SCMs können automatisch den aktiven CCM entdecken, indem sie CCM-Bekanntmachungen überwachen. CCM-Bekanntmachungs-Anfrage- und -Antwort-Nachrichten werden zu einer IP-Multicast-Adresse gesendet.
  • Ein Knoten kann eine CCM-Bekanntmachungs-Anfrage-Nachricht senden, um eine CCM-Bekanntmachungs-Antwort-Nachricht abzurufen.
  • Eine Registrierungs-Anfrage-Nachricht wird verwendet, um eine Registrierung für einen MN, AP oder CM bei der SWAN-Infrastruktur anzufordern. Ein SWAN-Knoten ist immer bei dem CCM und jedem LCM, SCM und AP auf dem Pfad zu dem CCM registriert. Eine Registrierungs-Anfrage wird immer eingehend auf einem einzigen Zweig in der SWAN-Topologie weitergeleitet. Es gibt zwei Typen von Registrierungs-Anfragen: Eine "anfängliche" Registrierungs-Anfrage wird erzeugt, um eine neue Pfadinstanz zu erzeugen. Eine "Aktualisierungs"-Registrierungs-Anfrage wird verwendet, um eine Pfadinstanz aufzufrischen und um im Cachespeicher aufgenommene dynamische Kontextinformationen zu aktualisieren.
  • Ein CM sendet eine Registrierungs-Antwort zurück, um den Empfang einer Registrierungs-Anfrage zu quittieren, eine "Pfadinstanz" zu erstellen und Kontextinformationen einschließlich irgendwelcher "alten Mobilitätsbindungen" zurückzusenden. Registrierungs-Antwort-Nachrichten bauen den Schicht-2-Weiterleitungspfad in drahtlosen Verbindungen auf. Eine Registrierungs-Antwort wird immer abgehend auf dem Rückwärtspfad der entsprechenden Anfrage weitergeleitet.
  • Vorabregistrierungs-Anfrage- und Vorabregistrierungs-Antwort-Nachrichten werden verwendet, um Sicherheits-Berechtigungsnachweise zu erhalten und um den Authentifizierungszustand für einen 802.11-MN oder Sohn-AP vor der Registrierung zu erstellen.
  • Ein CM sendet eine Deregistrierungs-Anfrage-Nachricht, um eine Löschung einer alten Pfadinstanz anzufordern, wenn eine Station roamt. Eine Deregistrierungs-Anfrage wird immer von einem CM (SCM, LCM oder CCM) erzeugt und wird immer abgehend auf einem einzigen Zweig in der SWAN-Topologie weitergeleitet.
  • Ein AP oder CM sendet eine Deregistrierungs-Antwort zurück, um den Empfang einer Deregistrierungs-Anfrage zu quittieren, um die jeweilige Pfadinstanz zu löschen und um (optional) Kontext- und Statusinformationen zurück zusenden. Übergangs-Abrechnungsstatistiken und ein Aktivitäts-Zeitstempel werden (optional) in der Deregistrierungs-Antwort zurückgesendet.
  • Ein AP oder CM senden eine Abtrenn-Anfrage-Nachricht zu seinem Vater-CM, um anzuzeigen, dass eine "abgetrennte" Sohnstation "deregistriert" werden sollte. Eine Abtrenn-Anfrage-Nachricht wird eingehend weitergeleitet, bis sie entweder einen CM mit einer "neueren" Registrierungsaufzeichnung oder den CCM erreicht.
  • Ein CM kann eine Abtrenn-Antwort-Nachricht senden, um eine Abtrenn-Anfrage zu quittieren.
  • Eine Kontext-Anfrage-Nachricht wird verwendet, um Kontext-, Konfigurations- oder Verwaltungsinformationen zu bekommen oder einzustellen. Kontextnachrichten stellen einen Allzwecktransport für den Austausch von Informationen bereit. Eine Kontext-Anfrage kann zum Beispiel dazu verwendet werden, eine laterale Weiterreichung zu initiieren, wenn eine Station von einem alten LCM zu einem neuen LCM roamt. Der neue LCM oder der alte LCM können die Kontext-Anfrage senden. Eine Kontext-Anfrage, die von dem alten LCM erzeugt wird, kann Kontext- und Konfigurationsinformationen enthalten. Eine Kontext-Anfrage-Nachricht kann auch verwendet werden, um Mobilitätskontext für einen MN zu SCMs oder APs prädiktiv weiterzuleiten. [Eine Kontext-Anfrage, die verwendet wird, um Informationen zu "bekommen", enthält eine oder mehrere "Anfrage"-TLVs.]
  • Eine Kontext-Antwort-Nachricht wird verwendet, um eine Kontext-Anfrage-Nachricht zu quittieren. Sie wird auch dazu verwendet, Statusinformationen (wie z. B. für eine "Einstellen"-Anfrage) oder Kontext-, Konfigurations- oder Managementinformationen (z. B. für eine "Bekommen"-Anfrage) für eine entsprechende Kontext-Anfrage-Nachricht zurückzusenden.
  • Eine Pfadaktualisierungs-Anfrage-Nachricht wird verwendet, um den rückwärts gelernten Pfad zwischen einer drahtlosen Station und jedem Korrespondenz-Host erneut einzurichten, wenn die drahtlose Station von einem alten AP zu einem neuen AP innerhalb eines einzigen Teilnetzes roamt. Die Pfadak tualisierungs-Anfrage wird von dem neuen AP zu dem alten AP mit der Quellen-802-Adresse der Station gesendet, die geroamt ist.
  • Eine Pfadaktualisierungs-Antwort-Nachricht wird optional verwendet, um eine Pfadaktualisierungs-Anfrage-Nachricht zu quittieren, und wird verwendet, um Übergangskontextinformationen direkt von einem "alten AP" zu einem "neuen AP" zu transferieren.
  • Eine Pfadüberprüfungs-Nachricht wird verwendet, um einen zuverlässigen Pfadaktualisierungsmechanismus zu implementieren (d. h., um verloren gegangene Pfadaktualisierungs-Anfrage-Nachrichten zurück zu gewinnen).
  • Eine Ablaufverfolgungs-Anfrage-Nachricht wird für das SWAN-Pfad-Testen, die Antwortzeitanalyse und die Stationsverfolgung verwendet.
  • Eine Ablaufverfolgungs-Antwort wird verwendet, um eine Ablaufverfolgungs-Anfrage zu quittieren.
  • AAA-Nachrichten sind eingekapselte 802.1X-EAPOL-Nachrichten, die typischerweise für die Authentifizierung verwendet werden. Alternativ dazu können die AAA-Nachrichten auch von der Art sein, dass sie den Beginn (START) oder das Ende (ERFOLG) eines AAA-Nachrichtenaustausches bezeichnen. Schließlich sind AAA-Nachrichten auch eingekapselte Cisco-Abrechnungsnachrichten, die typischerweise von dem AP verwendet werden, um die Sitzungsabrechnung zu aktualisieren, die von dem AS verwaltet wird. Wenn der MN die zentrale Schlüsselverwaltung von Cisco (CCKM; Cisco's Central Key Management) verwendet, wird eine anfängliche Schlüsselerstellung zwischen dem MN und dem MN-Authentifikator dadurch ausgelöst, dass der MN Authentifikator einen 4-Wege-Handshake initiiert, indem er dem MN eine EAPOL-Schlüssel-Nachricht mit einer 16-Byte-Nonce sendet. Um dies zu erzielen, wird eine Nonce von dem MN Authentifikator zu dem AP mittels einer AAA-Erfolgsnachricht weitergereicht. Einzelheiten der Schlüsselerstellung sind in der Fast Handoff Protocol Specification [8] beschrieben. Dieses ist die einzige EAPOL-Schlüssel-Nachricht, die von der SWAN-Topologie erzeugt wird, alle anderen ergeben sich aus der 802.1X-EAP-Authentifizierung.
  • AAA-Nachrichten sind WLCCP-Einkapselungen von 802.1X-EAPOL- oder Cisco-Sitzungsabrechnungs-Nachrichten und folgen deshalb nicht der Anfrage-Antwort-Norm. Aber da Authentifikatoren Authentifizierungsfehlschläge erfassen können, kann das Status-Feld, das in den abgehenden Nachrichten bereitgestellt wird, mehr Informationen bereitstellen, um den Authentifizierungsstatus zu reflektieren.
  • Pfad-Init-Anfrage-, -Antwort, -Bestätigung, -Ack. Pfad-Init-Nachrichten werden für die IN-Pfad-Authentifizierung verwendet, wobei ein IN gegenseitig einen Pfad-CTK mit jedem seiner Vorgänger authentifiziert und erstellt. Der notwendige Pfad-Authentifizierungs-4-Wege-Handshake kann aus 1) einem Pfad-Init-Anfrage-/Antwort-Austausch gefolgt von einem anfänglichen Registrierungs-Anfrage-/Antwort-Austausch oder 2) einem Pfad-Init-Anfrage-/Antwort-/-Bestätigungs-/-Ack-Austausch bestehen. (Die zweite Sequenz wird verwendet, um die Pfad-CTKs für einen registrierten IN aufzufrischen).
  • WLCCP-Felder werden in einer Netz-Byte- und Bit-Ordnung definiert (d. h., mit dem dicken Ende anfangend). Die Bits in jedem Feld sind von links nach rechts mit "0" beginnend durchnumeriert (d. h., das höherwertige Bit ist das Bit "0").
  • WLCCP-Nachrichten können in Ethernet-Rahmen oder in UDP/TCP/IP-Pakete eingekapselt werden. Die Ethernet-Einkapselung kann für Nachrichten innerhalb eines Teilnetzes verwendet werden, die zwischen zwei APs oder einem AP und einem SCM gesendet werden, die sich in dem gleichen Teilnetz befinden. Die IP-Einkapselung muß für Nachrichten zwischen Teilnetzen verwendet werden. Der WLCCP Ethernet DIX Typ ist 0x872d. Der WLCCP UDP/TCP Protokollport ist Dezimal 2887. Es handelt sich dabei um einen "wohlbekannten" Protokollport, der bei der Internet Assigned Number Authority (Internet-Rufnummmern-Zuordnungsdienststelle) registriert ist.
  • Ein einziges WLCCP-Nachrichtenformat wird sowohl für die Ethernet-Einkapselung als auch für die IP-Einkapselung verwendet. Alle WLCCP-Nachrichten teilen sich ein gemeinsames Header-Format, das unten definiert wird. Das Header-Format ist so definiert, dass es mit existierenden Ethernet- und IP DDP-Nachrichtenformaten eindeutig ist. Der WLCCP-Nachrichtenkörper, der auf den gemeinsamen Header folgt, enthält SAP-spezifische Nachrichtentypen. Dieses Dokument definiert Nachrichtenformate für das WLCCP-"Kontext-Management"-SAP, welches "0" ist.
  • Ein beispielhafter, Ethernet-eingekapselter WLCCP-Kontext-Management-Rahmen 2000 ist in 20 gezeigt. Der Rahmen 2000 umfasst die Ziel-MAC-Adresse 2002, die Quell-MAC-Adresse 2004, den DIX-Typ (bei diesem Beispiel 0x872D) 2006, den gemeinsamen WLCCP-Header 2008, den WLCCP-Kontext-Management-Header 2010, typenspezifische Felder 2012 und optionale TLVs 2014.
  • Im Allgemeinem kann die Ethernet-Einkapselung für WLCCP-Nachrichten verwendet werden, die auf ein einziges Teilnetz beschränkt sind. Die IP-Einkapselung wird für alle Nachrichten zwischen Teilnetzen benötigt. Die Ethernet-Einkapselung wird für SCM-Bekanntmachungs-Nachrichten und Registrierungs-, -Deregistrierungs-, Abtrenn-, Pfadaktualisierungs- und Pfadüberprüfungs-Nachrichten innerhalb eines Teilnetzes verwendet. Die UDP/IP-Einkapselung wird für CCM-Bekanntmachungs-Nachrichten und Registrierungs-, -Deregistrierungs- und -Abtrenn-Nachrichten zwischen Teilnetzen verwendet. Für Ablaufverfolgungsnachrichten kann entweder die Ethernet- oder die UDP/IP-Einkapselung verwendet werden. Die Ethernet-, UDP/IP- oder TCP/IP-Einkapselung kann für Kontextnachrichten verwendet werden.
  • Beispielsdefinitionen für den Ethernet-eingekapselten WLCCP-Kontext-Management-Rahmen 2000 sind unten gezeigt:
    #define WLCCCP_DIX_ETHER_TYPE 0x872d
    #define WLCCP_DEF_UDP_PROTO_PORT 2887
    #define WLCCP_IP_MCAST_ADDRESS 0xE0000128 /* 224.0.1.40 */
    #define WLCCCP_MCAST_ADDRESS_IN (0x01, 0x40, 0x96, 0xff, 0xff, 0xC0) Beispielhafte WLCCP-Knoten-Typ-Definitionen
    #define WLCCP_NODE_TYPE_ANY 0
    #define WLCCP_NODE_TYPE_AP 1
    #define WLCCP_NODE_TYPE_SCM 2
    #define WLCCP_NODE_TYPE_LCM 4
    #define WLCCP_NODE_TYPE_CCM 8
    #define WLCCP_NODE_TYPE_ICN 0x10 /* Infrastruktur-Client-Knoten */
    #define WLCCP_NODE_TYPE_CLIENT 0x40
    #define WLCCP_NODE_TYPE_MULTI_MASK 0x8000
    Beispielhafte WLCCP-Port-Typ-Definitionen
    #define WLCCP_PORT_TYPE_ETHER 1
    #define WLCCP_PORT_TYPE_INTERNAL 2
    #define WLCCP_PORT_TYPE_DOT11 0x80
    #define WLCCP_PORT_TYPE_DOT11A 0x81
    #define WLCCP_PORT_TYPE_DOT11B 0x82
    #define WLCCP_PORT_TYPE_DOT11G 0x83
  • Ein "interner" Port ist ein logischer Port, der zwischen einem AP und einem SCM existiert, die in der gleichen Vorrichtung angeordnet sind.
    #define WLCCP_PORT_COST_ETHER 10
    #define WLCCP_PORT_COST_INTERNAL 10
    #define WLCCP_PORT_COST_DOT11 50
    #define WLCCP_PORT_COST_DOT11A 30
    #define WLCCP_PORT_COST_DOT11B 50
    #define WLCCP_PORT_COST_DOT11G 40
    1.1.1 Beispielhafte sonstige Konstanten
    #define DEF_SCM_ADVERTISE_PERIOD FIVE_SECONDS
    #define DEF_SCM_LISTEN_TIME 4 *
    DEF_SCM_ADVERTISE_PERIOD
    #define MAX_SCM_ELECT_TIME 6 *
    DEF_SCM_ADVERTISE_PERIOD
    #define MAX_SCM_AGE 8 *
    DEF_SCM_ADVERTISE_PERIOD
  • Nun wird Bezug auf 21 genommen. Darin ist eine Tabelle gezeigt, die die Felder für einen WLCCP-Nachrichten-Header 2100 veranschaulicht.
  • Die Spalten umfassen den Feldnamen 2102, den Offset 2104, die Größe 2106 und eine Beschreibung 2108 jedes Feldes in dem Nachrichten-Header 2100.
  • Die Länge des festgelegten WLCCP-Headers 2100 beträgt 28 Bytes. Die Felder Protokoll ID/Version 2110, WLCCP SAP 2112 und Zielknotentyp 2114 sind allen WLCCP SAPs gemeinsam. Die restlichen festen Felder sind allen Kontext-Management-Rahmen gemeinsam (d. h., allen Rahmen, die in diesem Dokument definiert sind). Wenn das Relay Flag auf EIN gesetzt ist, dann folgt auf den Header sofort ein Relay-Knoten-ID-Feld von 8 Bytes.
  • #define WLCCP PROTO ID 0xc0
  • Die WLCCP-Protokoll-ID 2110, 0xC0, ist so definiert, dass sich WLCCP- und DDP-Nachrichten den gleichen DIX-Ethernet-Typ und UDP-Protokoll-Port teilen können. Der DDP-Nachrichten-Header ist im Anhang B definiert.
  • Die Felder des Zielknotentyps 2114 und des WLCCP SAP 2112 werden verwendet, um das innere Ziel in der Vorrichtung auszuwählen, das von der Ethernet- oder IP-Zieladresse identifiziert wird. Der Sender muß den Zielknotentyp 2114 auf den Knotentyp des direkten Empfängers einstellen, bevor er eine WLCCP-Nachricht sendet. Der Zielknotentyp 2114 kann "0" sein, wenn der SAP das innere Ziel eindeutig identifiziert.
  • Das Feld Hop-Zählung (hop count) 2116 enthält die Anzahl an WLCCP-Hops (minus eins) zwischen dem Absender und dem Antwortenden. Der Absender oder der Antwortende muß die Hop-Zählung auf "0" initialisieren. Die Hop-Zählung wird von jedem Zwischenkonten auf dem Pfad zu dem Absender oder dem Antwortenden inkrementiert. Eine Nachricht wird verworfen, wenn die Hop-Zählung WLCCP_MAX_HOP_COUNT überschreitet.
    #define WLCCP_MAX_HOP_COUNT 25
    #define WLCCP_PROTO_VERSION 1
    #define WLCCP_CONTEXT_MGMT_SAP 0x00 /* WLCCP (Mobilitäts-/Kontextsteuerung) */
    #define WLCCP_SECURITY_SAP 0x01
    #define WLCCP_RRM_SAP 0x02 /* Funkressourcenmanagement */
    #define WLCCP_QOS_SAP 0x03
    #define WLCCP_NM_SAP 0x04 /* Netzmanagement *1
    #define WLCCP_MIP_SAP 0x05
    Definitionen des WLCCP-Nachrichten-Typs 2118:
    #define WLCCP_TYPE_SCM_ADVERTISE 1
    #define WLCCP_TYPE_CCM_ADVERTISE 2
    #define WLCCP_TYPE_REG 3
    #define WLCCP_TYPE_DEREG 4
    #define WLCCP_TYPE_DETACH 5
    #define WLCCP_TYPE_CONTEXT 6
    #define WLCCP_TYPE_PATH_UPDATE 7
    #define WLCCP_TYPE_PATH_CHECK 8
    #define WLCCP_TYPE_PREREG 9
    #define WLCCP_TYPE_TRACE 10
    #define WLCCP_TYPE_EAP_AUTHEN 11
    #define WLCCP_TYPE_PATH_AUTHEN 12
  • WLCCP-"Antwort"-Nachrichtentypen sind gleich dem entsprechenden Anfragetyp, der mit WLCCP_TYPE_REPLY_MASK einem ODER unterzogen wird.
    #define WLCCP_TYPE_CONFIRM_MASK 0x80
    #define WLCCP_TYPE_REPLY_MASK 0x40
  • Das Flags-Feld 2120 wird wie folgt verwendet:
    Das Retry Flag (Flag für den erneuten Versuch) wird in zurückübertragenen bzw. erneut übertragenen Anfrage- oder Bestätigungsnachrichten auf EIN gesetzt. Die Nachrichten-ID in einer erneut übertragenen Nachricht ist dieselbe wie in der ursprünglichen Nachricht. Das Retry Flag wird in einer Antwort- oder Ack-Nachricht auf EIN gesetzt, wenn es in der entsprechenden Anfragenachricht auf EIN gesetzt ist.
  • Das Response-Req Flag (Antwort-Anfr.-Flag) wird in einer Anfragenachricht auf EIN gesetzt, um eine Antwort zu erbitten.
  • Das TLV Flag wird auf EIN gesetzt, um anzuzeigen, dass den festgelegten Feldern optionale TLV-Strukturen folgen.
  • Das Inbound Flag, das Outbound Flag und das Hopwise-Routing Flag bestimmen, wie eine WLCCP-Nachricht weitergeleitet wird (wie unten beschrieben werden wird).
  • Wenn das Root CM Flag (Wurzel-CM-FIag) in einer eingehenden Nachricht auf EIN gesetzt ist, dann wird die Nachricht immer zu dem CM an der Wurzel des gesamten Topologiebaums – dem "Wurzel-CM" – weitergeleitet. Wenn das Root CM Flag in einer abgehenden Nachricht auf EIN gesetzt ist, dann stammte die Nachricht von dem Wurzel-CM.
  • Wenn das Relay Flag (Übertragungs-Flag) auf EIN gesetzt ist, dann folgt auf den WLCCP-Header sofort ein 64-Bit-Relay-Knoten-ID-Feld (ein 16-Bit-Knotentyp, gefolgt von einer 48-Bit-Knotenadresse).
  • Das MIC Flag ist auf EIN in einer Nachricht gesetzt, die authentifiziert werden muß und eine WTLV_MIC TLV enthält.
  • Die Responder Node Type Bits (Bits des Knotentyps des Antwortenden; im Folgenden 'Antwortender-Knoten-Typ' genannt) enthalten den Knotentyp des WLCCP-Knoten, der die ursprüngliche Antwortnachricht erzeugt hat.
  • Die Absender-Knoten-ID (Originator Node ID; Knoten-ID des Absenders) 2122 identifiziert im Allgemeinen den Knoten, der eine Anfragenachricht ursprünglich verfasst hat. Die Antwortender-Knoten-ID (Knoten-ID des Antwortenden) (Responder Node ID) 2124 identifiziert im Allgemeinen das Ziel einer Anfragenachricht und die Quelle einer entsprechenden Antwortnachricht. In einer WLCCP-Registrierungsnachricht für einen MN ist die Absender-Knoten-ID die 802-Adresse des MN. Die Antwortender-Knoten-ID kann in Registrierungsanfrage-, Bekanntmachungsanfrage- oder Abtrennanfrage-Nachrichten"0" sein. Die Antwortender-Knoten-ID kann in jeder IP-eingekapselten Anfragenachricht"0" sein. Die Antwortender-Knoten-ID identifiziert die Quelle einer verlangten oder unverlangten Bekanntmachungs-Antwortnachricht.
  • Die Hop-Quellen-Knoten-ID enthält die WLCCP-Knoten-ID der Hop-Quelle einer Anfrage- oder Antwortnachricht.
  • Optionale Parameter können auf die festgelegten Feldern in jeder WLCCP-Nachricht folgen. Optionale Parameter liegen in dem "TLV"-Format vor, wie es in 22 gezeigt ist.
  • Das Feld des TLV-"Typs" 2210 enthält ein Container Flag, ein Encrypted Flag (Verschlüsselt-Flag), ein Request Flag (Anfrage-Flag), eine Gruppen-ID und eine Typ-ID. Bei einer "Anfrage-TLV" ist das Request Flag in dem Typ-ID-Feld auf EIN gesetzt.
    #define WLCCP_TLV_CONTAINER_MASK 0x8000
    #define WLCCP_TLV_ENCRYPTED_MASK 0x4000
    #define WLCCP_TLV_GROUP_MASK 0x0300
    #define WLCCP_TLV_REQUEST_MASK 0x0080
    #define WLCCP_TLV_TYPE_MASK 0x007f
  • TLV-Gruppen-IDs werden verwendet, um TLVs hierarchisch zu gruppieren. Eine Gruppen-ID kann verwendet werden, um das Software-Modul in dem Zielknoten zu identifizieren, das den jeweiligen TLV-Typ verarbeiten muß.
  • Das Request Flag ist in einer TLV in einer WLCCP-Anfragenachricht auf Ein gesetzt, um "Informationen" von dem Ziel-WLCCP-Knoten "anzufordern". Bei einer "Anfrage-TLV" ist das Request Flag auf EIN gesetzt.
  • Das TLV Container Flag kann verwendet werden, um feste Attribute und andere optionale TLVs zu einer einzigen "Container-TLV" zu gruppieren. Das Container Flag sollte in einer TLV nur dann auf EIN gesetzt sein, wenn auf irgendwelche benötigten TLV-Felder andere optionale TLVs folgen. Container-TLVs können gebündelt werden. TLV Gruppen-IDs:
    #define WTLV_WLCCP_GROUP_ID 0x00
    #define WTLV_SECURITY_GROUP_ID 0x01
    #define WTLV_RRM_GROUPD_ID 0x02 /* Funkressourcenmanagement */
    #define WTLV_QOS_GROUP_ID 0x03
    #define WTLV_NM_GROUP_ID 0x04 /* Netzmanagement */
    #define WTLV_MIP_GROUP_ID 0x05
  • WLCCP TLV Formate sind in den unten aufgeführten Tabellen definiert. Die erste Reihe in jeder Tabelle enthält den TLV-Namen, die TLV-ID und die TLV-Beschreibung. Die Beschreibung enthält eine Liste von Nachrichtentypen, die die jeweilige TLV enthalten können. Die Felder Typ und Länge sind in den Felddefinitionen nicht enthalten.
    WTLV_NULL 0x0000 Eine NULL TLV kann verwendet werden, um eine Nachricht für eine gerade Ausrichtung aufzufüllen. Die Länge muß wenigstens '4' betragen.
    WTLV_CONTAINER 0x0001 Die generische "Container"-TLV wird verwendet, um beliebige TLVs logisch zu gruppieren.
    WTLV_AP_PORT_INFO 0x0002 Der Typ, der Modus und die Adresse eines AP-Ports. Nachrichten: Enthalten in einer AP_PORT_LIST TLV in einer AP-Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    Typ 4 1 1 = Ethernet, 2 = intern, 0x80 = 802.11, 0x81 = 802.11a, 0x82 = 802.11b, 0x83 = 802.11g
    Modus 5 1 1 = Vater, 2 = Sohn, 3 = Vater/Sohn 0x80 = Primäre Port-Maske
    Adresse 6 6 802 Hardware-Adresse
    NIC ID 12 2 Eine ganze Zahl, die intern verwendet wird, um den NIC-Typ zu identifizieren (z. B. Venus Funk)
    Version String TLV (optional) 14 N
    WTLV_IPV4_SUBNET_ID 0x0003 IP-Teilnetz-Adresse. Nachrichten: Enthalten in einer SCM-Bekanntmachungsantwort, um die IP-Adresse und das Teilnetz des SCM bekannt zu geben. Optional enthalten in einer PMIP_SSID_LIST TLV in einer Registrierungsanfrage, um eine PMIP SSID an ein Teilnetz zu binden.
    Feldname Offset Größe Feldbeschreibung
    IPv4-Adresse 4 4 IPv4-Adresse
    Präfixlänge 8 1 Anzahl an Bits in der Teilnetzmaske
    Flags 9 1 (reserviert – muß 0 sein)
    WTLV_SEC_LAN_ADDR_LIST 0x0004 Eine Liste von Ethernet-Adressen von Stationen in einem sekundären LAN. Nachrichten: WLCCP-designierte Brücken-Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    Zählung 4 2 Anzahl an Adressen in der Liste
    VLAN ID 6 2 VLAN ID des von sekundären LAN. Ein Wert "0" wird verwendet, um das "native VLAN" anzuzeigen.
    Adressenliste 8 N × 6 Eine Liste von Ethernet-Adressen.
    WTLV_MCAST_ADDR_LIST 0x0005 Eine Liste von aktivierten Multicast-Ethernet-Adressen. Nachrichten: Sohn-AP-Registrierungsanfrage (Implementierung ist optional)
    Feldname Offset Größe Feldbeschreibung
    Zählung 4 2 Anzahl an Adressen in der Liste
    Adressenliste 6 N × 6 Eine Liste von Multicast-Ethernet-Adressen.
    WTLV_IPV4_MCAST_ADDR_LIST 0x0006 Eine Liste von aktivierten Multicast-IPv4-Adressen. Nachrichten: AP-Registrierungsanfrage (Implementierung ist optional)
    Feldname Offset Größe Feldbeschreibung
    Zählung 4 2 Anzahl an Adressen in der Liste
    Adressenliste 6 N × 4 Eine Liste von Multicast-IPv4-Adressen.
    WTLV_AP_PORT_LIST 0x0007 Eine Liste von AP_PORT_INFO TLVs (siehe oben). Nachrichten: AP-Registrierungsanfragen
    Feldname Offset Größe Feldbeschreibung
    Zählung 4 2 Anzahl an AP-Ports
    Portliste 6 N × 16 Eine Liste von AP PORT INFO TLVs.
    WTLV_SSID 0x0008 Die SSID eines 802.11 "Knotens eines Anfragenden" (im Folgenden 'Anfragender-Knoten' genannt). Wenn das "Broadcast Translation" Flag auf EIN gesetzt ist, dann hat die Station eine Broadcast-SSID verwendet. Nachrichten: Vorabregistrierungs- und Registrierungsanfragen und -antworten
    Feldname Offset Größe Feldbeschreibung
    Flags 4 1 Bit 0 – AAA zugewiesen (in einer Antwortnachricht auf EIN gesetzt, um einen MN zu der SSID zuzuweisen) Bit 1 – Broadcast Translation Bit 2 – IN WLCCP SSID Bit 3–7 – (reserviert – muß null sein)
    Länge 5 1 SSID-Länge (Max. Länge = 32)
    SSID 6 N 802.11 SSID
    WTLV_IPV4-ADDRES 0x0009 Die IPv4-Adresse eines "Anfragender-Knotens" – registriert in einer Anfragenachricht oder zurückgesendet in einer Antwortnachricht. Nachrichten: Vorabregistrierungs-, Registrierungs-, Kontextanfragen/-antworten
    Feldname Offset Größe Feldbeschreibung
    IP-Adresse 4 4 IPv4-Adresse
    WTLV_PARENT_AP_BSSID 0x000A Die BSSID für den BSS eines 802.11 MN oder eines AP-"Anfragender-Knotens". Nachrichten: Registrierungsanfrage für eine 802.11 Station
    Feldname Offset Größe Feldbeschreibung
    BSSID 4 6 802.11 BSSID der aktuellen BSS der Station
    WTLV_OLD_AP_BSSID 0x000B Die vorhergehende BSSID eines 802.11 MN- oder AP-"Anfragender-Knotens" aus dem "aktuellen AP"-Element in einer 802.11 Anfrage bezüglich einer erneuten Verbindung. Nachrichten: Vorabregistrierungs- oder Registrierungsanfrage für eine 802.11 Station.
    Feldname Offset Größe Feldbeschreibung
    BSSID 4 6 802.11 BSSID des vorhergehenden BSS der Station
    WTLV_PMIP_SSID_LIST 0x000C Eine Container-TLV, die SSID TLVs und für jede SSID TLV eine Liste von 0 oder mehr MIPV4-AGENT TLVs oder eine SUBNET_ID_TLV enthält. Die optionale SUBNET_ID ist nur enthalten, wenn ein HA nicht bekannt ist, aber die Teilnetzadresse bekannt ist. Nachrichten: SCM- oder AP-Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    SSID TLV 4 N SSID TLV, die eine PMIP SSID enthält (wiederholt für jede PMIP SSID)
    MIPV4_AGENT TLV 4 + N 6 MIPv4 HA für das Standard-Teilnetz, gebunden an die SSID (wiederholt für jeden HA in dem Teilnetz).
    WTLV_PARENT_CM (Anfrage) 0x008E Ein SCM verwendet eine Anfrage-PARENT_CM TLV, um einen Vater-CM (LCM oder CCM) von dem CCM anzufordern. Wenn der SCM vorher mit einem Vater-CM verbunden war, dann muß das Knoten-ID-Feld die Knoten-ID des alten Vater-CM enthalten; ansonsten muß das Knoten-ID-Feld "0" sein. Nachrichten: Kontextanfrage, gesendet von einem SCM zu dem CCM.
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Knoten-ID eines alten Vater-CM oder "0".
    IPv4-Adresse 12 4 IPv4-Adresse eines alten Vater-CM oder "0".
    WTLV_PARENT_CM 0x000E Der CCM verwendet eine PARENT_CM TLV, um einen SCM einem Vater-CM (LCM oder CCM) zuzuweisen. Nachrichten: Kontextantwort, gesendet von dem CCM zu einem SCM.
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Knoten-ID des Vater-CM. Eine Knoten-ID von "0" wird verwendet, um "kein Vater-CM" anzuzeigen (d. h., selbständiger Modus).
    IPv4-Adresse 12 4 IPv4-Adresse des Vater-CM.
    WTLV_DELETED_NODE_LIST 0x000F Eine Liste von Knoten-IDs von gelöschten Knoten. Ein Vater-SCM oder -AP verwendet die DELETED_NODE_LIST TLV, um einem Sohn-AP mitzuteilen, dass er sich erneut registrieren muß. Nachrichten: SCM-Bekanntmachungsantwort
    Feldname Offset Größe Feldbeschreibung
    Zählung 4 2 Die Anzahl der gelöschten Knoten.
    Knoteninstanz 6 12 Eine 8-Byte-Knoten-ID gefolgt von einer 4-Byte-Pfad-ID eines gelöschten Knotens. Das Knoteninstanzfeld wird für jeden gelöschten Knoten wiederholt.
    WTLV_MIPV4_AGENT 0x0010 Die IP-Adresse, Teilnetz-Präfixlänge und Fähigkeiten eines MIP HA. Nachrichten: Enthalten in einer PMIP SSID LIST TLV in einer SCM- oder AP-Registrierungsanfrage.
    Feldname Offset Größe Feldbeschreibung
    IPv4-Adresse 4 4 IPv4-Adresse des MIP Agenten
    Präfixlänge 8 1 Anzahl an Bits in der Teilnetzmaske des Agenten.
    Flags 9 1 Bit 0 = Statisch konfiguriert Bits 1–7 – (reserviert – müssen null sein)
    Fähigkeits-Bits 10 2 Die Fähigkeits-Bits sind die gleichen wie die letzten 16 Bits in einer MIPv4-Agent-Bekanntmachungs-Erweiterung: Bits 0–8 – R, B, H, F, M, G, H, r, T Bits 9–15 – (reserviert – müssen null sein)
    Alter 12 2 Verstrichene Zeit in Sekunden, seit eine Bekanntmachung von dem Agenten empfangen worden ist.
    WTLV_OLD_AP_BINDINGS 0x0011 Die Knoten-ID, IPv4-Adresse und BSSID des alten AP für einen 802.11 "Anfragender-Knoten". Nachrichten: Vorabregistrierungs- oder Registrierungsantwort für eine 802.11 Station.
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Knoten-ID des alten AP
    IP-Adresse 12 4 IPv4-Adresse des alten AP
    BSSID 16 6 802.11 BSSID der alten BSS
    WTLV_HOME_SUBNET 0x0012 Die IP-Adresse, der MIP HA und die Teilnetz-Präfixlänge eines Proxy MIP MN. Nachrichten: Registrierungsanfrage/-antwort
    Feldname Offset Größe Feldbeschreibung
    IPv4-Adresse 4 4 IPv4-Adresse des MN
    Präfixlänge 8 1 Anzahl an Bits in der Heimat-Teilnetz-Maske des MN. Das Feld kann "0" sein, wenn die Maske nicht bekannt ist.
    Flags 9 1 Bit 0 – At Home Flag (auf EIN gesetzt, wenn sich der MN zuhause befindet) Bits 1–7 – (reserviert – müssen null sein)
    HA-Adresse 10 4 IPv4-Adresse des HA des MN. Es handelt sich um den Standard-HA für das Teilnetz des MN in einer Anfrage. Es ist der zugewiesene HA in einer Antwort.
    WTLV_LOST_LINK 0x0013 Die LOST_LINK TLV wird verwendet, um eine verlorene Infrastrukturverbindung zu berichten. Nachrichten: eine verlorene sekundäre Verbindung wird in einer Registrierungsanfrage berichtet. Eine verlorene primäre SCM-Verbindung wird dem CCM in einer Kontextanfrage berichtet.
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Vater-Knoten-ID, wenn das Primary Flag auf EIN gesetzt ist; ansonsten die Sohn-Knoten-ID
    Grund 12 1 Grundcode. 0 = Allgemeiner Fehler, 1 = Retry-Fehler, 2 – Aufrechterhaltungs-Timeout, 3 = Administrative Beendigung der Registrierung, 4 = Beacon Timeout, 5 = Pfadkosten
    Flags 13 1 Bit 0 = primär (für eine primäre Verbindung ein EIN gesetzt; auf AUS gesetzt für eine sekundäre Verbindung) Bits 1–7 – (reserviert – müssen Null sein)
    WTLV_VERSION_STRING 0x0014 Die Hardware- und Software-Version eines AP- oder CM-"Anfragender-Knotens". Nachrichten: Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    HW-Version Länge 4 1 HW-Versions-String-Länge in Bytes. Die Länge kann "null" Stopfbytes enthalten
    HW-Version 5 M HW-Versions-String
    SW Version Länge 5 + M 1 SW-Versions-String-Länge in Bytes. Die Länge kann "null" Stopfbytes enthalten.
    Sw Version 6 + M N SW Versions-String
    WTLV_NAME 0x0015 Die Netzwerkzugangskennung (NAI) oder der Bereichsname eines MN, AP oder CM-"Anfragender-Knotens". Nachrichten: Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    Namentyp 4 1 1 = NAI, 2 = Bereichsname
    Namenlänge 5 1 Namenlänge in Bytes
    Name 6 N Ein String, der die NAI- oder den Bereichsnamen (domain name) enthält.
    WTLV_SYSTEM_ID 0x0016 System-ID-Werte. Nachrichten: Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    Produkt-ID 4 2 Eine ganze Zahl, die intern verwendet wird, um den Produkttyp zu identifizieren (z. B. Ivory AP)
    Version String TLV (optional) NA M Optionale VERSION_STRING TLV – die die HW- und/oder die SW-Version enthalten kann.
    System Name TLV (optional) NA N Optionale NAME TLV – die den Systemnamen enthält.
    WTLV_NODE_ID_LIST 0x0018 Eine Liste von Knoten-IDs, mit einem Eintrag für jeden Knoten in dem Pfad zu dem Wurzel-CM. Nachrichten: Pfadinitialisierungsanfrage/-antwort
    Feldname Offset Größe Feldbeschreibung
    Zählung 4 2 Die Anzahl an Knoten-IDs in der Liste.
    Knoten-ID-Liste 6 8 × N Eine Liste von Knoten-IDs.
    WTLV_MIP4_REG_REQ 0x0019 Ein SCM sendet eine MIP_REG_REQ Container TLV, um einen Vater-AP zu veranlassen, eine MIP-Registrierungsanfrage für den Anfragender-Knoten zu senden. Eine MIP"Deregistrierungsanfrage" wird gesendet, wenn der MN "zuhause" ist. Nachrichten: MN-Registrierungsantwort
    Feldname Offset Größe Feldbeschreibung
    Flags 4 2 Bit 0 = At Home Flag (auf EIN gesetzt, wenn der MN zuhause ist) Bits 1–15 – (reserviert – müssen Null sein)
    Heimat-Teilnetz-Bindungen 6 N HOME_SUBNET TLV (Es kann möglich sein, nur ein Flag in dem HOME_SUBNET TLV zu verwenden)
    WTLV_AUTH_METHOD 0x001A Das/Die Authentifizierungsverfahren, das/die für den "Anfragender-Knoten" verwendet wird/werden. Das Fast Reauthentication Flag ist auf EIN gesetzt, wenn der Knoten eine schnelle erneute Authentifizierung verwendet hat. Nachrichten: Vorabregistrierungs- und Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    Grundtyp 4 2 Keiner = 0, Offen = 0x0001, Gemeinsamer Schlüssel = 0x0002, LEAP = 0x0004, EAP = 0x0008, MAC-Adresse = 0x0010, Alternativ = 0x0020, Client = 0x0040, Unbekannt = 0x8000
    EAP-Typ 5 1
    Schnelle erneute Authentifizierung 6 1 Bit 0 – Fast Reauthentication Flag Bits 1–7 – Fast Reauthen. Typ. CCMK = 1
    WTLV_IPV4_HOP_ADDRESS 0x001B Die IPV4_HOP_ADDRESS TLV wird verwendet, um die IP-Adresse eines AP bekannt zu geben. Nachrichten: SCM-Bekanntmachungsantwort, erzeugt von einem AP.
    Feldname Offset Größe Feldbeschreibung
    IP-Adresse 4 4 AP IPv4-Adresse
    WTLV_EAP_IDENTITY 0x001C Der EAP-Identitäts-String des "Anfragender-Knotens". Nachrichten: Vorabregistrierungs- und Registrierungsanfrage
    Feldname Offset Größe Feldbeschreibung
    EAP-ID-Länge 4 1 Länge der EAP ID in Bytes.
    EAP-ID 5 N Ein String, der die EAP ID aus der EAP-Identitäts-Antwortnachricht von dem Knoten enthält.
    WTLV_MN_1X_AUTHEN 0x001E Die Knoten-ID und die IPv4-Adresse des 802.1X MN-Authentifikators. Nachrichten: IN-Registrierungsantwort und SCM-Bekanntmachungsantwort. Die TLV ist in den SCM-Bekanntmachungs-Nachrichten enthalten, um eine MN-Authentifikator-Änderung bekannt zu geben.
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Knoten-ID des 802.1X MN Authentifikators.
    IPv4-Adresse 12 4 IPv4-Adresse des 802.1X MN Authentifikators.
    WTLV_ROOT_CM_INFO 0x001F Die Knoten-ID und die IPv4-Adresse des WLCCP-Wurzel-CM. Nachrichten: SCM-Bekanntmachungs-Antwort
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Knoten-ID des Wurzel-CM.
    IPv4-Adresse 12 4 IPv4-Adresse des Wurzel-CM.
    WTLV_REPLY_STATE 0x0020 Opake Transaktionszustandsinformationen. REPLY_STATE TLVs, die in Anfragenachrichten enthalten sind, müssen der Reihe nach in Antwortnachrichten kopiert werden.
    Feldname Offset Größe Feldbeschreibung
    Knoten-ID 4 8 Knoten-ID des Knotens, der die TLV eingegeben hat.
    Zustand 12 N Opake Transaktionszustandsinformationen.
    WTLV_MN_REG 0x0021 Eine MN_REG TLV enthält jegliche Informationen, die notwendig sind, um einen MN zu registrieren. Sie ist in einer MN_REG_LIST TLV enthalten. Jegliche Felder, die nicht beschrieben sind, sind genauso definiert wie die entsprechenden Felder in dem Registrierungs-Header.
    Feldname Offset Größe Feldbeschreibung
    Anfragender-Knoten ID 4 8 WLCCP-Knoten-ID des MN.
    Pfad-ID 12 4 Enthält die Pfad-ID, die dem MN zugewiesen ist, in einer Antwortnachricht.
    Registration Flags 16 2
    VLAN ID 18 2
    Status 20 1
    Alter 21 1 Sekunden, seit der MN zum letzten Mal aktiv war.
    Optionale TLVs 22 N Optionale TLVs (z. B. IPV4_ADDRESS oder SSID) können eingeschlossen werden, indem das Container Flag auf EIN gesetzt wird.
  • Irgendwelche Parameter, die nicht in der WTLV_MN_REG TLV enthalten sind, werden aus der Registrierungsnachricht oder der eingekapselten WTLV_MN_REG_LIST TLV entnommen.
    WTLV_MN_REG_LIST 0x0022 Eine Liste von MN_REG TLVs und o
    Feldname Offset Größe Feldbeschreibung
    MN_REG TLVs und andere optionale TLVs. 4 N Alle TLVs außer den MN_REG TLVs erstellen Standardparameterwerte für nachfolgende MN_REG TLVs.
  • Die unten aufgeführte Tabelle zeigt die Felder für eine SCM-Bekanntmachungs-Antwortnachricht.
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Hop-Adresse 28 6 Quell-802-Port-Adresse
    SCM-Flags 34 2 Bit 15 – Active Flag. Auf EIN gesetzt in Bekanntmachungen von dem aktiven SCM. Bit 14 – Unscheduled Flag (auf EIN gesetzt in außerplanmäßigen Bekanntmachungsnachrichten) Bit 13 – Unattached Flag* (Nicht-Angeschlossen-Flag) (auf EIN gesetzt in Bekanntmachungen von einem nicht angeschlossenen Knoten) Bit 12 – Layer 2 Update Flag (auf EIN gesetzt, wenn die WLCCP-Schicht-2-Pfadaktualisierungen aktiviert sind. Standardmäßig auf AUS gesetzt) Bits 0–11 – (reserviert – müssen null sein)
    SCM-Auswahl-Gruppe 36 1 (reserviert für zukünftige Verwendung – muß null sein)
    Anschlusszählung (Attach Count) 37 1 Anschlusszählung der Hop-Quelle
    SCM-Priorität 38 1 Bits 1–7 – SCM-Prioritätswert von 0 (niedrigster) bis 127 (höchster). Bit 0 – Preferred Flag – Auf AUS gesetzt, wenn der SCM der "bevorzugte SCM" ist.
    Brückenpriorität 39 1 Bits 1–7 – Brückenprioritätswert von 0 (höchster) bis 127 (niedrigster). Bit 0 – Bridge Disable Flag. Auf EIN gesetzt, um anzuzeigen, dass das sekundäre Überbrücken deaktiviert ist. Die Brückenpriorität wird verwendet, um die designierte WLCCP-Brücke in einem sekundären Nicht-STP-Ethernet LAN auszuhandeln.
    Instanz-Alter 40 4 Das "Instanzalter" des SCM, in Sekunden
    SCM-Knoten-ID 44 2 WLCCP-Knoten-ID des SCM
    Pfadkosten 50 2 Summe der Portkosten in dem Pfad zu dem SCM
    Hop-Zählung 52 1 Anzahl an drahtlosen Hops auf dem Pfad zu dem SCM
    Bekanntmachungs-Zeitraum 53 1 Die durchschnittliche Anzahl an Sekunden zwischen SCM-Bekanntmachungen.
    (Optionale TLVs) 54 N (benötige TLVs sind unten definiert)
    • *Ein Vaterknoten sendet eine SCM-Bekanntmachungs-Anfrage mit dem Unattached Flag, das auf EIN gesetzt ist, um Sohnknoten schnell davon zu informieren, dass er in den "nicht angeschlossenen" Zustand übergegangen ist. Wenn sein Anschluss beendet worden ist, weil der aktive SCM verloren gegangen ist, dann muß er auch die SCM-Knoten-ID auf '0' setzen.
  • Das Instanzalter-Feld enthält das "Alter" der Instanz des Knotens, der eine SCM-Bekanntmachungs-Antwortnachricht sendet, in Sekunden. (Siehe den Abschnitt mit dem Titel "Topologiezustandsinformationen" bezüglich einer Beschreibung einer "Instanznummer".)
  • Eine SCM-Bekanntmachungs-Antwortnachricht muß eine WTLV_SUBNET_ID TLV enthalten, die die IP-Adresse und die Teilnetzmaske des SCM enthält.
  • Eine SCM-Bekanntmachungs-Antwortnachricht muß eine WTLV_ROOT_CM_INFO TLV umfassen, die die IPv4-Adresse des Wurzel-CM enthält (der auch der 802.1X IN-Authentifikator ist).
  • Eine SCM-Bekanntmachungs-Antwortnachricht, die von einem AP gesendet wird, kann eine WTLV_IPV4_HOP_ADDRESS TLV umfassen, die die IP-Adresse des AP enthält.
    #define SCM_ADVERTISE_INTERVAL 5 /* Das Standard-SCM-Bekanntmachungs-Intervall beträgt 5 Sekunden. */
    #define SCM_INFINITE_PATH_COST 0xFFFF
    #define SCM_INFINITE_HOP_COUNT 0xFF
  • Die unten aufgeführte Tabelle zeigt die Felder für eine SCM-Bekanntmachungs-Anfragenachricht.
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header*
    Hop-Adresse 28 6 Quell-802-Port-Adresse
    (optionale TLVs) 34 N
  • Die unten aufgeführte Tabelle zeigt die Felder für eine Registrierungsanfrage-/-antwort-Nachricht.
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Relay-Knoten-ID 28 8 Relay-Knoten-Typ und -Knoten-Adresse
    802 Hop-Adresse 36 6 802-Quellport-Schnittstellen-Adresse.
    Anfragender-Knoten-ID 42 8 WLCCP-Knoten-ID des Knotens, der die Netzregistrierung "anfordert". Es ist die 802-Adresse eines MN in einer "Proxy"-Anfrage.
    Registration Sub Type Flags 50 1 Bit 7 – Initial Registration Flag Bit 6 – Proxy Registration Flag Bit 5 – List Registration Flag Bits 0–5 (reserviert – müssen null sein)
    Bridging Flags 51 1 Bit 7 – Secondary Bridge Flag Bit 6 – Unicast Flooding Flag Bit 5 – Multicast Flooding Flag Bit 4 – IP Multicast Flooding Flag Bits 0–3 – (reserviert – müssen Null sein)
    Registration Flags 52 2 Bit 15 – Authenticated Flag Bit 14 – (reserviert – muß null sein) Bit 13 – Proxy MIP Flag Bit 12 – L2-Pfad-Aktualisierung (0 = deaktivieren, 1 = aktivieren) Bits 0–11 – (reserviert – müssen null sein)
    Verzögerung 54 2 Zeit, seit der Knoten zum letzten Mal aktiv war, in Hundertstel Sekunden, in einer Anfragenachricht.
    Pfad-ID 56 4 Pfad-ID, erstellt von einem CM. Ein Wert von '0' wird verwendet, um "keine Pfad-ID" anzuzeigen.
    Lebenszeit 62 1 Registrierungslebenszeit in Minuten. Ein Wert von '0' wird verwendet, um eine "unbegrenzte" Lebenszeit anzuzeigen.
    Status 63 1 Registrierungsstatus in einer Antwortnachricht. 0–126 – guter Status 127 (reserviert) 128–254 – Fehlerstatus 255 – erweiterter Fehlerstatus (ein erweiterter Fehlerstatus ist in einer TLV enthalten)
    VLAN ID 64 2 Bit 3 – Assigned Flag. Auf EIN in einer Antwort gesetzt, wenn die VLAN ID von der Infrastruktur zugewiesen wurde. Bits 4–15 – VLAN ID des Anfragender-Knoten (kann 0 sein).
    (Optionale TLVs) 66 N
    #define WLCCP_DEF_AP_REG_LIFETIME 10 /* 10 Minuten */
    #define WLCCP_DEF_CM_REG_LIFETIME 10
    #define WLCCP_DEF_MN_REG_LIFETIME 0/* unbegrenzt */
  • Das Status-Feld enthält den Registrierungsstatus in einer Antwortnachricht. Werte von 0 bis 126 werden verwendet, um einen "guten" Status anzuzeigen. Das höherwertige Bit wird auf EIN gesetzt, um einen Fehlerstatus anzuzeigen. Werte von 128 bis 254 werden verwendet, um einen Fehlerstatus zurückzusenden. Ein Wert von 255 wird verwendet, um anzuzeigen, dass ein erweiterter Fehlerstatuscode in einer WTLV_STATUS TLV enthalten ist.
  • Registrierungs-Antwort-Status-Codes:
    • 0 – Allgemeiner guter Status
    • 0x80 – Allgemeiner Fehlerstatus
    • 0x81 – Nicht authentifiziert. Der Anfragender-Knoten ist nicht authentifiziert.
    • 0x82 – Pfadfehler. Ein Pfadfehler wurde entdeckt. Der Fehler wird zum Beispiel auftreten, wenn ein Vater- oder Relay-Knoten nicht registriert ist.
    • 0x83 – Ungültige Aktualisierung. Eine Aktualisierungs-Registrierungsanfrage passte nicht zu der aktuellen Pfadinstanz, oder eine Pfadinstanz existierte nicht.
    • 0x84 – Falsche Reihenfolge. Die Registrierungsanfrage wurde nicht sequentiell empfangen.
    • 0x85 – Ein MIC-Fehler ist aufgetreten.
    • 0x86 – Administrativ deaktiviert. Der Anfragender-Knoten ist administrativ deaktiviert.
    • 0x87 – Maximale Knoten. Die Registrierung wurde zurückgewiesen, weil die maximale Anzahl an registrierten Knoten überschritten wurde.
    • 0x88 – Speicher. Ein Registrierungsfehler ist aufgetreten auf Grund eines Mangels an internen Ressourcen.
  • Das Authenticated Flag ist in einer Anfrage für einen MN auf EIN gesetzt, um anzuzeigen, dass der MN von dem Vater-AP authentifiziert worden ist. Das Flag wird verwendet, um authentifizierte MNs zu registrieren, wenn ein AP von einem verteilten Modus in den Infrastrukturmodus übergeht. Es ist auch auf EIN gesetzt für einen MN, bei dem eine Authentifizierung nicht benötigt wird (d. h., offene Authentifizierung).
  • Das Proxy MIP Flag ist in einer Registrierungsnachricht für einen Proxy MIP MN auf EIN gesetzt.
  • Das L2 Path Update Flag ist auf EIN gesetzt, wenn WLCCP-Schicht-2-Pfadaktualisierungen aktiviert sind.
  • Die VLAN ID in einer anfänglichen Registrierungsanfrage für einen MN ist auf die Standard VLAN ID für die SSID des MN gesetzt. Die VLAN ID in einer anfänglichen Antwortnachricht für einen MN enthält eine zugewiesene VLAN ID, wenn das Assigned VLAN ID Flag auf EIN gesetzt ist. Die VLAN ID in einer Anfrage bezüglich eines Sohn-AP ist immer '0'. Die VLAN ID in einer anfänglichen Antwort für einen Sohn-AP ist die native VLAN ID des AP. (Ein Sohn-AP erbt seine native VLAN ID von seinem Vater-AP.) Die VLAN ID in einer Aktualisierungsanfrage oder -antwort kann '0' oder die aktuelle VLAN ID für den Anfragender-Knoten sein.
  • Eine WTLV_IPV4_ADDRESS_TLV enthält immer die IP-Adresse des Anfragender-Knotens. Die IP-Adresse ist in einer Anfrage bezüglich einer Registrierung davon mit der WLCCP-Infrastruktur enthalten. Die IP-Adresse ist in einer Antwort für einen MN enthalten, um diese zu dem neuen Vater-AP zu übertragen.
  • Eine anfängliche Registrierungsanfrage für einen MN muß eine WTLV_AUTH_METHOD TLV umfassen, die den MN-Authentifizierungstyp enthält.
  • Eine anfängliche Registrierungsanfrage für eine 802.11-Station (MN oder Sohn-AP) muß eine WTLV_SSID TLV umfassen, die die SSID aus der 802.11-Anfragenachricht der Station bezüglich einer erneuten Verbindung enthält.
  • Eine anfängliche Registrierungsanfrage für eine 802.11-Station (MN oder Sohn-AP) muß eine WTLV_PARENT_AP_BSSID TLV umfassen, die die BSSID des Vater-AP der Station enthält.
  • Eine anfängliche Registrierungsanfrage für eine 802.11-Station, die sich "neu verbunden" hat, muß eine WTLV_OLD_AP_BSSID TLV umfassen, die die BSSID aus dem Feld "Alter AP" in der jeweiligen 802.11-Anfrage-Nachricht bezüglich einer erneuten Verbindung enthält.
  • Eine Registrierungsanfrage für einen AP muß eine WTLV_AP_PORT_LIST Container TLV enthalten, die eine Liste von einer oder mehreren WTLV_AP_PORT_INTO TLVs enthält.
  • Eine Registrierungsantwort für eine 802.11-Station muß eine WTLV_OLD_AP_BINDINGS TLV enthalten, wenn die Station vorher mit einem "alten AP" verbunden war.
  • Die unten aufgeführte Tabelle zeigt das Format der Vorabregistrierungsanfrage-/-antwort-Nachricht.
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Relay-Knoten-ID 28 8 Relay-Knoten-Typ und -Knoten-Adresse
    Anfragender-Knoten-ID 36 8 WLCCP-Knoten-ID der Sohn-802.11-Station (MN oder Sohn-AP).
    Preregistration Flags 42 2 Bits 0–15 – (reserviert – müssen null sein)
    (reserviert) 44 1 (muß null sein)
    Status 45 1 Vorabregistrierungsstatus in einer Antwortnachricht. 0 – guter Status
    VLAN ID 46 2 Bits 0–2 (reserviert – müssen null sein) Bit 3 – Assigned VLAN Flag Bits 4–15 – VLAN ID des Anfragender-Knotens (kann 0 sein). Standard VLAN ID in der Anfragenachricht. Optional zugewiesene VLAN ID in der Antwortnachricht.
    (Optionale TLVs) 48 N
  • Die VLAN ID in einer Vorabregistrierungsanfrage für einen MN ist auf die Standard VLAN ID für die SSID des MN gesetzt. Die VLAN ID in einer Antwortnachricht für einen MN enthält eine zugewiesene VLAN ID, wenn das Assigned VLAN ID Flag auf EIN gesetzt ist. Die VLAN ID in einer Anfrage bezüglich eines Sohn-AP ist immer '0'. Die VLAN ID in einer Antwort für einen Sohn-AP ist die native VLAN ID des AP. (Ein Sohn-AP erbt seine native VLAN ID von seinem Vater-AP.)
  • Eine Vorabregistrierungsanfrage für eine 802.11-Station (MN oder Sohn-AP) muß eine WTLV_SSID TLV umfassen, die die SSID aus der 802.11-Anfragenachricht bezüglich einer (erneuten) Verbindung der Station enthält.
  • Eine Vorabregistrierungsanfrage für eine 802.11-Station, die sich "erneut verbunden" hat, muß eine WTLV_OLD_AP_BSSID TLV enthalten, die die BSSID aus dem Feld "Alter AP" in der jeweiligen 802.11-Anfragenachricht für eine erneute Verbindung enthält.
  • Eine Vorabregistrierungsantwort für eine 802.11-Station muß eine WTLV_OLD_AP_BINDINGS TLV enthalten, wenn die Station vorher mit einem "alten AP" verbunden war.
  • Unter Bezugnahme auf die unten aufgeführte Tabelle ist eine Deregistrierungsanfrage-/-antwort-Nachricht gezeigt.
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Relay-Knoten-ID 28 8 Relay-Knoten-Typ und -Knoten-Adresse
    Pfad-ID 36 4 Pfadkennung, erstellt von einem CM.
    Status 40 1 Ein "Grund"-Code in einer Anfrage; ein "Status"-Wert in einer Antwort. Das höherwertige Bit des Grundcodes ist in "administrativen" Deregistrierungsanfragen auf EIN gesetzt.
    Deregistration Flags 41 1 Bit 7 – L2-Pfadaktualisierung (0 = deaktiveren, 1 = aktivieren) Bits 0–6 – (reserviert – müssen null sein)
    Registrierungs-Nachricht-ID 42 2 Nachrichten-ID der letzten Registrierungsanfrage, die für den Knoten empfangen wurde.
    Zielknoten-ID 44 8 WLCCP-Knoten-ID des Knotens, dessen Pfadinstanz "gelöscht" werden muß.
    Aktivitäts-Zeitstempel 52 2 Anzahl an Sekunden, seit der Zielknoten das letzte Mal aktiv war, in einer Antwortnachricht.
    (Optionale TLVs) 54 N
  • Das Format der Abtrennanfrage-/-antwort-Nachricht ist unten gezeigt:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Relay-Knoten-ID 28 8 Relay-Knoten-Typ und -Knoten-Adresse
    Pfad-ID 36 4 Pfadkennung, erstellt von einem CM.
    Status 40 1 Ein "Grund"-Code in einer Anfrage; ein "Status"-Wert in einer Antwort.
    Detach Flags 41 1 Bit 7 – L2-Pfadaktualisierung (0 = deaktiveren, 1 = aktivieren) Bits 0–6 – (reserviert – müssen null sein)
    Anfragender-Knoten-ID 42 8 WLCCP-Knoten-ID des Knotens, dessen Pfadinstanz "gelöscht" werden muß.
    (Optionale TLVs) 50 N
  • Das Format der Pfadüberprüfungsanfrage-/-antwort-Nachricht ist in der unten aufgeführten Tabelle gezeigt:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Relay-Knoten-ID 28 8 Relay-Knoten-Typ und -Knoten-Adresse
    Pfad-ID 36 4 Pfadkennung, erstellt von einem CM.
    Status 40 1 Ein "Grund"-Code in einer Anfrage; ein "Status"-Wert in einer Antwort.
    Query Flags 41 1 (reserviert – muß null sein)
    Vater-Knoten-ID 42 8 Knoten-ID des Vater-AP, der die "Pfadüberprüfung" initiiert hat.
    (Optionale TLVs) 50 N
  • Die Verwendung der Pfadüberprüfung wird weiter unten definiert werden.
  • Die Pfadaktualisierungsanfrage-/-antwort-Nachricht ist unten gezeigt:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Pfad-ID 28 4 Pfadkennung, erstellt von einem CM.
    Update Flags 32 2 (reserviert – muß 0 sein)
    Vaterknoten-ID 34 8 Knoten-ID des neuen Vater-AP
    (Optionale TLVs) 54 N
  • Es sollte angemerkt werden, dass Verbindungstrennungs-Benachrichtigungs-Nachrichten (Disassociation Notification messages) an Stelle der Pfadaktualisierungsnachrichten verwendet werden können, wenn es nicht notwendig ist, Kontextinformationen direkt von einem alten AP zu einem neuen AP zu übertragen.
  • Das Format der Kontextanfrage-/-antwort-Nachricht ist in der unten angeführten Tabelle angegeben:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer WLCCP-Kontext-Management-SAP-Header
    (Optionale TLVs) 28 + N P
  • WLCCP-AAA-Nachrichten werden verwendet, um EAPOL-Nachrichten und proprietäre Abrechnungsnachrichten, z. B. Cisco-Abrechnungsnachrichten, einzukapseln, damit Nachrichten zu und von dem WLCCP-Sicherheits-SAP in den WLCPP-MN- oder -IN-Authentifikator weitergeleitet werden können. Zum Beispiel wird eine EAPOL-Nachricht eines Repeater-AP oder MN von seinem Vater-AP gemäß WLCCP eingekapselt. Außerdem kann ein AP den AS mit Sitzungsabrechnungsaufzeichnungen aktualisieren und muß deshalb die zweckmäßigen proprietären Cisco-Nachrichten senden.
  • Die AAA-Nachrichten müssen weder verschlüsselt werden, da sie typischerweise entweder bereits von dem ursprünglichen Protokoll (z. B. EAPOL oder Cisco-Abrechnung) geschützt werden, noch müssen sie authentifiziert werden. Aber es gehört zu einer guten Sicherheitspraxis, (MIC-)Authentifizierungsnachrichten zu authentifizieren.
  • Optional sollten nur die EAPOL-Nachrichten des MN eine WTLV_MIC enthalten. Wenn eine WTLV_MIC TLV enthalten ist, authentifiziert die enthaltene MIC die gesamte WLCCP-Nachricht mittels des CTK der Verbindung. Wenn zum Beispiel die Nachricht von einem AP zu dem SCM übertragen wird, sollte der gemeinsame CTK zwischen dem AP und dem SCM benutzt werden. Jeder Hop in dem eingehenden (oder abgehenden) Pfad muß die MIC authentifizieren und neu berechnen, wenn diese aktiviert ist. Schließlich müssen AAA-Nachrichten auch angeben, ob die Zustandsmaschine Eingang in eine AAA-Nachricht gefunden hat sowie auch wann diese fertiggestellt ist. Um diese Zustände bereitzustellen, ist die AAA-Nachricht entsprechend weiter dargestellt.
  • Das allgemeine Format für eingekapselte EAPOL-Nachricht und proprietäre Abrechnungsnachrichten, wie z. B. Cisco-Abrechnungsnachrichten), ist wie folgt:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Anfragender-Knoten-ID 28 8 WLCCP-Knoten-ID des Knotens, der die Netzauthentifizierung "anfordert".
    AAA TYP 36 1 AAA-Protokollnachrichtentyp: 0 – Starten 1 – Beenden 2 – EAPOL 3 – Cisco-Abrechnung
    Authentifizierungs-Typ 37 1 Wenn AAA-Typ = EAPOL-Authentifizierung, dann könnte es sich um einen der folgenden Typen handeln: 0 – nur EAP 1 – nur MAC 2 – nimm MAC zuerst, falls dies fehlschlägt, dann nimm EAP 3 – nimm MAC und EAP 4 – nur LEAP 5 – nimm MAC zuerst, falls dies fehlschlägt, dann nimm LEAP 6 – nimm MAC, dann nimm LEAP
    Schlüsselverwaltungs-Typ 38 1 Typ der ausgehandelten Schlüsselverwaltung (oder keiner Schlüsselverwaltung). Gültige Werte sind: 0 – keine 1 – CCKM 2 – Legacy 802.1X 3 – SSN/TGi
    Status 39 1 Status-Feld
    Nachricht 40 N AAA-Nachricht
  • Die WLCCP-AAA-Nachrichten dienen mehreren Zwecken:
    • 1. Sie unterscheiden zwischen dem Eintritt und dem Austritt des AAA-Zustands.
    • 2. Sie kapseln Cisco-Abrechnungsnachrichten ein, die von einem AP zu dem AS gesendet werden, um Abrechnungsinformationen zu berichten.
    • 3. Sie kapseln EAPOL-Authentifizierungsnachrichten ein. Die erste WLCCP-(Anfrage)-Nachricht muß den Schlüsselverwaltungstyp definieren, um die Sitzungsschlüsselaktion durch den MN-Authentifikator auszulösen. Wenn CCKM definiert ist, dann wird der MN-Authentifikator eine EAPOL-Schlüssel-Nachricht nach dem Empfang einer Radius Access Accept mit einem sicher gelieferten NSK auslösen. Anderenfalls wird der MN-Authentifikator temporär den NSK halten, um diesen zu dem AP weiterzuleiten (wird aber den Eintrag des MN nach einer Vorabregistrierungsanfrage entfernen).
    • 4. Sie kapseln eine EAPOL-Schlüssel-Nachricht von dem MN-Authentifikator zu dem MN ein, um einen anfänglichen 4-Nachrichten-Handshake des CCKM zwischen dem MN-Authentifikator und dem MN zu initiieren, um den KRK und den BTK zu erstellen.
  • Wenn eine AAA-Nachricht von dem Typ Starten ist, dann ist das Nachrichtenformat nur eine Anfragenachricht (keine Antwort wird erwartet). Die Starten-Nachricht initiiert nicht nur den Start des AAA-Nachrichtenaustausches, sondern stellt auch SSID-Informationen sowie auch die nachfolgenden AAA-Authentifizierungs- und Abrechnungsnachrichten bereit. Die nachfolgenden AAA-Nachrichten müssen sowohl mit dem AAA-Authentifizierungs- als auch mit dem Schlüsselverwaltungs-Typ übereinstimmen, der in der Starten-Anfrage definiert ist. Ihr Format ist wie folgt:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Anfragender-Knoten-ID 28 8 WLCCP-Knoten-ID des Knotens, der "anfordert", AAA-Nachrichtenaustausche zu initiieren.
    AAA TYP 36 1 0 – für Starten
    Authentifizierungs-Typ 37 1 Wenn AAA-Typ = EAPOL-Authentifizierung, dann könnte es sich um einen der folgenden Typen handeln: 0 – nur EAP 1 – nur MAC 2 – nimm MAC zuerst, falls dies fehlschlägt, dann nimm EAP 3 – nimm MAC und EAP 4 – nur LEAP 5 – nimm MAC zuerst, falls dies fehlschlägt, dann nimm LEAP 6 – nimm MAC, dann nimm LEAP
    Schlüsselverwaltungs-Typ 38 1 Typ der ausgehandelten Schlüsselverwaltung (oder keiner Schlüsselverwaltung). Gültige Werte sind: 0 – keine 1 – CCKM 2 – Legacy 802.1X 3 – SSN/TGi
    Status 39 1 Feldwert wird ignoriert
    TLV 40 N SSID TLV
  • Wenn der AAA-Authentifizierungs- oder -Abrechnungsaustausch vollendet ist, muß eine AAA-Beendigungs-(Antwort)-Nachricht ausgegeben werden, um den AAA-Zustand zu beenden. Die AAA-Beendigung wird auch verwendet, um einen AAA-Erfolg (z. B. EAP- oder Abrechnungserfolg) anzuzeigen. Wenn die AAA-Beendigung erfolgreich ist und CCKM als die Schlüsselverwaltung definiert ist, dann umfasst die Beendigungs-Nachricht auch eine Nonce. Das AAA-Beendigungs-Nachrichtenformat ist wie folgt:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Anfragender-Knoten-ID 28 8 WLCCP-Knoten-ID des Knotens, der "anfordert", AAA-Nachrichtenaustausche zu initiieren.
    AAA TYP 36 1 1 – für Beenden
    Authentifizierungs-Typ 37 1 Der Typ muß mit dem übereinstimmen, der bei AAA-Starten definiert ist
    Schlüsselverwaltungs-Typ 38 1 Der Typ muß mit dem übereinstimmen, der bei AAA-Starten definiert ist
    Status 39 1 0 – Erfolg
    Nonce-Länge 40 2 Sollte immer auf 16 Bytes gesetzt sein
    Nonce 42 16 pseudozufälliger 16-Byte-Wert
  • Die unten angegebene Tabelle zeigt das Format der Pfad-Init-Anfrage-/-Antwort-/-Bestätigungs-/-ACK-Nachricht:
    Feldname Offset Größe (Bytes) Beschreibung
    WLCCP Header 0 28 Gemeinsamer Kontext-Management-SAP-Header
    Relay-Knoten 28 8 Knoten-ID irgendeines Zwischen-Relay-AP
    Anfragender-Knoten-ID 36 8 WLCCP-Knoten-ID des Knotens, der "anfordert", einen CTK zu erstellen, um diesen mit dem IN-Authentifikator zu teilen.
    Reserviert 44 1 Reserviert für Byte-Ausrichtung
    Status 45 1 Status-Feld
    TLV(s) 46 N Umfasst entweder Secure Context oder mit Session TLVs, um CTKs zu erstellen.
  • Der Anfragender-Knoten muß eine Secure Context TLV in der mit Session TLV umfassen, um zu gewährleisten, dass ein CTK wechselseitig zwischen dem Anfragender-Knoten und seinem IA abgeleitet wird. In der Secure Context TLV muß der Anfragender-Knoten seine Nonce und den CTK-Sequenzzähler bereitstellen, um es dem IA zu erlauben, einen CTK abzuleiten, und um sicher zu sein, dass die Anfrage keine Antwort ist. Bei anfänglichen Freigaben können die Rekeys verworfen werden, wenn ein Replay entdeckt worden ist; der Sequenzzähler ist ausreichend groß, so dass Rekeys niemals erschöpft sein sollten. Aber in dem Fall, bei dem der Wert dabei ist, umzubrechen, muß der IN erneut authentifiziert werden. Bezüglich weiterer Einzelheiten zu der Erstellung von CTKs wird Bezug auf die Abschnitte zu Secure Context TLVs genommen.
  • Die nachfolgenden 802.11-Elemente werden verwendet, um die Operation des WLCCP zu unterstützen.
    #define WLCCP_PATH_COST
    #define WLCCP_HOP_COUNT
    #define IPv4_SUBNET_ID
    #define MULTICAST_802_ADDRESS_LIST
    #define DOT1D_PATH_COST
    #define DOT1D_ROOT_ID /* 802-1D-Priorität und 802-Adresse der Wurzelbrücke */
  • Eine WLCCP Inter-AP SSID ist in einem Standard 802.11 SSID-Element enthalten.
  • Der allgemeine Betrieb der Architektur wird nun offenbart.
  • Eine Anfragenachricht wird immer von dem Absender zu dem Antwortenden weitergeleitet. Eine Antwortnachricht wird immer von dem Antwortenden zu dem Absender weitergeleitet. Die Inbound und Outbound Flags bestimmen, wie eine Nachricht weitergeleitet werden soll. Wenn sowohl die Inbound Flags als auch die Outbound Flags auf AUS gesetzt sind, dann wird eine Nachricht über IP-Routing und/oder transparentes Bridging zu dem Zielbestimmungsort weitergeleitet (d. h., zu dem "Antwortenden" in einer Anfragenachricht).
  • Das Inbound Flag oder das Outbound Flag werden in einer Nachricht auf EIN gesetzt, um anzuzeigen, dass die Nachricht jeweils eingehend oder abgehend auf einem Zweig des Topologiebaums weitergeleitet wird. Es handelt sich um einen Fehler, wenn ein Knoten eine "eingehende" Nachricht von einem Knoten erhält, der kein Nachfolger ist. Es handelt sich ebenfalls um einen Fehler, wenn ein Knoten eine "abgehende" Nachricht von einem Knoten erhält, der kein Vorgänger ist.
  • Das Hopwise-Routing Flag ist in einer eingehenden oder abgehenden Nachricht auf EIN gesetzt, um Zwischen-APs zu zwingen, die Nachricht zu verarbeiten, wobei ein "Zwischen-AP" irgendein AP in dem Topologiebaumzweig zwischen dem Absender und dem Antwortenden der Nachricht ist. Eine "Hop-weise geroutete" eingehende Nachricht wird zu der Hop-Adresse des Vaterknotens weitergeleitet; eine abgehende Nachricht wird zu dem "Next Hop" in dem Pfad zu dem Zielknoten weitergeleitet. Eine Hop-weise geroutete Nachricht wird von jedem Knoten in dem eingehenden oder abgehenden Pfad verarbeitet. Es handelt sich um einen Fehler, wenn ein Knoten eine Hop-weise geroutete Nachricht von einer Hop-Quelle erhält, die kein Nachbar ist.
  • Das Hopwise-Routing Flag kann in einer Registrierungsnachricht zum Beispiel verwendet werden, um Schicht-2-Pfadinformationen in jedem AP auf dem Pfad zu einem MN zu aktualisieren. Der Antwortende ist immer der SCM in einer Proxy-Registrierungsnachricht, die von einem AP erzeugt wird. 23 veranschaulicht, wie das Hopwise Routing verwendet wird. Wenn die Schicht-2-Pfadaktualisierung aktiviert ist (wie in der W2-Implementierung), dann werden Registrierungsnachrichten weitergeleitet, wobei das Hopwise-Routing auf EIN gesetzt ist. Wenn die Schicht-2-Pfadaktualisierung nicht aktiviert ist (wie in der W1-Implementierung), dann werden die Registrierungsnachrichten weitergeleitet, wobei das Hopwise-Routing Flag auf AUS geschaltet ist.
  • Wenn das Relay Flag in einer WLCCP-Nachricht auf EIN gesetzt ist, dann folgt auf den allgemeinen WLCCP-Header direkt ein Relay-Knoten-ID-Feld. Wenn das Relay-Knoten-ID-Feld nicht Null ist, dann enthält es die Knoten-ID irgendeines Zwischenknotens, der die jeweilige Nachricht "übermittelt" hat. Die Relay-Knoten-ID wird sowohl von dem Absender als auch von dem Antwortenden insgesamt auf Nullen initialisiert. Wie in 23 gezeigt ist, ist der AP 2304 der Relay-Knoten für eine Hop-weise geroutete Nachricht, die von dem AP 2306 zu dem SCM 2302 gesendet wird; deshalb muß der AP 2304 das Relay Flag auf EIN setzen und gibt seine Knoten-ID in das Relay-Knoten-ID-Feld ein, bevor er die Nachricht eingehend zu dem SCM weiterleitet.
  • Wenn das Root CM Flag in einer eingehenden Anfragenachricht auf EIN gesetzt ist, dann wird die Nachricht immer eingehend zu dem CM an der Wurzel des gesamten Topologiebaums – dem Wurzel-CM – weitergeleitet. In einem Campusnetz wird die Nachricht zum Beispiel zu dem CCM weitergeleitet. Zum Beispiel kann ein AP das Root CM Flag dazu verwenden, eine IP-Adresse des MN zu dem CCM weiterzuleiten. Der AP kann einfach eine Anfragenachricht zu seinem Vater-SCM senden, die die IP-Adresse des MN enthält und bei der das Root CM Flag auf EIN gesetzt ist.
  • In vielen Fällen muß der ursprüngliche Antwortende einer Anfragenachricht die Nachricht auf dem Pfad zu dem endgültigen Bestimmungsort weiterleiten. Zum Beispiel muß ein SCM eine eingehende Registrierungsanfrage zu seinem Vater-LCM weiterleiten, wenn der SCM nicht der "am nächsten liegende gemeinsame Vorgänger" ist oder wenn das Root CM Flag auf EIN gesetzt ist. In ähnlicher Weise muß ein LCM eine abgehende Deregistrierungsanfrage zu dem Vater-SCM des Zielknotens weiterleiten. Ein ursprünglicher oder dazwischenliegender "Relay-Antwortender" leitet eine solche Nachricht wie folgt weiter: a) Das Antwortender-Feld wird mit der Knoten-ID des Next-Hop-CM aktualisiert, b) der Relay-Antwortende gibt seine Knoten-ID in das Relay-Knoten-ID Feld ein, c) Die Felder für den Absender und die Nachrichten-ID bleiben unverändert. Der Relay-Antwortende aktualisiert das Antwortender-Feld in einer entsprechenden Antwortnachricht nicht; deshalb wird das Antwortender-Feld in der Antwortnachricht die Knoten-ID des "endgültigen Antwortenden" enthalten, wenn sie von dem Absender empfangen wird.
  • Der Absender einer Anfragenachricht setzt das Response-Req Flag auf EIN, um eine entsprechende Antwortnachricht zu erbitten. Der Absender ist immer verantwortlich für eine Fehlerkorrektur, wenn eine erwartete Antwortnachricht nicht empfangen wird. Ein Absender muß einen "Retry-Timer" (Zeitgeber für einen erneuten Versuch) für jede ausstehende Anfragenachricht starten, die eine Antwort verlangt. Eine Anfragenachricht wird mit dem auf EIN gesetzten Retry Flag und mit der ursprünglichen Nachrichten-ID erneut übertragen, wenn eine erwartete Antwortnachricht nicht empfangen wird, bevor der entsprechende Timer abläuft. Ein Retry-Timer wird in einem Zwischen-"Relay-Antwortenden" nicht benötigt, der eine Anfragenachricht auf dem Pfad zu dem letzten Antwortenden weiterleitet.
  • Ein Absender oder Relay-Knoten kann eine Reply_State TLV in einer Anfragenachricht enthalten, um den Betrag an Zustandsinformationen zu reduzieren, der im Speicher aufbewahrt werden muß. Eine Reply_State TLV enthält Informationen, die für die Verarbeitung (z. B. Weiterleitung) einer Antwortnachricht notwendig sind.
  • Eine AP-Nachrichten-Weiterleitungslogik ist im Allgemeinen unabhängig von der Netzinfrastruktur. Der Vater-SCM ist der Antwortende in Nachrich ten, die von einem AP erzeugt werden, mit einer Ausnahme. [Wenn die Schicht-2-Pfad-Aktualisierung aktiviert ist, dann ist der Antwortende in einer anfänglichen Registrierungsanfrage, die von einem Nicht-Wurzel-AP erzeugt worden ist, der Vater-AP.] In einer lokalen oder Campus-Infrastruktur leitet der SCM AP-Nachrichten zu dem Wurzel-CM je nach Bedarf weiter. In ähnlicher Weise ist die SCM-Nachrichten-Weiterleitungslogik in einer selbständigen lokalen Infrastruktur oder einer Campus-Infrastruktur die gleiche. Der Vater-LCM ist immer der Antwortende in Nachrichten, die von dem SCM erzeugt werden. In einem Campusnetz leitet der LCM SCM-Nachrichten je nach Bedarf zu dem CCM weiter.
  • Ein WLCCP-Knoten akzeptiert nur "gültige" WLCCP-Nachrichten, die auf seinem nativen VLAN übermittelt werden. Alle anderen Nachrichten werden verworfen. Eine Nachricht ist ungültig, wenn sie bei einer Nachrichtenintegritätsprüfung versagt oder wenn der Nachrichtentyp unbekannt ist.
  • Das SCM-Auswahl- und -Bekanntmachungs-Protokoll wird verwendet, um eine einzigen aktiven SCM für jedes Teilnetz auszuwählen und um Netzverfügbarkeits- und Netzparameter bekannt zu geben. Ein registrierter, aktiver SMC sendet periodisch SCM-Bekanntmachungs-Antwortnachrichten, bei denen das "SCM Active" Flag auf EIN gesetzt ist, zu einer WLCCP-"Alle Knoten"-802-Gruppenadresse. Ein AP wählt seinen "primären Port" aus und registriert sich bei dem aktiven SCM, wann immer sich die SCM-Instanz ändert.
  • Die allgemeinen Operationsschritte für eine SCM-Auswahl und -Bekanntmachung sind wie folgt:
    • 1) Ein oder mehrere "SCM-Kandidaten" werden mit einem Nicht-Null-SCM-Prioritätswert in jedem Teilnetz konfiguriert.
    • 2) Als eine Option kann sich jeder SCM-Kandidat bei den Wurzel-CM authentifizieren, um einen gemeinsamen WLCCP-Multicast-Schlüssel zu erstellen. Der Multicast-Schlüssel wird verwendet, um optional Multicast-SCM-Bekanntmachungsnachrichten zu authentifizieren. [Wenn SCM-Bekanntmachungs-Nachrichten nicht authentifiziert werden, wird die Authentifizierung verschoben, bis ein aktiver SCM ausgewählt wird.]
    • 3) Jeder SCM-Kandidat sendet eine Kontext-Management-Anfragenachricht zu dem CCM. In der Kontextantwortnachricht weist der CCM den SCM-Kandidaten zu einem Vater LCM zu oder leitet ihn an, in einem selbständigen Modus zu arbeiten.
    • 4) In einem Campus-Infrastrukturmodus initiiert jeder SCM-Kandidat eine Pfadauthentifizierung mit seinem zugewiesenen LCM und dem CCM.
    • 5) In jedem Teilnetz nehmen die SCM-Kandidaten an dem SCM-Auswahl-Protokoll teil, um den aktiven SCM für das Teilnetz zu bestimmen.
    • 6) In einem Campus-Infrastrukturmodus registriert sich der ausgewählte "aktive SCM" bei seinem zugewiesenen LCM und dem CCM.
    • 7) Die Schritte 3–5 werden wiederholt, wenn ein aktiver SCM in einen nicht angeschlossenen Zustand übergeht.
    • 8) Im Infrastrukturmodus beginnt der aktive SCM mit der Erzeugung von "aktiven" SCM-Bekanntmachungen (d. h., Bekanntmachungen, bei denen das Active Flag auf EIN gesetzt ist) nur dann, nachdem er sich erfolgreich bei dem Wurzel-CM registriert hat.
    • 9) Wurzel-APs müssen sich bei dem aktiven SCM registrieren und aktive SCM-Bekanntmachungen weiterreichen.
    • 10) Andere APs müssen sich bei dem aktiven SCM registrieren und aktive SCM-Bekanntmachungen weiterreichen. Ein registrierter Vater-AP muß eine außerplanmäßige Unicast-SCM-Bekanntmachung zu einem Sohn-AP senden, und zwar sofort, nachdem der Sohn-AP authentifiziert ist.
  • Das SCM-Auswahl-Protokoll wird in dem Abschnitt mit dem Titel "Aktive SCM-Auswahl" ausführlich beschrieben.
  • SCM-Bekanntmachungs-Nachrichten enthalten eine IPv4_SUBNET_ID TLV, die das lokale Teilnetz eindeutig identifiziert, sowie die Felder "Pfadkosten" und "Hop-Zählung". Das Pfadkostenfeld wird verwendet, um die Pfadkosten zu dem primären LAN für das jeweilige Teilnetz zu übermitteln. Das Hop-Zählungs-Feld wird für eine Rückwärtskompatibilität mit existierenden APs und mit einer Funk-Firmware verwendet und enthält die Anzahl an drahtlosen Hops zu dem primären LAN. Ein aktiver SCM sendet SCM-Bekanntmachungs- Antwort-Nachrichten, bei denen die Felder Pfadkosten und Hop-Zählung auf '0' gesetzt sind.
  • SCM-Bekanntmachungs-Nachrichten müssen eine Root CM IP Address TLV enthalten, die verwendet wird, um die IP-Adresse des Wurzel-CM in dem SWAN-Topologiebaum bekannt zu geben. Der SCM ist der Wurzel-CM, wenn der SCM in einem selbständigen Modus arbeitet. Wenn der SCM in einem Infrastrukturmodus arbeitet, dann ist die IP-Adresse des LCM oder des CCM, der sich an der Wurzel des gesamten Topologiebaums befindet. Der Wurzel-CM ist der Standard-802.1X-Authentifikator für Infrastrukturknoten.
  • SCM-Bekanntmachungs-Nachrichten enthalten ein Wurzel-CM-Feld, welches die Knoten-ID des Wurzel-CM enthält. Ein AP kann feststellen, ob sich der Wurzel-CM ändert, indem er das Wurzel-CM-Feld in SCM-Bekanntmachungen überwacht.
  • Ein AP- oder SCM-Kandidat kann eine Multicast-SCM-Bekanntmachungs-Anfrage senden, um eine "außerplanmäßige" SCM-Bekanntmachungs-Antwort-Nachricht zu erbitten. Der aktive SCM muß eine außerplanmäßige Unicast-Antwort senden, wenn er eine Anfrage an seinem Ethernet-Port empfängt. Ein "Angeschlossener" AP muß eine außerplanmäßige Unicast-Antwort senden, wenn er eine Anfrage an einem sekundären Port von einem Sohn-AP empfängt. Die Unicast-MAC-Zieladresse in der außerplanmäßigen Antwort wird aus der Hop Adresse in der entsprechenden Anfrage entnommen und ist die gleiche wie die MAC-Quellenadresse in der Anfrage.
  • Ein AP darf eine SCM-Bekanntmachungs-Anfrage NICHT weiterleiten. Der SCM und jeder angeschlossene AP müssen die Zustandsinformationen verwalten, die notwendig sind, um eine außerplanmäßige SCM-Bekanntmachungsantwort zu erzeugen (d. h., die Informationen, die verwendet werden, um die letzte planmäßige Bekanntmachungsnachricht zu erzeugen).
  • Ein SCM-Kandidat oder AP kann die Antwortender-Knoten-ID in einer SCM-Bekanntmachungs-Anfrage auf '0' setzen (d. h., wenn er die Knoten-ID des aktiven SCM oder des Vater-AP nicht kennt). Der tatsächliche Antwortende (d. h., der aktive SCM oder ein Vater-AP) muß seine Knoten-ID in das Antwortender-Feld in der Antwortnachricht eingeben.
  • Ein Nicht-Wurzel-AP sollte die Antwortender-Knoten-ID in einer SCM-Bekanntmachungs-Anfrage auf die Knoten-ID seines Vater-AP setzen, falls diese bekannt ist.
  • Eine "anfängliche Authentifizierung" wird verwendet, um einen Knoten vollständig zu authentifizieren, wenn er das Netz das erste Mal betritt. Ein MN authentifiziert sich anfänglich mit dem MN 802.1X-Authentifikator; ein Infrastrukturknoten (AP oder CM) authentifiziert sich anfänglich mit dem IN 802.1X Authentifikator in dem Wurzel-CM. Anfängliche Authentifizierungsnachrichten werden auf einer 802.11-Verbindung zwischen einer Sohn- und Vater-802.11-Station in 802.1X EAPOL-Nachrichten eingekapselt. Anfängliche Authentifizierungsnachrichten werden in allen anderen Verbindungen in WLCCP-AAA-Nachrichten eingekapselt.
  • Ein AP oder Sohn-CM verwendet "Pfadauthentifizierungs"-Nachrichten, um sich gegenseitig mit jedem seiner Vorgänger zu authentifizieren und einen CTK mit jedem seiner Vorgänger zu erstellen. Ein AP oder Sohn-CM initiiert eine Pfadauthentifizierung, nachdem er sich anfänglich authentifiziert und wann immer sich der Pfad ändert.
  • Eine "schnelle erneute Authentifizierung" wird verwendet, um eine 802.11-Station (MN oder Sohn-AP) schnell "erneut zu authentifizieren", wenn sie zu einem neuen Vater-AP roamt. Ein Vater-AP verwendet "Vorabregistrierungs"-Nachrichten, um den notwendigen Sicherheitskontext für die schnelle erneute Authentifizierung abzurufen, wenn sich eine 802.11-Station erneut verbindet. Vorabregistrierungsnachrichten führen KEINE Aktualisierung des Weiterleitungspfades durch.
  • Die anfängliche Authentifizierung, die Vorabregistrierung, die schnelle erneute Authentifizierung und die Pfadauthentifizierung werden in dem Abschnitt mit dem Titel "WLCCP-Sicherheitsunterstützung" ausführlich erörtert.
  • Das WLCCP-Registrierungs- und -Weiterreichungs-Protokoll wird verwendet, um Zweige und Pfadinstanzen in dem SWAN-Topologiebaum zu errichten, aufrecht zu erhalten und zu löschen. Registrierungsnachrichten (und Deregistrierungsnachrichten) werden auch verwendet, um Kontextinformationen zu übertragen, wenn ein Knoten roamt. Jeder authentifizierte Sohn-CM, AP und MN in einem SWAN-Netz ist bei der Wurzel des SWAN-Topologiebaums – dem Wurzel-CM – registriert. Im Allgemeinen ist jeder CM, AP und MN in einem Unterbaum zuverlässig bei dem CM an der Wurzel des Unterbaums registriert. Beispielhafte Registrierungs- und Weiterreichungs-Nachrichten-Sequenzen sind in den folgenden Abschnitten gezeigt.
  • Das Registrierungs- und Weiterreichungs-Protokoll wird mit drei Nachrichtentypen implementiert – Registrierung, Deregistrierung und Abtrennung (Detach).
  • Jeder MN, AP und Sohn-CM muß sich erfolgreich authentifizieren (oder erneut authentifizieren), bevor er bei der SWAN-Infrastruktur registriert wird.
  • Eine eingehende "anfängliche" Registrierungsanfrage wird erzeugt, um einen Knoten anfänglich bei dem Wurzel-CM zu registrieren, nachdem er sich erfolgreich (erneut) authentifiziert hat. Eine Registrierungsanfrage wird von einer Registrierungsantwort bestätigt, die eine übereinstimmende Nachrichten-ID enthält. Eine abgehende anfängliche Registrierungsantwort erstellt eine Pfadinstanz, die (optional) von einer Pfad-ID identifiziert wird. Eine "Aktualisierungs-Registrierungsanfrage" wird verwendet, um den Registrierungszustand einer angeschlossenen Station aufzufrischen. Eine Aktualisierungs-Registrierungsanfrage wird auch verwendet, um die Kontextinformationen zu aktualisieren, die in Vorgängerknoten in einem Cachespeicher gespeichert sind.
  • "Proxy"-Registrierungsanfrage-/-antwort-Nachrichten werden verwendet, um MNs zu registrieren, die keine Kenntnis von WLCCP haben. Ein "registrierter" Vater-AP erzeugt eine "anfängliche" Proxy-Registrierungsanfrage für einen damit verbundenen MN, nachdem er sich erfolgreich authentifiziert hat.
  • Eine Registrierungsnachricht enthält ein Initial Flag, das in einer "anfänglichen" Registrierungsnachricht auf EIN gesetzt ist und in einer "Aktualisierungs"-Registrierungsnachricht auf AUS gesetzt ist. Eine Registrierungsnachricht weist ein Proxy Flag auf, das in einer "Proxy"-Registrierungsnachricht auf Ein gesetzt ist, die "in Vertretung" (in proxy) von einem Vater-AP für einen Nicht-WLCCP-WN erzeugt wird. Bei einer "anfänglichen Proxy"-Registrierungsnachricht sind zum Beispiel sowohl das Initial Flag als auch das Proxy Flag auf EIN gesetzt.
  • Im Allgemeinen wird eine Registrierungsanfrage für einen Knoten, der geroamt ist, nach innen gerichtet bzw. eingehend weitergeleitet, bis er den "am nächsten liegenden gemeinsamen Vorgänger-CM" erreicht. Der "am nächsten liegende gemeinsame Vorgänger-CM" ist der CM, der sich an der Wurzel des kleinsten Unterbaums befindet, der sowohl den CM als auch die alten und neuen Vater-Knoten umfasst. Zum Beispiel ist der SCM der am nächsten liegende gemeinsame Vorgänger, wenn ein MN innerhalb eines einzigen Teilnetzes roamt. Ein LCM ist der nächste gemeinsame Vorgänger, wenn ein MN zwischen Teilnetzen in dem gleichen lokalen Kontrollbereich roamt. Der am nächsten liegende gemeinsame Vorgänger CM wird als der "gemeinsame CM" bezeichnet.
  • Der gemeinsame CM sendet eine Registrierungsantwort abgehend zurück, um die Registrierungsanfrage zu quittieren und um eine neue Pfadinstanz für den "Anfragender-Knoten" zu erstellen. Der gemeinsame CM "deregistriert" (optional) jede alte Pfadinstanz, wenn er die neue Pfadinstanz für den Knoten erstellt.
  • Ein Nicht-Vater-CM oder -AP muß eine "anfängliche" oder "Proxy"-Registrierungsantwort zu dem "Vater" des Anfragender-Knoten weiterleiten, der von dem Anfragender-Knoten-ID Feld identifiziert wird. Deshalb ist der Vaterknoten der Absender jeder "anfänglichen" oder "Proxy"-Registrierungsanfrage, die eingehend für einen Sohn-Anfragender-Knoten weitergeleitet wird.
  • Das Root CM Flag ist in einer Registrierungsanfrage auf EIN gesetzt, um eine "vollständige Pfadaktualisierung" zu erzwingen. Eine Registrierungsanfrage wird immer zu dem Wurzel-CM weitergeleitet, wenn das Root CM Flag auf EIN gesetzt ist.
  • Das Pfad-ID Feld in einer "anfänglichen" Registrierungsanfrage ist immer auf '0' gesetzt. Der Vater-CM erstellt (optional) die Pfad-ID für eine Pfadinstanz, indem er einen Pfad-ID-Wert in das Pfad-ID Feld einer anfänglichen Registrierungsantwort einträgt. Das Pfad-ID Feld in einer "Aktualisierungs"-Registrierungsanfrage wird auf die Pfad-ID für die Pfadinstanz gesetzt.
  • Eine Registrierungsanfrage wird immer mit dem auf EIN gesetzten Response-Req Flag übertragen, um eine Antwort zu erbitten. Eine Registrierungsanfragenachricht wird erneut übertragen, wenn eine erwartete passende Antwort nicht empfangen wird, bis ein REGISTRATION_RETRY_MAX-Limit überschritten wird. Die gleiche Nachrichten-ID wird für die ursprüngliche Registrierungsanfrage und alle erneuten Übertragungen verwendet.
  • Im Allgemeinen werden empfangene Registrierungsanfragen nach dem Zeitpunkt ihrer Ankunft geordnet. Das Registrierungs-Verzögerungs-Feld wird optional verwendet, um empfangene Proxy-Registrierungsanfragen zu ordnen, die von einem Vater-AP für einen Sohn-Knoten erzeugt werden. Das Verzögerungs-Feld enthält die verstrichene Zeit in Hundertstel Sekunden, seit der jeweilige Sohn-Knoten zuletzt einen Uplink-Rahmen übertragen hat. Eine Registrierungsaufzeichnung in einem CM muß ein Zeitstempelfeld enthalten, das "den Zeitpunkt der Ankunft" der letzten Registrierungsanfrage enthält. Der Zeitpunkt der Ankunft wird berechnet, indem der Verzögerungswert von der aktuellen Zeit subtrahiert wird.
  • Ein Vater-AP oder SCM leitet eine Registrierungsantwort zu einem Sohn-AP weiter, indem er diese zu der Port-MAC-Adresse sendet, die in dem Hop-Quellen-Feld in der ursprünglichen Registrierungsanfrage enthalten ist. Ein Vater-CCM oder -LCM leitet eine Nachricht zu einem Sohn-CM weiter, indem er diese zu der Hop-IP-Adresse des Sohn-CM sendet.
  • Wenn das WLCCP verwendet wird, um Weiterleitungspfade aufzubauen, dann muß eine "alte" Pfadinstanz gelöscht werden, wenn ein Knoten roamt. Eingehende Deregistrierungsantwort- und Abtrennanfrage-Nachrichten werden optional verwendet, um alte Pfadinstanzen zu löschen. Eine Deregistrierungsanfrage wird von einem "gemeinsamen CM" erzeugt, um jegliche alte Pfadinstanz zu löschen, wenn eine neue Pfadinstanz aufgebaut wird. Auch kann eine "administrative" Deregistrierungsanfrage von dem Wurzel-CM erzeugt werden, um die Verbindung eines Knotens administrativ zu trennen.
  • Ein Vater-AP erzeugt eine Abtrennanfrage, wenn ein Sohn-Knoten abgemeldet wird. Wenn der Sohn-Knoten ein AP ist, dann wird der Unterbaum, der an dem AP wurzelt, gelöscht. Die Deregistrierungs- und Abtrennlogik wird unten noch ausführlicher beschrieben werden.
  • Jeder AP in einem Teilnetz und jegliche MNs, die mit dem AP verbunden sind, sind bei dem aktiven SCM für dieses Teilnetz registriert. Ein AP entdeckt den "aktiven SCM" über das SCM-Bekanntmachungs-Protokoll, wie dies oben beschrieben ist. Jeder MN ist bei dem SCM für seinen Vater-AP registriert, selbst wenn der MN zu einem anderen Teilnetz gehört.
  • Die teilnetzinterne Registrierungslogik ist implementierungsspezifisch. In der einfachen W1-Implementierung wird die WLCCP-Registrierung dazu verwendet, Kontextinformationen zwischen dem SCM und Sohn-APs zu erstellen und zu verteilen. Sie wird NICHT dazu verwendet, den Schicht-2-Weiterleitungspfad aufzubauen. In Registrierungsnachrichten in der W1-Implementierung ist das L2-Path-Update Flag auf AUS gesetzt und das Hopwise-Routing Flag ist auf AUS gesetzt. Abtrenn- und Deregistrierungsnachrichten werden in der W1-Implementierung nicht verwendet.
  • Wenn die Schicht-2-Pfadaktualisierung aktiviert ist, dann baut die WLCCP-Registrierung zuverlässig den drahtlosen Weiterleitungspfad zwischen dem primären LAN und drahtlosen Stationen auf, so dass es niemals notwendig ist, Unicast-Rahmen zu den 802.11-Stationen zu fluten. Registrierungs-, Deregistrierungs- und Abtrennnachrichten müssen mit dem Hopwise Routing weitergeleitet werden, so dass jeder AP in der Pfadinstanz die Nachricht verarbeiten kann. Eine Registrierungsantwort wird zum Beispiel abgehend mittels des Hopwise Routing weitergeleitet, indem sie zu der MAC- oder IP-Zieladresse des "Next Hop" in dem Pfad zu dem Zielknoten gesendet wird. Eine Deregistrierungsantwort oder Abtrennanfrage wird eingehend mittels des Hopwise Routing weitergeleitet, indem sie zu der MAC- oder IP-Zieladresse des Vater-Knotens gesendet wird, der in der "Vaterknotenaufzeichnung" identifiziert wird.
  • Nicht-WLCCP-Brücken und -Switches leiten Registrierungsnachrichten transparent weiter.
  • Unter Bezugnahme auf 24 ist ein Blockdiagramm gezeigt, das einen mobilen Knoten 2412 veranschaulicht, der von einem ersten Zugriffspunkt 2408 zu einem zweiten Zugriffspunkt 2410 in einem Campusnetz 2400 roamt. Das Netz 2400 umfasst einen CCM 2402, der ein IN 802.1X Authentifikator ist, einen LCM 2404, der ein MN 802.1X Authentifikator ist, einen SCM 2406, einen ersten Zugriffspunkt 2408, einen zweiten Zugriffspunkt 2410 und den mobilen Knoten 2412.
  • Die Nachrichtensequenzen für die Registrierung und Deregistrierung des mobilen Knotens 2412 sind in 25 und 26 gezeigt. 25 zeigt die Nachrichtensequenzen für den mobilen Knoten 2412, wenn er sich zum ersten Mal mit dem Zugriffspunkt 2408 verbindet und authentifiziert, und 26 zeigt die Nachrichtensequenzen, wenn der mobile Knoten 2412 zu dem zweiten Zugriffspunkt 2410 roamt. Die Pfeile geben die Richtung der Nachricht (Quelle → Ziel oder bidirektional ↔) an, und die vertikalen Querstriche geben die Netzkomponente an.
  • Zuerst wird Bezug auf 25 genommen. Der mobile Knoten 2412 verbindet sich mit dem ersten Zugriffspunkt 2408. Die Schritte umfassen das Senden der Verbindungsanfrage 2502 von dem mobilen Knoten 2412 zu dem ersten Zugriffspunkt 2408 und dass der erste Zugriffspunkt 2408 eine Verbindungsantwort 2504 sendet. Der mobile Knoten 2412 authentifiziert sich dann mit dem LCM 2404 (dem MN 802.1X Authentifikator) und dem ersten Zugriffspunkt 2408. Der mobile Knoten 2412 führt eine anfängliche Authentifizierung 2506 mit dem ersten Zugriffspunkt 2408 durch, eine EAP-Authentifizierung 2508 wird dann zwischen dem ersten Zugriffspunkt 2408 und dem SCM 2406 durchgeführt, und eine AAA-Anfrage 2510 wird zwischen dem SCM 2406 und dem LCM 2404 durchgeführt.
  • Für mobile CCKM-Knoten ist eine Vorabregistrierung erforderlich. Die Vorabregistrierung startet damit, dass der erste Zugriffspunkt 2408 eine anfängliche Proxy-Registrierungsanfrage 2512 zu dem SCM 2406 sendet. Der SCM 2406 leitet dann die anfängliche Registrierungsanfrage 2514 zu dem LCM 2404 weiter. Die CCKM-Vorabregistrierungsantwort 2418 wird von dem LCM 2404 zu dem SCM 2406 und dann, wie durch 2516 gezeigt, von dem SCM 2406 zu dem ersten Zugriffspunkt 2408 gesendet, und der erste Zugriffspunkt 2408 sendet das CCKM-Keying 2530 zu dem mobilen Knoten 2412. Der mobile Knoten 2412 kann kommunizieren, nachdem die anfängliche Authentifizierung und das Keying vollendet ist.
  • Der erste Zugriffspunkt sendet dann eine anfängliche Proxy-Registrierungsanfrage 2520 zu dem SCM 2406, der SCM 2406 leitet dann die anfängliche Proxy-Registrierungsanfrage-Anfrage 2522 zu dem LCM 2404 weiter, wobei hier der LCM 2404 der Antwortende ist, dann leitet der LCM 2404 die anfängliche Registrierungsanfrage 2532 zu dem CCM 2402 weiter, wobei hier der CCM der Antwortende ist. Der CCM 2402 sendet dann eine anfängliche Registrierungsantwort 2528 zu dem LCM 2404. Der LCM 2404 leitet dann die anfängliche Registrierungsantwort, wie durch 2526 gezeigt ist, zu dem SCM 2406 weiter. Der SCM 2406 leitet dann die anfängliche Registrierungsantwort zu dem ersten Zugriffspunkt 2408 weiter, wie durch 2524 gezeigt ist.
  • Nun wird Bezug auf 26 genommen. Darin ist die Nachrichtenübertragungs-Sequenz gezeigt, wenn der mobile Knoten von dem ersten Zugriffspunkt 2408 zu dem zweiten Zugriffspunkt 2410 roamt. Der mobile Knoten 2412 verbindet sich erneut mit dem zweiten Zugriffspunkt 2410, indem er eine erneute Verbindungs-Anfrage 2552 zu dem Zugriffspunkt 2410 sendet. Der zweite Zugriffspunkt 2410 sendet dann eine Vorabregistrierungsanfrage 2554 zu dem SCM 2406, um die dynamischen Berechtigungsnachweise für den mobilen Knoten 2410 zu erhalten. Der SCM 2406 sendet dann eine Vorabregistrierungsantwort 2558 zu dem zweiten Zugriffspunkt 2410. Der zweite Zugriffspunkt 2412 sendet dann eine erneute Verbindungs-Antwort 2556 zu dem mobilen Knoten 2412. Der mobile Knoten 2412 authentifiziert sich dann erneut durch eine schnelle erneute Authentifizierung 2560 mit dem zweiten Zugriffspunkt 2419 unter Verwendung seiner dynamischen Berechtigungsnachweise. Der mobile Knoten kann kommunizieren, nachdem die erneute Authentifizierung vollendet ist. Der zweite Zugriffspunkt 2410 sendet dann eine anfängliche Proxy-Registrierungsanfrage 2562 zu dem SCM 2406 für den mobilen Knoten 2412. Der SCM 2406 sendet dann eine Deregistrierungsanfrage 2564 zu dem ersten Zugriffspunkt 2408. Der SCM 2406 sendet dann eine anfängliche Registrierungsantwort 2566 zu dem zweiten Zugriffspunkt 2410. Der erste Zugriffspunkt 2408 sendet eine Deregistrierungsantwort 2568 zu dem SCM 2406. Der zweite Zugriffspunkt 2410 sendet eine Pfadaktualisierungsanfrage 2570 zu dem ersten Zugriffspunkt 2408.
  • Unter Bezugnahme auf 27 ist ein Blockdiagramm gezeigt, das einen Repeater-Zugriffspunkt 2712 veranschaulicht, der von einem ersten Zugriffspunkt 2708 zu einem zweiten Zugriffspunkt 2710 in einem Campusnetz 2700 roamt. Das Netz 2700 umfasst einen CCM 2702, der ein IN 802.1X Authentifikator ist, einen LCM 2704, einen SCM 2706, einen ersten Zugriffspunkt 2708, einen zweiten Zugriffspunkt 2710 und den Repeater-Zugriffspunkt 2712.
  • Die Nachrichtensequenzen für das Registrieren und Deregistrieren des Repeater-Zugriffspunkts 2712 sind in 28a und 28b gezeigt. 28a zeigt die Nachrichtensequenzen für den Repeater-Zugriffspunkt 2712, wenn er sich zum ersten Mal mit dem Zugriffspunkt 2708 verbindet und authentifiziert, und 28b zeigt die Nachrichtensequenzen, wenn der Repeater-Zugriffspunkt 2712 zu dem zweiten Zugriffspunkt 2710 roamt. Die Pfeile zeigen die Richtung der Nachricht an (Quelle → Ziel) und die vertikalen Querstriche geben die Netzkomponente an.
  • Unter Bezugnahme auf 28a verbindet sich der Repeater-AP 2712 (AP 2712) mit dem ersten Zugriffspunkt 2708 (AP 2708). Dieser Prozess beinhaltet, dass der AP 2712 eine Verbindungsanfrage 2802 zu dem AP 2708 sendet und der AP 2708 mit einer Verbindungsantwort 2804 antwortet. Der AP 2712 authentifiziert sich dann mit dem CCM 2702, dem IN 802.1X Authentifikator, und dem AP 2708 über die anfängliche Authentifizierung 2806 und AAA 2808.
  • Der AP 2712 sendet dann eine Pfad-Init-Anfrage zu dem AP 2708, wobei der AP 2708 der Antwortende ist. Der AP 2708 sendet dann die Pfad-Init- Anfrage zu dem SCM 2706, wie dies durch 2812 gezeigt ist, wobei hier der SCM 2706 der Antwortende ist. Der SCM 2706 leitet die Pfad-Init-Anfrage zu dem LCM 2704 weiter, wie dies durch 2814 gezeigt ist, wobei hier der LCM 2704 der Antwortende ist. Der LCM leitet dann die Pfad-Init-Anfrage zu dem CCM 2702 weiter, wie dies durch 2816 gezeigt ist, wobei der CCM der Antwortende ist. Wie bei 2834 gezeigt ist, sendet der CCM 2702 dann eine Pfad-Init-Antwort zu dem LCM 2704, wobei der AP 2708 der Absender ist. Der LCM 2704 sendet dann die Pfad-Init-Antwort zu dem SCM 2706, wobei hier der AP 2708 der Absender ist, wie dies durch 2822 gezeigt ist. Der SCM 2706 sendet die Pfad-Init-Antwort zu dem AP 2708, wie durch 2820 gezeigt ist. Der AP 2708 sendet die Pfad-Init-Antwort zu dem AP 2712, wie dies durch 2818 gezeigt ist.
  • Der AP 2712 sendet dann eine anfängliche Registrierungsanfrage 2826 zu dem AP 2708, wobei der AP 2712 der Antwortende ist. Der AP 2708 sendet bei 2828 die anfängliche Registrierungsanfrage zu dem SCM 2706 für den AP 2712, wobei der SCM 2706 der Antwortende ist. Bei 2830 leitet der SCM 2706 die anfängliche Registrierungsanfrage zu dem LCM 2704 weiter, wobei hier der LCM 2704 der Antwortende ist. Dann leitet der LCM 2704 bei 2832 die anfängliche Registrierungsanfrage zu dem CCM 2702 weiter, wobei der CCM 2702 der Antwortende ist. Bei 2840 sendet der CCM 2702 eine anfängliche Registrierungsanfrage-Antwort zu dem LCM 2704. Bei 2838 leitet der LCM 2704 dann die anfängliche Registrierungsanfrage-Antwort zu dem SCM 2706 weiter. Dann leitet der SCM 2706 bei 2836 die anfängliche Registrierungsanfrage-Antwort zum AP 2708 weiter, der dann bei 2834 die anfängliche Registrierungsanfrage-Antwort zu dem AP 2712 weiterleitet.
  • Nun wird Bezug auf 28b genommen. Darin ist die Sequenz von Nachrichten gezeigt, die stattfindet, wenn der Repeater-AP (AP 2712) von dem ersten Zugriffspunkt 2708 (AP 2708) zu einem zweiten Zugriffspunkt 2710 (AP 2710) roamt. Der Prozess beginnt bei 2850, wenn der AP 2712 eine erneute Verbindungs-Anfrage zu dem AP 2760 sendet und eine "schnelle erneute Authentifizierungs"-Fähigkeit anzeigt. Bei 2852 sendet der AP 2710 dann eine Vorabregistrierungsanfrage zu dem SCM 2706, um die dynamischen Berechtigungsnachweise für den AP 2712 zu erhalten. Der SCM 2706 sendet eine Vorabregistrierungsantwort zu dem AP 2710 bei 2856. Der AP 2720 sendet dann eine erneute Verbindungsanfrage-Antwort zu dem AP 2712 bei 2854. Bei 2858 authentifiziert sich der AP 2712 erneut mit dem AP 2710 mittels seiner dynamischen Berechtigungsnachweise.
  • Der AP 2712 sendet dann eine Pfad-Init-Anfrage zu dem AP 2710 bei 2860, wobei der AP 2710 der Antwortende ist. Bei 2862 sendet der AP 2710 eine Pfad-Init-Anfrage zu dem SCM 2706 für den AP 2712, wobei der SCM 2706 der Antwortende ist. Der SCM 2706 sendet eine Pfad-Init-Anfrage zu dem AP 2710 bei 2866, wobei der AP 2710 der Absender ist. Bei 2864 sendet der AP 2710 eine Pfad-Init-Antwort zu dem AP 2712.
  • Bei 2872 sendet der AP 2712 eine anfängliche Registrierungsanfrage zu dem AP 2710, wobei der AP 2710 der Antwortende ist. Bei 2874 sendet der AP 2710 eine anfängliche Registrierungsanfrage zu dem SCM 2706 für den AP 2712, wobei hier der SCM 2706 der Antwortende ist. Bei 2876 sendet der SCM 2706 eine Deregistrierungsanfrage zu dem AP 2708. Bei 2880 sendet der SCM 2706 eine anfängliche Registrierungsantwort zu dem AP 2710. Bei 2878 sendet der AP 2710 eine anfängliche Registrierungsantwort zu dem AP 2721. Bei 2882 sendet der AP 2708 eine Deregistrierungsantwort zu dem SCM 2706. Der AP 2710 sendet eine Pfadaktualisierungsanfrage zu dem AP 2708.
  • Ein einziger aktiver SCM wird für jedes Teilnetz ausgewählt, wie dies weiter unten beschrieben wird. Standardmäßig arbeiten APs in einem Teilnetz in einem "verteilten Modus", wenn keine SCM-Kandidaten für das Teilnetz konfiguriert sind.
  • Der aktive SCM arbeitet entweder in einem 1) selbständigen Modus oder in einem 2) SWAN-Infrastrukturmodus. Ein SCM arbeitet immer dann in einem selbständigen Modus, wenn er nicht mit einem Vater-LCM kommunizieren kann. Im Infrastrukturmodus ist ein SCM bei einem Vater-LCM registriert und leitet WLCCP-Nachrichten zu seinem Vater-CM weiter. Die SCM-Operation in dem Infrastrukturmodus ist in dem Abschnitt mit dem Titel "W2 – SCM-Operation" spezifiziert.
  • Der zusammen mit dem CCM angeordnete LCM ist der Standard-Reserve-LCM für alle SCMs.
  • Wenn ein aktiver SCM von dem selbständigen Modus in den Infrastrukturmodus übergeht, dann muß jeder existierende Unterbaum, der an dem SCM wurzelt, gelöscht werden, um alle Knoten in dem Unterbaum zu zwingen, sich erneut zu registrieren. [Ein SCM setzt ein Instanzalter auf '0' zurück, um seinen Unterbaum zu löschen. Die Unterbaumlöschung wird in einem separaten Abschnitt beschrieben.]
  • Der Unterbaum, der an dem SCM wurzelt, muß NICHT neu aufgebaut werden, wenn ein SCM von dem Infrastrukturmodus in den selbständigen Modus überwechselt. Der SCM muß in dem selbständigen Modus als der IEEE 802.1X Authentifikator für sein Teilnetz funktionieren.
  • Die allgemeinen SCM-Datenstrukturen und -Zustandsvariablen werden nun beschrieben werden.
  • SCM_Advertisement_Timer (SCM-Bekanntmachungs-Zeitgeber) – Eine SCM-Bekanntmachungs-Antwort-Nachricht wird von einem SCM-Kandidaten oder einem aktiven SCM erzeugt, wenn der Timer abläuft. Die Zeitspanne des Timers beträgt DEF_SCM_ADVERTISE_PERIOD Sekunden (z. B. 5 Sekunden).
  • SCM_Instance_Age (SCM-Instanzalter) – Das SCM_Instance_Age wird immer dann auf '0' initialisiert und auf '0' zurückgesetzt, wenn ein SCM den aktiven SCM-Status aufgibt. Der aktive SCM inkrementiert den SCM_Instance_Age-Wert jedes Mal dann, wenn der SCM_Advertisement_Timer abläuft.
  • Authenticated Node Table (Tabelle der authentifizierten Knoten) – Der SCM ist der 802.1X IN- und MN-Authentifikator IN, wenn der SCM in dem selbständigen Modus arbeitet. In dem selbständigen Modus muß der SCM eine Tabelle authentifizierter Knoten unterhalten, welche eine Liste von authentifizierten Knoten-Einträgen ist. Jeder authentifizierte Knoten-Eintrag enthält Authentifizierungszustandsinformationen für APs und MNs in dem Unterbaum, der am dem SCM wurzelt. Der Authentifizierungszustand in einem Knoteneintrag wird auf "nicht authentifiziert" initialisiert. Die Zustandsinformationen, die in der Tabelle enthalten sind, sind in dem Abschnitt mit dem Titel "WLCCP-Sicherheitsunterstützung" definiert.
  • Registration Tables (Registrierungstabellen) – Der aktive SCM muß eine Registrierungstabelle verwalten, die Zustandsinformationen für jeden AP und MN in seinem Unterbaum enthält. Eine AP-Registrierungstabelle enthält eine AP-Registrierungsaufzeichnung für jeden AP in seinem Teilnetz. Eine MN-Registrierungstabelle enthält eine MN-Registrierungsaufzeichnung für jeden MN, der mit einem AP in dem Teilnetz verbunden ist. Eine Registrierungsaufzeichnung wird erstellt oder aktualisiert, wenn eine Registrierungsanfrage für einen AP oder MN empfangen wird. Eine Registrierungsaufzeichnung enthält einen Querverweis auf einen authentifizierten Knoten-Eintrag. Eine MN-Registrierungsaufzeichnung enthält einen Querverweis auf die AP-Registrierungsaufzeichnung für den Vater-AP des MN. Eine Registrierungsaufzeichnung wird gealtert und verworfen, wenn eine erfolgreiche Registrierungsanfrage für den entsprechenden Knoten mit der Registrierungs-Lebenszeit nicht empfangen wird.
  • SCM Candidate Path Authentication (SCM-Kandidaten-Pfadauthentifizierung). Jeder SCM-Kandidat in einem Campuskontrollbereich wird automatisch einem Vater-LCM durch den CCM unter Verwendung von Kontextanfrage-/-antwortnachrichten zugewiesen. Ein SCM-Kandidat muß eine Pfad-Init-Anfrage zu seinem zugewiesenen Vater-LCM senden, nachdem er sich erfolgreich bei dem Wurzel-CM authentifiziert hat, um die Pfadauthentifizierung zu initiieren. Der LCM leitet die Pfad-Init-Anfrage in dem Campus-Infrastrukturmodus immer zu dem CCM weiter. Der CCM funktioniert als ein KDC, um den SCM-Kandidaten und den LCM gegenseitig zu authentifizieren und einen gemeinsamen CTK zu erstellen. Ein (optionaler) WLCCP-"Multicast-CTK" wird zu dem SCM während des Pfadauthentifizierungsprozesses weitergeleitet. Der SCM-Kandidat verwendet (optional) den WLCCP-Multicast-CTK, um SCM-Bekanntmachungs-Antwortnachrichten zu unterschreiben. Der CTK, der von einem SCM-Kandidaten und dem LCM gemeinsam genutzt wird, wird nicht verwendet, wenn der SCM-Kandidat nicht als der aktive SCM ausgewählt ist.
  • Aktive SCM-Auswahl.
  • Ein SCM-Auswahlprotokoll wird verwendet, um einen einzigen aktiven SCM für jedes Teilnetz auszuwählen, und zwar aus einem Satz von einem oder mehreren SCM-Kandidaten. Definitionsgemäß ist das primäre LAN das verdrahtete Ethernet-LAN, das an dem SCM angeschlossen ist; deshalb errichtet die SCM-Auswahl automatisch das primäre LAN für jedes Teilnetz. Das Auswahlprotokoll wird durch SCM-Bekanntmachungs-Nachrichten ermöglicht.
  • Jeder SCM-Kandidat ist mit einem Nicht-Null-SCM-Prioritätswert von 1 bis 255 konfiguriert. Ein WLCCP-Knoten ist kein SCM-Kandidat, wenn er mit einem SCM-Prioritätswert von '0' konfiguriert ist. Das werthohe Bit des SCM-Prioritätswerts wird als ein "Preferred SCM" Flag verwendet und ist in einem "bevorzugten" SCM auf EIN gesetzt. Das Preferred SCM Flag ist in einem "Reserve"-SCM auf AUS gesetzt. Deshalb werden Prioritätswerte von 128 bis 255 für "bevorzugte" SCM-Kandidaten verwendet. Normalerweise sollte es nur einen bevorzugten SCM-Kandidaten geben. Prioritätswerte von 1 bis 127 werden für "Reserve"-SCM-Kandidaten verwendet. Der SCM-"Prioritätswert" wird mit der SCM-Knoten-ID zur Bildung einer SCM-"Prioritäts-ID" verkettet. Die effektive relative SCM-Priorität wird unten im Einzelnen erörtert werden.
  • Die unten angeführte Zustandsübergangstabelle definiert die Operation des SCM-Auswahlprotokolls.
    Zustand Ereignis Aktion Nächster Zustand
    Anfänglich SCM-Priorität ist nicht null SCM-Listen-Timer mit einer durchschnittlichen Ablaufzeit von DEF_SCM_LISTEN_TIME Sekunden starten; periodischen SCM-Bekanntmachungs-Timer starten; SCM-Bekanntmachungs-Anfrage senden SCM_CAND
    SCM_CAND SCM-Bekanntmachung mit höherer Priorität empfangen SCM-Listen-Timer mit einer Ablaufzeit von MAX_SCM_AGE Sekunden erneut starten SCM_BACKUP
    SCM_CAND SCM-Bekanntmachungs-Anfrage oder SCMBekanntmachungsAntwort mit niedrigerer Priorität empfangen Eine SCM-Bekanntmachung senden, wobei das Active Flag auf AUS gesetzt ist SCM_CAND
    SCM_CAND SCM-Bekanntmachungs-Timer läuft ab Eine SCM-Bekanntmachung senden, wobei das Active Flag auf AUS gesetzt ist SCM_CAND
    SCM_CAND SCM-Listen-Timer läuft ab SCM-Instanzalter auf 0 zurücksetzen; SCM-Bekanntmachung senden, wobei das Active Flag auf EIN gesetzt ist; SCM-Bekanntmachungs-Timer neu starten SCM_ACTIVE
    SCM_BACKUP SCM-Bekanntmachung mit höherer Priorität empfangen Den SCM-Listen-Timer mit einer Ablaufzeit von MAX_SCM_AGE Sekunden erneut starten SCM_BACKUP
    SCM_BACKUP SCM-Listen-Timer läuft ab Den SCM-Listen-Timer mit einem Ablauf von DEF_SCM_LISTEN_TIME Sekunden erneut starten; periodischen SCM-Bekanntmachungs-Timer erneut starten; SCM-Bekanntmachung senden, wobei das Active Flag, auf AUS gesetzt ist SCM_CAND
    SCM_ACTIVE SCM-Bekanntmachung mit höherer Priorität empfangen. (Die effektive Priorität der empfangenen Bekanntmachung ist "höher", wenn a) der "Prioritätswert" höher ist, oder b) das Active Flag EIN ist und die Prioritäts-ID höher ist.) SCM-Listen-Timer mit einer Ablaufzeit von MAX_SCM_AGE Sekunden starten SCM_BACKUP
    SCM_ACTIVE Eine SCM-Bekanntmachungs-Anfrage oder eine SCM-Bekanntmachungsantwort mit niedrigerer Priorität empfangen Außerplanmäßige Unicast-SCM-Bekanntmachung senden, wobei das Active Flag auf EIN gesetzt ist SCM_ACTIVE
    SCM_ACTIVE SCM-Bekanntmachungs-Timer läuft ab Planmäßige SCM-Bekanntmachung senden, wobei das Active Flag auf EIN gesetzt ist; den SCM-Bekanntmachungs-Timer erneut starten SCM_ACTIVE
  • Das SCM-Auswahl-/Bekanntmachungs-Protokoll arbeitet in einem einzigen "nativen" VLAN, das von SCM-Kandidaten und APs gemeinsam genutzt wird. SCM-Bekanntmachungs-Nachrichten, die in irgendeinem anderen VLAN empfangen werden, werden ignoriert.
  • Ein "SCM-Kandidat" ist mit einem Nicht-Null-SCM-"Prioritätswert" konfiguriert. Jeder SCM-Kandidat weist eine "SCM-Prioritäts-ID" auf, die aus der Verkettung des SCM-Prioritätswerts und der SCM-Knotenadresse besteht. Die Regeln für die effektive relative SCM-Priorität sind wie folgt:
    • 1) Ein SCM-Kandidat oder aktiver SCM weist eine relativ "höhere Priorität" auf, wenn er mit einem höheren Prioritätswert konfiguriert ist.
    • 2) Ein erster SCM-Kandidat weist eine relativ höhere Priorität als ein zweiter SCM-Kandidat auf, wenn er eine SCM-"Prioritäts-ID" aufweist, die lexikographisch höher ist.
    • 3) Ein erster aktiver SCM weist eine relativ höhere Priorität als ein zweiter aktiver SCM auf, wenn er eine SCM-"Prioritäts-ID" aufweist, die lexikographisch höher ist.
    • 4) Ein SCM-Kandidat weist eine relativ höhere Priorität als ein aktiver SCM auf, wenn er mit einem höheren Prioritätswert konfiguriert ist. Wenn ein SCM-Kandidat mit dem gleichen Prioritätswert wie oder einem niedrigeren Prioritätswert als der aktive SCM konfiguriert ist, dann besitzt er eine relativ niedrigere Priorität als der aktive SCM.
  • Die effektive Priorität ist so strukturiert, dass ein SCM-Kandidat einen aktiven SCM mit dem gleichen Prioritätswert nicht ersetzen wird, selbst wenn er eine "höhere " Knoten-ID aufweist. Aber der Benutzer kann den aktiven SCM explizit auswählen, indem er einen höheren Prioritätswert konfiguriert.
  • Ein SCM-Kandidat tritt anfänglich in einen SCM_CANDIDATE Zustand ein, um auf SCM-Bekanntmachungen an seinem Ethernet Port zu lauschen (listen). Der SCM-Kandidat bleibt in dem SCM_CANDIDATE Zustand für eine "Listen"-Zeitdauer, die 3 SCM-Bekanntmachungs-Intervalle überschreitet, oder bis er einen SCM mit einer höheren Priorität entdeckt. Der SCM-Kandidat tritt in den SCM_ACTIVE Zustand ein, wenn er innerhalb der Listen-Zeitdauer KEINE SCM-Bekanntmachungs-Nachricht mit einer höheren Priorität empfängt. In dem Infrastrukturmodus muß sich der "erwählte" aktive SCM sofort bei seinem Vater-LCM und dem CCM registrieren. Der aktive SCM setzt das "SCM Active" Flag in seinen SCM-Bekanntmachungs-Antwortnachrichten auf EIN, nachdem er sich erfolgreich registriert hat oder in den "selbständigen Modus" eintritt.
  • Ein SCM-Kandidat oder aktiver SCM tritt in einen SCM_BACKUP Zustand ein, wenn er einen SCM mit einer höheren Priorität entdeckt.
  • Ein AP- oder SCM-Kandidat muß eine SCM-Bekanntmachungs-Anfragenachricht zu der WLCCP-"alle INs"-Gruppenadresse an jedem Port senden, wenn der Port zum ersten Mal aktiviert wird. Ein Knoten in dem SCM_ACTIVE oder SCM_CANDIDATE Zustand antwortet, indem er eine SCM-Bekanntmachungsantwort sendet. Ein Knoten in dem SCM_CANDIDATE Zustand setzt das "SCM Active" Flag in der Antwort auf AUS und setzt die Pfadkosten- und Hop-Zählungs-Felder auf "unbegrenzte" Werte.
  • Als eine Option können mehrere aktive SCMs für ein einziges Teilnetz ausgewählt werden. Eine SCM-Bekanntmachungs-Anfragenachricht enthält zu diesem Zweck ein SCM-Gruppenauswahl-Feld. Das Feld enthält die Anzahl von SCM-Auswahlgruppen und die Gruppen-ID, die dem jeweiligen SCM-Kandidaten zugewiesen ist (d. h., identifiziert von der SCM Knoten-ID). Die Gruppen-ID muß kleiner als die Anzahl an Auswahlgruppen sein. Ein SCM-Kandidat berücksichtigt nur SCM-Bekanntmachungen von anderen Kandidaten in derselben Gruppe, so dass ein aktiver SCM für jede Gruppe ausgewählt wird. Registrierungen werden quer durch mehrere aktive SCMs verteilt. Der Algorithmus zur Bestimmung des aktiven SCM für einen Knoten ist in dem Abschnitt mit dem Titel "WLCCP-Registrierungsprotokoll" beschrieben.
  • Der ausgewählte aktive SCM sendet SCM-Bekanntmachungs-Antwortnachrichten, bei denen das Active Flag auf EIN gesetzt ist, einmal pro Bekanntmachungsperiode. Die Felder in den SCM_Bekanntmachungs-Antwortnachrichten, die von dem aktiven SCM gesendet werden, sind folgendermaßen gesetzt:
  • WLCCP-Header-Felder:
    • Typ – '0x41' (SCM_Advertisement Reply) (SCM-Bekanntmachungs-Antwort).
    • Absender – '0'.
    • Antwortender – SCM Knoten-ID.
    • Outbound Flag – '1'.
    • TLV Flag – '1' (die Anfrage muß eine IPV4_SUBNET TLV und eine ROOT_CM_INFO TLV enthalten).
  • SCM_Bekanntmachungs-Antwort-Felder:
    • Hop_Address – Die SCM Ethernet Port Adresse.
  • SCM Flags
    • Active Flag – '1'
    • SCM Priorität – Benutzerkonfigurierte SCM-Priorität.
    • SCM Knoten-ID – SCM-Knotentyp und Ethernet Port Adresse
    • Instanzalter – SCM_Instance_Age Wert.
    • Pfadkosten – '0'
    • Hop-Zählung – '0'
    • Bekanntmachungsperiode – DEF_SCM_ADVERTISE_PERIOD Sekunden.
    • WTLV_IPV4_SUBNET_ID TLV – IPv4-Adresse und Präfixlänge des SCM
    • WTLV_ROOT_CM_INFO TLV – Enthält die IPv4-Adresse des Wurzel-CM (welcher auch der 802.1X IN Authentifikator ist).
  • SCM-Registrierung.
  • Ein SCM muß sich bei dem Wurzel-CM sofort, nachdem er als der "aktive SCM" für sein Teilnetz ausgewählt worden ist, registrieren. [Es sei angemerkt, dass er die Pfadauthentifizierung bereits abgeschlossen hat.] Der erwählte aktive SCM sendet eine "anfängliche" Registrierungsanfrage zu seinem zugewiesenen Vater-LCM. Der LCM leitet die anfängliche Registrierungsanfrage in dem Campus-Infrastrukturmodus immer eingehend zu dem CCM weiter. Der CCM sendet eine anfängliche Registrierungsantwort-Nachricht zu dem Vater-LCM zurück, der die Registrierungsantwort-Nachricht zu dem SCM weiterleitet. Die Antwortnachricht enthält die Knoten-ID und die IP-Adresse des "Wurzel-CM" in einer Root CM TLV.
  • Der SCM muß periodisch Registrierungsanfragenachrichten "aktualisieren", um seine Registrierungsbindungen in dem Vater-LCM und dem CCM aufzufrischen. Die Aktualisierungs-Registrierungsanfragenachrichten werden immer zu dem Wurzel-CM weitergeleitet. Der Wurzel-CM sendet eine Aktualisierungs-Registrierungsantwortnachricht zurück, um die Registrierungsanfrage zu bestätigen. Der Vater-LCM setzt das Alter der DPR für den SCM auf '0' zurück, wenn er eine "passende" Registrierungsanfrage mit einem "guten" Status empfängt. Ein Vater-LCM muß den Unterbaum, der an dem SCM wurzelt, löschen, wenn er keine Aktualisierungs-Registrierungsantwortnachricht für den SCM mit der Registrierungs-Lebenszeit empfängt.
  • Ein SCM muß die Pfadauthentifizierungs- und anfänglichen Registrierungsprozesse immer dann wiederholen, wenn er einer anderen Vater-LCM-Instanz zugewiesen wird.
  • Nun werden allgemeine AP-Operationen erörtert.
  • Ein WLCCP AP arbeitet entweder in 1) einem "verteilten Modus" oder in 2) einem SWAN-"Infrastrukturmodus".
  • Der AP-Betriebsmodus hängt von dem Vorhandensein eines SCM und von einem AP-"Betriebsmodus"-Parameter ab, der auf einen der folgenden Werte eingestellt werden kann:
    • a) Nur Infrastruktur
    • b) Automatischer Ersatz (Automatic Fallback) (Standard)
  • Ein WLCCP AP arbeitet immer in dem "Infrastrukturmodus", wenn er einen SWAN SCM entdeckt. Ein AP arbeitet in dem "verteilten Modus", wenn er sich nicht bei dem aktiven SWAN SCM registrieren kann und der "Betriebsmodus" auf "Automatischer Ersatz" eingestellt ist. Das CISCO Datagram Delivery Protocol (DDP) wird als das Inter-AP-Protokoll in einem verteilten Modus verwendet. Es sollte angemerkt werden, dass eine WLCCP-Kontext- oder Pfadaktualisierungsnachricht in dem verteilten Modus verwendet werden kann, um direkt Kontext von einem "alten AP" zu einem "neuen AP" zu transferieren, wenn eine Station roamt. [Die MAC-Adresse des "alten AP" kann aus einer 802.11 Nachricht bezüglich einer erneuten Verbindung erhalten werden.] Jeder AP muß in dem verteilten Modus als der 802.1X Authentifikator funktionieren. APs sollten in einem verteilten Modus arbeiten, wenn das Netz Nicht-WLCCP-APs enthält.
  • Ein AP kann NICHT in dem "verteilten Modus" arbeiten, wenn der "Betriebsmodus" auf "Nur Infrastruktur" eingestellt ist.
  • Der AP-Betrieb in dem Infrastrukturmodus ist in einer selbständigen Teilnetz-Infrastruktur, einer selbständigen lokalen Infrastruktur oder in einer Campus-Infrastruktur im Allgemeinen der gleiche.
  • Ein AP, der in dem Infrastrukturmodus arbeitet, wird als "Angeschlossen" betrachtet, wenn er bei dem aktiven SCM registriert ist; anderenfalls wird er als "Nicht angeschlossen" betrachtet. Ein AP, der in dem "verteilten" Modus arbeitet, wird als "Angeschlossen" betrachtet, wenn er eine gute Ethernet-Verbindung aufweist, die in einem Vater- oder Vater-/Sohn-Modus konfiguriert ist (siehe unten), oder wenn er mit einem Vater-AP assoziiert ist; anderenfalls wird er als "Nicht angeschlossen" betrachtet. Ein nicht angeschlossener AP muß 802.11-Stationsverbindungen verbieten, um Stationen daran zu hindern, sich mit einem AP zu verbinden, der keinen Zugang zu dem primären LAN bereitstellen kann. Eine Managementstation kann eine spezielle "Management SSID" verwenden, um eine Verbindung mit einem nicht angeschlossenen AP herzustellen, wenn andere Stationsverbindungen verboten sind.
  • Eine Sohn-802.11-Brücke oder ein Repeater-AP kann nicht im Infrastrukturmodus arbeiten, außer sie/er ist mit einem Vater-AP verbunden, der in einem Infrastrukturmodus arbeitet. [Ein Vater-AP, der in einem Infrastrukturmodus arbeitet, sendet periodische SCM-Bekanntmachungs-Antwortnachrichten zu den Sohn-APs und -Brücken.]
  • Unten aufgeführt ist eine Liste von allgemeinen AP-Zustandsvariablen.
    Infrastructure_Mode – WAHR, wenn es einen aktiven SCM gibt; anderenfalls FALSCH.
    AP_Top_Level_State – Enthält den aktuellen Top-Level-AP-Zustand. Top-Level-AP-Zustände und Top-Level-Zustandsübergänge sind in dem Abschnitt mit dem Titel "AP-Betriebsmodi" beschrieben.
    Parent_SCM_Record – enthält die nachfolgenden Informationen über den aktiven Vater-SCM:
    SCM_Node_ID – Die Knoten-ID des aktiven SCM, kopiert aus der SARpM.
    SCM_Age – Wird einmal pro SCM-Bekanntmachungsperiode inkrementiert. Zurückgesetzt auf 0, wenn eine "aktive" SARpM empfangen wird. Infrastructure_Mode wird auf FALSCH zurückgesetzt, wenn das SCM_Age gleich dem MAX_SCM_AGE ist.
    SCM_Instance_Age – Das Instanzalter des SCM, kopiert aus der SARpM.
    SCM_Subnet_Address – Die IPv4-Adresse und (optional) die Teilnetzmaske des SCM, kopiert aus einer WTLV_IPV4_SUBNET_ID TLV in der SARpM.
    SCM_Priority – Die Priorität des aktiven SCM, kopiert aus dem SCM-Prioritäts-Feld in der SARpM.
    SCM_Advertisement_Period – Die Anzahl an Sekunden zwischen planmäßigen SCM-Bekanntmachungen, kopiert aus dem Bekanntmachungsperioden-Feld in der SARpM.
    SCM_Path_Cost – Der Pfadkosten Wert aus der SARpM, plus die Kosten, die dem primären Port des AP zugewiesen sind.
    SCM_Hop_Count – Der Hop-Zählungs-Wert aus der SARpM, plus '1' für den primären Port.
    SCM_Advertisement_Timer (optional) – Ein Timer, der einmal pro "SCM-Bekanntmachungsperiode" abläuft, wenn WLCCP aktiviert ist. Die Zeitspanne des Timers beträgt SCM_Advertisement_Period Sekunden (siehe oben).
    IN_1X_Authenticator – Knoten-ID und IPv4-Adresse des WLCCP-Infrastruktur-802.1X Authentifikators, der in der einfachen WLCCP-Implementierung immer der SCM ist.
  • Ein AP muß SCM-Bekanntmachungs-Antwortnachrichten überwachen, die an seinem primären Port in dem nativen VLAN empfangen werden, um festzustellen, ob es einen aktiven SCM für das native VLAN gibt. Ein AP arbeitet in dem Infrastrukturmodus und führt das WLCCP-Protokoll aus, wenn es einen aktiven SCM für das native VLAN des AP gibt.
  • Ein AP muß seine "Vater-SCM-Aufzeichnung" jedes Mal dann aktualisieren, wenn er eine SCM-Bekanntmachungs-Antwortnachricht empfängt. Der Infrastrukturmodus wird aktiviert, wenn ein AP zum ersten Mal eine SCM-Bekanntmachung empfängt, bei der das "Active_Flag" auf EIN gesetzt ist. Ein AP muß SCM-Bekanntmachungs-Antwortnachrichten an jedem seiner sekundären Ports erzeugen, und zwar unter Verwendung einer der nachfolgenden Verfahren: 1) Ein AP kann einfach SCM-Bekanntmachungen an jedem seiner sekundären Ports erzeugen, wenn er eine SCM-Bekanntmachung an seinem primären Port empfängt, oder 2) ein AP kann jedes Mal dann einen periodischen SCM_Advertisement_Timer starten und SCM-Bekanntmachungen an seinen sekundären Ports erzeugen, wenn der Timer abläuft. Die Zeitdauer des Timers ist der Nicht-Null-Bekanntmachungsperioden-Wert in Bekanntmachungen, die an dem primären Port empfangen werden. Das erste Verfahren muß verwendet werden, wenn der Bekanntmachungsperioden-Wert in Bekanntmachungen, die an dem primären Port empfangen werden, Null ist.
  • Ein Repeater-AP muß eine Multicast-SCM-Bekanntmachungs-Anfrage auf seinem primären Port senden, wenn er sich zum ersten Mal mit einem Vater-HP verbindet, um eine außerplanmäßige Unicast-SCM-Bekanntmachungs-Antwortnachricht abzurufen.
  • Die unten aufgeführte AP-Top-Level-Zustandsübergangs-Tabelle spezifiziert die Prozesslogik für die SCM_Advertisement Reply Message (SARpM) (SCM-Bekanntmachungs-Antwortnachricht). Bei einer "aktiven" SARpM ist das "Active Flag" auf EIN gesetzt.
  • Der IN 802.1X Authentifikator befindet sich in dem Wurzel-CM, wenn sich der AP in dem I, R-Zustand befindet; anderenfalls befindet sich der IN 802.1X Authentifikator in dem AP. Vorabregistrierung und Registrierung der MNs ist nur in dem I, R-Zustand aktiviert.
  • Unten werden nun AP-Top-Level-Zustände (AP-Zustände höchster Ebene) beschrieben:
    D, * – Jeglicher Zustand in dem verteilten Modus. "Infrastructure_Mode" ist Falsch, weil der AP noch keinen aktiven SCM entdeckt hat.
    D, L – Der AP befindet sich in einer Start-SCM-Entdeckungsperiode.
    D, A – Der AP arbeitet aktiv im verteilten Modus und nimmt Stationsverbindungen an.
    D, SC – Der AP hat während der Start-SCM-Entdeckungsperiode einen SCM-Kandidaten entdeckt.
    I, U – Infrastructure_Mode ist Wahr, und der AP hat sich noch nicht bei dem Wurzel-CM authentifiziert.
    I, A – Infrastructure_Mode ist Wahr, und der AP hat sich erfolgreich bei dem Wurzel-CM authentifiziert.
    I, P – Der AP hat die Pfadauthentifizierung erfolgreich abgeschlossen.
    I, R – Der AP hat sich erfolgreich bei dem Wurzel-CM registriert; die MN-(Vorab-)Registrierung ist aktiviert.
    I, * – Jeglicher Zustand, bei dem Infrastructure_Mode Wahr ist. Top-Level-AP-Zustandsübergangs-Tabelle
    Zustand Ereignis Aktion Nächster Zustand
    Anfänglich System zurückgesetzt; gute Ethernet-Verbindung; automatischer Ersatz ist aktiviert Einen "SCM-Listen-Timer" mit einer Ablaufzeit von 10 Sekunden starten; SCMBekanntmachungs-Anfrage senden D, L
    D, * Aktive SARpM empfangen Infrastructure_Mode auf WAHR setzen; Die Vater-SCM-Aufzeichnung und den IN_1X_Authenticator aktualisieren; Die Authentifizierung mit dem SCM initiieren I, U
    D, L Inaktive SARpM empfangen SCM-Listen-Timer mit einer MAX_SCM_ELECT_TIME-Ablaufzeit erneut starten; SCM-Kandidaten-Prioritäts-ID abspeichern D, SC
    D, SC Inaktive SCM-Bekanntmachung mit höherer Priorität empfangen SCM-Listen-Timer mit einer MAX_SCM_ELECT_TIME-Ablaufzeit erneut starten; SCM-Kandidaten-Prioritäts-ID abspeichern D, SC
    D, L SCM-Listen-Timer läuft ab Aktiven Betrieb im verteilten Modus starten D, A
    D, SC SCM-Listen-Timer läuft ab (d. h., weil die aktive SCM-Auswahl nicht vollendet wurde) Aktiven Betrieb im verteilten Modus starten. D, A
    D, A Inaktive SARpM empfangen (keine) D, U
    1, U Die Authentifizierung bei dem Wurzel-CM wird erfolgreich abgeschlossen. Pfadauthentifizierung initiieren. I, A
    I, A Die Pfadauthentifizierung wird erfolgreich abgeschlossen AP-Registrierung initiieren P
    I, P Die Registrierung wird erfolgreich abgeschlossen MN-Vorabregistrierung und -Registrierung aktiveren; Authentifizierte MNs registrieren; die MN 802.1X Authentifikator-Funktion zu dem SCM transferieren; den SCM_Advertisement_Timer starten I, R
    I, * Eine aktive SARpM von der aktiven SCM-Instanz empfangen. Das SCM_Age auf 0 zurücksetzen; Die Parent_SCM_Record aktualisieren I, *
    I, * Inaktive SARpM oder eine "aktive" SARpM mit einem niedrigeren Instance Age von dem aktiven SCM empfangen Infrastrucutre_Mode auf Falsch setzen D, U
    I, * Eine aktive SARpM mit einer höheren Priorität von einem SCM mit einer anderen Priorität empfangen Die SCM-Zustandsinformationen aktualisieren; Authentifizierung mit dem neuen aktiven SCM initiieren I, U
    I, * Eine inaktive SARpM oder eine aktive SARpM mit einer niedrigeren Priorität von einem anderen SCM (Kandidaten) empfangen (keine) I, *
    I, R SCM_Advertisement_Timer läuft ab; das SCM_Age ist geringer als das MAX_SCM_Age Den Timer mit der aktuellen Bekanntmachungsperiode erneut starten; das SCM-Alter inkrementieren; SARpMs an jedem sekundären Port erzeugen I, R
    I, R SCM_Advertisement_ Timer läuft ab; das SCM_Age ist gleich dem MAX_SCM_AGE Infrastructure_Mode auf Falsch setzen D, U
  • SCM-Bekanntmachungs-Antwortnachrichten werden NICHT transparent von den WLCCP APs weitergeleitet. Statt dessen erzeugt ein registrierter AP "sekundäre" SCM-Bekanntmachungs-Antwortnachrichten an jedem seiner aktiven sekundären Ports mit der gleichen Periode wie der SCM. [Die Bekanntmachungsperiode ist in SCM-Bekanntmachungs-Antwortnachrichten enthalten.] SCM-Bekanntmachungs-Antwortnachrichten werden NICHT auf dem primären Port des AP oder auf AP-Ports gesendet, die von dem darunter liegenden STP "blockiert" sind.
  • SCM-Bekanntmachungen, die an sekundären Ports des AP übertragen werden, enthalten aktualisierte "Pfadkosten"- und "Hop-Zählungs"-Werte. Jedem AP-Port sind benutzerkonfigurierbare "Pfadkosten" zugewiesen. Standard-Pfadkosten-Werte sind für jeden AP-Port-Typ (z. B. Ethernet, 802.11a, 802.11b) definiert. Die aktualisierten Pfadkosten werden berechnet, indem die Pfadkosten, die dem primären Port des AP zugewiesen sind, zu den Pfadkosten des Vater-AP addiert werden (d. h., die Pfadkosten in den SCM-Bekanntmachungen, die an dem primären Port empfangen werden); die "Hop-Zählung" wird um '1' inkrementiert, wenn der primäre Port des AP ein drahtloser Port ist. Eine Teilnetzadresse und aktualisierte Pfadkosten- und Hop-Zählungs-Informationen werden auch in 802.11 Beacon- und Probe-Antwortnachrichten bekannt gegeben, die auf sekundären 802.11 Ports des AP gesendet werden, so dass nicht verbundene drahtlose APs und MNs schnell den kostengünstigsten Pfad zu dem primären LAN entdecken können (d. h., ohne sich iterativ mit jedem potentiellen Vater-AP verbinden und authentifizieren zu müssen).
  • Ein AP kann sich bei einem logischen SCM registrieren, der in derselben Hardware-Zelle enthalten ist. In diesem Fall sollten die Kosten, die dem "internen primären Port" zugewiesen sind, mit den Ethernet-Port-Kosten übereinstimmen (d. h., um Stationen daran zu hindern, zu einem AP zu wandern, der in der gleichen Zelle wie ein SCM angeordnet ist).
  • Ein Nicht-SWAN-AP kann SCM-Bekanntmachungs-Antwortnachrichten, die von einem anderen SWAN-Knoten erzeugt werden, transparent weiterleiten. Ein Sohn-AP muß jegliche SCM-Bekanntmachungs-Antwortnachrichten verwerfen, die nicht von seinem Vater erzeugt werden. Ein Sohn-AP kann das Hop-Quellen-Feld der SCM-Bekanntmachung verwenden, um festzustellen, ob sein Vater-AP eine SCM-Bekanntmachungs-Nachricht erzeugt hat. Die Hop-Quellen-Adresse muß die gleiche sein wie die Hop-Adresse des Vater-AP.
  • Wurzel-APs sind immer an den aktiven SCM in dem nativen VLAN gebunden. Ein Wurzel-AP empfängt nur SCM-Bekanntmachungs-Antwortnachrichten in seinem nativen VLAN an dem primären Port. Ein Nicht-Wurzel-AP muß zu demselben Teilnetz gehören wie sein Vater-AP; deshalb ist ein Nicht-Wurzel-AP immer an denselben SCM gebunden wie der Vater-(oder Vorgänger-)Wurzel-AP.
  • SWAN APs sind mit einer einzigen "WLCCP SSID" konfiguriert. Eine Campus-weite WLCCP SSID ist ausreichend, wenn ein Campusnetz nur Wurzel-APs enthält oder wenn sich Nicht-Wurzel-APs dynamisch an jedes Teilnetz binden können. Teilnetzspezifische WLCCP SSIDs können verwendet werden, um Nicht-Wurzel-APs an ein spezifisches Teilnetz zu binden (d. h., das Teilnetz mit den Wurzel-APs mit einer übereinstimmenden WLCCP SSID). [Ein Sohn-AP kann DHCP verwenden, um sich dynamisch an ein Teilnetz zu binden; aber das native VLAN und der Satz von aktivierten VLANs in einem Vater- und Sohn-AP müssen übereinstimmen.]
  • Ein Sohn-802.11-Port (d. h., in einem Repeater-AP oder einer Sohn-802.11-Brücke) verwendet die WLCCP SSID, um sich mit einem Vater-AP zu verbinden. Ein Sohn-AP sendet Probe-Anfragen, die die WLCCP SSID enthalten, und potentielle Vater-APs antworten mit einer Probe-Antwort, die eben falls die WLCCP SSID enthält. Ein Sohn-AP kann sich nur mit einem Vater-AP mit einer übereinstimmenden WLCCP SSID verbinden.
  • Ein AP oder Sohn-CM muß seinen Pfad zu dem Wurzel-CM authentifizieren, nachdem er sich erfolgreich mit dem 802.1X IN Authentifikator authentifiziert hat, um sich gegenseitig mit jedem Vorgängerknoten auf seinem Zweig des SWAN-Topologiebaums zu authentifizieren und einen geheimen Kontexttransferschlüssel (CTK) mit jedem Vorgängerknoten auf seinem Zweig des SWAN-Topologiebaums zu erstellen. Ein AP muß auch immer dann eine Pfadauthentifizierung initiieren, wenn er eine neue SCM-Instanz entdeckt. Ein Nicht-Wurzel-AP muß ebenfalls immer dann eine Pfadauthentifizierung initiieren, wenn er zu einem neuen Vater-AP roamt. [Als eine Option braucht ein Nicht-Wurzel-AP sich nicht vollständig zu authentifizieren, wenn er roamt, wenn eine schnelle erneute Authentifizierung für die Sohn-APs unterstützt wird.]. Die Pfadauthentifizierung umfasst einen Pfad-Init-Anfrage-/Antwort-Austausch und einen anfänglichen Registrierungsanfrage-/-antwort-Austausch. Die Pfadauthentifizierung und CTK-Aktualisierungen werden in dem Abschnitt mit dem Titel "Infrastruktur-Pfadauthentifizierung" genauer beschrieben.
  • Ein nicht angeschlossener AP muß eine Pfad-Init-Anfrage zu seinem ausgewählten Vaterknoten an seinem ausgewählten primären Port senden, um die Pfadauthentifizierung zu initiieren. In der Pfad-Init-Anfrage und der entsprechenden Antwort ist der Absender der nicht angeschlossene AP; der Anfragende ist ebenfalls der nicht angeschlossene AP; und der Antwortende ist der ausgewählte Vaterknoten (d. h., der Vater-AP oder SCM).
  • Nicht-Sicherheitsfelder in einer Pfad-Init-Anfrage, die von einem nicht angeschlossenen AP gesendet wird, werden so eingestellt, wie dies unten beschrieben ist. (Nicht spezifizierte Felder werden auf '0' gesetzt.) Das Hopwise-Routing Flag wird auf '1' gesetzt, so dass jeder Vorgänger-AP in dem Pfad zu dem SCM die Anfrage und die entsprechende Antwort verarbeitet. Sicherheits-TLVs sind in den Pfad-Init-Nachrichten (und den anfänglichen Registrierungsnachrichten) enthalten.
  • WLCCP-Header-Felder:
    • Typ – '12'
    • Absender – Knoten-ID des nicht angeschlossenen AP.
    • Antwortender – Knoten-ID des SCM.
    • Response-Req Flag – '1' zum Abrufen einer Antwort.
    • Inbound Flag – '1'.
    • Hopwise-Routing Flag – '1', wenn Schicht-2-Pfadaktualisierungen aktiviert sind; anderenfalls '0' ..
    • Root CM Flag – '1'.
    • TLV Flag – '1' (Die Anfrage muß eine EAP_IDENTITY_TLV enthalten.)
  • Pfad-Init-Felder:
    • Anfragender – Knoten-ID des AP.
    • Relay-Knoten-ID – '0'.
    • Proxy Flag – '0'.
  • Der Vaterknoten muß eine Pfad-Init-Anfrage von einem nicht angeschlossenen AP oder CM eingehend weiterleiten, bis sie den Wurzel-CM erreicht. Der Vaterknoten gibt seine Knoten-ID in das Absender-Feld ein und die Knoten-ID seines Vater-CM in das Antwortender-Feld ein, bevor die Anfrage eingehend weitergeleitet wird. Ein Zwischen-LCM muß das Antwortender Feld mit der CCM-Knoten-ID aktualisieren, bevor er die Anfrage eingehend zu dem CCM weiterleitet. Der CCM sendet eine Pfad-Init-Antwort zu dem Vaterknoten (d. h., dem Absender) zurück. Der Vaterknoten aktualisiert das Antwortender-Feld mit der Antwortender-Knoten-ID, bevor er die Antwort zu dem nicht angeschlossenen AP oder CM weiterleitet.
  • Ein AP muß sich bei dem Wurzel-CM authentifizieren, bevor er sich bei der SWAN-Infrastruktur registrieren kann. Ein AP entdeckt den Wurzel-CM über eine WTLV_ROOT_CM TLV, die in den SCM-Bekanntmachungsnachrichten enthalten ist. Der Wurzel-CM kann der lokale SCM, ein LCM oder der CCM sein.
  • Ein nicht angeschlossener AP sucht nach einem potentiellen Vater-SCM oder -AP an jedem seiner Ports, die in einem Sohn- oder Vater-/Sohn-Modus konfiguriert sind. [Es sei angemerkt, dass ein angeschlossener AP in den nicht angeschlossenen Zustand übergeht, wenn er eine neue Instanz seines Vater-AP oder -SCM entdeckt.] Ein nicht angeschlossener AP oder CM muß eine anfäng liche Registrierungsanfrage zu seinem ausgewählten Vaterknoten an seinem ausgewählten primären Port senden, um ein Anschließen an das Netz anzufordern. In der anfänglichen Registrierungsanfrage und der entsprechenden Antwort ist der Absender der nicht angeschlossene AP; der Anfragende ist ebenfalls der nicht angeschlossene AP; und der Antwortende ist der ausgewählte Vaterknoten (d. h., der Vater-AP oder -SCM).
  • Die Felder in einer anfänglichen Registrierungsanfrage, die von einem nicht angeschlossenen AP gesendet wird, sind wie unten beschrieben eingestellt. (Nicht spezifizierte Felder werden auf '0' gesetzt.)
  • WLCCP-Header-Felder:
    • Typ – '3'
    • Absender – Knoten-ID des nicht angeschlossenen AP.
    • Antwortender – Knoten-ID des ausgewählten Vaterknotens (Vater-AP oder Vater-SCM).
    • Response-Req Flag – '1' zum Abrufen einer Antwort.
    • Inbound Flag – '1'.
    • Hopwise-Routing Flag – '1'.
    • TLV Flag – '1' (die Anfrage muß eine WTLV_AP_PORT_ADDRESS TLV für jeden AP-Port enthalten).
  • Registrierungsfelder:
    • Anfragender – Knoten-ID des nicht angeschlossenen AP.
    • Hop-Adresse – 802-Adresse des ausgewählten primären Ports des nicht angeschlossenen AP.
    • Relay-Knoten-ID – '0' in einer Registrierungsnachricht, die von dem Absender oder dem Antwortenden erzeugt wird. Anderenfalls die Knoten-ID eines Zwischen-"Relay"-Knotens, der die Nachricht weitergeleitet hat.
    • Initial Flag – '1'.
    • VLAN ID – Die native VLAN ID sowohl des nicht angeschlossenen AP als auch des Vaterknotens. Der VLAN ID Wert kann '0' sein. Wenn der VLAN ID Wert anders als die native VLAN ID des Vaterknotens ist, liegt ein Fehler vor.
  • Der Vaterknoten muß eine anfängliche Registrierungsanfrage von einem nicht angeschlossenen AP eingehend weiterleiten, bis diese den Wurzel-CM erreicht. Der Vaterknoten gibt seine Knoten-ID in das Absender-Feld ein und die Knoten-ID seines Vater-CM in das Antwortender-Feld ein, bevor er die Anfrage eingehend weiterleitet. Ein Zwischen-LCM muß das Antwortender-Feld mit der CCM-Knoten-ID aktualisieren, bevor er die Anfrage nach innen gerichtet bzw. eingehend zu dem CCM weiterleitet. Der CCM sendet eine Registrierungsantwort zu dem Vaterknoten (d. h., dem Absender) zurück. Der Vaterknoten aktualisiert das Antwortender Feld mit der Anfragender-Knoten-ID, bevor er die Antwort zu dem nicht angeschlossenen AP oder CM weiterleitet.
  • Ein AP sendet periodisch eine "Aktualisierungs"-Registrierungsanfrage-Nachricht zu dem SCM, um seine Mobilitätsbindungen in jedem Knoten auf dem Pfad zu dem SCM "aufzufrischen". Bei einer Aktualisierungs-Registrierungsanfrage ist das Initial Flag auf AUS gesetzt, und sie enthält eine gültige Pfad-ID. Ein angeschlossener AP oder CH kann eine "Aktualisierungs"-Registrierungsanfrage direkt zu seinem Vater-CM senden, wobei er selber sowohl der Absender, als auch der Antwortender-Knoten ist und der Vater-CM der Antwortende ist. Der Vater-CM muß das Antwortender Feld mit der Knoten-ID seines Vater-CM aktualisieren, bevor er die Anfrage eingehend weiterleitet.
  • Ein AP sendet eine Registrierungsanfrage (erneut) entweder, bis er eine Registrierungsantwort mit einer passenden Nachrichten-ID empfängt, oder bis die maximalen erneuten Versuche überschritten sind. Ein AP ist "registriert", wenn er eine passende Registrierungsantwort mit einem "guten" RegStatus empfängt. Die Registrierungsantwort enthält eine Pfad-ID, die von dem SCM gesetzt ist, die die "Pfadinstanz" von dem AP zu dem SCM identifiziert.
  • Eine Registrierungsanfrage von einem AP muß eine WTLV_AP_PORT_LIST TLV enthalten, die eine Liste von WLTV_AP_PORT_INFO TLVs enthält. Jede PORT_INFO TLV enthält den Porttyp, den Portmodus (Vater, Sohn oder Vater/Sohn), und die 802-Portadresse einer physikalischen Kommunikationsschnittstelle.
  • Eine Registrierungsanfrage von einem AP muß eine IP Address TLV enthalten, um seine IP-Adresse an seine Knoten-ID zu binden. Ein AP muß eine Aktualisierungs-Registrierungsanfrage sofort immer dann erzeugen, wenn sich seine IP-Adresse ändert.
  • Eine Registrierungsanfrage von einem AP, der mit einer Proxy MIP SSID konfiguriert ist, muß eine WTLV_PMIP_SSID_LIST TLV umfassen, die eine Liste von Proxy MIP SSIDs und MIP HA Bindungen enthält.
  • Vorabregistrierungsnachrichten werden verwendet, um Kontextinformationen zu erhalten, die vor der Registrierung benötigt werden. Ein neuer Vater-AP sendet optional eine Vorabregistrierungsanfrage-Nachricht zu seinem Vater-SCM, um dynamische Berechtigungsnachweise und "alte AP-Bindungen" für eine 802.11-Station (MN oder Sohn-AP) zu erhalten, wenn sie sich "erneut verbindet". [Eine Vorabregistrierungsanfrage wird NICHT erzeugt, wenn sich eine 802.11-Station anfänglich "verbindet".] Der Vater-AP erzeugt eine Vorabregistrierungsanfrage, wenn er 1) eine erneute 802.11-Verbindungsanfrage oder 2) eine 802.1X EAP Identitätsantwortnachricht von der 802.11-Station empfängt. Die Vorabregistrierungsanfrage enthält die Knoten-ID der Sohn-Station und deren Sicherheits-"Kennung".
  • Eine Vorabregistrierungsanfrage wird eingehend zu dem am nächsten liegenden gemeinsamen Vorgänger-CM des alten AP und des neuen AP weitergeleitet (mit einigen Einschränkungen, die unten aufgeführt sind). Wenn der "gemeinsame CM" die Mobilitätsbindungen und den Sicherheitskontext für die Sohnstation besitzt, dann werden die alten AP-Bindungen und die dynamischen Berechtigungsnachweise in einer Vorabregistrierungsantwortnachricht zurückgesendet. Anderenfalls wird eine Vorabregistrierungsantwort mit einem "nicht gefunden"-Status zurückgesendet und die Station muß sich vollständig authentifizieren.
  • Eine Vorabregistrierungsanfrage für einen MN wird niemals über den nächsten gemeinsamen LCM hinaus weitergeleitet, da der LCM der MN-Authentifikator ist. Ein AP kann nicht über Teilnetzgrenzen roamen; deshalb sollte der nächste gemeinsame Vorgänger-CM für einen Sohn-AP immer der lokale SCM sein.
  • Eine Vorabregistrierungsantwort erstellt KEINE "gebundene" Pfadinstanz. Eine 802.11-Antwortnachricht für eine erneute Verbindung wird optional erzeugt, wenn der Vater-AP eine Antwort empfängt.
  • Ein neuer Vater-AP braucht keine Vorabregistrierungsanfrage zu senden, um die dynamischen Berechtigungsnachweise für eine 802.11-Station zu bekommen, wenn die schnelle erneute Authentifizierung mit einem Netz-Sitzungsschlüssel nicht unterstützt wird oder wenn die dynamischen Berechtigungsnachweise der Station "prädiktiv" zu dem neuen Vater-AP weitergeleitet werden. In diesem Fall werden die "alten AP-Bindungen" der Station in einer Registrierungsantwortnachricht zurückgesendet. Ein spezifisches Vorabregistrierungs-Handshaking hängt von dem 802.11-Verfahren für eine erneute Authentifizierung ab.
  • Die Felder in einer Proxy-Vorabregistrierungsanfrage-Nachricht, die von einem Vater-AP für einen Sohn-802.11-MN erzeugt werden, werden wie folgt eingestellt:
  • WLCCP-Header-Felder:
    • Typ – '9'
    • Absender – Knoten-ID des Vater-AP.
    • Antwortender – Knoten-ID des SCM.
    • Response-Req Flag – '1' zum Abrufen einer Antwort.
    • Inbound Flag – '1'.
    • Root CM Flag – '1' für einen AP; '0' für einen MN.
    • Hopwise-Routing Flag – '0'.
    • TLV Flag – '1' (Die Anfrage muß eine EAP_IDENTITY_TLV und eine SSID_TLV enthalten).
  • Vorabregistrierungsfelder:
    • Anfragender – Knoten-ID des MN.
    • Relay-Knoten-ID – '0'.
    • Proxy Flag – '1'.
    • EAP_IDENTITY TLV – Die Vorabregistrierungsanfrage für einen MN oder Sohn-AP muß eine WTLV_EAP_IDENTITY TLV enthalten, die die Kennung des Knotens aus einem optionalen 802.11-Element für eine erneute Verbindung oder aus der EAP Identitätsantwortnachricht enthält.
    • SSID_TLV – Die SSID des MN, herausgenommen aus der (erneuten) Verbindungsanfragenachricht des MN.
  • Ein Sohn-AP kann optional ein Node_ID-Element in seinen (erneuten) Verbindungsanfragenachrichten enthalten, um zu seinem Vater-AP seine WLCCP-Knoten-ID zu kommunizieren. Wenn ein Vater-AP die Knoten-ID eines Sohn-AP nicht kennt, dann muß er, wenn er eine Vorabregistrierungsnachricht für den Sohn-AP erzeugt, die Knotenadresse des Anfragenden auf '0' setzen. Eine Vorabregistrierungsanfrage sollte eine WTLV_PORT_ADDRESS_TLV enthalten, die die MAC-Portadresse des Sohn-AP enthält.
  • Ein Vater-AP erzeugt "Proxy"-Registrierungsanfrage-Nachrichten für verbundene MNs. Die Felder des Absenders, des Antwortenden und des Anfragenden werden wie folgt eingestellt:
    Absender – Knoten-ID des Vater-AP.
    Antwortender – Knoten-ID des SCM.
    Anfragender – 802-Adresse des MN.
  • Ein Vater-AP muß eine Proxy-Registrierungsanfrage für einen MN erzeugen, nachdem er sich erfolgreich authentifiziert oder erneut authentifiziert (wie unten beschrieben wird).
  • Eine Proxy-MN-Registrierungslogik ist charakteristisch für die Implementierung und wird unten in den Abschnitten mit den Titeln "W1 Proxy-MN-Registrierung" und "W2 Proxy-MN-Registrierung" noch ausführlicher beschrieben.
  • Die SWAN-Authentifizierung und der SWAN-Datenschutz werden erzielt, indem SWAN-Infrastruktur-Knoten gezwungen werden, sich gegenseitig sowohl mit dem Wurzel-CM (CCM) als auch mit den IN-Knoten, mit denen sie kommunizieren werden, zu authentifizieren. Der Schutz von WLCCP-Nachrichten wird erreicht, indem der CCM CTKs nach einer erfolgreichen Vorabregistrierung von INs erzeugt und verteilt.
  • Eine "anfängliche Authentifizierung" basiert auf dem IEEE 802.1X Protokoll. Jeder "sichere MN", AP und CM muß sich anfänglich mit einem 802.1X Authentifikator über eine externen Authentifizierungsserver (z. B. einen RADIUS-Server) "gegenseitig authentifizieren". Infrastrukturknoten (APs, SCMs und LCMs) authentifizieren sich gegenseitig mit einem "IN-Authentifikator". "Sichere MNs" authentifizieren sich gegenseitig mit einem "MN-Authentifikator". Während MNs aus irgendwelchen unterstützten 802.1X EAP-Authentifizierungstypen auswählen können, sollen sich IN-Knoten unter Verwendung von LEAP authentifizieren.
  • In einem Campusnetz enthält der SWAN CCM den IN-Authentifikator und LCMs enthalten einen MN-Authentifikator. In einem selbständigen lokalen Bereich sind sowohl der IN-Authentifikator als auch der MN-Authentifikator in dem LCM enthalten. In einem selbständigen Teilnetzbereich sind sowohl der IN-Authentifikator als auch der MN-Authentifikator in dem SCM enthalten.
  • Alle Knoten müssen sich vor der Registrierung in die SWAN-Topologie authentifizieren. Der Knotenauthentifikator wird die Berechtigungsnachweise nach einer erfolgreichen 802.1X EAP-Authentifizierung in einem Cachespeicher aufnehmen. Der IN-Authentifikator wird Folgendes im Cachespeicher aufnehmen:
    Feld Länge (Bytes) Beschreibung
    Reserviert 1 Verwendet für die Byte-Ausrichtung
    Zustand 1 Gibt an, ob dieser Knoten aktiv ist oder nicht.
    Knoten-ID 8 WLCCP-Knotenkennung; Die MAC-Adresse des AP (z. B. BSSID)
    NSK 16 Der Schlüssel, der sich aus einer erfolgreichen LEAP-Authentifizierung ergibt.
    Sitzungs-Timeout 4 Sitzungsablaufzeit, die von der Radius Access Accept bereitgestellt wird
    CTK 32 Der aktuelle Kontexttransferschlüssel, der verwendet wird, um Kommunikationen zwischen dem SCM-Authentifikator und der Knoten-ID zu schützen
    Schlüsselsequenzzähler 4 Ein Sequenzzähler, der verwendet wird, um zu verfolgen, wie viele CTK-Schlüssel-Auffrischungen aufgetreten sind
    MIC-Sequenzzähler 8 Ein Sequenzzähler, der verwendet wird, um zu verfolgen, wie viele Nachrichten authentifiziert wurden
  • In ähnlicher Weise wird der MN-Authentifikator Folgendes in den Cachespeicher aufnehmen:
    Feld Länge (Bytes) Beschreibung
    Reserviert 1 Benutzt für die Byte-Ausrichtung
    Zustand 1 Zeigt an, ob dieser Knoten aktiv ist oder nicht
    STA Adr 8 WLCCP-Knotenkennung: MAC-Adresse des MN
    Authentifizierungstyp 1 EAP-Typ, der zur Authentifizierung verwendet wird
    Schlüsselmanagementtyp 1 Der ausgehandelte Typ der (oder keine) Schlüsselverwaltung. Gültige Werte sind: 0 – keine (NSK wird nicht weitergeleitet) 1 – CCKM 2 – 802.1X Legacy-Systeme (die eine effektive erneute Authentifizierung durchführen) leiten den NSK weiter. 3 – SSN
    Sitzungs-Timeout 4 Sitzungsablaufzeit, die von der Radius Access Accept bereitgestellt wird
    KRK 16 Haupt-Anfrageschlüssel, der verwendet wird, um die Anfrage von MNs bezüglich Kontexttransfers zu authentifizieren
    BTK 32 Basis-Übergangsschlüssel, der zum Ableiten der PTKs verwendet wird
    RN 8 Erneute Schlüssel-Nummer, die verwendet wird, um zu verfolgen, wie viele PTKs von dem BTK abgeleitet worden sind
    SSID L SSID TLV, die mit dem MN assoziiert ist
    EAP-ID P EAP Identity TLV
    VLAN ID 2 VLAN-Zuweisung, die mit dem MN assoziiert ist
    BSSID 6 Definiert den aktuellen assoziierten AP
    Cipher (Verschlüsselung) 2 Ausgehandelte Verschlüsselung, Werte sind: 0x0000 – keine 0x0001 – WEP 0x0002 – TKIP 0x0003 – AES-OCB 0x0004 – AES-CCMP 0x0005 – CKIP 0xff<Wert> – Händlerspezifisch
    NSK Länge 2 NSK-Länge in Bytes
    NSK N Der Schlüssel, der sich aus einer erfolgreichen 802.1X-EAP-Authentifizierung ergibt. Dies ist der MS-MPPE Rx-Schlüssel, der von dem AS gesendet wird
    Tx Schlüssellänge 2 Tx-Schlüssellänge
    Tx Schlüssel M Der Schlüssel, der sich aus einer erfolgreichen 802.1X-EAP-Authentifizierung ergibt. Dies ist der MS-MPPE Tx-Schlüssel, der von dem AS gesendet wird
  • Die Felder in jedem Registrierungseintrag werden entweder bei einem 802.1X-EAP-Authentifizierungserfolg oder während einer Vorabregistrierung bestückt. Eine erfolgreiche Authentifizierung wird zu der Erschaffung eines Registrierungseintrags mit den richtigen IDs, dem NSK und den definierten Sitzungs-Timeout-Werten führen. Für den MN werden auch die gültige BSSID, SSID und VLAN ID bei der Authentifizierung auf der Grundlage der EAP-Identität definiert.
  • 802.1X EAP-Authentifizierungsnachrichten werden von dem Vater des Knotens gemäß WLCCP eingekapselt. Ein Infrastrukturknoten kommuniziert während der Authentifizierung direkt über eine verdrahtete Verbindung mit dem IN-Authentifikator. Wenn der IN-Vater die EAPOL-Authentifizierungnachricht empfangen hat, wird er diese unter Verwendung einer WLCCP_AAA-Nachricht einkapseln.
  • Da ein MN immer durch den AP mit dem MN-Authentifikator kommuniziert, muß der AP die EAP-Nachrichten gemäß WLCCP einkapseln. Da sich der AP bei dem MN-Authentifikator authentifiziert und registriert hat, können WLCCP_AAA-Nachrichten optional authentifiziert werden. Wie in dem Abschnitt mit dem Titel "EAP-Authentifizierungsanfrage-/-antwort-Nachricht" beschrieben ist, können WLCCP_AAA-Nachrichten eine MIC TLV als Anhang aufweisen. Die MIC gilt für die gesamte WLCCP-Nachricht, einschließlich des Headers:
    MIC = HMAC-MD5(TCK, WLCCP-_AAA Nachricht)
    wobei CTK = der Schlüssel, der von dem direkten Sender und dem direkten Empfänger gemeinsam benutzt wird.
  • WLCCP-Antworten oder abgehende Nachrichten erlauben die Möglichkeit, einen Status zu spezifizieren. Für Fehlerbedingungen werden die folgenden Statuswerte während einer WLCCP_AAA gelten:
    Status Wert Beschreibung
    KEIN KONTEXT 1 Unzureichende Berechtigungsnachweise wurden bereitgestellt: entweder der NSK oder der Sitzungs-Timeout haben in der Radius Access Accept Nachricht gefehlt
    SCHLECHTE SSID 2 Eine ungültige SSID ist spezifiziert
    EAP FEHLSCHLAG 3 Die EAP-Authentifizierung schlug fehl
  • Jeder "sichere" MN muß sich gegenseitig mit einem MN 802.1X Authentifikator über einen externen Sicherheitsserver authentifizieren. In dem Infrastrukturmodus befindet sich der MN Authentifikator in einem LCM. In dem selbständigen SCM-Modus befindet sich der MN-Authentifikator in dem SCM.
  • Ein MN muß keine Kenntnis von der Infrastruktur hinter dem AP haben. Somit wird aus der Sicht des MN die MN-Authentifizierung so ausgeführt, wie sie von den 802.11(SSN und TGi)-Protokollen als auch von der Verwendung des CCKM spezifiziert ist. Damit ein MN von der SWAN-Topologie richtig gemanagt werden kann, muß er eine 802.1X EAP-Authentifizierung aushandeln.
  • Der MN muß eine 802.1X EAP-Authentifizierung verwenden, um die Nutzen aus den Sicherheitsvorteilen von LEAP, SSN oder TGi sowie auch der SWAN-Handhabbarkeit zu ziehen. In der SWAN-Architektur ist der MN-Authentifikator von dem Vater-AP abgelöst. Wenn sich der MN auf eine 802.1X EAP-Authentifizierung einlässt, werden seine EAPOL-Nachrichten gemäß WLCCP von dem Vater-AP in EAP-Authentifizierungsanfrage-Nachrichten eingekapselt und zu dem MN-Authentifikator weitergeleitet.
  • In Abhängigkeit von der ausgehandelten Schlüsselverwaltung muß der MN-Authentifikator auch die erforderlichen Schlüssel zu dem AP in einem Vorabregistrierungsanfrage-/-antwort-Austausch richtig weiterleiten. Die nachfolgende Tabelle beschreibt, was der MN-Authentifikator auf der Grundlage des ausgehandelten Schlüsselverwaltungstyps weiterleiten muß:
    Schlüsselverwaltungstyp Beschreibung
    Keiner Während das Radius einen NSK erzeugen kann, wird der MN-Authentifikator den NSK nur bei der anfänglichen Verbindung weiterleiten; die Operation ist effektiv ein nicht in einem Cachespeicher aufgenommener NSK.
    Cisco-LEAP Der Radius-MS-MPPE-Schlüssel wird für den Schutz von 802.11-Paketen zu dem SCM und danach zu dem AP weitergeleitet
    SSN/TGI Der Radius-MS-MPPE-Schlüssel wird für den 802.1X-4-Wege-Handshake zur Erstellung von PTKs pro AP zu dem SCM und danach zu dem AP weitergeleitet
    CCKM Der MN-Authentifikator läßt sich auf einen 4-Wege-Handshake ein, um den erneuten Schlüssel-Authentifizierungsschlüssel KRK und den Basis-Übergangsschlüssel, den BTK zu erstellen. Nur die BTKs müssen zu dem AP weitergeleitet werden, um PTKs zu erstellen. CCKM benötigt eine Vorabregistrierungsanfrage/-antwort, die auf die anfängliche Authentifizierung folgt.
  • Die paarweisen Übergangsschlüssel (PTKs), die verwendet werden, um Kommunikationen zwischen dem MN und dem AP zu schützen, werden von dem MN und dem AP in allen Schlüsselverwaltungsschemata erzeugt.
  • Der AS muß auch die Sitzungs-Timeout-Einstellung auf der Grundlage von Schlüsselverwaltungslösungswegen anpassen. Für LEAP bleibt der Sitzungs-Timeout eine Funktion der ausgehandelten 802.11 Cipher Suite. Aber für sowohl SSN/TGi als auch CCKM ist der Sitzungs-Timeout eine Funktion des gegenseitig abgeleiteten Schlüssels jedes EAP-Authentifizierungstyps.
  • Nachdem sich ein CCKM MN erfolgreich authentifiziert hat, muß der MN-Authentifikator eine Schlüsselinitialisierung auslösen, um den Haupt-Anfrageschlüssel (KRK) und den Basis-Übergangsschlüssel (BTK) zu erstellen, bevor der MN und der assoziierte AP PTKs erstellen können.
  • Zum Auslösen der KRK- und BTK-Ableitung muß der MN-Authentifikator eine 16 Byte große Nonce erzeugen. Eine EAPOL-Schlüssel-Nachricht des Formats, das in dem aktuellen TGi-Entwurf [6] beschrieben ist, wird erzeugt, um die Nonce zu dem MN zu senden und auf diese Weise den 4-Wege-Handshake zu initiieren, der verwendet wird, um KRK und BTK zu erstellen. Die EAPOL-Schlüssel-Nachricht wird in eine WLCCP AAA-Nachricht eingekapselt und dem MN zugestellt. Die Zustellung erfolgt durch den AP, auf diese Weise wird der AP die WLCCP-Nachricht entkapseln und die EAPOL-Schlüssel-Nachricht zu dem MN weiterleiten. Der Handshake schreitet voran, wie dies in der schnellen Weiterreichung (Fast Handoff) unter Verwendung der Central Key Management Protocol Spezifikation von Cisco beschrieben ist.
  • Nachdem sich ein CCKM MN erfolgreich authentifiziert hat, muß der MN-Authentifikator eine Schlüsselinitialisierung auslösen, um den Haupt-Anfrageschlüssel (KRK) und den Basis-Übergangsschlüssel (BTK) zu erstellen, bevor der MN und der assoziierte AP PTKs erstellen können.
  • Zum Auslösen der KRK- und BTK-Ableitung muß der Authentifikator eine 16 Byte große Nonce erzeugen. Eine EAPOL-Schlüsselnachricht des Formats, das in dem aktuellen TGi-Entwurf [6] beschrieben ist, wird erzeugt, um die Nonce zu dem MN zu senden und auf diese Weise den 4-Wege-Handshake zu initiieren, der verwendet wird, um KRK und BTK zu erstellen. Die EAPOL-Schlüsselnachricht wird in eine WLCCP_AAA-Nachricht eingekapselt und dem MN zugeführt. Die Zustellung erfolgt durch den AP, auf diese Weise wird der AP die WLCCP-Nachricht entkapseln und die EAPOL-Schlüsselnachricht zu dem MN weiterleiten. Der Handshake geht so von statten, wie dies in der schnellen Weiterreichung unter Verwendung der Central Key Management Protocol Spezifikation von Cisco beschrieben ist.
  • Ein Infrastrukturknoten muß sich zuerst mit dem IN-Authentifikator mittels der 802.1X EAP-Authentifizierung authentifizieren, um einen geheimen Netz-Sitzungsschlüssel (NSK) zu erstellen. Für anfängliche Freigaben wird LEAP der Authentifizierungstyp sein. Da LEAP dafür bekannt ist, dass es anfällig ist für Wörterbuch-Angriffe, sowie auch für eine gute Sicherheitspraxis bekannt ist, muß ein CTK auch gegenseitig abgeleitet werden, um Daten zu schützen, die zwischen dem IN und dem IN-Authentifikator ausgetauscht werden.
  • Ein authentifizierender "Supplicant"-IN tauscht EAPOL-Authentifizierungsnachrichten mit seinem Vater-AP oder -CM aus. Der Vater-AP oder -CM des Supplicant überträgt die EAPOL-Authentifizierungsnachrichten zwischen dem Supplicant und dem IN-Authentifikator in dem Wurzel-CM. Die EAPOL-Authentifizierungsnachrichten werden mit einer Ausnahme in WLCCP-AAA-Nachrichtenanfrage- und -antwort-Nachrichten eingekapselt. Ein Sohn-AP muß unbearbeitete EAPOL-Nachrichten mit seinem Vater-AP auf einer 802.11-Verbindung austauschen.
  • Der IN-Authentifikator enthält einen RADIUS Client, der EAP_Authentifizierungsanfrage-Nachrichten in RADIUS-Anfragenachrichten umwandelt und RADIUS-Antwortnachrichten in AAA-Nachrichtenantworten umwandelt. Der IN-Authentifikator stellt auf der Grundlage der empfangenen RADIUS-Nachrichten fest, ob der Authentifizierungsprozess fehlgeschlagen ist. Der IN-Authentifikator zeigt einen Authentifizierungsfehlschlag an, indem er einen Nicht-Null-Status-Wert in einer WLCCP_AAA-Antwort zurücksendet.
  • Ein geheimer "Sitzungsschlüssel" NSK wird während der anfänglichen Authentifizierung erstellt. Der NSK wird dann von dem IN und dem IA zusammen mit ausgetauschtem Schlüsselmaterial verwendet, um gegenseitig den CTK abzuleiten. Die den CTK schützenden TLVs und Nachrichten zwischen dem IN und dem IA sind die einzigen CTKs, die eine gegenseitige Ableitung erfordern, alle CTKs der anderen Verbindungen werden durch eine starke Pseudo-Random-Funktion von dem IA abgeleitet und den INs zugeführt.
  • Ein SCM oder LCM bestimmt, dass er sich anfänglich mit dem IN-Authentifikator in dem CCM authentifizieren muß, wenn er mit der IP-Adresse des CCM konfiguriert ist.
  • Alle Infrastrukturknoten müssen nach einer erfolgreichen LEAP-Authentifizierung auch eine "Pfadauthentifizierung" initiieren, um sich gegenseitig mit jedem ihrer Vorgänger zu authentifizieren und um mit diesen einen CTK zu erstellen. Die Pfadauthentifizierung wird unten in dem Abschnitt mit dem Titel "Infrastruktur-Pfadauthentifizierung" beschrieben.
  • SCM-Bekanntmachungs-Antwortnachrichten enthalten eine ROOT_CM_INFO TLV, die es den APs ermöglicht, automatisch den Wurzel-CM und den IN-Authentifikator zu entdecken. Ein AP muß sich anfänglich mit dem IN-Authentifikator authentifizieren, der von der IP-Adresse identifiziert wird, die in der TLV enthalten ist.
  • Eine Registrierungsantwortnachricht, die zu einem AP gesendet wird, kann eine MN_1X_AUTHEN TLV enthalten, die den aktuellen MN-Authentifikator identifiziert. Der SCM kann einen neuen MN-Authentifikator in einer MN_1X_AUTHEN TLV bekannt geben, die in den SCM-Bekanntmachungs-Antwortnachrichten enthalten ist.
  • Ein IN muß periodisch den anfänglichen Authentifizierungsprozess wiederholen, um einen "frischen" Sitzungsschlüssel (z. B. NSK) aufrecht zu erhalten; das Auffrischen der NSKs wird von dem Sitzungs-Timeout bestimmt, der von dem Authentifizierungsserver (AS) definiert wird.
  • Wenn sich der SCM in einem selbständigen Modus befindet, dann agiert er sowohl als der MN- als auch als der IN-Authentifikator. Eine Pfadinitialisierungsnachricht mit nur einer einzigen Secure Context TLV wird benötigt, da sie nur den direkten CTK mit dem IN-Authentifikator (z. B. den SCM) benötigt. Da dies die einzige vorhandene Verbindung ist, benötigt die Pfadinitialisierungsnachricht nur einen 3-Wege-Handshake: Anfrage, Antwort und Bestätigung (Confirm). Aber um mit einer kompletten Topologieinfrastruktur in Einklang zu bleiben, soll der AP in der selbständigen SCM-Konfiguration einen Anfrage-/Antwort-Handshake für die Pfadinitialisierung verwenden und die Schlüsselerstellung durch die Verwendung der Authenticator TLV in dem Registrierungsanfrage-/-antwort-Austausch bestätigen.
  • Aber in einer vollständigen SWAN-Topologie wird ein kompletter 4-Nachrichten-Handshake benötigt, um sowohl die Schlüsselzustellung als auch die Lebendigkeitsbestätigung zwischen dem Supplicant-IN und seinen Vorgängern zu erstellen. Die Anfrage-/Antwortnachrichten werden für die Schlüsselzustellung benötigt, und die Confirm/Ack werden benötigt, um zu beweisen, dass jede Verbindung lebendig ist. 29 gibt ein Beispiel für eine Wurzel-AP-Authentifizierung an. Obwohl das Beispiel die Wurzel-AP-Authentifizierung und die CTK-Erstellung demonstriert, werden die gleichen Schritte für alle anderen Infrastrukturknoten, z. B. den LCM und den SCM, benötigt.
  • Nachdem sich ein Infrastrukturknoten anfänglich authentifiziert hat, muß er sich mit jedem seiner Vorgängerknoten, einschließlich des IA, gegenseitig authentifizieren und mit diesen einen separaten geheimen "Kontexttransferschlüssel" (CTK) erstellen. Eine Pfad-Init-Nachricht wird verwendet, um CTKs zwischen dem Supplicant-IN und seinen Vorgängern zu erstellen. Jeder Vorgängerknoten muß eine 16-Byte-Nonce bereitstellen, um die Verteilung von neuen CTKs zu gestatten. Der IA dient für diesen Zweck als ein vertrauenswürdiges Schlüsselverteilungscenter KDC (key distribution center). Die CTKs wer den verwendet, um MICs zu erzeugen und sensible Kontextinformationen in Nachrichten zu verschlüsseln, die auf Zweigen des Topologiebaums weitergeleitet werden. CTKS sind 256-Bit-Werte, deren niederwertige 128 Bits dazu verwendet werden, Nachrichten und TLV zu authentifizieren, und deren höherwertige 128 Bits dazu verwendet werden, Nachrichten und TLVs zu verschlüsseln.
  • Für den CTK, der zwischen dem IN und dem IA verwendet wird, muß der Supplicant-IN eine 16-Byte-Nonce in der Pfad-Init-Anfragenachricht bereitstellen, so dass der IA den CTK ableiten kann. Der IA stellt seine 16-Byte-Nonce in der Pfad-Init-Antwortnachricht bereit, so dass der IN den CTK ableiten kann. Eine abschließende Pfad-Init-Bestätigungsnachricht wird benötigt, um es dem IN zu erlauben, den korrekten Empfang von Schlüsselmaterial und die Lebendigkeit des CTK zu bestätigen. Wenn eine komplette Pfadauthentifizierung durch die Verwendung eines WTLV_INIT_SESSION TLV angefordert wird, wird eine vierte Nachricht benötigt, um die Lebendigkeit des CTK zu erstellen, der in dem Pfad-Init-Anfrage-/-antwort-Austausch verteilt wird.
  • Ein nicht registrierter und nicht authentifizierter IN-"Supplicant" initiiert eine Pfadauthentifizierung, indem er eine Pfad-Init-Anfragenachricht zu seinem ausgewählten Vaterknoten sendet und dabei eine WTLV_INIT_SESSION einbettet. In der mit Session TLV ist eine Secure Context TLV enthalten, die die 16-Byte-Nonce des IN umfasst, die auf den IA gerichtet ist (z. B. die DST-ID ist der IA in der Secure Context TLV). Der Vaterknoten leitet die Pfad-Init-Anfrage eingehend zu dem Wurzel-CM weiter, der den IA enthält. Jeder Knoten auf dem Pfad zu dem Wurzel-CM, einschließlich des Vaterknotens, fügt eine Secure Context TLV in die Init Session TLV der Anfragenachricht ein. Der IN-Authentifikator in dem Wurzel-CM bestimmt die Liste von Vorgängern des Supplicant aus der Liste von WTLV_IN_SECURE_CONTEXT_REQ TLVs, wenn er die Pfad-Init-Anfrage empfängt.
  • Der IA wird wechselseitig den CTK ableiten, um die Verbindung zwischen dem anfragenden IN und dem IA zu schützen. Außerdem wird der IA CTKs für jeden der Vorgänger des Supplicant erzeugen. Der IA muß zuerst den CTK ableiten, der die IN-IA-Verbindung schützt, damit er die Transfer Key TLVs erzeugen kann, um die CTKs korrekt zu dem anfragenden IN zuzustellen. Für alle Vorgänger werden die CTKs in entsprechenden (und nun verschlüsselten) Secure Context TLVs eingebettet. Für die Secure Context TLV, die der IN-IA-Verbindung entspricht, ist die Nonce, die von dem IA erzeugt wurde, in der TLV enthalten, und eine neue MIC wird unter Verwendung des neu erstellten CTKIN-IA berechnet. Diese WTLV_MIC innerhalb der Secure Context TLV dient als der Lebendigkeitsauthentifikator für den anfragenden IN.
  • Um die Aktionen besser beschreiben zu können, die benötigt werden, um einen IN gegenüber der SWAN-Topologie zu authentifizieren, wird eine vereinfachte Terminologie definiert. Zuerst einmal wird der Satz von CTKs explizit in 30 definiert.
  • Die AP-Pfadauthentifizierung ist folgendermaßen:
    • – Ein NSK wird von dem AP und dem CCM gemeinsam genutzt
    • – Es wird vorausgesetzt, dass sich ihre Vorgänger erfolgreich registriert haben. In dem in 30 gezeigten Beispiel sind der CTK1, der CTK2 und der CTK3 neu und gültig. Dies ist eine Voraussetzung, da der CTK1 für die Zustellung und für die Authentifizierung der Zustellung des CTK5 zu dem LCM verwendet wird. Dahingegen wird der CTK2 dazu verwendet, den CTK6 zu dem SCM zu liefern, wird aber über den LCM gesendet. Der LCM wiederum schützt die WTLV_IN_SECURE_CONTEXT_REPLY unter Verwendung des CTK3.
  • Die WTLV_TRANSIENT_KEYs, die verwendet werden, werden in Kurzschrift folgendermaßen beschrieben:
    TKE1 = WTLV_TRANSIENT_KEY(CTK4, KSCAP-LCM ∥ LCM-ID ∥ AP-ID ∥ CTK5 ∥ MICCTK4)
    TKE2 = WTLV_TRANSIENT_KEY(CTK4, KSCAP-SCM ∥ SCM-ID ∥ AP-ID ∥ CTK6 ∥ MICCTK4)
  • Diese TKEs werden in die verschlüsselten Secure Context TLVs eingebettet, deren Kurzform folgendermaßen lautet:
    WSC0 = WTLV_IN_SECURE_CONTEXT_REQ(<no encryption/MIC>, IA-ID ∥ AP-ID ∥ NonceAP)
    WSC1 = WTLV_IN_SECURE_CONTEXT_REQ(CTK2, SCM-ID ∥ AP-ID ∥ NonceSCM ∥ MICCTK2)
    WSC2 = WTLV_IN_SECURE_CONTEXT_REQ(CTK1, LCM-ID ∥ AP-ID ∥ NonceLCM ∥ MICCTK1)
    WSC3 = WTLV_IN_SECURE_CONTEXT_REPLY(CTK1, LCM-ID ∥ AP-ID ∥ NonceLCM ∥ CTK5 ∥ TKE1 ∥ MICCTK1)
    WSC4 = WTLV_IN_SECURE_CONTEXT_REPLY(CTK2, SCM-ID ∥ AP-ID ∥ NonceSCM ∥ CTK6 ∥ TKE2 ∥ MICCTK2)
    WSC5 = WTLV_IN_SECURE_CONTEXT_REPLY(<no encryption>, AP-ID ∥ IA-ID ∥ NonceIA ∥ MICCTK4)

    WAUTH1 = WTLV_AUTHENTICATOR(CTK6, KSCAP-SCM ∥ SCM-ID ∥ AP-ID ∥ NonceAP-SCM ∥ MICCTK6)
    WAUTH2 = WTLV_AUTHENTICATOR(CTK5, KSCAP-LCM ∥ LCM-ID ∥ AP-ID ∥ NonceAP-LCM ∥ MICCTK5)
    WAUTH3 = WTLV_AUTHENTICATOR(CTK4, KSCAP-CCM ∥ CCM-ID ∥ AP-ID ∥ NonceAP-CCM ∥ MICCTK4)
    WAUTH4 = WTLV_AUTHENTICATOR(CTK6, KSCAP-SCM ∥ SCM-ID ∥ AP-ID ∥ NonceAP-SCM + 1 ∥ MICCTK6)
    WAUTH5 = WTLV_AUTHENTICATOR(CTK5, KSCAP-LCM ∥ LCM-ID ∥ AP-ID ∥ NonceAP-LCM + 1 ∥ MICCTK5)
    WAUTH6 = WTLV_AUTHENTICATOR(CTK4, KSCAP-CCM ∥ CCM-ID ∥ AP-ID ∥ NonceAP-CCM + 1 ∥ MICCTK4)
  • Wenn man die obige Terminologie verwendet, dann dienen die WTLV_INIT_SESSION (WIS) TLV-Austausche während der Pfadauthentifizierung als das Mittel zur Authentifizierung und Erstellung der Pfad-CTKs zwischen einem anfragenden Infrastrukturknoten und seinen Vorgängern. Ein Beispiel einer AP-Authentifizierung und -Registrierung bei der Infrastruktur ist in 31 dargestellt.
  • Eine alternative Sequenz dafür, wann die Pfade aktualisiert werden müssen, aber keine Registrierung benötigt wird, ist in 32 gezeigt.
  • Jeder CTK, der zu dem Supplicant geliefert wird, ist in einer WTLV_TRANSIENT_KEY TLV codiert. Der CTK wird direkt zu dem Vorgänger des Supplicant in der WTLV_SECURE_CONTEXT_REPLY TLV geliefert. Die Liste von TLVs wird dann in die Pfad-Init-Antwortnachricht eingegeben, die zu dem Vaterknoten des Supplicant gesendet wird. Der Vaterknoten gibt die Antwort zu dem Supplicant weiter. Jeder Knoten auf dem abgehenden Pfad der Pfad-Init-Antwort entschlüsselt den CTK, den er mit dem Supplicant teilt, wenn er seine jeweilige WTLV_SECURE_CONTEXT_REPLY TLV empfängt. Wie in 32 gezeigt ist, muß der Supplicant dann, wenn er die Pfad-Init-Antwortnachricht empfängt, eine "anfängliche" Registrierungsanfragenachricht zu dem Wurzel-CM über seinen Vaterknoten senden, wie dies oben beschrieben ist. Der Supplicant muß eine WTLV_AUTHENTICATOR TLV in die Anfragenachricht für jeden seiner Vorgängerknoten eingeben. Jeder Vorgängerknoten "authentifiziert" den Supplicant, wenn er seine WTLV_AUTHENTICATOR TLV empfängt; deshalb ist der Supplicant vollständig authentifiziert, bevor eine Registrierungsantwort erzeugt wird. Jeder Vorgängerknoten muß die WTLV_AUTHENTICATOR TLV aktualisieren und erneut verschlüsseln, bevor er die Registrierungsanfrage weiterleitet. Der Supplicant authentifiziert wechselseitig jeden seiner Vorgängerknoten, wenn er die aktualisierte Liste von WTLV_AUTHENTICATOR TLVs in der Registrierungsantwort empfängt.
  • CTKS können in ähnlicher Weise auch so aufgefrischt werden, wie dies in 33 gezeigt ist, wobei der einzige Unterschied darin liegt, dass dort keine Registrierung benötigt wird und somit, anstatt einen Registrierungsnachrichtentyp zu verwenden, die Pfad-Init-Nachricht so erweitert wird, dass die Untertypen Confirm und ACK verwendet werden.
  • Die CTKS müssen auf der Grundlage der Entropie aufgefrischt werden, die von den Cipher Suites definiert ist, die verwendet werden, um den Datenschutz und die Authentizität bereitzustellen. [Anfängliche Freigaben werden RC4 und HMAC-MD5 jeweils für die Verschlüsselung und die Authentifizierung aller Nachrichten oder TLVs verwenden. Aber zukünftige Freigaben können AES unterstützen.] CTKS müssen aufgefrischt werden, wenn der Nachrichtensequenzzähler abgelaufen ist, oder mit einer Häufigkeit von nicht mehr als ein paar Mal pro Tag ist (ein 6-Stunden-Intervall wird vernünftig sein). Aber wenn ein Knoten häufige MIC- oder Entschlüsselungsfehlschläge erfährt, sollte er diese Nachrichten schweigend verwerfen. Optional (z. B. bei zukünftigen Freigaben) kann der IN mit einer richtigen Heuristik entscheiden, ob eine CTK- Auffrischung oder eine vollständige (erneute) Authentifizierung ausgelöst werden soll.
  • CTK-Auffrischungen können optional für einen gesamten Zweig aufgefrischt werden, wobei WTLV_INIT_SESSION verwendet wird, oder ein einziger CTK kann unter Verwendung eines sicheren Kontextanfrage-/-antwort-Austausches aufgefrischt werden. Während der CTK, der zwischen dem Infrastrukturknoten und dem IA verwendet wird, auch in WTLV_INIT_SESSION oder WTLV_SECURE_CONTEXT_REQ und WTLV_SECURE_CONTEXT_REPLY erstellt und aufgefrischt wird, kann sein Schlüssel nicht direkt von dem IA geliefert werden, sondern statt dessen wird das Schlüsselmaterial (z. B. Noncen) ausgetauscht, um gegenseitig einen CTK abzuleiten. Auf diese Weise ändert sich die Semantik von WTLV_SECURE_CONTEXT_{REQ/REPLY} in Abhängigkeit davon, ob der CTK geliefert oder abgeleitet wird.
  • Um einen einzigen CTK schlüsselmäßig zu erneuern oder zu erstellen, muß der Supplicant-IN von dem IA einen neuen Schlüssel anfordern. Ein 2-Phasen-Austausch ist erforderlich. In der ersten Phase wird eine WTLV_SECURE_CONTEXT TLV verwenden, um den CTK zu erstellen. In der zweiten Phase wird eine WTLV_AUTHENTICATOR TLV verwendet, um die Lebendigkeit des CTK zu bestätigen. Die erste Phase wird während eines Pfad-Init-Anfrage/-Antwort-Austausches durchgeführt, während die zweite Phase während der anfänglichen Registrierung durch die Verwendung von WTLV_AUTHENTICATORen vollendet wird. Die zweite Phase wird benötigt, um die CTK-Lebendigkeit zwischen den Verbindungsknoten zu gewährleisten.
  • In 33 ist ein Beispiel dafür gezeigt, wie ein CTK, der verwendet wird, um die Verbindung zwischen dem AP und dem SCM zu schützen, den CCM für die Schlüssellieferung und die direkte Pfadauthentifizierung von dem AP zu dem SCM verwendet, um die Lebendigkeit des CTK zu bestätigen.
  • – Sicherheitskontexttransfer des mobilen Knotens.
  • Dynamische Sicherheitsberechtigungsnachweise für einen MN werden in dem anfänglichen MN-Authentifizierungsprozess erstellt, wie dies oben beschrieben ist. Diese Berechtigungsnachweise umfassen: NSK, Sitzungs- Timeout, VLAN ID, SSID, KRK, BTK und RN. Die Konfigurationsinformationen und die dynamischen Berechtigungsnachweise eines MN, die in einen Cachespeicher aufgenommen sind, werden automatisch zu dem neuen Vater-AP transferiert, wenn ein MN roamt. Die in einen Cachespeicher aufgenommenen Konfigurationsinformationen und dynamischen Berechtigungsnachweise werden auch zu jedem neuen SCM auf dem neuen Pfad weitergeleitet, so dass ein zukünftiges Roaming lokalisiert wird (d. h., so dass auf den LCM nicht zugegriffen wird, wenn der MN innerhalb des Teilnetzes roamt). Die dynamischen Berechtigungsnachweise werden zu dem SCM während SCM-Registrierungsaktualisierungen weitergeleitet.
  • MN SSID Autorisierung
  • Ein MN muß autorisiert sein, um seine SSID zu verwenden. Der 802.1X Authentifizierungsserver sendet eine Liste von zulässigen SSIDs für einen MN zurück, wenn sich der MN authentifiziert. Die Liste von SSIDs (und alle anderen statischen Konfigurationsinformationen) werden in jedem CM auf dem Pfad zu dem MN in einen Cachespeicher aufgenommen. Eine SSID eines MN ist in seinen Vorabregistrierungs- und Registrierungsanfragen enthalten. Der am nächsten gelegene gemeinsame Vorgänger-CM verifiziert jedes Mal dann, wenn er eine Vorabregistrierungs- oder Registrierungsanfrage für den MN empfängt, dass ein MN autorisiert ist, seine SSID zu benutzen.
  • Schnelles Roaming und erneute Schlüsselbildung (Rekeying)
  • Auf eine erneute Verbindungsanfrage hin bewirkt der roamende Knoten eine authentifizierte Schlüssel-Auffrischungsanfrage zu dem neuen AP. Der neue AP fordert danach Sicherheitsberechtigungsnachweise zu dem MN-Authentifikator über eine Vorabregistrierungsanfrage an. Der MN-Authentifikator muß die Sicherheitsberechtigungsnachweise validieren, die von dem MN bereitgestellt werden (weitergeleitet von dem neuen AP zu dem MN-Authentifikator). Nach einer erfolgreichen Vorabregistrierungsantwort wird der MN-Authentifikator die Sicherheitsberechtigungsnachweise zu dem neuen AP weiterleiten. Bei einer fehlgeschlagenen Vorabregistrierungsantwort wird der MN-Authentifikator nur einen Statuscode bereitstellen, um den Punkt des Fehlschlags anzuzeigen und um es dem AP zu erlauben, zu entscheiden, ob er es dem MN erlauben soll, Berechtigungsnachweise erneut zu erstellen, indem er eine vollständige Authentifizierung auferlegt, oder ob er den MN vollständig abmelden soll.
  • – MN Sicherheitskontext-Weiterleitung
  • In einer vollständigen Topologie agiert der LCM als der MN-Authentifikator. Die Lage des MN-Authentifikators in einer vollständigen Topologie kann längere Latenzzeiten mit sich bringen, und somit ist es wünschenswert, die Sicherheitsberechtigungsnachweise des MN hinunter zu dem SCM weiterzuleiten. Das Weiterleiten der Berechtigungsnachweise wird während der Registrierungsanfrage/-antwort erzielt. Dies erlaubt es den Infrastrukturvorgängern des MN, hauptsächlich dem SCM, die Sicherheitsberechtigungsnachweise des MN in den Cachespeicher aufzunehmen und das Roaming zu ermöglichen.
  • Die Berechtigungsnachweise werden auf Anforderung hin weitergeleitet. Das heißt, während einer MN-Registrierungsanfrage kann jeder Vorgänger (mit Ausnahme des AP) eine WTLV_SECURE_CONTEXT_REQ einfügen, die anfordert, dass die MN-Berechtigungsnachweise weitergeleitet werden, eine MIC muß in der Secure Context TLV für einen MN-Authentifikator zur Validierung enthalten sein. Auf eine erfolgreichen Anfrage hin wird der MN-Authentifikator dann eine WTLV_MN_SEC_CONTEXT_REPLY TLV einbetten, die alle der in einen Cachespeicher aufgenommenen Berechtigungsnachweise enthält, die in der TLV verschlüsselt sind. Ähnlich wie die Anfrage muß die Secure Context TLV auch in einer Antwort einer MIC unterzogen werden. Eine vollständige Darstellung einer MN-Authentifizierung und -Registrierung unter der SWAN-Topologie ist in 34 gezeigt.
  • Die WLCCP_AAA-Nachricht ist der einzige explizite Nachrichtentyp, der für die Knotenauthentifizierung definiert ist. EAPOL-Nachrichten werden mit Hilfe einer MIC in der WLCCP-Nachrichteneinkapselung vor Man-in-the-Middle-Angriffen (Mittelmann-Angriffen) geschützt, während sie zu dem Authentifikator des Knotens geroutet werden.
  • TLVs können geschützt werden, indem ein modifizierter RC4-Algorithmus verwendet wird, um den Datenschutz bereitzustellen, und HMAC-MD5 verwendet wird, um die Nachrichtenauthentizität bereitzustellen. Für den Datenschutz werden TLVs unter Verwendung des Standard-RC4-Algorithmus verschlüsselt, aber die ersten 256 Bytes des RC4-Stroms werden gelöscht, um den FMS-Angriff zu vereiteln. Für die Authentizität ist eine MIC TLV in dem WLCCP enthalten. Der CTK ist somit ein 256-Bit-Wert, der aus zwei Schlüsseln besteht, wobei die 128 Bits höherer Ordnung als der HMAC-MD5-Schlüssel verwendet werden, während die 128 Bits niedrigerer Ordnung als der RC4-Schlüssel verwendet werden.
  • Eine Message Integrity Check (MIC) TLV wird verwendet, um WLCCP-Nachrichten zu authentifizieren. Ein Quellknoten kann optional das MIC Flag auf EIN setzen und eine WTLV_MIC TLV in eine WLCCP-Nachricht eingeben, um die Nachricht gegenüber dem Ziel zu "authentifizieren". Die TLV enthält eine MIC, die mit den 128 Bits höherer Ordnung des Kontexttransferschlüssels (CTK) berechnet wird, der von der Quelle und dem Ziel gemeinsam benutzt wird. Wenn eine Anfragenachricht authentifiziert ist, dann muß die entsprechende Antwortnachricht ebenfalls authentifiziert werden. Sowohl der Quellknoten als auch der Zielknoten verwalten einen Nachrichtensequenzzähler MSC, der auf 0 initialisiert wird, wenn ein CTK initialisiert oder aufgefrischt wird. Der MSC dient als ein Wiedergabezähler sowie auch als der RC4-Initialisierungsvektor. Wenn der aktuelle MSC kleiner als der oder gleich dem vorhergehenden MSC-Wert ist, dann ist die Nachricht eine Wiedergabe (Replay) und muß gelöscht werden. Der MSC-Wert wird mit den 128 Bits niedrigerer Ordnung des CTK verkettet, um den RC4-Schlüssel zu erzeugen. In einer Reihenfolge, die mit dem dünnen Ende anfängt:
    RC4-Schlüssel = MSC ∥ CTK[0:127], wobei ∥ die Verkettungsfunktion ist.
  • Um MSC-Kollisionen und die Definition von direktionalen CTKS zu vermeiden, sollen die MSC-Werte auf eingehenden Pfaden geradzahlig und auf abgehenden Pfaden ungeradzahlig sein. Der MSC sollte auch jedes Mal dann inkrementiert werden, wenn eine TLV oder eine Nachricht verschlüsselt oder authentifiziert wird.
  • Nachrichten, die auf Zweigen des SWAN-Topologiebaums weitergeleitet werden, werden mit CTKs authentifiziert, die während des Vorabregistrierungs-/Registrierungsprozesses erstellt werden. Nachrichten, die "lateral" weitergeleitet werden, werden mit dynamisch erstellten lateralen CTKs authentifiziert. Die laterale Nachrichtenauthentifizierung wird in dem nächsten Abschnitt erörtert.
  • Wenn das Relay Flag in einer Nachricht auf AUS gesetzt ist, dann wird die MIC unter Verwendung des CTK berechnet, der von dem Absender und dem Antwortenden gemeinsam genutzt wird. Ein Zwischen-AP kann eine Nachricht "weiterreichen", die mit "Hopwise Routing" weitergeleitet wird. Wenn das Relay Flag in einer Nachricht auf EIN gesetzt ist, dann wird die MIC unter Verwendung des CTK berechnet, der von dem direkten Sender und dem direkten Empfänger gemeinsam genutzt wird. Die Regeln für das Bestimmen des gemeinsamen CTK für eine Hop-weise geroutete Nachricht sind wie folgt:
    Der direkte Sender-AP einer eingehenden Nachricht verwendet den CTK, den er mit seinem Vaterknoten gemeinsam nutzt.
    Der direkte Sender (AP oder SCM) einer abgehenden Nachricht verwendet den CTK, den er sich mit dem Next-Hop-Sohnknoten teilt.
    Der direkte Empfänger verwendet den CTK, den er mit dem direkten Sender gemeinsam verwendet. Wenn das Relay Flag auf AUS gesetzt ist, dann ist der direkte Sender der Absender in einer Anfragenachricht und der Antwortende in einer Antwortnachricht. Wenn das Relay Flag auf EIN gesetzt ist, dann ist der direkte Sender der "Relay-Knoten", der von dem benötigten Relay-Knoten-ID Feld identifiziert wird.
  • Ein CTK wird auch dazu verwendet, irgendwelche TLVs zu verschlüsseln, die sensible Daten enthalten (z. B. einen Sitzungsschlüssel für einen Nachfolgerknoten). Die Regeln für die Bestimmung des CTK, der verwendet wird, um sensible TLVs zu verschlüsseln, sind die gleichen wie die Regel zur Bestimmung des CTK, der für die Nachrichtenauthentifizierung verwendet wird. Es sei angemerkt, dass jeder Relay-AP TLVs in Nachrichten entschlüsseln und erneut verschlüsseln muß, die mit dem Hopwise-Routing weitergeleitet werden.
  • TLVs sind so definiert, dass sie die Knotenauthentifizierung, das Kontextmanagement und das CTK- und PTK-Management zulassen (d. h., die Pfadauthentifizierung und die Vorabregistrierung).
  • Es gibt fünf grundlegende Operationen zur Erstellung von Sicherheitsberechtigungsnachweisen, zu deren Aufnahme in einen Cachespeicher und zu deren Verwaltung; diese sind als TLV-Gruppen-IDs in der folgenden Tabelle definiert:
    TLV Typ-ID Wert Beschreibung
    WTLV_INIT_SESSION 0x0101 Ein IN-Knoten muß seinen CTK mit der SWAN-Infrastruktur initialisieren. Ein MN-Knoten muß seinen BTK mit der SWAN-Infrastruktur initialisieren.
    WTLV_IN_SECURE_CONTEXT_REQ 0x0102 IN-Knoten-CTK-Auffrischung
    WTLV_UPDATE_RN 0x0103 Aktualisierung des PTK-Sequencing eines MN
    WTLV_TRANSIENT_KEY 0x0104 Einen CTK liefern
    WTLV_AUTHENTICATOR 0x0106 Die Verbindungsauthentifizierung muß bei der Registrierung erzielt werden
    WTLV_NSK 0x0107 Der MN-Authentifikator muß den NSK aus dem verbundenen AP abrufen, da der Schlüssel statisch konfiguriert ist
    WTLV_MIC 0x0108 Generischer MIC, der in Nachrichten oder TLVs eingebettet werden kann
    WTLV_MN_SEC_CONTEXT 0x0109 Die TLV, die verwendet wird, um benötigte MN-Sicherheitsberechtigungsnachweise weiterzuleiten
    WTLV_IN_SECURE_CONTEXT_REPLY 0x010a Die TLV, die verwendet wird, um IN CTKs zu liefern
    WTLV_MN_SECURE_CONTEXT_REQ 0x010b Anfrage des IN nach den Berechtigungsnachweisen des MN
    WTLV_MN_SECURE_CONTEXT_REPLY 0x010c Antwort des IA bezüglich der Anfrage nach MN-Cache
    WTLV_EAP_ID 0x010d EAP-Identität
    WTLV_CCKM_ASSOCIATE 0x010e Inhalte der 802.11-Verbindung, benötigt für die CCKM-Validierung
    WTLV_CCKM_REASSOCIATE 0x010f Inhalte des 802.1-CCKM-Elements für die erneute Verbindung
  • Der vierte Typ, WTLV_TRANSIENT_KEY, ist eine eingebettete TLV, die verwendet wird, um Verbindungsschlüssel innerhalb einer WTLV_INIT_SESSION oder WTLV_SECURE_CONTEXT_REPLY zu liefern.
  • Die Identitätszeichenfolge, die in einer EAP-Identitätsanfrage/-antwort für MNs bereitgestellt ist, wird an dem SCM in einen Cachespeicher aufgenommen und in den Secure Context TLVs verwendet, um eine korrekte Abrechnung an dem AP zu ermöglichen. Da die EAP-Identität von einer willkürlichen Länge sein kann, ist eine TLV wie folgt definiert:
    TLV-Typ-ID Länge Identität (Bytes) Länge EAP-Identität
    WTLV_EAP_ID TLV-Länge 8 Bytes N Bytes
  • – WTLV_MIC
  • Eine andere TLV, die verwendet wird, um WLCCP-Nachrichten oder TLVs zu sichern, ist die WTLV_MIC. Sie ist definiert als
    TLV-Typ-ID Länge Nachrichtensequenzzähler MIC-Länge (in Bytes) Wert = 8 MIC
    WTLV_MIC TLV-Länge 8 Bytes 2 Bytes 8 Bytes
  • Die WTLV_MIC erlaubt eine Erweiterung der MIC für eine zukünftige Verwendung. Zu anfangs ist die MIC-Länge auf 8 Bytes voreingestellt, um zu definieren, dass die MIC eine Länge von 8 Bytes aufweisen soll. Der Nachrichtensequenzzähler wird verwendet, um die Anzahl an WTLV_MICs zu definieren, die unter Verwendung des entsprechenden CTK erzeugt werden. Diese TLV wird an jede WLCCP-Nachricht angehängt, deren Flags-Wert das MIC Flag (0x0100) umfasst. Nachrichten, die eine WTLV_MIC benötigen, müssen die Felder definieren, die von der HMAC-MD5-Funktion abgedeckt werden.
  • Einige WLCCP-Nachrichten und TLVs, die eine WTLV_MIC TLV benötigen:
    • WTLV_MIC wird verwendet, um WLCCP_AAA-Nachrichten nur für MN-Authentifizierungen zu authentifizieren.
    • WTLV_TRANSIENT_KEYs müssen eine MIC enthalten, um die Lieferung eines CTK zu authentifizieren oder wenn sie Schlüssel des MN weiterleiten.
    • WTLV_MN_SECURE_CONTEXT_REQ, WTLV_IN_SECURE_CONTEXT_REQ, WTLV_IN_SECURE_CONTEXT_REPLY und WTLV_MN_SECURE_CONTEXT_REPLY müssen authentifiziert werden, wenn sie von Hop zu Hop erweitert und weitergereicht werden.
    • WTLV_INIT_SESSION muß authentifiziert werden, wenn sie von dem Supplicant-Knoten zu seinem Authentifikator erweitert und weitergereicht werden.
    • WTLV_AUTHENTICATOR muß eine MIC enthalten, um die Sitzungslebendigkeit zwischen einem Supplicant-Knoten und einem Vorgänger zu garantieren.
  • – WTLV_INIT_SESSION: Pfadauthentifizierung und Vorabregistrierung
  • Die Pfadauthentifizierung und die Vorabregistrierung werden benötigt, um jeweils CTKs und BTKs zu erstellen. Für IN-Knoten müssen CTKs zwischen dem Knoten und seinen Vorgängern bis hoch zu dem Wurzel-CM erstellt wer den. Die WTLV_INIT_SESSION TLV löst den Zustand für die Erstellung frischer CTKs aus. Auf eine erfolgreiche WTLV_INIT_SESSION hin werden die Sequenzzähler auf Null initialisiert, und CTKs werden für alle Verbindungen zwischen den anfragenden IN-Knoten und dem IN-Authentifikator erstellt.
  • Für MN-Knoten werden für den Verbrauch nur PTKs für einen MN und seinen augenblicklich assoziierten AP benötigt. Der Schlüssel, der zwischen dem MN und dem IA erstellt wird, muß zu dem AP weitergeleitet werden, bevor PTKs gegenseitig abgeleitet und zwischen dem MN und dem AP konsumiert werden können. Aber ein BTK muß zuerst für einen CCKM MN erstellt werden. Die WTLV_INIT_SESSION löst den Zustand für die Erstellung neuer CTKs und BTKs aus. Nach einer erfolgreichen 802.1X-Authentifizierung, gefolgt von einer WTLV_INIT_SESSION, werden die Sequenzzähler auf Null initialisiert und CTKs werden für alle Verbindungen zwischen den anfragenden IN-Knoten und dem IN-Authentifikator erstellt. Schlüsselsequenzzähler werden nur nach einer erfolgreichen Authentifizierung auf Null gesetzt, sie werden jedes Mal dann inkrementiert, wenn ein Schlüssel aufgefrischt wird.
  • Für einen CCKM MN werden ein BTK und ein erster PTK für die Sicherung von Datenpaketen zwischen dem AP und dem MN erstellt; dies impliziert natürlich, dass der AP für den selbständigen SCM-Modus zwischen sich selbst und dem SCM einen CTK gesichert haben muß. Das heißt, die APs müssen sich zuerst in der SWAN-Topologie authentifizieren und registrieren, bevor sie MNs vorab registrieren oder registrieren können.
  • Die WTLV_INIT_SESSION TLV ist folgendermaßen definiert:
    Feldname Länge Beschreibung
    WTLV_INIT_SESSION 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Reserviert 1 Reserviert für die Byte-Ausrichtung
    Pfadlänge 1 Anzahl an Vorgängern zwischen dem Supplicant und dem IN-Authentifikator
    Optionale TLV(s) N Unterschiedliche TLVs müssen eingeschlossen werden, in Abhängigkeit von dem spezifizierten Zustand und der spezifizierten Richtung
  • Da TLVs längenmäßig variieren können, geht jeder TLV ein Offset (Versatz) voraus, um die nächste TLV-Länge oder den Offset zu der nächsten TLV anzuzeigen. Ein Offset von 0 (Null) zeigt das Ende an, z. B. keine weiteren TLVs.
  • – WTLV_INIT_SESSION für MNs
  • Wenn sich MNs erfolgreich in das Netz authentifizieren, wird der MN-Authentifikator deren NSK und andere relevante Sicherheitsberechtigungsnachweise in einen Cachespeicher aufnehmen. Wenn CCKM der ausgehandelte authentifizierte Schlüsselmanagement-Selektor ist, dann muß der MN-Authentifikator mit einem EAPOL-Schlüssel zu dem MN antworten und die Erstellung des KRK und des BTK auslösen.
  • Die Antwort von dem MN stellt eine NonceMN und die ausgehandelten Sicherheitselemente bereit, für die der AP eine Validierung durchführen kann. Aber der MN-Authentifikator muß ebenfalls einige dieser Berechtigungsnachweise validieren, um zu gewährleisten, dass kein VLAN-Hopping stattfindet.
  • Für eine eingehende MN-Vorabregistrierungsanfrage umfasst die WTLV_INIT_SESSION eine Secure Context TLV, die die Identität des AP als die Ziel-ID und das ausgehandelte 802.11.Sicherheitsinformationselement (RSNIE) enthält. Die SSID ist ebenfalls in der Sicherheitskontextanfrage von dem MN enthalten und wird von dem MN-Authentifikator geprüft, um zu gewährleisten, dass der MN nicht ein VLAN-Hopping ausführt und somit die Sicherheit verletzt. Die Nonce des Sicherheitskontextes muß von dem MN bereitgestellt werden, da sie als das Schlüsselbildungsmaterial dient, das verwendet wird, um den KRK und den BTK abzuleiten.
  • Die WTLV_INIT_SESSION, die von dem AP (im Namen des MN) erzeugt wird, ist folgendermaßen definiert:
    Feldname Länge Beschreibung
    WTLV_INIT_SESSION 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Reserviert 1 0
    Pfadlänge 1 Anzahl an Vorgängern zwischen dem Supplicant und dem IN-Authentifikator
    SECURE_CONTEXT TLV N MN_SECURE_CONTEXT ist eingebettet mit SID = MD-ID und DID = AP-ID, einschl. RSNIE
  • Wenn der MN CCKM ausgehandelt hat, dann muß er auch eine Nonce bereitgestellt haben, die in der WTLV_MN_SECURE_CONTEXT_REQ eingebettet ist. Der AP sollte einen Fehler auslösen, wenn der MN keine Nonce bereitstellt.
  • Wenn der MN SSN oder Legacy-Systeme ausgehandelt hat, dann muß sich der AP nur den NSK besorgen. Aber wenn der MN CCKM ausgehandelt hat, dann muß der MN-Authentifikator den BTK ableiten und zu dem AP liefern und den KRK in einen Cachespeicher aufnehmen. Somit muß der MN-Authentifikator auf eine Antwort hin den Schlüssel (NSK oder BTK) zu dem AP liefern, der in der MN_SECURE_CONTEXT_TLV eingebettet ist. Da es ein MN ist, der einen solchen Schlüssel anfordert, wird der MN-Authentifikator den WTLV_TRANSIENT_KEY weglassen, der normalerweise verwendet wird, um den NSK oder den BTK zu dem MN zu liefern. Dieser Schritt ist überflüssig und unnötig, da der MN bereits gegenseitig seinen Schlüssel abgeleitet hat und da er auch nicht wissen muß, was sich hinter dem AP befindet.
  • 1.1.1.1.1.1 WTLV_INIT_SESSION für INs
  • Die Pfadauthentifizierung und die Initialisierung von CTKs für IN-Knoten setzt voraus, dass sich die Vorgänger des IN erfolgreich in die SWAN-Infrastruktur hinein registriert haben. Die Pfadauthentifizierung wird mit einer Pfad-Init-Anfrage initiiert, die eine WTLV_INIT_SESSION TLV der folgenden Form enthält:
    Feldname Länge Beschreibung
    WTLV_INIT_SESSION 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Reserviert 1 0
    Pfadlänge 1 0
    Sichere Kontextanfrage für IN-IA TLV N WTLV_IN_SECURE_CONTEXT_REQ SID = ID, DID = IA
  • Da die WLCCP-Pfad-Init-Anfrage zu dem IA weitergeleitet wird, werden die Vorgänger des Supplicant wiederum einen Schlüssel anfordern, um die Verbindung zwischen ihnen und dem anfragenden IN zu schützen, indem sie ihre WTLV_SECURE_CONTEXT_REQ einbetten:
    Feldname Länge Beschreibung
    WTLV_INIT_SESSION 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Reserviert 1 0
    Pfadlänge 1 0
    Sichere Kontextanfrage für IN-IA TLV N WTLV_IN_SECURE_CONTEXT_REQ SID = ID, DID = IA
    Sichere Kontextanfrage für Vorgänger[i] TLV M WTLV_IN_SECURE_CONTEXT_REQ SID = IN, DID = Vorgänger[i]
    ... Fortsetzung der Liste von Secure Context TVLs
  • Wenn die eingehende WTLV_INIT_SESSION-Anfrage die WTLV_IN_SECURE_CONTEXT_REQs erweitert, wird die abgehende Antwort diese TLVs konsumieren und mit WTLV_IN_SECURE_CONTEXT_REPLYs antworten und diese mit dem CTK und einem WTLV_TRANSIENT_KEY aktualisieren, der von dem Supplicant-Knoten konsumiert werden soll. 33 ist ein Beispiel dafür, wie ein Knoten die CTKs zwischen sich selbst und seinem Vorgängerpfad bis hoch zu dem IA initialisiert.
  • Das Pfadlängen-Feld muß von jedem Vorgänger um Eins inkrementiert werden, wenn die Anfrage zu dem IA weitergeleitet wird. Der IA muß diesen Wert zurückschicken und bestätigen, dass es Pfadlängen- WTLV_SECURE_CONTEXT_REQ TLVs in der WTLV_INIT_SESSION gibt.
  • Wenn zu viele oder zu wenige bereitgestellt sind, dann muß er diese Anfrage verwerfen.
  • Jeder Vorgänger muß sich selber identifizieren und seine entsprechende WTLV_SECURE_CONTEXT_REQ bereitstellen. Der IA wiederum wird jede anfragende Secure Context TLV in eine WTLV_SECURE_CONTEXT_REPLY umwandeln, um die entsprechenden CTKs zu liefern. Da Schlüssel in WTLV_SECURE_CONTEXT_REPLYs geliefert werden, müssen die antwortenden Secure Context TLVs sowohl verschlüsselt werden, als auch einer MIC unterzogen werden.
  • – WTLV_TRANSIENT_KEY: Lieferung von Schlüsseln
  • Ein Schlüssel muß sicher verteilt werden. Um dies zu gewährleisten, wird der Schlüssel unter Verwendung eines gemeinsamen Geheimnisses zwischen der Quelle und dem beabsichtigten Empfänger verschlüsselt. Die TLV wird wie folgt eingekapselt:
    Typ Länge KSC IN-ID In-ID Schlüssel MIC TLV
    WTLV_TRANSIENT_KEY LTV len Schlüsselsequenzzähler Quell-IN ID Ziel-IN-ID ESUP_DST Key – MICSUP_DST
  • Die TLV schließt die Quell-IN-Kennung aus der Gesamt-WLCCP-Nachricht, um zu viel Redundanz zu vermeiden. Die Verschlüsselung verwendet nur RC4, um den Schlüssel zu verschlüsseln:
    ESUP_DST = Verschlüsselter Schlüssel RC4(MSC ∥ CTKAuthenticator_AP, CTKIN-ID_SupplicantID)
  • Der Schlüssel CTKIN-ID_SupplicantID wird mittels des Schlüssels verschlüsselt, der zwischen dem IN-Authentifikator und dem Ziel-IN erstellt worden ist. Der gelieferte Schlüssel CTKIN-ID_SupplicantID wird verwendet, um Daten zwischen dem Ziel-IN und dem Supplicant zu schützen. Für den Supplicant-Knoten wird der NSK verwendet, um seinen CTK zu liefern, da er der Blattknoten ist, der sich registrieren muß.
  • Die Schlüssellieferung zum Schützen von Nachrichten zwischen dem AP und dem MN ist identisch zu derjenigen, die oben definiert worden ist, mit dem Unterschied, dass nur der BTK der gelieferte Schlüssel zusammen mit der erneuten Schlüsselsequenz-Nummer zu dem AP ist.
    EAP = Verschlüsselter Schlüssel RC4(MSC ∥ CTKAuthenticator_AP, BTKMN)
  • Die Authentifizierung der TLV umfasst Felder, die in dem WTLV_TRANSIENT_KEY ausgeschlossen sind, aber in der Gesamt-WLCCP-Nachricht eingebettet sind. Die MIC für eine IN-Knotenantwort wird wie folgt berechnet:
    KEY-MICSUP_DST = HMAC-MD5(CTKAuthenticator_IN-ID, KSC, SNonce, ANoncei, Supplicant-ID, Destination-IN_ID, ESUP_DST)
  • Die antwortende MIC für eine AP-Anfrage bezüglich eines BTK wird wie folgt berechnet:
    KEY-MICAP = HMAC-MD5(CTKAuthenticator_AP, KSC, SNonce, ANoncei, Supplicant-ID, Destination-IN_ID, EAP)
  • Ein Zähler KSC für alle Schlüssel, die zu dem Ziel-IN geliefert werden, muß unterhalten werden und zwischen dem Ziel-IN und dem IN-Authentifikator verwendet werden, um Wiedergaben (Replays) zu verhindern. In ähnlicher Weise muß dann, wenn die Schlüssel zu dem AP für den Schutz von Kommunikationen von dem AP zu dem MN geliefert werden, auch eine Zählung für solche Schlüssel in seinem KSC aufbewahrt werden.
  • – Secure Context TLVs
  • Secure Context TLVs werden verwendet, um Verbindungsschlüssel zwischen dem Supplicant-Knoten und seinem Vorgänger zu erstellen. Da anfordernde Secure Context TLVs keine Schlüssel enthalten, sondern andere sach dienliche Informationen zum Übertragen der Anfragen, werden die Secure Context TLVs in eine anfragende und eine antwortende Secure Context TLV aufgespaltet. Und da die MNs einen Schlüsselverwaltungstyp definieren und der AP als ein Proxy für sie dient, unterscheiden sich außerdem die Secure Context TLVs für das Anfordern von MN-Sicherheitsberechtigungsnachweisen von den IN Secure Contexts.
  • Die anfragende MN Secure Context TLV ist wie folgt definiert:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REQ 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Anzahl an Malen, die dieser Schlüssel aktualisiert worden ist
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, der anfragt, den Schlüssel mit SID zu teilen
    Supplicant-ID (SID) 8 Anfragender (Supplicant-)Knoten
    Reserviert 1 Verwendet für Byte-Ausrichtung
    Schlüsselverwaltungstyp 1 0 – keiner (NSK wird nicht weitergeleitet 1 – CCKM 2 – 802.1X Legacy-Systeme (die eine effektive erneute Authentifizierung durchführen) leiten den NSK weiter. 3 – SSN (dieses Feld wird ignoriert, wenn IN-Pfad-CTKs erstellt werden)
    Nonce 16 Willkürlicher Wert
    EAP ID Q EAP ID TLV
    SSID L SSID TLV
    RSNIE P Die RSNIE TLV für die Authentifizierung weiterreichen
    Optionale (CCKM) TLVs N Wenn CCKM die ausgehandelte Schlüsselverwaltung ist, dann müssen Associate oder Reassociate TLVs bereitgestellt werden
    MIC M WTLV_MIC für diese TLV
  • Optionale TLVs werden auch für den Fall bereitgestellt, wenn CCKM die verhandelte Schlüsselverwaltung ist und somit von dem MN-Authentifikator weitere Arbeiten erforderlich sind, um die EAPOL-Schlüsselnachricht bei der Verbindung oder das erneute Verbindungs-CCKM-Element zu validieren.
  • Die anfragende IN Secure Context TLV ist folgendermaßen definiert:
    Feldname Länge Beschreibung
    WTLV_IN_SECURE_CONTEXT_REQ 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Anzahl an Malen, die dieser Schlüssel aktualisiert worden ist
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, der anfragt, den Schlüssel mit SID zu teilen
    Supplicant-ID (SID) 8 Anfragender (Supplicant-)Knoten
    Nonce 16 Willkürlicher Wert
    MIC M WTLV_MIC für diese TLV
  • Eine antwortende MN Secure Context TLV ist folgendermaßen definiert:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REPLY 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Anzahl an Malen, die dieser Schlüssel aktualisiert worden ist
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, der anfragt, den Schlüssel mit SID zu teilen
    Supplicant-ID (SID) 8 Anfragender (Supplicant-)Knoten
    Nonce 16 Willkürlicher Wert
    Sitzungs-Timeout 4 Restlicher Sitzungs-Timeout für MN
    EAP ID Q EAP ID TLV
    Rx-Schlüssellänge 2 Rx-Schlüssellänge
    Rx-Schlüssel 32 Entspricht einem des CTK, BTK oder NSK
    Optionale Tx-Schlüssellänge 2 Tx-Schlüssellänge
    Optionaler Tx-Schlüssel M Wird nur nach einer erfolgreichen Authentifizierung bereitgestellt, wenn AS einen Tx-Schlüssel als ein Ergebnis einer erfolgreichen Authentifizierung zurücksendet
    Optionale MN-Berechtigungsnachweise, aufgenommen in einen Cachespeicher P Wird nur während der MN-Registrierung bereitgestellt, um in einen Cachespeicher aufgenommene Berechtigungsnachweise von dem IA zu abgehenden Knoten (SCM) weiterzuleiten.
    MIC Q WTLV_MIC für diese TLV
  • Die antwortende MN Secure Context TLV wird schließlich (einen) Schlüssel zu dem Supplicant-Knoten liefern. In Abhängigkeit von dem Supplicant-Knoten-(SID)-Typ sind optionale Felder enthalten. Die nachfolgenden Unterabschnitte geben eine weitere Beschreibung der benötigten Felder auf der Grundlage der Anfragen.
  • Wenn ein MN roamt, wird eine WLCCP-Vorabregistrierung verwendet, um Sicherheitsberechtigungsnachweise anzufordern. Der Vater-AP sendet eine Vorabregistrierungsanfrage-Nachricht zu dem SCM, um Sicherheitsberechtigungsnachweise anzufordern. [Die Anfrage kann je nach Bedarf eingehend weitergeleitet werden, wenn die Sicherheitsberechtigungsnachweise nicht in dem SCM in einem Cachespeicher aufgenommen sind.] Die Vorabregistrierungsanfrage umfasst eine WTLV_SECURE_CONTEXT REQ TLV. Für den Vater- AP muß eine Authentifizierung mit dem SCM durchgeführt werden, und der Vater-AP muß einen CTK aufweisen, der zwischen ihm und dem SCM erstellt ist (d. h., über eine Pfadauthentifizierung).
  • Die WTLV_SECURE_CONTEXT_REPLY, die in einer Vorabregistrierungsantwort enthalten ist, wird verwendet, um Schlüssel zu liefern, und somit muß die TLV wie folgt verschlüsselt werden:
    RC4'(MSC ∥ CTKIN-AI, Schlüsselverwaltungstyp ∥ Nonce ∥ <enthaltene Felder in TLV>)
  • In ähnlicher Weise muß die TLV während einer Antwort folgendermaßen authentifiziert werden:
    MIC = HMAC-MD5(CTKIN-IA, DST-ID ∥ SRC-ID ∥ KSC ∥
    Nonce ∥ <enthaltene Felder in TLV>)
  • Eine antwortende IN Secure Context TLV ist folgendermaßen definiert:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REPLY 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Anzahl an Malen, die dieser Schlüssel aktualisiert worden ist
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, der anfragt, den Schlüssel mit SID zu teilen
    Supplicant-ID (SID) 8 Anfragender (Supplicant-)Knoten
    Nonce 16 Willkürlicher Wert
    Sitzungs-Timeout 4 Restlicher Sitzungs-Timeout für MN
    CTK-Schlüssellänge 2 Rx-Schlüssellänge
    CTK-Schlüssel 32 Entspricht einem des CTK, BTK oder NSK
    Optionale Schlüssel-TLV N WTLV_TRANSIENT_KEY, die den neuen CTK zu der SID liefert. Dieses Feld muß bereitgestellt werden, wenn CTKs zwischen INs erstellt werden. Es fehlt, wenn der SID IN gegenseitig Schlüssel mit seinem IA ableitet.
    MIC Q WTLV_MIC für diese TLV
  • – Weiterreichen von MN-Verbindungsinformationen für CCKM
  • Das WTLV_CCKM_ASSOCIATE-Element wird verwendet, um die zweite EAPOL-Schlüsselnachricht von dem MN zu dem MN-Authentifikator weiterzuleiten, wenn er mit dem KRK, den nur der MN-Authentifikator gespeichert hat, einer MIC unterzogen wird. Die EAPOL-Schlüsselnachricht muß von dem MN-Authentifikator validiert werden. Infolgedessen wird eine TLV so definiert, dass sie die EAPOL-Schlüsselnachricht für die MIC-Validierung wie folgt weiterreicht:
    Feldname Länge Beschreibung
    WTLV_CCKM_ASSOCIATE 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    EAPOL-Nachrichtenlänge 4 Byte-Länge der EAPOL-Nachricht
    EAPOL-Nachricht N EAPOL-Nachricht, wie sie von dem AP empfangen wird und zu dem MN-Authentifikator weitergeleitet wird
    MIC-KRK P MIC TLV, die die EAPOL MIC enthält, die den KRK verwendet
  • – Weiterreichen des erneuten Verbindungs-CCKM-Elements des MN
  • Das WTLV_CCKM_REASSOCIATE-Element wird verwendet, um den Zeitstempel und MIC-Abschnitte des CCKM-Informationselements weiterzuleiten, die von dem MN in der Nachricht bezüglich der erneuten Verbindung bereitgestellt wurden. Wenn die CCKM in Kraft ist, umfasst der MN ein CCKM- Element in der Nachricht bezüglich der erneuten Verbindung von dem folgenden Format:
    Element-ID Länge OUI OUI-Typ Zeitstempel RN MIC_
    1 Byte 1 Byte 3 Bytes 1 Byte 8 Bytes 4 Bytes 8 Bytes
  • Der AP platziert den RN-Wert als das KSC-Feld in der MN Secure Context Request TLV. Außerdem reicht er dieses Element in der CCKM Reassociate TLV wie folgt weiter:
    Feldname Länge Beschreibung
    WTLV_CCKM_REASSOCIATE 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Element ID 1 Muß 0x9c sein
    Element ID Länge 1 Sollte 24 (Bytes) sein
    OUI 3 Muß 00:40:96 sein
    OUI Typ 1 Muß 0 sein
    Zeitstempel 8 TSF-Timer, der von dem AP validiert sein muß, weitergeleitet für die Authentifizierung
    RN 4 Muß identisch zu KSC sein und von dem MN-Authentifikator validiert werden
    MIC P MIC TLV, die HMAC-MD5(KRK, MN-ID ∥ BSSID ∥ RSNIEMN Zeitstempel ∥ RN) enthält
  • – CTK-Anfragen von IN zu IN unter Verwendung von WTLV_SECURE_CONTEXT
  • IN-Knoten können spätere CTKs über eine WTLV_SECURE_CONTEXT-Anfrage anfordern. WTLV_SECURE_CONTEXT fordert einen neuen CTK für die Verbindung an, die zwischen dem Supplicant und dem IN spezifiziert wird. Das Anfragenformat ist wie folgt definiert:
    Feldname Länge Beschreibung
    WTLV_IN_SECURE_CONTEXT_REQ 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Ein Replay-Zähler, der verwendet wird, um den Zustand der Bitten um neue Schlüssel (Rekeys) für die Verbindung zwischen SID und DID zu beobachten
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, mit dem der IN eine neue Schlüsselerstellung wünscht
    Supplicant-ID (SID) 8 Anfragender IN
    Reserviert 1 Verwendet für Byte-Ausrichtung
    Schlüsselverwaltungstyp 1 Für IN ist der Wert immer auf 0 gesetzt.
    Nonce 16 Willkürlicher Wert, bereitgestellt von der DID
    MIC M WTLV_MIC für diese TLV
  • Der IN-Authentifikator wird einen CTK für den Schutz von WLCCP-Nachrichten zwischen dem Supplicant und dem IN-ID liefern. Der Zustellungsmechanismus zu dem Supplicant erfolgt durch die Verwendung des WTLV_TRANSIENT_KEY, wohingegen der Schlüssel in dem verschlüsselten WTLV_SECURE_CONTEXT direkt zu dem Bestimmungsort (Vorgänger des Supplicant) geliefert werden kann.
  • Die WTLV_SECURE_CONTEXT-Antwort muß die Nonce, den Schlüssel und die Schlüssel-TLV verschlüsseln sowie auch eine WTLV_MIC anhängen.
    Feldname Länge Beschreibung
    WTLV_IN_SECURE_CONTEXT_REPLY 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Anzahl an Malen, die dieser Schlüssel aktualisiert worden ist
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, der anfragt, den Schlüssel mit SID zu teilen
    Supplicant-ID (SID) 8 Anfragender IN
    Nonce 16 Willkürlicher Wert, bereitgestellt von DID
    Sitzungs-Timeout 4 Restlicher Sitzungs-Timeout für SID
    CTK-Länge 2 Die CTK-Länge sollte 32 sein
    CTK 32 CTK, gemeinsam benutzt von SID und DID
    Schlüssel-TLV N WTLV_TRANSIENT_KEY, die den neuen CTK zu der SID liefert.
    MIC Q WTLV_MIC für diese TLV
  • – CTK-Anfragen von IN zu IA unter Verwendung von WTLV_SECURE_CONTEXT.
  • Sowohl der IN als auch der IA müssen ihren Verbindungs-CTK gegenseitig ableiten, da:
    • – Schlüssel nicht ohne weiteres in einem klaren Kanal geliefert werden können
    • – der NSK, der bei der Authentifizierung bereitgestellt worden ist, eventuell die Frischeerfordernisse nicht erfüllt
    • – die Schlüssellängenerfordernisse zum Schutz von Nachrichten und TLVs eventuell nicht erfüllt sind
  • Der Supplicant-IN muß in der anfragenden WTLV_SECURE_CONTEXT_REQ eine Nonce enthalten, so dass der IN dann einen CTK ableiten kann und diesen verwenden kann, um die Antwort zu authentifizieren. Die Antwortnachricht wird die Nonce des IA und seine WTLV_SECURE_CONTEXT_REPLY MIC sowie eine Extra-WTLV MIC enthalten, die als der Authentifikator für den Supplicant-IN dient. Die endgültige Au thentifizierung und der endgültige Lebendigkeitsbeweis dieser Schlüsselauffrischung müssen mit einem WTLV_AUTHENTICATOR abgeschlossen werden.
  • Sowohl der IN als auch der IA können den CTK folgendermaßen gegenseitig ableiten:
    CTKIN-IA = PRF-256(NSK, "SWAN IN-IA Verbindungs-Kontexttransferschlüssel-Ableitung" ∥
    IN-ID ∥ IA-ID ∥ KSC ∥ NonceAP ∥ NonceSCM)
  • Die definierte PRF-256-Funktion basiert auf dem HMAC-SHA1 und erlaubt es, dass der NSK auf 256 ausgedehnt werden kann, und garantiert die Frische, indem sie veranlasst, dass jeder Knoten frisches Schlüsselmaterial beisteuert.
  • Die Extra-MIC, die für den IN für die Validierung berechnet wird, ist folgendermaßen definiert:
    MICSTATE2 = HMAC-MD5(CTKIN-IA, DST-ID ∥ SRC-ID ∥
    KSC ∥ NonceIN ∥ NonceAP)
  • Es sei angemerkt, dass, da die Antwort die NonceIN nicht klar sendet, sie den Wert der NonceIN authentifizieren muß. Und da der Schlüssel gegenseitig abgeleitet wird, wird auch kein WTLV_TRANSIENT_KEY geliefert; diese TLV ist durch die authentifizierende MIC ersetzt, wie dies oben definiert ist.
  • – WTLV_SECURE_CONTEXT für anfängliche Verbindungen.
  • Wenn sich ein CCKM-fähiger MN zum ersten Mal verbindet und eine 802.1X-Authentifizierung in das Netz durchführt, initiiert der SCM einen 4-Wege-Handshake mit dem MN, um den KRK und den BTK zu erstellen. Die Nachrichten werden zu dem MN über den AP weitergeleitet, wobei der AP den WLCCP-Header entkapselt und die EAPOL-Schlüssel-Nachrichten zu dem MN weiterleitet. Beim Empfang der 2. Nachricht von dem MN zu dem SCM löst der AP eine Vorabregistrierungsanfrage aus, um die Weiterleitung des BTK anzufordern. Einzelheiten dieses Austausches sind in der Fast Handoff Specification (Spezifikation zur schnellen Weiterleitung) [8] dargestellt.
  • Die Vorabregistrierung verwendet eine WTLV_INIT_SESSION, die eine Secure Context TLV einbettet, die die folgenden MN-Informationen weiterleitet:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REQ 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 sollte auf 1 gesetzt sein
    Ziel-ID (DID; Destination-ID) 8 AP ID
    Supplicant-ID (SID) 8 MN ID
    reserviert 1 Verwendet für Byte-Ausrichtung
    Schlüsselverwaltungstyp 1 0 = keiner (NSK wird nicht weitergeleitet) 1 – CCKM 2 – 802.1X Legacy-Systeme (die eine effektive erneute Authentifizierung durchführen) leiten den NSK weiter. 3 – SSN
    Nonce 16 Nonce, die benötigt wird, um KRK & BTK abzuleiten
    SSID L SSID TLV
    RSNIE P Die RSNIE_LTV für die Authentifizierung weiterreichen
    Optionale TLV M Für CCKM die WTLV_CCKM_ASSOCIATE aufnehmen
    MIC N WTLV_MIC für diese TLV
  • Wenn der Schlüsselverwaltungstyp = 1 (CCKM), dann enthält die Vorabregistrierungsanfrage die obige TLV, um die NonceMN weiterzureichen, die von dem MN beigesteuert wird, sowie auch die MIC TLV weiterzureichen, die verwendet wird, um die Lebendigkeit gegenüber dem SCM zu beweisen, und dass der MN den KRK korrekt abgeleitet hat. Die Vorabregistrierung schließt mit einer Antwort mit der Secure Context TLV wie folgt ab:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REPLY 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Sollte 1 sein (RN-Wert)
    Ziel-ID (DID; Destination-ID) 8 AP-ID
    Supplicant-ID (SID) 8 MN-ID
    Nonce 16 Die 1. Nachrichten-Nonce erneut bestätigen (erneut senden)
    Sitzungs-Timeout 4 Restlicher Sitzungs-Timeout für MN
    Optionale Rx-Schlüssellänge 2 Muß = 32 sein
    Optionaler Rx-Schlüssel 32 BTK
    Optionale Tx-Schlüssellänge 2 Sollte = 0 sein
    Optionaler Tx-Schlüssel 0 Kein Tx-Schlüssel ist anwendbar
    MIC Q WTLV_MIC für diese TLV
  • Wenn der Schlüsselverwaltungstyp = 2 oder 3, dann wird der MN-Authentifikator den Berechtigungsnachweis des MN entfernen, nachdem er eine Vorabregistrierungsantwort sendet. Das heißt, der MN-Authentifikator wird den PMK weder in einem Cachespeicher aufbewahren, noch diesen zu irgendeinem Knoten außer dem direkten AP propagieren. Die Vorabregistrierungsantwort endet, indem der PMK zu dem AP unter Verwendung der folgenden Secure Context TLV weitergeleitet wird:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REPLY 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Wert wird ignoriert
    Ziel-ID (DID; Destination-ID) 8 AP-ID
    Supplicant-ID (SID) 8 MN-ID
    Nonce 16 Wert wird nicht verwendet (ignoriert)
    Sitzungs-Timeout 4 Restlicher Sitzungs-Timeout für MN
    Optionale Rx-Schlüssellänge 2 Reflektiert Wert auf der Grundlage des 802.1X Auth.-Typs
    Optionaler Rx-Schlüssel 32 Schlüssel, der im MS-MPPE Rx-Schlüssel gesendet wird
    Optionale Tx-Schlüssellänge 2 Reflektiert Wert auf der Grundlage des 802.1X Auth.-Typs
    Optionaler Tx-Schlüssel 0 Schlüssel, der im MS-MPPE Tx-Schlüssel gesendet wird
    MIC N WTLV_MIC für diese TLV
  • Es sei angemerkt, dass es eine zweite optionale Tx-Schlüssellänge gibt, und zwar für die Authentifizierungstypen, die sowohl einen Rx- als auch einen Tx-Schlüssel in dem MS-MPPE-Radius-Attribut bereitstellen. Alle Authentifizierungstypen werden einen Rx-Schlüssel bereitstellen, der Tx-Schlüssel ist optional, und seine Länge wird null sein, wenn er nicht von dem Authentifizierungsserver bereitgestellt wird. Es sei angemerkt, dass in jedem der ausgehandelten Schlüsselverwaltungstypen das VLAN zu dem AP als das VLAN-Feld weitergeleitet wird, das in der Vorabregistrierungsnachricht bereitgestellt ist.
  • Die WTLV_SECURE_CONTEXT-Antworten werden aus dem WTLV_SECURE_CONTEXT Nonce-Feld durch das Ende (bis zu der, aber ausschließlich) der WTLV-MIC verschlüsselt, wobei der CTK verwendet wird, der zwischen dem AP und dem MN-Authentifikator erstellt ist. In ähnlicher Weise werden die gleichen Felder unter Verwendung von HMAC-MD5 authentifiziert.
  • – WTLV_SECURE_CONTEXT für erneute MN-Verbindungen
  • Wenn ein MN roamt, muß der neue Vater-AP eine Vorabregistrierung initiieren, um den WTLV_SECURE_CONTEXT des MN anzufordern. Zur Ermöglichung des Kontexttransfers und zur Minimierung der Transaktionen zwischen dem AP und dem MN stellt CCKM einen Basisschlüssel BTK bereit, um den Verbindungsschlüssel PTK zu erzeugen. Das Anfrageformat ist unten wie folgt definiert:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REQ 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 Ein Replay-Zähler, der verwendet wird, um den Zustand der Rekeys für die Verbindung zwischen SID und DID zu beobachten
    Ziel-ID (DID; Destination-ID) 8 AP-ID
    Supplicant-ID (SID) 8 MN-ID
    Reserviert 1 Verwendet für Byte-Ausrichtung
    Schlüsselverwaltungstyp 1 0 – keiner (NSK wird nicht weitergeleitet) 1 – CCKM 2 – 802.1X Legacy-Systeme 3 – SSN
    Nonce 16 Willkürlicher Wert, bereitgestellt von der DID
    SSID L SSID TLV
    RSNIE P RSNIEMN für die Authentifizierung weiterreichen, wenn der Zustand = 0
    Optionale (CCKM) TLV M Für CCKM die WTLV_CCKM_REASSOCIATE aufnehmen
    MIC N SECURE CONTEXT MIC TLV
  • Der neue AP identifiziert den MN, indem er seine MAC-Adresse verwendet. Die BSSID, RN und MICMN müssen von dem MN bereitgestellt werden. Die RN ist als das KSC eingekapselt. Die MIC ist eine HMAC-MD5-Operation über die gesamte WTLV_MN_SECURE_CONTEXT_REQ-Nachricht, beginnend mit dem WTLV_MN_SECURE_CONTEXT_REQ-Typ durch die und einschließlich der MICMN. Die MICMN muß bereitgestellt werden, wenn der Zustand = 0; dies zeigt an, dass der MN CCKM ausgehandelt hat und sich selbst mit dem MN-Authentifikator über die spezifizierte MICMN authentifiziert.
  • Die SSID dient als ein Mittel für den MN-Authentifikator, um Sicherheitsberechtigungsnachweise für den MN zu validieren und um zu gewährleisten, das der MN nicht auf ein verbotenes VLAN umschaltet. Obwohl der MN-Authentifikator die Sicherheitsberechtigungsnachweise effektiv abgleichen kann, liegt es bei dem AP, eine Entscheidung bezüglich der Policy durchzuführen; z. B. muß der AP definieren, in welchen Zustand er im Falle eines Fehlschlags übergehen wird. Der MN-Authentifikator muß auch die Autorisierung des MN validieren, indem er die bereitgestellte MICMN berechnet und abgleicht. Schließlich muß er auch gewährleisten, dass der Sitzungs-Timeout für den MN noch nicht abgelaufen ist. Bei einer erfolgreichen Antwort wird der MN-Authentifikator den BTK sicher zu dem neuen AP liefern und ein Umschalten von dem alten AP auf den neuen AP bewirken. Das heißt, der Registrierungseintrag des MN wird die BSSID des neuen AP reflektieren, und die RN wird um Eins inkrementiert. Die Antwort-TLV ist wie folgt definiert:
    Feldname Länge Beschreibung
    WTLV_MN_SECURE_CONTEXT_REPLY 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Schlüsselsequenzzähler (KSC) 4 RN-Wert
    Ziel-ID (DID; Destination-ID) 8 Vorgänger, mit dem der AP einen Rekey durchführen will
    Supplicant-ID (SID) 8 Anfragender IN
    Nonce 16 Beliebiger Wert, bereitgestellt von dem DID
    Sitzungs-Timeout 4 Restlicher Sitzungs-Timeout für MN
    Optionale Rx-Schlüssellänge 2 Länge des gelieferten Schlüssels (in Byte)
    Optionaler Rx-Schlüssel Q/32 BTK, wenn der Schlüsselverwaltungstyp = 1 (Q = 32) anderenfalls NSK oder MS-MPPE Rx-Schlüssel
    Optionale Tx-Schlüssellänge 2 0, wenn Schlüsselverwaltungstyp = 1 anderenfalls Tx-Schlüssellänge
    Optionaler Tx-Schlüssel Key len MS-MPPE TX Schlüssel anderenfalls
    Optionale MN Credential TLV P Berechtigungsnachweise des MN, in einen Cachespeicher aufgenommen
    MIC N WTLV_MIC für SECURE_CONTEXT
  • Die WTLV_MN_SECURE_CONTEXT_REPLY-Antwort wird aus dem WTLV_MN_SECURE_CONTEXT_REPLY-Nonce-Feld durch das Ende (bis zu der, aber ausschließlich) der WTLV-MIC verschlüsselt, wobei der CTK verwendet wird, der zwischen dem AP und dem MN-Authentifikator erstellt ist. In ähnlicher Weise werden die gleichen Felder unter Verwendung von HMAC-MD5 authentifiziert.
  • Da der MN-Authentifikator den Sitzungs-Timeout des MN dem aktiven AP bereitstellt, liegt es bei dem AP, eine erneute Authentifizierung vor dem Ablauf des Sitzungs-Timeout zu erzwingen.
  • Wenn der MN-Authentifikator bei irgendeiner der Überprüfungen versagt, die für einen sicheren Kontexttransfer benötigt werden, dann wird die Antwort das BTK-Feld komplett mit Nullen bestücken und einen der nachfolgenden Statuswerte umfassen:
    Status Wert Beschreibung
    KEIN KONTEXT 1 MN besitzt keine in einen Cachespeicher aufgenommene Berechtigungsnachweise (kein Registrierungseintrag)
    REPLAY 2 RN ist außerhalb der Sequenz
    SSID 3 Ungültige SSID
    SITZUNG ABGELAUFEN 5 Die Sitzung des MN ist abgelaufen
    SCHLECHTE MIC 6 Die MIC des MN passte nicht zu der berechneten MIC des Authentifikators
  • Die Berechtigungsnachweise des MN werden während einer MN-Registrierung weitergeleitet. Wenn die Berechtigungsnachweise weitergeleitet werden, dann wird kein optionaler Schlüssel weitergeleitet, statt dessen wird eine neue TLV, die die meisten in einen Cachespeicher aufgenommenen Berechtigungsnachweise des MN enthält, zu den Vorgänger-Infrastrukturknoten des MN mit dem SCM als Endpunkt weitergereicht. In dem selbständigen Modus leitet der SCM Berechtigungsnachweise nicht weiter, außer ein prädiktives Roaming wird (statisch) an dem Zeitpunkt konfiguriert, an dem der SCM oder der LCM initialisiert wird. Die Berechtigungsnachweise des MN werden unter Verwendung des WTLV_MN_SEC_CONTEXT weitergeleitet.
  • – WTLV_MN_SEC_CONTEXT.
  • Diese TLV wird nur während einer MN-Registrierungsantwort verwendet, um seine Berechtigungsnachweise von dem MN-Authentifikator zu den Vorgängern des MN mit der Ausnahme des AP weiterzuleiten (außer das prädiktive Roaming ist konfiguriert worden). Wenn der LCM zum Beispiel der MN-Authentifikator ist, dann wird der LCM die Berechtigungsnachweise des MN zu dem SCM weiterleiten.
  • Die TLV ist wie folgt definiert:
    Feld Länge (bytes) Beschreibung
    WTLV_MN_SEC_CONTEXT 2 TLV-Typ
    TLV Länge 2 TLV-Länge
    Zustand 1 Zeigt an, ob dieser Knoten aktiv ist oder nicht
    STA Adr 8 WLCCP-Knotenkennung: MAC-Adresse des MN
    Authentifizierungstyp 1 EAP-Typ, der zur Authentifizierung verwendet wird
    Schlüsselverwaltungstyp 1 Typ der ausgehandelten (oder keiner) Schlüsselverwaltung. Gültige Werte sind: 0 – keiner (NSK wird nicht weitergeleitet) 1 – CCKM 2 – 802.1X Legacy-Systeme 3 – SSN
    Sitzungs-Timeout 4 Sitzungsablaufzeit, die von der Radius Access Accept bereitgestellt wird
    KRK 16 Haupt-Anfrageschlüssel, der verwendet wird, um die Anfrage des MN bezüglich Kontexttransfers zu authentifizieren
    BTK 32 Basis-Übergangsschlüssel, der verwendet wird, um PTKs abzuleiten
    RN 8 Rekey-Nummer, die verwendet wird, um zu verfolgen, wie viele PTKs von dem BTK abgeleitet worden sind
    SSID L Die mit dem MN assoziierte SSID TLV
    VLAN ID 2 Die mit dem MN assoziierte VLAN-Zuweisung
    BSSID 6 Definiert den aktuell assoziierten AP
    Cipher (Verschlüsselung) 2 Ausgehandelte Verschlüsselung, Werte sind: 0x0000 – keine 0x0001 – WEP 0x0002 – TKIP 0x0003 – AES_OCB 0x0004 – AES-CCMP 0x0005 – CKIP 0xff<Wert> – Händlerspezifisch
    NSK-Länge 2 NSK-Länge in Bytes (z. B. Rx-MS-MPPE-Schlüssel)
    NSK N Der Rx-Schlüssel, der sich aus einer erfolgreichen 802.1X-EAP-Authentifizierung ergibt
    Tx-Schlüssellänge 2 Tx-Schlüssellänge (wenn von Radius gesendet)
    Tx-Schlüssel P Der Tx-Schlüssel, der sich aus einer erfolgreichen 802.1X-EAP-Authentifizierung ergibt
  • Diese TLV überträgt hoch sensible Informationen und muß deshalb unter Verwendung des CTK verschlüsselt werden, der von dem MN-Authentifikator und dem Ziel-IN gemeinsam benutzt wird. Außerdem muß die Secure Context TLV, die die MN Secure Credentials TLV einbettet, authentifiziert werden, z. B. muß auch eine TLV MIC verwendet werden. Die MN Secure Credentials TLV wird aus dem Zustandsfeld durch das Cipher-Feld verschlüsselt.
  • – WTLV_UPDATE_RN: Aktualisierungssequentialisierung für PTKs.
  • Diese TLV ist nur zwischen APs und MN-Authentifikatoren gültig, da sie verwendet wird, um die Schlüsselsequentialisierung zwischen dem AP und dem MN zu aktualisieren. Da APs in der Lage sind, PTK-Rekeys zu bewirken, muß der SCM von allen Schlüsselauffrischungen informiert werden, wenn diese stattfinden. Eine Anfrage bezüglich eine Aktualisierung muß von dem AP zu dem MN-Authentifikator wie folgt gesendet werden:
    Typ Länge 8 Bytes 6 Bytes 6 Bytes 4 Bytes 8 Bytes
    WTLV_KEY_UPDATE TLV len MSC BSSID MN MAC Adr RN MICAP
  • Die WTLV_KEY_UPDATE-Nachricht wird unter Verwendung des CTK verschlüsselt und authentifiziert, der zwischen dem AP und dem MN-Authentifikator erstellt worden ist.
  • Der MN-Authentifikator muß diese Anfrage für eine erfolgreiche Aktualisierung und eine erfolgreiche Antwort korrekt entschlüsseln und authentifizieren. Das heißt, wenn die Nachricht weder entschlüsselt bzw. authentifiziert werden kann, noch die RN größer als die aktuelle RN ist, dann verwirft der MN-Authentifikator diese Nachricht, und keine Aktualisierung wird durchgeführt. Aber die Antwort muß einen Status bereitstellen, um anzuzeigen, wie sie fehlgeschlagen ist. Die Antwort wird wie folgt definiert:
    Typ Länge 8 Bytes 6 Bytes 6 Bytes 4 Bytes 8 Bytes
    WTLV_KEY_UPDAT E TLV len MSC BSSID MN MAC Adr RN MICAP
  • Wenn die Aktualisierungsanfrage fehl schlägt, dann wird sie auch einen Statuswert aus der nachfolgenden Tabelle enthalten:
    Status Wert Beschreibung
    SCHLECHTE MIC 1 Berechnete MIC stimmte nicht mit der MIC der TLV überein
    REPLAY 2 Die bereitgestellte RN ist außerhalb der Sequenz und wird als Replay (Wiedergabe) betrachtet
    UNGÜLTIGE BSSID 3 Der spezifizierte MN ist nicht mit der gegebenen BSSID assoziiert
    KEIN MN 4 Der spezifizierte MN ist nicht registriert
  • – WTLV_NSK
  • Der MN-Authentifikator muß nach einer erfolgreichen EAP-Authentifizierung eventuell den NSK des verbundenen AP anfordern. Für Legacy-MN-Knoten, die nur statische WEP-Schlüssel und/oder 802.1X-Authentifizierungstypen unterstützen (wie etwa EAP-MD5), die keine dynamischen Schlüssel bereitstellen, muß der MN-Authentifikator den statisch konfigurierten NSK des AP für das ausgehandelte SSID/VLAN verwenden. Um dies zu erzielen, wird eine neue WTLV definiert, um es dem MN-Authentifikator zu erlauben, den NSK des verbundenen AP anzufordern.
  • Die anfragende TLV ist folgendermaßen definiert:
    Typ Länge 8 Bytes MIC
    WTLV_NSK TLV-Länge MN-ID WTLV_MIC
  • Die Antwort-TLV ist folgendermaßen definiert.
    Typ Länge 8 Bytes NSK MIC
    WTLV_NSK TLV-Länge MN-ID WTLV_TRANSIENT_KEY WTLV_MIC
  • Diese TLV wird nur benötigt, wenn vorab gemeinsam genutzte Schlüssel und Authentifizierungstypen, wie etwa EAP-MD5, verwendet werden und zu der Verwendung von statisch konfigurierten Schlüsseln führen. Obwohl von dieser Verwendung auf Grund von Unsicherheiten in hohem Maße abgeraten wird, wird dieses Merkmal präsentiert, um Legacy-Systeme besser zu unterstützen und um einem Migrationspfad zuzulassen. Das Abrufen der Schlüssel würde unter Verwendung eines WLCCP_CONTEXT-Anfrage-/Antwort-Austausches zwischen dem MN und dem AP zustande gebracht.
  • – WTLV_AUTHENTICATOR.
  • Ein WTLV_AUTHENTICATOR wird benötigt, um die Lebendigkeit eines CTK zwischen einer Verbindung zu garantieren. Dies ist effektiv das Mittel, mit dem sich der Ursprungs-IN mit seinem Vorgänger authentifiziert. Obwohl irgendeiner der Verbindungsendpunkte dies in einer Vorabregistrierungsanfrage-Antwort anfordern kann, wird erwartet, dass dies nach einer sicheren Kontext-(oder einer WTLV_INIT_SESSION)-Anfrage und -Antwort typischerweise während der Registrierung folgt. Die TLV ist wie folgt definiert:
    Feld Länge Beschreibung
    WTLV_AUTHENTICATOR 2
    TLV Länge 2
    DST-ID 8 Ziel-IN-ID, die beweisen muß, dass sie den gleichen CTKSRC-DST benutzt wie die SRC-ID, um die Verbindung (SRC-ID, DST-ID) zu schützen
    SRC-ID 8 Ursprungs-IN-ID, die einen Lebendigkeitsnachweis verlangt
    KSC 4 Schlüsselsequenzzähler, der als ein Replay-Protektor dient. Dieser Wert muß mit dem Wert übereinstimmen, der während eines sicheren Kontextanfrage-/-antwort-Austausches verwendet wird
    Reserviert 1
    Status 1 Wird in der Anfragenachricht ignoriert, aber kann in einer Antwort gesetzt werden. Ein Nicht-Null-Wert zeigt an, dass die Verbindung nicht den gleichen CTK teilt oder dass ein Replay entdeckt worden ist.
    Nonce 16 Eine zufällige Herausforderung (Random Challenge), die verwendet wird, um die Lebendigkeit zu beweisen. Der Absender muß einen willkürlichen 16-Byte-Wert bereitstellen
    MIC ML WTLV_MIC, die diese TLV authentifiziert
  • Die Ursprungs-MIC wird wie folgt berechnet:
    MICrequest = HMAC-MD5(CTKSRC-DST, SRC-ID ∥ DST-ID ∥ LSC ∥ NonceSRC)
  • Das Ziel muß die bereitgestellte NonceSRC inkrementieren und seine MIC wie folgt berechnen:
    NonceDST = NonceSRC + 1
    MICreply = HMAC-MD5(CTKSRC-DST, SRC-ID ∥ DST-Id ∥ KSC ∥ NonceDST)
  • Sowohl der Anfrage- als auch der Antwort-WTLV_AUTHENTICATOR muß die TLV wie folgt verschlüsseln:
    RC4'(MSC ∥ CTKSRC-DST, Status ∥ Nonce)
  • Das Ersetzen der Klartext-Felder mit ihren verschlüsselten Werten. (Es sei angemerkt, dass die ersten 256 Bytes des RC4-Random-Stroms zuerst gelöscht werden müssen, bevor ein Exklusiv-Oder mit Klartext durchgeführt wird).
  • – WTLV_RSNIE.
  • Die Sicherheitspolitik, die von dem MN ausgehandelt ist, muß zu dem SCM weitergereicht werden, wenn:
    Der MN erfolgreich CCKM ausgehandelt hat und augenblicklich mit einem AP verbunden ist
    Der MN von dem aktuellen AP zu einem neuen AP roamt und eine erneute Verbindung mit dem neuen AP aufbaut.
  • Während der erneuten Verbindung ist das RSNIE in dem Signaturelement enthalten, das in der erneuten Verbindungs-Nachricht enthalten ist. Somit muß das RSNIE zu dem SCM für die Validierung weitergereicht werden. Da das RSNIE in der Länge variiert, ist seine TLV folgendermaßen definiert.
    Feld Länge Beschreibung
    WTLV_RSNIE 2 TLV-Typ
    TLV 2 TLV-Länge
    RSNIE-Element N Inhalte des RSNIE, wie diese von dem MN bereitgestellt werden
  • – Laterale Nachrichtenauthentifizierung und Datenschutz
  • Eine "laterale" Kontextanfrage- oder Kontextantwort-Nachricht wird unabhängig von dem SWAN-Topologiebaum weitergeleitet. Der Absender und der Antwortende befinden sich vielleicht nicht auf demselben Topologiebaumzweig.; deshalb können sich der Absender und der Antwortende keinen geheimen CTK teilen. Die Inbound und Outbound Flags sind in einer lateralen Kontextnachricht auf AUS gesetzt.
  • Ein "lateraler L-CTK" (L-CTK), der von dem Absender und dem Antwortenden einer lateralen Kontextnachricht gemeinsam genutzt wird, wird verwendet, um die Nachricht zu authentifizieren und um alle sensiblen TLVs zu verschlüsseln, die in der Nachricht enthalten sind. Ein gemeinsamer Vorgänger des Absenders und des Antwortenden fungiert als eine vertrauenswürdige dritte Partei, um einen L-CTKL-CTK zu erzeugen. Der gemeinsame Vorgänger verwendet den Pfad-CTK, den er mit dem Absender gemeinsam nutzt, und den Pfad-CTK, den er mit dem Antwortenden gemeinsam nutzt, um den L-CTKL-CTK sicher zu jedem Knoten zu liefern.
  • Der gemeinsame Vorgänger erzeugt ein "Ticket" und einen L-CTK. Der L-CTK wird mit dem Pfad-CTK verschlüsselt, der von dem gemeinsamen Vorgänger und dem Absender gemeinsam genutzt wird. Das Ticket enthält ebenfalls den L-CTK und wird mit dem Pfad-CTK verschlüsselt, der von dem gemeinsamen Vorgänger und dem Antwortenden gemeinsam genutzt wird. Der L-CTK und das Ticket werden zu dem Kontexttransfer-Absender in einer WTLV_CTK_TICKET TLV geliefert.
  • Der Absender schließt die Knoten-ID des gemeinsamen Vorgängers, das Ticket und einen "Authentifikator" in einer WTLV_AUTHEN_TICKET TLV in der lateralen Kontextanfrage ein, die zu dem Antwortenden gesendet wird. Der Absender verwendet den L-CTK, um die WTLV_MIC TLV zu erzeugen, die verwendet wird, um die Kontextanfrage zu authentifizieren. Der Antwortende entschlüsselt das Ticket mit dem Pfad-CTK, den er sich mit dem gemeinsamen Vorgänger teilt, und extrahiert den L-CTK. Der Antwortende kann dann den L-CTK verwenden, um die Nachricht zu authentifizieren und um irgendwelche verschlüsselten TLVs zu entschlüsseln. Der Antwortende verwendet den CTK auch, um die Antwortnachricht zu authentifizieren und um irgendwelche sensiblen TLVs zu verschlüsseln, die in der Nachricht enthalten sind.
  • Der Wurzel-CM ist der gemeinsame Vorgänger aller SWAN-Knoten; deshalb kann der Wurzel-CM einen L-CTK für irgendwelche zwei Knoten erstellen. Ein Absender-Knoten kann eine WTLV_TICKET_REQUEST TLV in einer Kontextanfragenachricht zu dem Wurzel-CM senden, um einen L-CTK und ein Ticket für einen zweiten Antwortender-Knoten anzufordern. Der Wurzel-CM sendet das Ticket und den L-CTK in einer WTLV_CTK_TICKET TLV in der Kontextantwortnachricht zurück.
  • Wenn ein MN von einem alten AP zu einem neuen AP roamt, kann es eventuell notwendig sein, dass Kontextinformationen lateral von dem alten AP zu dem neuen AP in einer Kontextanfragenachricht weitergeleitet werden müssen. Der am nächsten gelegene gemeinsame Vorgänger-CM kann automatisch einen L-CTK und ein "Ticket" für den neuen AP in der Deregistrierungsanfrage-Nachricht, die zu dem alten AP gesendet wird, liefern. Der alte AP kann den L-CTK benutzen, um eine WTLV_MIC TLV zu erzeugen und um alle sensiblen Kontextinformationen in der Kontextanfrage zu verschlüsseln, die zu dem neuen AP gesendet werden, wie dies oben beschrieben ist.
  • Ein ähnlicher Mechanismus kann verwendet werden, um Kontext lateral von dem "alten LCM" zu dem "neuen LCM" zu transferieren, wenn ein MN zu einem neuen lokalen Kontrollbereich roamt.
  • – Eine einfache WLCCP-Implementierung (W1)
  • Dieser Abschnitt beschreibt eine einfache Einzel-Teilnetz-WLCCP-Implementierung, bei der der SCM für jedes Teilnetz in einem selbständigen SCM-Modus arbeitet und WLCCP NICHT verwendet wird, um Schicht-2-Weiterleitungspfade zu aktualisieren. Die einfache Implementierung umfasst die folgenden Komponenten:
    Der SCM ist der "Wurzel-CM" in einer selbständigen Einzel-Teilnetz-Infrastruktur.
    Anfängliche AP- und MN-Authentifizierung
    SCM-Auswahl und -Bekanntmachung
    AP-Pfadauthentifizierung
    Sicherheitskontexttransfer für MNs innerhalb eines Teilnetzes (d. h., MN-Vorabregistrierung).
    Schnelle erneute MN-Authentifizierung
    Einfache AP- und MN-Registrierung. (Die WLCCP-Registrierung erstellt KEINE Schicht-2-Weiterleitungspfade.)
    WLCCP-Nachrichtenauthentifizierung und Datenschutz.
  • Der SCM ist der 802-1X-Authentifikator für sowohl die MNs als auch die APs. EAPOL-Nachrichten werden zwischen dem SCM und den Vater-APs in WLCCP-AAA-Nachrichten übertragen.
  • Die einfache Implementierung unterstützt keine Schicht-2-Pfad-Aktualisierungen, Weiterreichungen zwischen Teilnetzen oder den Kontexttransfer zwischen Teilnetzen. Die Netztopologie umfasst keinen CCM bzw. keine LCMs. Das existierende Cisco DDP Protokoll wird verwendet, um Schicht-2-Weiterleitungspfade zu erstellen und zu löschen. DDP wird auch für Weiterreichungen innerhalb eines Teilnetzes verwendet (d. h., wenn Stationen innerhalb eines einzigen Teilnetzes roamen).
  • Die einfache Implementierung verwendet die folgenden WLCCP-Nachrichtentypen:
    • – SCM-Bekanntmachung
    • – Registrierung
    • – Vorabregistrierung
    • – AAA
    • – Pfad-Init
  • Die W1-Netztopologie umfasst einen SCM und APs in einem einzigen Teilnetz. Es umfasst auch jegliche MNs, die mit diesen APs verbunden sind. Schicht-2-Pfad-Aktualisierungen werden nicht unterstützt; die schnelle erneute Authentifizierung von Repeater-APs wird nicht unterstützt; deshalb sind Multi-Hop-AP-zu-AP-Verbindungen für die W1-Implementierung im Allgemeinen transparent.
  • In der einfachen WLCCP-Implementierung arbeitet der aktive SCM in einem selbständigen Teilnetzmodus.
  • Die Datenstrukturen und die Zustandsvariablen, die für die W1-Implementierung benötigt werden, sind die gleichen wie die allgemeinen SCM-Datenstrukturen und -Zustandsvariablen. Der SCM ist der IN und der MN 802.1X-Authentifikator; deshalb muß er eine authentifizierte Knoten-Tabelle unterhalten.
  • Jeder SCM-Kandidat, der mit einem Nicht-Null-SCM-Prioritätswert konfiguriert ist, muß an dem SCM-Auswahlprotokoll teilnehmen, wie dies in dem Abschnitt mit dem Titel "Aktive SCM Auswahl beschrieben ist.
  • Die Felder in den SCM_Bekanntmachungs-Antwort-Nachrichten werden so gesetzt, wie sie in dem Abschnitt mit dem Titel "Aktive SCM Auswahl" beschrieben ist, wobei es die folgenden Einschränkungen gibt:
    Die WTLV_ROOT_CM_INFO TLV enthält die IPv4-Adresse des SCM.
  • W1 – IN-Authentifizierung.
  • Jeder AP muß sich gegenseitig mit dem 802.1X-Infrastruktur-Authentifikator authentifizieren, welcher in der einfachen WLCCP-Implementierung der aktive SCM ist. Der SCM gibt seine IP-Adresse in der ROOT_CM_INFO TLV in den SCM_Bekanntmachungs-Antwort-Nachrichten bekannt. Gemäß WLCCP IP eingekapselte Kontextanfrage- und -antwort-Nachrichten werden verwendet, um EAPOL-Authentifizierungsnachrichten zwischen dem "Supplicant"-AP und dem 802.1X-Authentifikator zu transportieren. Der Prozess der gegenseitigen Authentifizierung von AP und SCM erstellt einen Netz-Sitzungsschlüssel (NSK), der von dem Supplicant-AP und dem SCM gemeinsam verwendet wird. Ein AP muß eine Pfadauthentifizierung mit dem SCM initiieren, nachdem er erfolgreich authentifiziert worden ist (und immer dann, wenn er roamt). Der NSK wird in dem Pfadauthentifizierungsprozess verwendet (der unten beschrieben wird), um einen AP-SCM-Kontexttransferschlüssel (CTK) zu erstellen.
  • W1 – SCM-Registrierungsverarbeitung
  • Der aktive SCM muß eine Registrierungstabelle unterhalten, die einen Eintrag für jeden AP in seinem Teilnetz und jeden MN, der mit diesen APs ver bunden ist, aufweist. Die Registrierungstabelle wird auf "leer" initialisiert. Der aktive SCM setzt die Tabelle immer dann auf leer zurück, wenn er den aktiven SCM-Status aufgibt. In der einfachen WLCCP-Implementierung wird die Registrierungstabelle nur verwendet, um MN-Kontextinformationen zu verwalten. Sie enthält KEINE Schicht-2-Weiterleitungsinformationen und Pfadzustandsinformationen.
  • Der SCM erzeugt oder aktualisiert eine Registrierungsaufzeichnung für einen AP oder MN, wenn er eine gültige Registrierungsanfrage empfängt und eine entsprechende Registrierungsantwort für den AP oder MN erzeugt.
  • W1 – (Vorab-)Registrierungs-Nachrichten-Authentifizierung
  • In der einfachen WLCCP-Implementierung werden Vorabregistrierungs- und Registrierungs-Nachrichten mit einem SCM/AP-CTK authentifiziert, der über die AP-Pfadauthentifizierung erstellt worden ist. Der CTK wird verwendet, um eine Nachrichtenintegritätsprüfung zu erzeugen und zu überprüfen, die in einer WTLV_MIC TLV in allen (Vorab-)Registrierungsnachrichten enthalten ist. Der SCM verwendet immer den CTK, den er mit dem Absender gemeinsam nutzt, um (Vorab-)Registrierungsanfrage-Nachrichten zu authentifizieren. Der AP verwendet immer den CTK, den er mit dem SCM (d. h., dem Antwortenden) gemeinsam nutzt, um (Vorab-)Registrierungsantwort-Nachrichten zu authentifizieren. (Vorab-)Registrierungsnachrichten, die von einem Nicht-Wurzel-AP erzeugt werden, werden in der einfachen WLCCP-Implementierung von Zwischen-APs nicht verarbeitet oder authentifiziert. Die allgemeine WLCCP-Nachrichtenauthentifizierung ist ausführlich in dem Abschnitt mit dem Titel "WLCCP-Nachrichtenauthentifizierung" erörtert.
  • Wenn der SCM eine "ungültige" (Vorab-)Registrierungsanfrage empfängt, die bei der Nachrichten-Integritäts-Authentifizierung scheitert, sendet der SCM eine Antwortnachricht mit einem "Schlechte MIC"-Status zurück, ohne die Nachricht weiter zu verarbeiten.
  • W1 – Empfangene AP-Pfad-Init-Anfrage
  • Ein AP muß seinen Pfad gegenüber dem SCM authentifizieren, wie dies oben beschrieben ist, um einen Kontexttransferschlüssel (CTK) zu erstellen und zu aktualisieren, den er mit dem SCM gemeinsam nutzt. Der SCM erzeugt eine Pfad-Init-Antwort, wenn er eine Pfad-Init-Anfrage empfängt, bei der das Response-Req Flag auf EIN gesetzt ist. Der SCM sendet eine Pfad-Init-Antwort mit einem "gut"-Status zurück, wenn er einen authentifizierten Knoten-Eintrag den Anfragender-AP aufweist, der sich in dem "authentifizierten", "vorabregistrierten" oder "registrierten" Zustand befindet; anderenfalls sendet der SCM eine Pfad-Init-Antwort mit einem "nicht authentifiziert"-Status zurück.
  • Die Pfadauthentifizierung, die die AP/SCM-CTK-Generierung und -Verteilung umfasst, ist in dem Abschnitt mit dem Titel "Infrastruktur-Pfadauthentifizierung" ausführlich beschrieben.
  • W1 – Empfangene AP-Registrierungsanfrage
  • Ein AP, der eine Pfadauthentifizierung erfolgreich vollendet hat, muß sich bei dem SCM registrieren, wie dies unten beschrieben wird. Der SCM erzeugt eine Registrierungsantwort für einen AP, wenn er eine Registrierungsanfrage von dem AP empfängt, bei der das Response-Req Flag auf EIN gesetzt ist. Der SCM sendet eine Registrierungsantwort mit einem "gut"-Status zurück, wenn er einen authentifizierten Knoten-Eintrag für den Anfragenden-AP aufweist, der sich in dem "vorabregistrierten" oder "registrierten" Zustand befindet; anderenfalls sendet der SCM eine Registrierungsantwort mit einem "nicht authentifiziert"-Status zurück.
  • Der SCM erzeugt oder aktualisiert eine AP-Registrierungsaufzeichnung für den Absender, wenn er eine Registrierungsantwort mit einem "gut"-Status erzeugt. Das Alter der Registrierungsaufzeichnung wird auf '0' zurückgesetzt, wenn eine gute Antwort erzeugt wird.
  • W1 – Empfangene MN-Vorabregistrierungsanfrage
  • Ein neuer Vater-AP sendet eine Vorabregistrierungsanfrage zu dem SCM, bei der das Response Req Flag auf EIN gesetzt ist, um die dynamischen Sicherheitsberechtigungsnachweise eines Sohn-MN zu erhalten, wenn er sich erneut verbindet. Der SCM erzeugt eine Vorabregistrierungsantwort für einen MN, wenn er die Vorabregistrierungsanfrage empfängt. Der SCM sendet eine Antwort mit einem "gut"-Status zurück, wenn er einen authentifizierten Knoten-Eintrag für den MN besitzt. Das Protokoll für das Transferieren von Sicherheitsberechtigungsnachweisen des MN zu einem neuen Vater-AP ist in dem Abschnitt mit dem Titel "MN-Sicherheitskontexttransfer" ausführlich beschrieben.
  • W1 – Empfangene MN-Registrierungsanfrage.
  • Der SCM erzeugt eine Registrierungsantwort für einen MN, wenn er eine Registrierungsanfrage von dem Vater-AP des MN empfängt, bei der das Response-Req Flag auf EIN gesetzt ist. Der SCM sendet eine Registrierungsantwort mit einem "gut"-Status zurück, wenn er 1) einen authentifizierten Knoten-Eintrag mit einem "erfolgreich"-Status für den Anfragender-MN aufweist, und 2) eine "gebundene" Registrierungsaufzeichnung für den Absender-AP aufweist. Der SCM sendet eine Registrierungsantwort mit einem "nicht authentifiziert"-Status zurück, wenn der MN nicht authentifiziert ist. Der SCM sendet eine Registrierungsantwort mit einem 'nicht registrierter Vater'-Status zurück, wenn der Vater-AP keine gebundene Registrierungsaufzeichnung aufweist.
  • Der SCM akzeptiert Registrierungsanfragen in der Reihenfolge ihrer Ankunft. Als eine Option sollte der SCM eine MN-Registrierungsaufzeichnung jedes Mal dann mit einem Zeitstempel versehen, wenn eine "gute" Registrierungsantwort für den jeweiligen MN erzeugt wird. Der Zeitstempel wird unter Verwendung der aktuellen Zeit minus irgendeines Verzögerungswerts in der entsprechenden Registrierungsanfrage berechnet. Der SCM sollte eine empfangene Registrierungsanfrage für einen MN verwerfen, wenn es eine existierende Registrierungsaufzeichnung für den MN gibt und der Zeitstempelwert in dem Eintrag größer als der Wert der aktuellen Zeit minus irgendeiner Verzögerung in der Registrierungsanfrage ist.
  • In der einfachen WLCCP-Implementierung erzeugt der SCM KEINE Deregistrierungsanfrage, wenn ein MN zu einem anderen Vater-AP roamt.
  • W1 – AP-Operation.
  • Dieser Abschnitt definiert die AP-Zustandsvariablen, -Timer und -Prozeduren, die für die einfache WLCCP-Implementierung notwendig sind. AP-Prozeduren werden im Allgemeinen geordnet nach AP-"Top-Level"-WLCCP-Zustandsübergängen beschrieben. Top-Level-AP-WLCCP-Zustände und -Zustandsübergänge sind in dem Abschnitt mit dem Titel "AP-Betriebsmodi" beschrieben.
  • Die einfache AP-Implementierung erfordert die folgenden AP-Prozeduren:
    Ein AP muß SCM-Bekanntmachungs-Antwortnachrichten verarbeiten, um den aktiven SCM zu entdecken.
    Ein AP muß sich gegenseitig mit dem 802.1X IN-Authentifikator authentifizieren und einen NSK erstellen.
    Jeder AP muß seinen Pfad zu dem SCM authentifizieren, um einen CTK zu erstellen.
    APs müssen sich bei dem SCM registrieren.
    Registrierte APs müssen SCM-Bekanntmachungs-Antwortnachrichten an sekundären Ports erzeugen.
    Registrierte APs müssen MNs vorab registrieren, um die dynamischen Berechtigungsnachweise der MNs zu erhalten.
    Registrierte APs müssen MNs registrieren.
    Vorabregistrierungs- und Registrierungsnachrichten werden gesendet, bei denen das Hopwise-Routing Flag auf AUS gesetzt ist; deshalb verarbeiten Zwischen-APs die Nachrichten nicht.
  • W1 – SCM-Bekanntmachungsnachrichten-Verarbeitung
  • Ein AP muß SCM-Bekanntmachungs-Antwortnachrichten überwachen, die er an seinem primären Port in dem nativen VLAN empfängt, um festzustellen, ob es einen aktiven SCM für das native VLAN gibt. Ein AP führt das einfache WLCCP-Protokoll aus, wenn es einen aktiven SCM für das native VLAN des AP gibt.
  • Der MN 802.1X Authentifikator ist in dem SCM, wenn der AP mit dem aktiven SCM registriert ist; anderenfalls ist der MN 802.1X-Authentifikator in dem AP. Pfadkosten- und Hop-Zählungs-Informationen werden in der W1-Implementierung nicht verwendet. Das SCM Bekanntmachungs-Protokoll wird nicht verwendet, um den primären Port des AP zu bestimmen.
  • W1 – Anfängliche AP-Authentifizierung
  • Ein AP muß sich gegenseitig mit dem 802.1X IN-Authentifikator authentifizieren, wenn er zum ersten Mal eine neue Instanz eines aktiven SCM entdeckt, wie dies oben in dem Abschnitt mit dem Titel "W1 – IN-Authentifizierung" beschrieben ist. Der IN-Authentifikator ist in der einfachen WLCCP-Implementierung immer der aktive SMC.
  • W1 – AP-Pfadauthentifizierung
  • Ein AP muß die Pfadauthentifizierung mit dem SCM initiieren, nachdem er erfolgreich authentifiziert ist, um einen geheimen Kontexttransferschlüssel (CTK) zu erstellen, der von dem AP und dem SCM gemeinsam genutzt wird. [Ein AP muß periodisch seinen AP-SCM CTK mittels Aktualisierungs-Registrierungsanfrage-/-antwort-Nachrichten aktualisieren.]
  • Die AP-Pfadauthentifizierung in der einfachen W1-Implementierung ist so, wie sie oben in dem Abschnitt mit dem Titel "Allgemeine AP-Pfadauthentifizierung" beschrieben worden ist, mit der Ausnahme, dass 1) der Wurzel-CM immer der SCM ist, und 2) das Hopwise-Routing Flag auf AUS gesetzt ist. Das Hopwise-Routing Flag ist auf AUS gesetzt, weil die Schicht-2-Pfadaktualisierung nicht aktiviert ist; deshalb ist es nicht notwendig, einen gemeinsam genutzten CTK zwischen einem Sohn-AP und irgendwelchen Vorgänger-APs zu erstellen.
  • W1 – AP-Registrierung
  • Ein AP muß sich bei dem aktiven SCM für sein Teilnetz am Anfang registrieren, wenn er eine neue Instanz des SCM entdeckt, und periodisch registrieren, um seine Registrierungsaufzeichnung in dem SCM aufzufrischen.
  • Die Felder in einer anfänglichen Registrierungsanfrage, die von einem nicht angeschlossenen AP gesendet werden, werden wie unten beschrieben gesetzt. (Nicht spezifizierte Felder werden auf '0' gesetzt.)
  • WLCCP-Header-Felder:
    • Typ – '3'
    • Absender – Knoten-ID des nicht angeschlossenen AP.
    • Antwortender – Knoten-ID des SCM.
    • Response-Req Flag – '1', um eine Antwort abzurufen.
    • Inbound Flag – '1'.
    • Hopwise-Routing Flag – '0'
  • Registrierungsfelder:
    • Anfragender – Knoten-ID des nicht angeschlossenen AP.
    • Hop-Adresse – 802 Adresse des ausgewählten primären Ports des nicht angeschlossenen AP.
    • Relay-Knoten-ID – '0'
    • Initial Flag – '1'.
  • Ein AP sendet eine Registrierungsanfrage (erneut) entweder solange, bis er eine Registrierungsantwort mit einer übereinstimmenden Nachrichten-ID empfängt, oder bis die maximalen erneuten Versuche überschritten sind. Ein AP ist "registriert", wenn er eine passende Registrierungsantwort mit einem "guten" Registrierungsstatus empfängt.
  • Ein AP sendet periodisch eine "Aktualisierungs"-Registrierungsanfrage-Nachricht zu dem SCM, um seine Registrierungsaufzeichnung "aufzufrischen". Bei einer Aktualisierungs-Registrierungsanfrage ist das Initial Flag auf AUS gesetzt.
  • Ein AP kann keine Proxy-Vorabregistrierungs- und -Registrierungs-Nachrichten für MNs erzeugen, bis er sich erfolgreich bei dem SCM registriert hat.
  • Ein AP, der sich erfolgreich bei dem aktiven SCM registriert hat (d. h., der obige "I, R"-Zustand), muß periodisch SCM-Bekanntmachungs-Antwortnachrichten an jedem seiner sekundären Ports erzeugen.
  • Ein SCM_Advertisement_Timer wird anfänglich gestartet, wenn sich der AP erfolgreich bei dem aktiven SCM registriert hat. Er wird jedes Mal dann neu gestartet, wenn er abläuft, bis der AP in einen nicht registrierten Zustand übergeht (d. h., wenn sich der aktive SCM ändert oder verloren geht). Die Zeitspanne des SCM_Advertisement_Timer wird immer auf den SCM_Advertisement_Period-Wert (in Sekunden) in der Parent_SCM_Record des AP gesetzt. Die SCM_Bekanntmachungs-Period wird jedes Mal dann aktualisiert, wenn der AP eine SCM-Bekannmachung von dem aktiven SCM empfängt.
  • Ein registrierter AP führt das Folgende durch, wenn der SCM Advertisement Timer abläuft:
    Wenn das SCM_Age gleich dem MAX_SCM_AGE ist, dann wird WLCCP deaktiviert.
    Anderenfalls, wenn das SCM_Age kleiner als das Inkrement des SCM_Age ist, dann das Neustarten des SCM Advertisement Timer mit dem aktuellen Advertisement_Period-Wert;
    Inkrementieren des SCM_Age-Wertes;
    Erzeugen einer "aktiven" SCM_Bekanntmachungs-Antwortnachricht an jedem sekundären Port.
  • Ein registrierter AP erzeugt eine planmäßige SCM_Bekanntmachungs-Antwortnachricht mit den Feldwerten, die unten gezeigt sind. Felder, die nicht spezifiziert sind, werden auf '0' gesetzt.
  • WLCCP-Header-Felder:
    • Typ – '0x41' = (SCM_Advertisement Antwort)
    • Absender – '0'
    • Antwortender – AP-Knoten-ID.
    • Outbound Flag – '1'
    • TLV Flag – '1' (die Anfrage muß eine IPV4_SUBNET TLV und eine IN_1X_ATHEN TLV enthalten).
  • SCM_Advertisement Antwort-Felder:
    • Hop_Address – Die 802 Hop-Adresse, die verwendet wird, um auf den AP über den jeweiligen Ausgangsport zuzugreifen (welches die AP-Knotenadresse ist, wenn der Ausgangsport in einem gemischten Modus arbeitet).
  • SCM Flags:
    • Active Flag – '1'
    • SCM-Priorität – kopiert aus der Parent_SCM_Record
    • SCM-Knoten-ID – kopiert aus der Parent_SCM_Record
    • Instanzalter – kopiert aus der Parent_SCM_Record
    • Pfadkosten – kopiert aus der Parent_SCM_Record
    • Hop-Zählung – kopiert aus der Parent_SCM_Record
    • Bekanntmachungsperiode – kopiert aus der Parent_SCM_Record
    • WTLV_IPV4_SUBNET_ID TLV – IPv4-Adresse und Präfixlänge des AP
    • WTLV_ROOT_CM_INFO TLV – kopiert aus der IN_1X_Authenticator Zustandsvariablen
  • W1 – Proxy-MN-Vorabregistrierung.
  • Die MN-Vorabregistrierung ist in der einfachen WLCCP-Implementierung exakt die gleiche wie die allgemeine Proxy-MN-Vorabregistrierung.
  • W1 – Proxy-MN-Registrierung.
  • Die WLCCP-MN-Registrierung wird in einem AP aktiviert, nachdem er sich erfolgreich mit dem aktiven SCM registriert hat (d. h., wenn er in den oben genannten I, R-Zustand übergeht). Ein Vater-AP erzeugt eine anfängliche Proxy- Registrierungsanfrage für einen MN, nachdem sich der MN erfolgreich authentifiziert hat oder erneut authentifiziert hat. [Eine Registrierungsanfrage kann verwendet werden, um einen Authentifizierungs-Handshake zu vollenden; aber der MN muß vollständig authentifiziert sein, bevor eine "authentifiziert"-Registrierungsantwortnachricht von dem SCM erzeugt wird.]
  • In der einfachen WLCCP-Implementierung wird der WLCCP-Registrierungsprozess nicht verwendet, um Schicht-2-Weiterleitungspfade zu erstellen oder zu löschen; deshalb sind das L2_Path_Update Flag und das Hopwise-Routing Flag in den Registrierungsnachrichten auf AUS gesetzt. Der Absender ist immer der Vater-AP und der Antwortende ist immer der Vater-SCM. Eine Registrierungsanfrage für einen MN muß die SSID des MN und die Standard-VLAN-ID für den MN enthalten.
  • Der SCM bestätigt eine Registrierungsanfrage, indem er eine Registrierungsantwort zu dem Absender zurückschickt. Der Status-Wert in der Antwort zeigt an, ob die Registrierungsanfrage akzeptiert wurde.
  • Wenn ein Vater-AP eine erwartete Registrierungsantwort nicht empfängt, dann muß er die Registrierungsanfrage erneut senden, wobei das Retry Flag auf EIN gesetzt wird, und mit der gleichen Nachrichten-ID, bis die Anzahl an erneuten Versuchen gleich dem REGISTRATION_RETRY_LIMIT ist. Das Verzögerungs-Feld in einer erneut übertragenen Registrierungsanfrage sollte auf die abgelaufene Zeit eingestellt sein, seit der MN zuletzt einen Uplink-Rahmen übertragen hat.
  • Das Registrierungsantwort-Lebenszeit-Feld enthält einen Registrierungslebenszeitwert in Minuten. Ein AP muß eine Aktualisierungs-Registrierungsanfrage für einen MN erzeugen, bevor die Registrierungslebenszeit abläuft.
  • Die Felder in einer anfänglichen Proxy-Registrierungsanfrage für einen MN werden so gesetzt, wie dies unten beschrieben ist. Nicht spezifizierte Felder werden auf '0' gesetzt.
  • WLCCP-Header-Felder:
    • Typ – '3'
    • Absender – Knoten-ID des Vater-AP.
    • Antwortender – Knoten-ID des SCM.
    • Response-Req Flag – '1' zum Abrufen einer Antwort.
    • Inbound Flag – '1'.
    • Hopwise-Routing Flag – '1'.
    • TLV_Flag – '1' (die Anfrage muß eine SSID_TLV enthalten).
  • Registrierungsfelder:
    • Anfragender – 802 Adresse des MN.
    • Hop-Adresse – 802 Adresse des primären Ports des Vater-AP.
    • Relay-Knoten-ID – '0'
    • Proxy Flag – '1'.
    • Initial Flag – '1'.
    • Authenticated Flag – Das Authenticated Flag wird in einer Anfrage auf '1' gesetzt, um anzuzeigen, dass der MN von dem Vater-AP authentifiziert wurde.
    • Proxy MIP Flag – wird auf '1' gesetzt, wenn der MN eine SSID verwendet, bei der Proxy MIP aktiviert ist.
    • Delay – Die Verzögerung in hundertstel Sekunden, seit der MN zuletzt einen Uplink-Rahmen gesendet hat. Die Verzögerung ist für Gewöhnlich '0', wenn das Retry Flag '0' ist.
    • VLAN ID – Die VLAN ID, die dem MN zugewiesen ist. Die VLAN ID des MN ist für Gewöhnlich die Standard-VLAN-ID, die der SSID des MN zugewiesen ist. Die zugewiesene VLAN ID kann '0' sein, wenn der MN dem "nativen VLAN" zugewiesen ist. Das VLAN ID Feld in der Registrierungsantwort für einen MN kann eine andere VLAN ID enthalten, um den MN explizit einem VLAN zuzuweisen.
    • SSID_ TLV – Die Registrierungsanfrage für einen MN muß eine WTLV_SSID TLV enthalten, die die aktive SSID für den MN enthält, die in der (erneuten) Verbindungsanfrage des MN enthalten ist. Das Broadcast SSID Flag muß auf EIN gesetzt sein, wenn der MN mit einer Broadcast-SSID assoziiert ist. Eine Registrierungsantwort für einen MN kann eine SSID TLV mit einer anderen SSID umfassen, um den MN explizit einem Dienstsatz (Service Set) zuzuweisen.
    • AUTHENTICATION_TYPE_TLV – Enthält den 802.11 Authentifizierungstyp (offen, gemeinsamer Schlüssel oder EAP-Typ), der verwendet wird, um den MN zu authentifizieren.
  • Eine Registrierungsanfrage, die für eine 802.11-Station erzeugt wird, die "sich erneut verbunden hat", muß die BSSID des alten AP in einer WTLV_OLD_AP_BSSID TLV enthalten. Die BSSID wird aus dem "alter AP"-Feld in der 802.11-Anfrage bezüglich einer erneuten Verbindung erhalten, die von der Station gesendet wird.
  • Eine Registrierungsantwortnachricht für einen MN enthält immer die IP-Adresse des MN, wenn sie bekannt ist. Ein Vater-AP muß eine "Registrierungsanfrage für einen MN" erzeugen, wenn er das erste Mal eine neue oder andere IP-Adresse für den MN entdeckt (d. h., indem er IP/ARP-Pakete belauscht, die von dem MN übertragen werden). Das Root CM Flag wird in der Anfrage auf EIN gesetzt, um eine Aktualisierung in dem vollständigen Pfad zu dem Wurzel-CM zu veranlassen.
  • – Eine vollständige WLCCP-Implementierung (W2)
  • Dieser Abschnitt beschreibt eine vollständige WLCCP-Implementierung, die Folgendes unterstützt:
    • – Kontexttransfer über LCMs und den CCM zwischen Teilnetzen.
    • – Zuverlässige Schicht-2-Pfad-Aktualisierungen.
    • – Eine Teilnetz-Topologie, die Repeater-APs, einfache drahtlose Brücken (z. B. WGBs) und eine beliebige Mischung aus Ethernet- und 802.11-Verbindungen enthält.
  • Pfadinstanzen.
  • Wie oben angemerkt worden ist, liegt ein Pfad auf einem Zweig des SWAN-Topologiebaums. Der vollständige Pfad zu einem Knoten in einem Campusnetz umfasst den Knoten, den CCM und jegliche Zwischenknoten und -verbindungen. Eine Pfadinstanz ist ein vollständiger oder ein teilweiser Pfad zu einem bestimmten Zeitpunkt. Jeder CCM erstellt Pfadinstanzen für jeden Knoten innerhalb seines Bereichs. Zum Beispiel erstellt ein SCM eine "SCM-Pfadinstanz" für jeden AP und MN in seinem Teilnetzbereich; der CM erstellt eine "CCM-Pfadinstanz" für jeden CM, AP und MN in dem Campusnetz. Eine Pfadinstanz wird erstellt, wenn ein nicht angeschlossener Knoten einen Vaterknoten auswählt und sich bei der SWAN-Infrastruktur registriert.
  • Eine CM-Pfadinstanz wird von einer Pfad-ID identifiziert, die von dem jeweiligen CM zugeordnet wird. Eine Pfad-ID von '0' wird verwendet, um "keine Pfad-ID" anzuzeigen. Gültige Pfad-IDs starten bei '1'. Ein CM inkrementiert seine Pfad-ID für einen Knoten, wenn er eine "anfängliche" Registrierungsanfragenachricht für den Knoten empfängt. Registrierungsantwort-, "Aktualisierungs"-Registrierungsanfrage-, Abtrenn-, Deregistrierungs-, Pfadaktualisierungs- und Pfadprüf-Nachrichten enthalten immer eine gültige Pfad-ID.
  • Eine SCM-Pfadinstanz existiert innerhalb des Kontextes einer LCM-Pfadinstanz. Eine LCM-Pfadinstanz existiert im Kontext einer CCM-Pfadinstanz. Die kombinierten CCM-, LCM- und SCM-Pfad-IDs identifizieren die vollständige Pfadinstanz für einen MN in einem Campusnetz. In 1 ist zum Beispiel die volle Pfadinstanz für MN-2 durch die Pfad-IDs 15, 10 und 6 identifiziert, die jeweils von dem CCM, dem LCM und dem SCM erstellt wurden.
  • Ein "eingehender" Pfad wird von der Struktur des Topologiebaums definiert. Ein "abgehender" Pfad zu einem Knoten wird von den Zustandsinformationen definiert, die in jedem CM und AP auf dem Pfad zu dem Knoten verwaltet werden. In dem vorliegenden Dokument sind die Pfadzustandsinformationen für einen einzigen Nachfolgerknoten in einer "Nachfolgerpfadaufzeichnung" (DPR; Descendant Path Record) in jedem CM und AP auf dem abgehenden Pfad zu dem Knoten enthalten.
  • In dem Topologiebaum können keine abgetrennten Pfadfragmente existieren. Eine "gebundene" Pfadinstanz wird durch eine "abgehende" Registrierungsantwortnachricht erstellt. Der eingehende Abschnitt einer Pfadinstanz muß existieren, bevor der abgehende Abschnitt erstellt werden kann. Zum Beispiel kann ein SCM in einem Infrastrukturmodus keine Pfadinstanz für einen Knoten erstellen, wenn eine LCM-Pfadinstanz für den Knoten nicht bereits existiert. Wenn ein MN roamt, dann wird zuerst der ganz außen liegende abge hende Abschnitt des "alten Pfades" gelöscht (d. h., durch eine nach innen gerichtete Deregistrierungsantwort- oder Abtrennanfrage-Nachricht). Wenn die Verbindung zu einer Sohn-AP- oder -CM-Verbindung verloren geht, dann werden alle Pfadinstanzen in dem Unterbaum, der an dem AP oder CM wurzelt, gelöscht.
  • – W2 Registrierungsaufzeichnungen.
  • Jeder CM oder AP muß eine Registrierungstabelle verwalten, die eine Nachfolgerregistrierungsaufzeichnung (DRR) für jeden Nachfolgerknoten (MN, AP oder CM) in seinem Unterbaum enthält. Eine Registrierungstabelle kann optional eingehende Registrierungsaufzeichnungen (IRR; Inbound Registration Records) für Knoten enthalten, die sich nicht in dem Unterbaum des jeweiligen AP oder CM befinden. Eine temporäre, nicht gebundene Registrierungsaufzeichnung (URR; Unbound Registration Record) wird verwendet, um Zustandsinformationen für einen nicht registrierten Knoten zu speichern. Registrierungsaufzeichnungen werden durch Registrierungs-, Deregistrierungs- und Abtrennnachrichten aktualisiert. Eine Registrierungsaufzeichnung wird gealtert und verworfen, wenn sie nicht innerhalb der Registrierungs-Lebenszeit aufgefrischt wird. Der Hauptschlüssel für eine Registrierungsaufzeichnung ist die WLCCP Knoten-ID des jeweiligen Knotens.
  • In der W2-Implementierung muß ein AP oder CM zusätzliche Weiterleitungs- und Pfadzustandsinformationen für jeden Nachfolger-WLCCP-Knoten verwalten. In dem vorliegenden Dokument enthält eine "Nachfolgerpfadaufzeichnung" (DPR) alle Informationen, die benötigt werden, um eine Nachricht zu einem Nachfolgerknoten zu senden, sowie auch andere Pfadzustandsinformationen. Jede DRR zeigt auf eine DPR. "DRR/DPR" wird verwendet, um eine DRR und die entsprechende DPR zu kennzeichnen.
  • Eine DPR kann sich in einem "gebundenen" oder "nicht gebundenen" Zustand befinden. Ein Vater-AP erschafft eine nicht gebundene DPR und erzeugt eine "anfängliche" Registrierungsanfrage für einen Sohn-802.11-MN, wenn der MN zum ersten Mal in den gemäß 802.11 "verbundenen und authentifizierten" Zustand eintritt. Die anfängliche Registrierungsanfrage erzeugt auch eine nicht gebundene DPR in jedem AP und CM auf dem Pfad zu dem CCM. Eine "nicht gebundene" DPR enthält die Nachrichten-ID der entsprechenden anfänglichen Registrierungsanfrage.
  • Eine DPR wird "gebunden", wenn eine "authentifizierte" Registrierungsantwort mit einer passenden Nachrichten-ID und einem guten Status empfangen wird. Eine "gebundene" DPR enthält eine Nicht-Null-Pfad-ID, die von dem Vater-CM in der Registrierungsantwort gesetzt wird. Eine DPR in einem SCM enthält eine SCM-Pfad-ID und eine LCM-Pfad-ID. Die SCM-Pfad-ID identifiziert den abgehenden Pfad, der an dem SCM seinen Ursprung hat; die LCM-Pfad-ID (d. h., die Pfad-ID, die von dem LCM erstellt wurde) identifiziert den eingehenden Pfad zu dem LCM. Eine DPR in einem LCM enthält aus ähnlichen Gründen eine LCM-Pfad-ID und eine CCM-Pfad-ID.
  • Ein Pfad ist "gebunden", wenn sich jede DPR in dem Pfad in einem "gebundenen" Zustand befindet. Der Pfad zu einem Knoten kann sowohl gebunden als auch nicht gebunden sein. Zum Beispiel wird das äußerste abgehende Fragment des Pfads zu einem MN nicht gebunden sein (d. h., bis die Wiederherstellung initiiert ist), wenn eine anfängliche Registrierungsantwortnachricht verloren geht. Nicht gebundene DPRs werden schnell gealtert und verworfen; deshalb ist es nicht notwendig, einen "nicht gebundenen Pfad" explizit zu löschen.
  • Das maximale Alter einer gebundenen DPR wird während der WLCCP-Registrierung über ein Registrierungs-Lebenszeit-Feld erstellt. Vater-APs und – CMs altern DPRs für Sohn-Knoten. Eine DPR wird verworfen, wenn sie innerhalb der Registrierungslebenszeit nicht "aufgefrischt" wird. Die DPR für einen Sohn-MN wird durch Uplink-Daten- oder Management-Rahmen aufgefrischt. Die DPR für einen Sohn-AP oder -CM wird durch periodische Aktualisierungs-Registrierungsanfragen aufgefrischt. Wenn die DPR für einen Sohn-AP oder – CM gelöscht wird, dann wird die Registrierung des AP oder CM aufgehoben, und auch der gesamte Unterbaum, der an dem Sohn-AP oder -CM wurzelt, wird gelöscht.
  • Der CCM weist eine DRR/DPR für jeden aktiven CM, AP oder MN in dem SWAN-Campusnetz auf. Eine CCM DPR enthält die Knoten-ID und die IP-Adresse des Vater-LCM des Knotens. Ein LCM weist eine DRR/DPR für jeden MN, AP und SCM in seinem lokalen Kontrollbereich auf (d. h., in seinen zugewiesenen Teilnetzen). Eine LCM DPR für einen AP oder MN enthält die Knoten-ID und die IP-Adresse des Vater-SCM. Ein SCM weist eine DPR für jeden AP und MN in seinem Teilnetz auf. Eine SCM DPR weist die Knoten-ID des Vater-AP, falls diese existiert, und die Knoten-ID des Wurzel-AP auf.
  • In einem AP enthält eine MN DPR einen Zeiger auf eine Portaufzeichnung. Wie oben angemerkt worden ist, werden ein Ethernet-Port, ein 802.11 BSS und jede AP-zu-AP-Verbindung als ein logischer Port betrachtet. Zu irgendeinem gegebenen Zeitpunkt ist jeder aktive logische AP-Port entweder als ein primärer Port in einem "Sohn"-Modus oder als ein sekundärer Port in einem "Vater"-Modus tätig. Eine Portaufzeichnung enthält den "Portzustand" und die Informationen, die notwendig sind, um einen Rahmen auf dem jeweiligen logischen Port weiterzuleiten. Eine Portaufzeichnung enthält die 802-" Hop-Adresse" für 802.11-Ports. Ein Nicht-Wurzel-AP leitet eine Nachricht "eingehend" weiter, indem er die Nachricht an seinem primären Port sendet.
  • – W2 Teilnetztopologie
  • Ein SWAN-Teilnetz ist ein Ethernet-LAN. In dem vorliegenden Dokument wird vorausgesetzt, dass ein zugrunde liegendes IEEE 802.1D Spannbaumprotokoll (STP) oder ein anderes STP verwendet wird, um verdrahtete Ethernet-LAN-Segmente in jedem AP-Teilnetz zu einer schleifenfreien Spannbaumtopologie zu organisieren. Das WLCCP ist im Allgemeinen unabhängig von dem darunter liegenden STP; deshalb ist das WLCCP mit anderen STPs, wie etwa dem PVST + STP von Cisco, kompatibel.
  • Das WLCCP-SCM-Bekanntmachungs- und -Registrierungsprotokoll wird verwendet, um einen WLCCP-Spannbaum in jedem Teilnetz aufzubauen, der an der Spitze jedes darunter liegenden (d. h., 802.1D) Spannbaums existieren kann. Der WLCCP-Spannbaum kann den darunter liegenden 802.1D Spannbaum mit Nicht-STP-Verbindungen zu drahtlosen Nicht-STP-"Repeater"-APs oder Nicht-STP-802.11-Brücken erweitern. In dem WLCCP-Spannbaum ist ein AP (z. B. ein Wurzel-AP, Repeater-AP oder eine 802.11-Brücke) ein innerer Knoten und ein MN ist ein Blatt.
  • Ein einzelnes primäres LAN befindet sich an der Wurzel des WLCCP-Spannbaums in jedem Teilnetz. Jedes Teilnetz besitzt einen einzelnen aktiven SCM. Definitionsgemäß ist das primäre LAN die Gruppe aus möglicherweise überbrückten, verdrahteten Ethernet-Segmenten, die direkt mit dem SCM verbunden sind. Andere sekundäre drahtlose Ethernet-LANs oder "Sekundäre LANs" sind mit dem primären LAN über drahtlose 802.11-Brückenverbindungen verbunden. [Ein primäres oder sekundäres LAN kann 802.11-Brücken enthalten, die am WLCCP nicht teilnehmen. Solche Nicht-WLCCP-802.11-Brücken sind für das WLCCP transparent.]
  • Ein Teilnetzkontrollbereich umfasst alle APS, die sich in demselben Teilnetz wie der jeweilige SCM und irgendwelche Client-Stationen befinden, die direkt oder indirekt mit diesen APs verbunden sind. Zum Beispiel umfasst er alle MNs, die mit diesen APs verbunden sind, selbst wenn ein MN einem anderen Teilnetz auf der Netzwerkschicht über ein VLAN-Trunking oder eine MIP-Tunnelung zugewiesen ist. Er umfasst auch alle ENs, die an den sekundären LANs angeschlossen sind, die mit dem primären LAN über Brücken verbunden sind.
  • Ein beispielhafter WLAN-Spannbaum 3500 für ein einzelnes Teilnetz ist in 35 gezeigt. Die 802.1D-STP-Verbindungen und STP APs sind mit 3502 bezeichnet. Drahtlose Verbindungen sind als gestrichelte Linien gezeigt.
  • Die primären und sekundären LANs können mehrere Ethernet-Segmente und 802.1D-Brücken und/oder -Switches umfassen. Die 802.1D-"Wurzel-Brücke" kann in entweder dem primären LAN oder in einem sekundären LAN enthalten sein. Ein primäres oder sekundäres Ethernet-LAN funktioniert wie eine logische, transparente Verbindung im Hinblick auf das WLCCP.
  • Der "primäre Port" in einem WLCCP AP ist derjenige Port, der für den Zugang zu dem primären LAN verwendet wird. Ein "Wurzel-AP" ist direkt mit dem primären LAN an seinem primären Ethernet-Port verbunden. Ein "sekundärer Port" ist jeder logische oder physikalische AP-Port außer dem primären Port. Ein primärer oder sekundärer Port kann ein Ethernet-Port oder ein 802.11-Port sein. Ein logischer 802.11-Port existiert für jede drahtlose AP-zu-AP-Verbindung. Ein logischer sekundärer BSS-Port stellt den Zugang zu 802.11- Stationen in dem lokalen BSS bereit. Der AP 3508 weist einen primären 802.11-Port und einen sekundären Ethernet-Port auf.
  • Es sei angemerkt, dass der 802.1D-Wurzel-Port in einem STP AP der gleiche wie der primäre Port sein wird, wenn, und nur dann, wenn die 802.1D-Wurzel-Brücke in dem primären LAN enthalten ist.
  • Ein einzelner "WLCCP-designierter AP" ist verantwortlich für das Bridging von Rahmen zu einem sekundären LAN. Der WLCCP-designierte AP für ein sekundäres Ethernet-Segment kann anders sein als die 802.1D-designierte Brücke für dasselbe Ethernet-Segment. Zum Beispiel ist der AP 3508 in 35 der "WLCCP-designierte AP" für das "sekundäre LAN". Wenn die 802.1D-Wurzel-Brücke in dem primären LAN enthalten ist, dann ist der AP 3508 auch die 802.1D-designierte Brücke für sein Ethernet-Segment in dem sekundären LAN. Ein WLCCP-designierter AP muß sein angeschlossenes sekundäres LAN bei dem SCM registrieren, um für das sekundäre LAN Weiterleitungs- und Flooding-Parameter auf drahtlosen Verbindungen zu erstellen.
  • In einem Ethernet-LAN erstellt ein "Rückwärtslernen" den Weiterleitungspfad zu verdrahteten Stationen und MNs in 802.1D-Brücken oder – Switches. Das VLAN-Tagging und das Rückwärtslernen erstellt den Weiterleitungspfad in einem Ethernet-VLAN. Das Rückwärtslernen ist nicht zuverlässig; deshalb müssen Unicast-Rahmen von einer transparenten Brücke, einem Switch oder einem AP "geflutet" (flooded) werden, wenn der Standort der Zieladresse unbekannt ist.
  • Unicast-Rahmen werden niemals in ein 802.11 BSS geflutet, weil sich 802.11-Stationen zuverlässig mit einem Vater-AP verbinden. Das Unicast-Flooding wird selektiv zu sekundären Ethernet-LANs aktiviert. Ein WLCCP-"Registrierungsprotokoll" wird verwendet, um zuverlässig den Weiterleitungspfad von dem primären LAN zu den 802.11-Stationen zu erstellen und sekundäre LANs auszuwählen. Deshalb ist es niemals notwendig, Unicast-Rahmen "abgehend" (d. h., von dem primären LAN aus) zu 802.11-Stationen zu fluten und sekundäre LANs auszuwählen. Das Unicast-Flooding wird immer an einem primären Port eines AP aktiviert. Standardmäßig werden Unicast-Rahmen "eingehend" in Richtung auf das primäre LAN weitergeleitet, wenn der Bestimmungsort unbekannt ist.
  • Das WLCCP-Registrierungsprotokoll wird auch dazu verwendet, Multicast-Gruppen-Mitgliedsschafts-Informationen zu dem primären LAN weiterzuleiten. Optional werden Multicast-Rahmen nur auf denjenigen sekundären Ports weitergeleitet, die verwendet werden, um Zugang zu Mitgliedern der Multicast-Gruppe zu erhalten, die von der jeweiligen Multicast-Zieladresse identifiziert werden. [Multicast-Kommunikationen zwischen 802.11-Stationen können optional verboten werden, um das Multicast-Flooding weiter einzuschränken.]
  • Ein "sekundäres LAN" existiert relativ zu jedem AP. Zum Beispiel ist das verdrahtete LAN in 35, das mit "sekundäres LAN" 3510 bezeichnet ist, nur ein sekundäres LAN von der Perspektive des AP 3512 und des AP 3514 aus. In einem einzelnen AP kann das "primäre LAN" als der Abschnitt des WLAN-Spannbaums betrachtet werden, auf den für Rahmen-Weiterleitungszwecke über den primären Port des AP zugegriffen wird. Zum Beispiel leitet der AP 3516 einen Rahmen zu dem primären LAN weiter, indem er einfach den Rahmen an seinem primären Port überträgt (z. B. zu dem Ethernet-LAN, das "sekundäres LAN" genannt wird). Die drahtlosen Verbindungen zu dem primären LAN sind im Allgemeinen transparent für den AP 3516.
  • Das 802.1D STP sollte in drahtlosen Verbindungen betrieben werden, die verwendet werden, um verdrahtete STP LANs zu überbrücken. In 35 sollte das 802.1D STP zum Beispiel in den drahtlosen Verbindungen zwischen den APs 3512, 3514 und 3508 betrieben werden, wenn das sekundäre LAN 802.1D-Brücken/-Switches enthält. Der AP 3518 ist mit einem STP AP, nämlich dem AP 3520, auf einer Nicht-STP-Leitung verbunden.
  • Der WLAN-Spannbaum kann drahtlose Nicht-STP-Verbindungen zu drahtlosen Nicht-STP-Repeater-APs und "Work-Group Bridges" (WGB; Arbeitsgruppenbrücken) enthalten. Nicht-STP-Repeater-APs und WGBs sind an dem WLAN-Spannbaum in ziemlich ähnlicher Weise wie 802.11 MNs angeschlossen.
  • Standardmäßig ist ein AP an dem Netz an einem primären "Normalzugangs"-Port angeschlossen. Ein AP kann optional mit dem Netz an einem primären VLAN-Trunk-Port angeschlossen sein, so dass ein einziger 802.11 BSS MNs von mehreren VLANs umfassen kann.
  • Eine benutzerkonfigurierbare "WLCCP-Portmodus"-Variable wird auf einen der folgenden Werte für jeden AP-Port gesetzt:
    • a) Sohnmodus. Der Sohnmodus ist der Standard an dem AP-Ethernet-Port.
    • b) Vatermodus.
    • c) Vater-/Sohnmodus. Der Vater-/Sohnmodus ist der Standard an den 802.11-Ports.
  • Ein AP-Port, der in einem "Sohnmodus" konfiguriert ist, kann nur als der primäre WLCCP-Port fungieren. Ein AP-Port, der in einem "Vatermodus" konfiguriert ist, kann nur als ein sekundärer WLCCP-Port fungieren. Ein 802.11-"Vater"-Port erzeugt Beacons und akzeptiert Stationsverbindungen. Ein 802.11-"Sohn"-Port verbindet sich mit einem 802.11-"Vater"-Port.
  • Ein 802.11-Port, der in einem "Vater-/Sohnmodus" konfiguriert ist, kann sowohl als ein "Vater"-Port als auch als ein "Sohn"-Port funktionieren (d. h., als ein Repeater-Port). Ein Ethernet-Port, der in einem "Vater-/Sohnmodus" konfiguriert ist, kann als ein sekundärer "Vater"-Port in einer Sohn-802.11-Brücke oder als ein primärer "Sohn"-Port in einem verdrahteten AP oder einer verdrahteten Brücke funktionieren. Der Vater-/Sohnmodus ist dafür gedacht, eine selbstkonfigurierende Teilnetztopologie zu ermöglichen.
  • Ein Port (oder Ports) in einem "nicht angeschlossenen AP", der in einem Sohnmodus oder einem Vater-/Sohnmodus konfiguriert ist, scannt nach einem potentiellen Vater-AP oder -SCM. Ein AP wählt automatisch einen "primären Port" und einen Vaterknoten aus, die den "besten" (d. h., kostengünstigsten) Pfad zu dem primären LAN bereitstellen. Alle anderen Ports mit Ausnahme des primären Ports sind ein "sekundärer Port" eines AP.
  • Der Benutzer kann eine "Vater-AP-Liste" für einen Sohn-802.11-Port konfigurieren, um potentielle Vater-APs zu begrenzen. Es sei angemerkt, dass ein Benutzer eine AP-zu-AP-Verbindung explizit konfigurieren kann, indem er eine "Vater-AP-Liste" mit einem einzigen Eintrag konfiguriert.
  • Ein Vater-/Sohn-Port in einem angeschlossenen AP arbeitet folgendermaßen: a) er arbeitet in einem "Sohn"-Modus, wenn er der primäre Port ist. b) Er arbeitet in einem "Vater"-Modus, wenn er ein sekundärer Port ist. c) Ein physikalischer Funk-Port in einem angeschlossenen Repeater-AP arbeitet sowohl in dem Vatermodus als auch in dem Sohnmodus, wobei der einzelne Port sowohl einen logischen primären Uplink-Port als auch einen oder mehrere logische Downlink-Ports bereitstellt.
  • Ein "Wurzel-AP" betreibt seinen primären Ethernet-Port immer im Sohnmodus und seine sekundären Funk-Ports im "Vatermodus". Standardmäßig besitzt ein AP keine Ethernet-Verbindung, die als ein "Repeater" arbeitet, weil der Standard-802.11-Port-Modus der "Vater-/Sohnmodus" ist.
  • Eine "Sohn-802.11-Brücke" betreibt ihren primären Funk-Port immer im "Sohn"- oder "Vater-/Sohn"-Modus und ihren sekundären Ethernet-Port im "Vatermodus". Es sei angemerkt, dass ein AP nur dann als eine Sohn-802.11-Brücke fungieren kann, wenn sein Ethernet-Port explizit im "Vater"-Modus oder im "Vater-/Sohn"-Modus konfiguriert ist.
  • Beim Starten "scannt" ein nicht angeschlossener AP anfänglich nach SCM-Bekanntmachungs-Informationen, um den SCM zu entdecken und um den besten Pfad zu dem primären [AN zu bestimmen. Der AP wählt dann einen Vaterknoten und einen primären Port aus, welche den besten Pfad bereitstellen, und registriert sich bei dem SCM.
  • Pfadkosteninformationen sind in den SCM-Bekanntmachungs-Nachrichten und in 802.11-Beacon- und Probe-Antwort-Nachrichten enthalten, die an den AP-Ports empfangen werden, die in dem Sohnmodus oder in dem Vater-/Sohnmodus konfiguriert sind. Ein AP akzeptiert nur SCM-Bekanntmachungen mit einer "passenden" Teilnetz-ID und akzeptiert nur Beacon- und Probe-Antwort-Nachrichten mit einer passenden Teilnetz-ID und übereinstimmender WLCCP SSID.
  • Ein AP stellt sofort fest, dass er ein "Wurzel"-AP ist, wenn er SCM-Bekanntmachungs-Nachrichten an seinem Ethernet-Port empfängt, bei denen das Preferred SCM Flag auf EIN gesetzt ist und eine Hop-Zählung auf Null gesetzt ist. Der Vater-SWAN-Knoten für einen Wurzel-AP ist der lokale SCM. Ein Wurzel-AP wählt sofort den Ethernet-Port als seinen "primären Port" aus und registriert sich bei dem SCM. Nachdem er sich erfolgreich registriert hat, erzeugt er SCM-Bekanntmachungen an jedem seiner sekundären Ports.
  • Standardmäßig wählt ein Nicht-Wurzel-AP (d. h., ein AP, der nicht direkt an dem primären LAN angeschlossen ist) einen primären Port und einen Vater-AP aus, die den "besten" Pfad zu dem primären LAN bereitstellen, wobei der beste Pfad der kostengünstigste Pfad mit einer akzeptablen Signalqualität ist. Ein Nicht-Wurzel-AP registriert sich bei der SWAN-Infrastruktur über seinen ausgewählten "Vater-AP" an seinem ausgewählten primären Port.
  • Ein AP kann SCM-Bekanntmachungsnachrichten an seinem Ethernet-Port empfangen, bei denen das Preferred SCM Flag auf AUS gesetzt ist. In diesem Fall sollte der AP für einen willkürliches Zeitraum an jedem Port, bei dem der "Sohnmodus" aktiviert ist, Ausschau nach einem SCM mit einer höheren Priorität halten. Der AP arbeitet als ein Wurzel-AP, wenn er keinen SCM mit einer höheren Priorität entdeckt. Ein AP kann eine SCM-Bekanntmachung von einem Reserve-CM empfangen, weil 1) der bevorzugte SCM ausgefallen ist, oder 2) die verdrahtete Netztopologie bruchstückhaft ist. Für den letzteren Fall ist das Scannen nach einem SCM mit einer höheren Priorität für eine Topologiekonvergenz notwendig.
  • Ein SWAN-AP kann optional das 802.1S-Spannbaumprotokoll (STP) ausführen. Die SWAN-Operation mit STP APs wird weiter unten erörtert.
  • Eine Sohn-802.11-Brücke ist die WLCCP-designierte Brücke für ein sekundäres Ethernet-LAN. Eine Sohn-802.11-Brücke ist verantwortlich für das Anschließen des sekundären LAN und von angeschlossenen sekundären Ethernet-Knoten an dem primären LAN. Das Unicast-Flooding und das Multicast-Flooding zu dem sekundären LAN werden lokal an der designierten Brücke aktiviert bzw. deaktiviert. Unicast- und Multicast-Flooding-Anforderungen werden eingehend zu dem primären LAN weitergereicht.
  • Eine Nicht-STP-Sohn-802.11-Brücke ist mit einer Brückenpriorität konfiguriert. Die Brückenpriorität wird verwendet, um die WLCCP-designierte Brücke auszuwählen, wie dies unten in dem Abschnitt mit dem Titel "Auswahl der WLCCP-designierten Brücke" beschrieben ist, wenn mehr als eine Sohn-Brücke an einem sekundären LAN angeschlossen ist.
  • Eine benutzerkonfigurierte Ethernet-Adressenliste kann an einem AP-Ethernet-Port konfiguriert werden. Die Ethernet-Adressenliste enthält eine Liste von statischen 802-Adressen, wobei jede Adresse eine Station identifiziert, auf die über den Ethernet-Port zugegriffen wird. [Die Liste kann über Standard-802.1D-Konfiguriationsoptionen konfiguriert werden, die die Erzeugung von "statischen" Datenbankeinträgen unterstützen.] Eine Sohn-802.11-Brücke schließt Adressen in der Liste und andere dynamisch gelernte Adressen an das primäre LAN an.
  • Eine Work Group Bridge (WGB) ist ein spezieller Fall einer Sohn-802.11-Brücke mit den folgenden Konfigurationseinstellungen:
    • 1) Der Ethernet-Port ist in einem "Vater"-Modus konfiguriert.
    • 2) Die 802.11-Ports sind in einem "Sohn"-Modus konfiguriert.
    • 3) Das Unicast-Flooding ist an dem Ethernet-Port deaktiviert.
    • 4) Eine WGB führt nicht das STP aus. [Eine WGB kann Zugang zu einem sekundären LAN bereitstellen, das Teil eines mobilen Netzes ist (z. B. ein LAN in einem Fahrzeug, das Teil eines größeren mobilen Netzes ist). Auf Grund der häufigen Topologieänderungen ist es nicht praktisch, das Standard-802.1D STP in einer mobilen Brücke auszuführen.]
  • Eine WGB muß eine WLCCP_SEC_LAN_ADDR_LIST TLV in ihren WLCCP-Registrierungsanfragen-Aufzeichnungen enthalten. Die TLV enthält eine Liste von 802-Adressen, wobei jede Adresse eine Ethernet-Station in dem Ethernet-LAN identifiziert, das an dem sekundären Ethernet Port der WGB angeschlossen ist.
  • Das Auswahlprotokoll für die WLCCP-designierte Brücke ermöglicht es, dass zwei oder mehr redundante WGBs an einem sekundären Work Group LAN angeschlossen werden können.
  • Es sei angemerkt, dass der Ethernet-Port an einer WGB in einem "Vater"-Modus konfiguriert ist; deshalb kann eine WGB an ihrem Ethernet-Port keinen Anschluss an das SWAN-Netz bereitstellen – selbst wenn sie einen kostengünstigeren Pfad bereitstellen könnte.
  • Ein "alter Pfad" zu einem Knoten muß gelöscht werden, wenn 1) der Knoten zu einem neuen Vater-AP oder -CM roamt, 2) der Knoten von einem Netzwerkadministrator "deaktiviert" wird, oder 3) die Verbindung des Knotens physisch von dem Netz getrennt wird. Für die ersten zwei Fälle erzeugt ein CM eine "Deregistrierungsanfrage", um den alten Pfad zu löschen. Für den dritten Fall erzeugt der Vaterknoten eine "Abtrennanfrage", um den alten Pfad zu löschen.
  • Das WLCCP-Registrierungs-/-Deregistrierungs-/Abtrenn-Protokoll ist so strukturiert, dass es "abgetrennte Pfadfragmente" verhindert. Eine Registrierungsantwort mit einem "guten" Statuscode erstellt eine Pfadinstanz für einen "Anfragender-Knoten", während sie abgehend von dem gemeinsamen CM aus zu dem Anfragender-Knoten weitergeleitet wird. Pfadinstanzen werden in der umgekehrten Richtung gelöscht. Eine Pfadinstanz wird gelöscht, wenn eine Deregistrierungsantwort- oder Abtrennanfrage-Nachricht eingehend weitergeleitet wird.
  • – Deregistrierungsanfragen.
  • Ein CM "deregistriert" jegliche alte Pfadinstanz (beendet eine Registrierung einer alten Pfadinstanz), wenn 1) eine neue Pfadinstanz für einen Knoten, der geroamt ist, erstellt wird, oder 2) ein Netzwerkadministrator einen Knoten "deaktiviert". Ein CM sendet eine Deregistrierungsanfrage-Nachricht, bei der das Response-Req Flag auf EIN gesetzt ist, abgehend auf dem alten Pfad, um eine Deregistrierungsantwort-Nachricht abzurufen. Die Deregistrierungsantwort wird eingehend (mit einem Hopwise Routing, wenn die L2-Pfadaktualisierungen aktiviert sind) weitergeleitet, bis sie den Absender erreicht. Die alte Pfadinstanz wird in jedem Knoten gelöscht, wenn die eingehende Deregistrierungsantwort empfangen wird; deshalb wird der äußerste abgehende Abschnitt der alten Pfadinstanz als erster gelöscht.
  • Der CM, der der "am nächsten liegende gemeinsame Vorgänger" ist, ist verantwortlich für ein zuverlässiges Deregistrieren einer alten Pfadinstanz eines Knotens, wenn der Knoten roamt. Der am nächsten liegende gemeinsame Vorgänger-CM wird als der "gemeinsame CM" bezeichnet.
  • Ein gemeinsamer CM deregistriert nur gebundene Pfadinstanzen für Nachfolgerknoten (d. h., Pfadinstanzen, bei denen eine gebundene DPR vorliegt). Eine Deregistrierungsanfrage und die entsprechende Antwort enthalten die Pfad-ID der alten gebundenen Pfadinstanz. Der gemeinsame CM ist immer der "Absende" in den Deregistrierungsanfrage-/-antwort-Nachrichten.
  • Ein CCM deregistriert eine alte Pfadinstanz für einen Knoten, indem er eine Deregistrierungsanfrage zu dem "alten" LCM sendet, wobei hier der alte LCM der "Antwortende" ist. Ein LCM deregistriert eine alte Pfadinstanz, indem er eine Deregistrierungsanfrage zu dem alten SCM sendet, wobei hier der SCM der Antwortende ist. Ein SCM deregistriert den Pfad zu einem MN oder Sohn-AP, indem er eine Deregistrierungsanfrage zu dem "alten" Vater-AP sendet, wobei hier der alte Vater-AP der Antwortende ist.
  • Der gemeinsame CM überträgt eine Deregistrierungsanfrage erneut, bis er eine Deregistrierungsantwort mit einer passenden Nachrichten-ID empfängt. Ein gemeinsamer CM muß Deregistrierungs-Zustandsinformationen für eine "alte" Pfadinstanz aufrecht erhalten, bis er eine passende Antwort empfängt oder bis die maximale Anzahl an erneuten Deregistrierungsversuchen überschritten ist. Andere Nachfolger-APs oder -CMs in dem alten Pfad müssen KEINE Deregistrierungs-Zustandsinformationen aufrecht erhalten.
  • Eine Deregistrierungsanfrage wird immer zu dem direkten Vater des Zielknotens weitergeleitet, falls dies möglich ist. Der direkte Vater muß die Deregistrierungsantwort erzeugen, wenn er eine Deregistrierungsanfrage empfängt.
  • Wenn ein Zwischen-CM eine Deregistrierungsanfrage empfängt, muß er zuerst bestimmen, ob er eine DPR für die Pfadinstanz besitzt, die von der Zielknoten-ID und der Pfad-ID identifiziert ist. Wenn er KEINE solche DPR besitzt, dann muß er eine Deregistrierungsantwort zurücksenden. Anderenfalls muß er die Anfrage abgehend zu dem direkten Vater weiterleiten. Bevor die Anfrage weitergeleitet wird, muß ein LCM zuerst den Antwortenden auf den alten SCM ändern; ein SCM muß zuerst den Antwortenden auf den alten Vater-AP ändern. Ein Zwischen-CM muß das Pfad-ID-Feld aktualisieren, um die abgehende oder die eingehende Pfadinstanz zu identifizieren, bevor er eine Deregistrierungsanfrage- oder -antwort-Nachricht zu einem Sohn-CM oder Vater-CM weiterleitet.
  • Ein Zwischen-AP muß eine Deregistrierungsanfrage zu dem Next-Hop-AP in dem abgehenden Pfad zu dem direkten Vater-AP (d. h. dem Antwortenden) weiterleiten, wenn ein solcher Next-Hop-AP existiert. Anderenfalls muß ein Zwischen-AP eine Deregistrierungsantwort mit einem Fehlerstatus erzeugen, wenn ein solcher Next-Hop-AP nicht existiert. Es sei angemerkt, dass sich ein AP sowohl in dem alten als auch auf dem neuen Pfad befindet, wenn ein MN zwischen Sohn-APs in seinem Unterbaum roamt.
  • Es ist möglich, dass der Anschluss eines "alten Vaterknotens" getrennt werden wird, bevor eine alte Pfadinstanz deregistriert ist. In diesem Fall wird der alte Vaterknoten (AP oder CM) deregistriert werden, wenn der CM eine alte Pfadinstanz nicht erfolgreich löschen kann, und der gesamte Unterbaum, der an dem alten Vaterknoten wurzelt, wird gelöscht werden.
  • Ein AP oder CM muß eine "gebundene DPR" für einen Knoten löschen, wenn er eine Deregistrierungsantwort für den Knoten mit einer passenden Knoten-ID und einer passenden oder "neueren" Pfad-ID empfängt. Ein AP muß auch eine DPR für einen Knoten löschen, wenn er eine Registrierungsantwort mit einer "neueren" Pfad-ID empfängt. Die entsprechende DRR kann gelöscht oder optional in eine IRR umgewandelt werden.
  • Eine DPR enthält die Nachrichten-ID der letzten empfangenen Registrierungsanfrage für die jeweilige Pfadinstanz. Wenn ein gemeinsamer CM eine defekte anfängliche Registrierungsanfrage empfängt, wird er eine Deregistrierungsanfrage erzeugen, die die Registrierungs-Nachrichten-ID enthält. Ein AP oder CM muß eine "nicht gebundene" DPR löschen, wenn er eine Deregistrie rungsanfrage mit einer passenden Registrierungs-Nachrichten-ID empfängt. Eine "gebundene" DPR darf er NICHT löschen.
  • Nicht gebundene DPRs (d. h., die nicht in den gebundenen Zustand übergehen) werden schnell gealtert und verworfen; deshalb ist es nicht notwendig, ein nicht gebundenes Pfadsegment explizit zu löschen.
  • Eine falsche Übergangspfadinstanz für einen schnell roamenden MN wird existieren, wenn Registrierungsanfrage-Nachrichten für den MN an dem CM nicht sequentiell ankommen. In diesem Fall wird der CM den korrekten Pfad zu dem MN mit einer Deregistrierungsanfrage löschen. Der Vater-AP des MN muß den MN abmelden, wenn er die Deregistrierungsanfrage empfängt. Deshalb wird schnell eine korrekte Pfadinstanz erstellt, wenn sich der MN neu verbindet.
  • – Abtrennanfragen.
  • Ein "Vater"-Knoten erzeugt eine Abtrennanfrage, um die Pfadinstanz für einen "Sohn" zu löschen, wenn die Verbindung zu dem Sohn "getrennt" wird. Eine Abtrennanfrage wird aus den folgenden Gründen erzeugt: 1) Ein Vater-AP erzeugt eine Abtrennanfrage für eine Sohn-802.11-Station, wenn die Station "abgemeldet ", also die Verbindung der Station "beendet" wird; 2) ein Vaterknoten (AP oder CM) erzeugt eine Abtrennanfrage für einen Sohnknoten (MN, AP oder CM), wenn er nicht mehr länger mit dem Sohnknoten kommunizieren kann, oder 3) ein Vaterknoten erzeugt eine Abtrennanfrage für einen Sohnknoten, wenn er die DPR für den Sohnknoten verwirft (d. h., weil die Registrierungslebenszeit abgelaufen ist, bevor die DPR aufgefrischt wurde). [Theoretisch kann auch ein AP oder ein CM eine Abtrennanfrage bezüglich seiner Trennung von dem Netz erzeugen.]
  • Der Absender einer Abtrennanfrage ist der Vaterknoten des getrennten Sohnknotens. Der Antwortende ist immer der Vater-CM des Vaterknotens. Der Anfragende ist der abgetrennte Sohnknoten.
  • Eine Abtrennanfrage wird (erneut) übertragen, bis der Absender eine passende Abtrennantwort empfängt. Die Abtrennanfrage wird verwendet, um den Registrierungszustand in jedem AP und CM auf dem Pfad zu dem CCM in "nicht gebunden" zu ändern. Eine Abtrennanfrage enthält die Pfad-ID für die Pfadinstanz. Wenn ein AP oder ein SCM eine Abtrennanfrage für einen MN empfängt, setzt er den DPR-Zustand auf "nicht gebunden", wenn die Pfad-ID in der DPR nicht "neuer" als die Pfad-ID in der Abtrennanfrage ist. Der DPR-Zustand wird in einem Vater-AP sofort auf "nicht gebunden" gesetzt, wenn die Verbindung einer Station getrennt wird.
  • Das Pfad-ID- und Antwortender-Feld muß aktualisiert werden, wenn eine Abtrennanfrage eingehend weitergeleitet wird, genau so, wie dies bei einer eingehenden Deregistrierungsantwort der Fall ist.
  • Unterbaumlöschung
  • Wenn ein "angeschlossener" AP von dem SWAN-Topologiebaum abgetrennt wird, dann müssen der AP und jeder Knoten in dem Unterbaum, der an dem AP wurzelt, zuverlässig in den "nicht angeschlossenen" Zustand übergehen.
  • Es gibt zwei allgemeine Fälle:
    • 1) Ein Vater-AP oder -SCM kann einen Sohnknoten "abtrennen".
    • 2) Ein "angeschlossener" Sohnknoten kann selbständig in den "nicht angeschlossenen" Zustand übergehen.
  • Fall 1: Ein Vater-AP oder -CM trennt einen Sohnknoten asynchron ab, wenn a) die DPR für den Sohnknoten gealtert und verworfen wird, b) der Vater nicht mehr länger mit dem Sohn kommunizieren kann, oder c) eine administrative Deregistrierungsanfrage für den Sohn empfangen wird. Wenn ein Vaterknoten einen Sohn-AP löscht, dann müssen der Sohn-AP und der gesamte Unterbaum, der an dem AP wurzelt, zuverlässig in den nicht angeschlossenen Zustand übergehen.
  • Wenn eine DPR gealtert und verworfen wird, dann wird garantiert, dass der Sohn-AP bereits in den nicht angeschlossenen Zustand übergegangen ist und keine weitere Aktion benötigt wird.
  • Ein Vater-AP kann einen 802.11-Sohn in seinem BSS einfach dadurch abtrennen, dass der Zustand des 802.11-Sohnes in den nicht verbundenen Zustand gewechselt wird und optional eine Verbindungstrennungs-(oder Authentifizierungsbeendigungs-)Nachricht zu der Station gesendet wird. Im schlimmsten Fall wird der Sohnknoten entdecken, dass er nicht angeschlossen ist, wenn er versucht, einen Uplink-Rahmen zu senden.
  • Wenn ein Vater-SCM oder -AP einen Sohn-AP abtrennt, der an einem sekundären Ethernet-Port angeschlossen ist, dann muß er die Knoten-ID und die Pfad-ID des Sohn-AP in einer WTLV_DELETED_MODE_LIST TLV in den SCM-Bekanntmachungs-Antwortnachrichten bekannt geben, die an dem sekundären Ethernet-Port übertragen werden. Die Knoten-ID des abgetrennten AP muß für eine gewisse Schwellenwertzeitdauer, oder bis sich der AP erneut registriert, bekannt gegeben werden. Es wird garantiert, dass der Sohn-AP in den nicht angeschlossenen Zustand übergehen wird, wenn er entweder a) alle SCM-Bekanntmachungs-Antwortnachrichten von seinem Vater in einer gewissen kleinen Schwellwertzeitdauer verpasst, oder wenn er b) seine Knoten-ID in einer Liste gelöschter Knoten entdeckt.
  • Fall 2: Ein "angeschlossener" Sohnknoten geht in den "nicht angeschlossenen" Zustand über, wenn er a) die Verbindung zu seinem Vater verliert; b) entdeckt, dass sein Vaterknoten in den nicht angeschlossenen Zustand übergegangen ist; c) eine neue Vater-"Instanz" entdeckt; oder d) seine Knoten-ID und gegenwärtige Pfad-ID in einer Liste abgetrennter Knoten in einer Bekanntmachungsnachricht zu finden sind.
  • Jeder SWAN CM muß ein internes "Instanzalter" verwalten, wie dies in dem Abschnitt mit dem Titel "Topologie-Zustandsinformationen" beschrieben ist. Das Instanzalter wird in das Instanzalter-Feld in Bekanntmachungsantwort-Nachrichten eingegeben. Das Instanzalter eines Knotens wird jedes Mal dann auf '0' initialisiert und auf '0' zurückgesetzt, wenn der Knoten in den nicht angeschlossenen Zustand übergeht.
  • Ein AP muß eine interne "Anschlußzählungs"-Variable verwalten, die jedes Mal dann auf '0' initialisiert wird und inkrementiert wird, wenn sich der AP anfänglich bei dem SCM registriert. Die Anschlusszählung wird in das Anschlußzählungs-Feld in den SCM-Bekanntmachungsantwort-Nachrichten kopiert, die an den sekundären Ports des AP übertragen werden.
  • Ein Sohnknoten muß das Instanzalter seines Vater-CM abspeichern. Ein Nicht-Wurzel-AP muß auch die Anschlusszählung seines Vater-AP abspeichern. Ein angeschlossener Knoten geht in den nicht angeschlossenen Zustand über, wenn er eine Bekanntmachungsantwort-Nachricht von seinem Vaterknoten mit einem niedrigeren Instanzalter empfängt (z. B. weil der Vaterknoten neu gestartet hat). Ein Nicht-Wurzel-AP geht auch in den nicht angeschlossenen Zustand über, wenn er eine Bekanntmachungsantwort mit einer unterschiedlichen Anschlusszählung empfängt. Es sei angemerkt, dass ein SCM seinen gesamten Unterbaum direkt oder indirekt löschen kann, indem er eine SCM-Bekanntmachungsnachricht mit einem niedrigeren Instanzalter-Wert überträgt.
  • Ein Sohn-AP muß auch eine Variable verwalten, die die aktuelle Anschlusszählung seines Vater-AP enthält. Ein Sohn-AP muß in den nicht angeschlossenen Zustand übergehen, wenn er eine Bekanntmachungsantwort von seinem Vater-AP mit einer anderen Anschlusszählung empfängt (z. B. weil der Vater-AP geroamt ist).
  • Wenn ein SCM in den nicht angeschlossenen Zustand übergeht, muß er a) eine außerplanmäßige Multicast-SCM-Bekanntmachungs-Antwortnachricht, bei der das Unattached Flag auf EIN gesetzt ist, sowie eine unbegrenzte Pfadkosten und Hop-Zählung senden und 2) alle DPRs löschen.
  • Wenn ein angeschlossener AP in den nicht angeschlossenen Zustand übergeht, muß er: a) eine außerplanmäßige Multicast-SCM-Bekanntmachungs-Antwortnachricht, bei der das Unattached Flag auf EIN gesetzt ist, sowie eine "unbegrenzte" Pfadkosten und Hop-Zählungan jedem sekundären Ethernet-Port senden, b) bei allen Sohn-802.11-Stationen die Verbindung beenden, c) alle DPRs löschen, d) das Beaconing an 802.11-Ports stoppen, und 3) das Scannen nach einem neuen Vater-SCM oder -AP initiieren. Der AP "beendet die Verbindungen" der 802.11-Stationen, indem er den 802.11-Zustand in "nicht authentifiziert und nicht verbunden" ändert; er braucht keine 802.11-Verbindungstrennungsanfrage an jede Sohnstation senden.
  • Ein AP muß für eine Haltezeitdauer (d. h., 5 Sekunden) in dem nicht angeschlossenen Zustand bleiben, bevor er sich bei einem neuen Vater-AP registriert, um zu gewährleisten, dass alle Sohn-802.11-Stationen verbindungsmäßig abgetrennt worden sind, und um Registrierungsanfragen in einer nichtsequentiellen Reihenfolge zu verhindern.
  • W2 – SCM-Unterbaumlöschung.
  • Wenn ein "angeschlossener" SCM von seinem Vater-LCM abgetrennt wird, dann geht er in den selbständigen Teilnetzmodus über. Der Unterbaum, der an dem SCM wurzelt, wird NICHT gelöscht, wenn der SCM von dem lokalen Infrastrukturmodus in den selbständigen Teilnetzmodus übergeht; deshalb darf der SCM sein Instanzalter NICHT zurücksetzen.
  • Der Unterbaum, der an dem SCM wurzelt, der in dem selbständigen Modus arbeitet, muß gelöscht werden, wenn der SCM in den lokalen Infrastrukturmodus übergeht. Deshalb muß ein selbständiger SCM sein Instanzalter zurücksetzen, nachdem er sich anfänglich bei einem neuen Vater-LCM registriert hat.
  • Wenn ein "angeschlossener" LCM von dem CCM getrennt wird, dann geht er in den lokalen selbständigen Modus über. Der Unterbaum, der an dem LCM wurzelt, wird NICHT gelöscht, wenn der LCM von dem Campus-Infrastrukturmodus in den lokalen selbständigen Modus übergeht; deshalb darf der LCM sein Instanzalter NICHT zurücksetzen.
  • Der Unterbaum, der an dem LCM wurzelt, welcher im selbständigen Modus arbeitet, muß gelöscht werden, wenn der LCM in den Campus-Infrastrukturmodus übergeht. Deshalb muß ein selbständiger LCM sein Instanzalter zurücksetzen, nachdem er sich anfänglich bei dem CCM registriert.
  • W2 – LCM-Pfadauthentifizierung.
  • In einem Campus-Infrastrukturmodus muß ein nicht angeschlossener LCM eine Pfad-Init-Anfrage zu dem CCM senden, nachdem er sich anfänglich authentifiziert, um eine Pfadauthentifizierung zu initiieren. Die Pfadauthentifi zierung ist ausführlich in dem Abschnitt mit dem Titel "Infrastruktur-Pfadauthentifizierung" beschrieben.
  • W2 – LCM-Registrierung.
  • Ein LCM sendet eine "anfängliche" Registrierungsanfrage zu dem CCM, nachdem er die Pfadauthentifizierung erfolgreich vollendet hat. Der CCM sendet eine anfängliche Registrierungsantwort-Nachricht zurück. Der LCM muß periodisch "Aktualisierungs"-Registrierungsanfrage-Nachrichten erzeugen, um seine Registrierungsbindungen in dem CCM aufzufrischen. Der CCM sendet eine Aktualisierungs-Registrierungsantwort-Nachricht zurück, um die Registrierungsanfrage zu bestätigen.
  • W2 – SCM-Operation.
  • – Vater-LCM-Zuweisung.
  • Ein SCM muß eine Kontextanfragenachricht mit einer "Anfrage"-WTLV_PARENT_CM TLV zu dem CCM beim Start und auch immer dann senden, wenn seine Verbindung zu einem zugewiesenen LCM verloren geht. Der CCM ermittelt den Vater-LCM des SCM aus der Gruppe von registrierten LCMs, wenn er die Kontextanfrage empfängt. [Der Benutzer muß LCM-/Teilnetz-Bindungen in dem CCM konfigurieren. Für Redundanzzwecke kann ein Benutzer primäre oder Ersatz-LCMs für jedes Teilnetz konfigurieren. Standardmäßig kann der LCM, der zusammen mit dem CCM angeordnet ist, als der Ersatz für defekte LCMs funktionieren. Der CCM weist einen SCM einem aktiven LCM zu, wenn das Teilnetz des SCM dem LCM zugewiesen ist.] Der CCM sendet eine Kontextantwort mit einer Nicht-Null-WTLV_PARENT_CM TLV zurück, um den SCM explizit einem Vater-LCM zuzuweisen. Anderenfalls sendet der CCM eine Null-WTLV_PARENT_CM TLV zurück, um den SCM anzuleiten, in einem selbständigen Teilnetzmodus zu arbeiten. Eine Nicht-Null-TLV enthält die Knoten-ID und die IP-Adresse des zugewiesenen Vater-LCM. Der SCM muß dann eine Pfadauthentifizierung durchführen und sich bei seinem zugewiesenen Vater-LCM registrieren.
  • Wenn ein SCM nicht mit einem Vater-LCM kommunizieren kann und er nicht mit seinem zugewiesenen CCM kommunizieren kann, dann muß er in einem selbständigen Modus arbeiten. Aber der SCM muß periodisch versuchen, die Kommunikationen mit dem CCM erneut herzustellen.
  • Der CCM wird eine Null-WTLV_PARENT_CM TLV (d. h., mit einer Knoten-ID von '0') zurücksenden, um einen SCM anzuweisen, in einem selbständigen Modus zu arbeiten.
  • Ein SCM muß den Prozess wiederholen, um seinen (d. h., neuen) Vater-LCM zu ermitteln, wenn er in den nicht angeschlossenen Zustand übergeht. Ein angeschlossener SCM geht in den nicht angeschlossenen Zustand über, wenn er a) die Verbindung zu seinem Vater-LCM verliert, b) sich nicht erfolgreich bei seinem Vater-LCM registrieren kann, c) eine neue Instanz des CCM oder seines Vater-LCM entdeckt, oder d) eine gültige administrative Deregistrierungsanfrage empfängt. Wenn ein angeschlossener SCM von seinem Vater-LCM getrennt wird, muß er eine Kontextanfrage an den CCM senden, welche eine Nicht-Null-"Anfrage" und WTLV_PARENT_CM TLVs enthält. Die "Anfrage"-TLV enthält die Knoten-ID und die IP-Adresse des "alten Vater-LCM". Wenn der SCM seine Verbindung zu dem Vater-LCM verloren hat, dann muß er auch eine WTLV_LOST_LINK TLV in die Kontextanfrage mit aufnehmen. Wie vorher, umfasst der CCM jeweils eine Null- oder Nicht-Null-WTLV_PARENT_CM TLV in der Kontextantwort, um entweder den SCM anzuweisen, in einem selbständigen Modus zu arbeiten, oder um den SCM einem Vater-LCM zuzuweisen.
  • W2 – AP-Operation.
  • W2 – AP-Zustandsvariable.
  • Die AP-Zustandsvariablen für die W2-Implementierung sind in dem Abschnitt mit dem Titel "Allgemeine AP-Zustandsvariable" beschrieben, mit einer Ausnahme. Der AP muß eine Registrierungstabelle mit Aufzeichnungen verwalten, die Weiterleitungs- und Pfadzustandinformationen enthalten, wie sie in dem Abschnitt mit dem Titel "W2-Registrierungsaufzeichnungen" beschrieben sind.
  • W2 – AP-Pfadauthentifizierung.
  • Ein AP muß eine Pfadauthentifizierung initiieren, nachdem er sich erfolgreich authentifiziert hat, um einen geheimen Kontexttransferschlüssel (CTK) mit jedem seiner Vorgänger zu erstellen. Die AP-Pfadauthentifizierung in der W2-Implementierung ist so, wie sie oben in dem Abschnitt mit dem Titel "Allgemeine AP-Pfadauthentifizierung" beschrieben ist.
  • W2 – AP-Registrierung.
  • Ein nicht angeschlossener AP führt einen Scan bezüglich eines potentiellen Vater-SCM oder -AP an jedem seiner Ports durch, die in einem Sohnmodus oder Vater-/Sohnmodus konfiguriert sind. [Es sei angemerkt, dass ein angeschlossener AP in den nicht angeschlossenen Zustand übergeht, wenn er eine neue Instanz seines Vater-AP oder -SCM entdeckt.] Ein nicht angeschlossener AP oder CM muß eine anfängliche Registrierungsanfrage zu seinem ausgewählten Vaterknoten an seinem ausgewählten primären Port senden, um das Anschließen an das Netz anzufordern. In der anfänglichen Registrierungsanfrage und der entsprechenden Antwort ist der Absender der nicht angeschlossene AP; der Anfragende ist ebenfalls der nicht angeschlossene AP; und der Antwortende ist der ausgewählte Vaterknoten (d. h., Vater-AP oder -SCM).
  • Die Felder in einer anfänglichen Registrierungsanfrage, die von einem nicht angeschlossenen AP gesendet wird, sind wie unten beschrieben gesetzt. (Nicht spezifizierte Felder werden auf '0' gesetzt).
  • WLCCP-Header-Felder:
    • Typ – 3
    • Absender – Knoten-ID des nicht angeschlossenen AP.
    • Antwortender – Knoten-ID des ausgewählten Vaterknotens (Vater-AP oder Vater-SCM).
    • Response-Req Flag – '1' zum Abrufen einer Antwort.
    • Inbound Flag – '1'.
    • Hopwise-Routing Flag – '1'
    • TLV-Flag – '1' (die Anfrage muß eine WTLV_AP_PORT_LIST TLV enthalten).
  • Registrierungsfelder:
    • Anfragender – Knoten-ID des nicht angeschlossenen AP.
    • Hop-Adresse – 802-Adresse des ausgewählten primären Ports des nicht angeschlossenen AP.
    • Relay-Knoten-ID – '0' in einer Registrierungsnachricht, die von dem Absender oder dem Antwortenden erzeugt wird. Anderenfalls die Knoten-ID eines Zwischen-"Relay"-Knotens, der die Nachricht weitergeleitet hat.
    • Initial Flag – '1'.
    • VLAN ID – Die ID des nativen VLAN sowohl des nicht angeschlossenen AP als auch des Vaterknotens. Der VLAN ID Wert kann '0' sein. Es liegt ein Fehler vor, denn der VLAN ID Wert anders als die ID des nativen VLAN des Vaterknotens ist.
  • Der Vaterknoten muß eine anfängliche Registrierungsanfrage von einem nicht angeschlossenen AP eingehend weiterleiten, bis sie den Wurzel-CM erreicht. Der Vaterknoten gibt seine Knoten-ID in das Absender-Feld ein und gibt die Knoten-ID seines Vater-CM in des Antwortender-Feld ein, bevor er die Anfrage eingehend weiterleitet. Ein Zwischen-LCM muß das Antwortender Feld mit der CCM-Knoten-ID aktualisieren, bevor er die Anfrage eingehend zu dem CCM weiterleitet. Der CCM sendet eine Registrierungsantwort zu dem Vaterknoten (d. h., dem Absender) zurück. Der Vaterknoten aktualisiert das Antwortender-Feld mit der Knoten-ID des Anfragenden, bevor er die Antwort zu dem nicht angeschlossenen AP oder CM weiterleitet.
  • Ein angeschlossener AP oder CM kann eine "Aktualisierungs"-Registrierungsanfrage direkt zu seinem Vater-CM senden, um seine Pfadinstanz aufzufrischen, wobei er selbst der Absender sowie auch der Anfragender-Knoten ist und der Vater-CM der Antwortende ist. Der Vater-CM muß das Antwortender-Feld mit der Knoten-ID seines Vater-CM aktualisieren, bevor er die Anfrage eingehend weiterleitet.
  • Ein AP überträgt eine Registrierungsanfrage (erneut) entweder, bis er eine Registrierungsantwort mit einer passenden Nachrichten-ID empfängt oder bis die maximalen erneuten Versuche überschritten werden. Ein AP ist "regist riert", wenn er eine passende Registrierungsantwort mit einem "guten" Registrierungsstatus empfängt. Die Registrierungsantwort enthält eine Pfad-ID, die von dem SCM gesetzt ist, die die "Pfadinstanz" von dem AP zu dem SCM identifiziert.
  • Ein AP sendet periodisch eine "Aktualisierungs"-Registrierungsanfrage-Nachricht zu dem SCM, um seine Mobilitätsbindungen in jedem Knoten auf dem Pfad zu dem SCM aufzufrischen. Bei einer Aktualisierungs-Registrierungsanfrage ist das Initial Flag auf AUS gesetzt, und sie enthält eine gültige Pfad-ID.
  • Eine Registrierungsanfrage von einem AP muß eine WTLV_AP_PORT_LIST TLV umfassen, die eine Liste von AP-Port-Deskriptoren enthält. Jeder Port-Deskriptor umfasst den Porttyp, den Portmodus (Vater, Sohn oder Vater/Sohn) und die 802-Port-Adresse einer physikalischen Kommunikationsschnittstelle.
  • Eine Registrierungsanfrage von einem AP muß eine IP Address TLV enthalten.
  • Eine Registrierungsanfrage von einem AP, die mit einer Proxy MIP SSID konfiguriert ist, muß eine WTLV_PMIP_SSID_LIST TLV enthalten, die eine Liste von Proxy MIP SSIDs und MIP HA Bindungen enthält.
  • W2 – Proxy-MN-Registrierung
  • Dieser Abschnitt beschreibt die MN-Registrierung durch einen Vater-AP, wenn die WLCCP-Registrierung verwendet wird, um den Schicht-2-Weiterleitungspfad zwischen dem MN und dem primären LAN zu erstellen.
  • Ein "Proxy WLCCP MN" in einem Vater-AP stellt Proxy-WLCCP-Registrierungsdienste für MNs bereit, die keine Kenntnis von WLCCP aufweisen. Jeder MN ist bei dem SCM für das native VLAN oder seinen Vater-AP registriert, selbst wenn der MN zu einem anderen VLAN gehört.
  • Ein Vater-AP erzeugt eine "anfängliche, authentifizierte" Registrierungsanfragenachricht für einen MN, nachdem sich der MN erfolgreich authentifiziert oder erneut authentifiziert hat. Eine Registrierungsanfrage für einen MN muß die SSID des MN und das Standard-Teilnetz für den MN enthalten.
  • Wenn ein Vater-AP eine erwartete Registrierungsantwort nicht empfängt, dann muß er die Registrierungsanfrage erneut senden, wobei das Verzögerungs-Feld auf die abgelaufene Zeit gesetzt ist, seit der MN zuletzt einen Uplink-Rahmen gesendet hat. Ein Vater-AP muß die Verbindung eines MN beenden, wenn er eine erwartete Registrierungsantwort nach erneuten REGISTRATION_RETRY_LIMIT-Übertragungen nicht empfangen hat.
  • Die Felder in einer anfänglichen Proxy-Registrierungsanfrage für einen MN werden wie unten beschrieben gesetzt. Nicht spezifizierte Felder werden auf '0' gesetzt.
  • WLCCP-Header-Felder:
    • Typ – '3'
    • Absender – Knoten-ID des Vater-AP.
    • Antwortender – Knoten-ID des SCM.
    • Response-Req Flag – '1' zum Abrufen einer Antwort.
    • Inbound Flag – '1'.
    • Hopwise-Routing Flag – '1'.
    • TLV Flag – '1' (die Anfrage muß eine SSID_TLV enthalten).
  • Registrierungsfelder:
    • Anfragender – 802-Adresse des MN.
    • Hop-Adresse – 802-Adresse des primären Ports des Vater-AP.
    • Relay-Knoten-ID – '0' in einer Registrierungsnachricht, die von dem Absender oder dem Antwortenden erzeugt wird. Ansonsten die Knoten-ID eines Zwischen-"Relay"-Knotens, der die Nachricht weitergeleitet hat.
    • Proxy Flag – '1'.
    • Initial Flag – '1'.
    • Authenticated Flag – Das Authenticated Flag wird in einer Anfrage auf '1' gesetzt, um anzuzeigen, dass der MN von dem Vater-AP authentifiziert worden ist.
    • Proxy MIP Flag – auf '1' gesetzt, wenn der MN eine SSID benutzt, bei der Proxy MIP aktiviert ist.
    • Verzögerung – Die Verzögerung in hundertstel Sekunden, seit der MN zuletzt einen Uplink-Rahmen gesendet hat. Die Verzögerung ist normalerweise '0', wenn das Retry Flag '0' ist.
    • VLAN ID – Die VLAN ID, die dem MN zugewiesen ist. Die VLAN ID des MN ist für Gewöhnlich die Standard-VLAN ID, die der SSID des MN zugewiesen ist. Die zugewiesene VLAN ID kann '0' sein, wenn der MN dem "nativen VLAN" zugewiesen ist. Das VLAN ID Feld in der Registrierungsantwort für einen MN kann eine andere VLAN ID enthalten, um den MN explizit einem VLAN zuzuweisen.
    • SSID_TLV – Die Registrierungsanfrage für einen MN muß eine WTLV_SSID TLV enthalten, die die aktive SSID für den MN enthält, die in der (erneuten) Verbindungsanfrage des MN enthalten war. Das Broadcast SSID Flag muß auf EIN gesetzt sein, wenn der MN mit einer Broadcast SSID assoziiert ist. Eine Registrierungsantwort für einen MN kann eine SSID TLV mit einer anderen SSID enthalten, um den MN explizit einem Dienstsatz zuzuweisen.
    • AUTHENTICATION_TYPE TLV – Enthält den 802.11-Authentifizierungstyp (offen, gemeinsamer Schlüssel oder EAP-Typ), der verwendet wird, um den MN zu authentifizieren.
  • Eine Registrierungsanfrage, die für eine 802.11-Station erzeugt wird, die sich "erneut verbunden" hat, muß die BSSID des alten AP in einer WTLV_OLD_AP_BSSID TLV enthalten. Die BSSID wird aus dem "alter AP"-Feld in der 802.11-Anfrage bezüglich einer erneuten Verbindung entnommen, die von der Station übertragen würde.
  • Eine Registrierungsanfrage für einen MN wird immer zu dem "am nächsten liegenden gemeinsamen Vorgänger"-CM weitergeleitet. Ein SMC muß eine anfängliche Registrierungsanfrage für einen MN zu seinem Vater-LCM weiter leiten, wenn er eine Registrierungsanfrage von dem Vater-AP des MN empfängt und eine der folgenden Bedingungen zutrifft:
    Der SCM weist keine gebundene DPR für den MN auf.
    KEINE BSSID in der empfangenen Registrierungsanfrage ist die Adresse eines Ports an dem "Vater-AP" in der DPR des SCM für den MN.
    Der SCM erzeugt oder aktualisiert eine "gebundene" DPR für den MN, wenn er eine passende Registrierungsantwort von seinem Vater-LCM mit einem "guten" Status empfängt. Der SCM erzeugt eine Registrierungsantwort, wenn er die Registrierungsantwort von seinem Vater-CM empfängt, um die neue Pfadinstanz in seinem Teilnetz zu erstellen.
  • Ein LCM muß eine empfangene anfängliche Registrierungsanfrage für einen MN eingehend zu dem CCM weiterleiten, wenn er keine gebundene DPR für den MN aufweist.
  • Eine Registrierungsantwort-Nachricht für einen MN enthält immer die IP-Adresse des MN, wenn sie bekannt ist. Ein Vater-AP muß eine "Registrierungsanfrage für einen MN erzeugen, wenn er zum ersten Mal eine neue oder andere IP-Adresse für den MN entdeckt (d. h., durch Belauschen von IP/ARP-Paketen, die von dem MN übertragen werden). Das Root CM Flag ist in der Anfrage auf EIN gesetzt, um eine Aktualisierung in dem vollständigen Pfad zu dem Wurzel-CM zu veranlassen.
  • Ein Vater-AP erzeugt eine Pfadaktualisierungsnachricht für einen MN, nachdem sich der MN erfolgreich authentifiziert hat. Eine Pfadaktualisierungsnachricht wird immer in dem VLAN des MN übertragen, um die Weiterleitungstabellen in Brücken und Switches zu aktualisieren. Die Pfadaktualisierungsnachricht wird zu der 802-Adresse des "alten Vater-AP" gesendet, wenn die Adresse bekannt ist und sich der alte Vater-AP in dem gleichen VLAN wie der MN befindet; ansonsten wird die Pfadaktualisierung zu der 802 Broadcast-Adresse in dem VLAN des MN gesendet.
  • Ein Vater-AP muß einen Sohn-MN abmelden, wenn er innerhalb eines MAX_MN_INACTIVITY Zeitraums von dem MN keinen Uplink-Rahmen empfängt. Der Vater-AP muß eine WLCCP-Abtrennanfrage zu dem SCM senden, wenn die Verbindung einer Sohnstation (MN oder AP) beendet wird. Die Abtrennanfragelogik wird unten noch ausführlicher erörtert werden.
  • Daten-Rahmen können zu oder von einem MN weitergeleitet werden, sobald der MN authentifiziert ist. Aber Unicast-Daten-Rahmen werden nicht abgehend auf einer AP-zu-AP-Verbindung weitergeleitet, bis eine "gebundene" Pfadinstanz für die Zieladresse existiert. Daten-Rahmen werden von einem "Heimat-Teilnetz" nicht zu einem Proxy MIP MN in einem "fremden Teilnetz" weitergeleitet, bis ein MIP-Tunnel erstellt wird.
  • – 802.11 Brücken-Registrierung.
  • Eine "Vater-802.11-Brücke" registriert sich wie jeder andere AP, wie dies in dem Abschnitt mit dem Titel "AP-Registrierung" beschrieben ist.
  • Eine "Sohn-802.11-Brücke" ist die WLCCP-designierte Brücke für ein sekundäres Ethernet-LAN. Die designierte Brücke muß sich selbst registrieren, wie jeder andere AP auch, und sie muß auch ihr angeschlossenes sekundäres LAN und ihre angeschlossenen Ethernet-Knoten in dem sekundären LAN registrieren. Eine WLCCP-designierte Brücke muß das Secondary LAN Flag in ihren Registrierungsanfragenachrichten auf EIN setzen.
  • Das Unicast-Flooding zu einem sekundären LAN wird lokal an dem sekundären Ethernet-Port der designierten Brücke aktiviert bzw. deaktiviert. Wenn das Unicast-Flooding aktiviert ist, dann muß die WLCCP-designierte Brücke ein Unicast Flooding Flag in ihren WLCCP-Registrierungsanfrage-Nachrichten auf EIN setzen, um Unicast-Flutungs-Anforderungen zu dem primären LAN weiterzureichen. Das Unicast-Flooding wird dynamisch an einem logischen sekundären AP-Port aktiviert, wenn eine Registrierungsanfrage an dem Port empfangen wird, bei der das Unicast Flooding Flag auf EIN gesetzt ist. Im Allgemeinen muß ein AP das Unicast Flooding Flag in seinen Registrierungsanfragenachrichten auf EIN setzen, wenn das Unicast-Flooding statisch oder dynamisch an irgendeinem seiner sekundären Ports aktiviert ist. Deshalb ist das Unicast-Flooding an jedem sekundären AP-Port aktiviert, wenn der Unterbaum, der an dem Port wurzelt, ein sekundäres Ethernet-LAN aufweist, bei dem das Unicast-Flooding aktiviert ist. Das dynamisch aktivierte Unicast- Flooding wird an einem sekundären AP-Port deaktiviert, wenn eine Registrierungsanfrage, bei der das Unicast Flooding Flag auf EIN gesetzt ist, nicht innerhalb der maximalen AP-Registrierungslebenszeit empfangen wird.
  • Wenn das Unicast-Flooding in einem sekundären LAN deaktiviert ist, dann muß die WLCCP-designierte Brücke eine WTLV_SEC_LAN_ADDR_LIST TLV in ihren Registrierungsanfrageaufzeichnungen enthalten, um Ethernet-Knoten in dem sekundären LAN an dem primären LAN anzuschließen. Die TLV enthält eine Liste von VLAN-ID/802-Adressenpaaren für Stationen in dem sekundären LAN. Die Adressen können statisch konfiguriert werden oder dynamisch mittels Rückwärtslernen "gelernt" werden.
  • Eine benutzerkonfigurierte Ethernet-Adressen-Liste kann an einem AP-Ethernet-Port konfiguriert werden. Die Ethernet-Adressen-Liste enthält eine Liste von statische 802-Adressen, wobei jede Adresse eine Station identifiziert, auf die über den Ethernet-Port zugegriffen werden kann. [Die Liste kann mittels Standard-802.1D-Konfigurationsoptionen konfiguriert werden, die die Erschaffung von "statischen" Datenbankeinträgen unterstützen.] Eine Sohn-802.11-Brücke verknüpft Adressen in der Liste mit dem primären LAN, wie dies oben beschrieben ist.
  • – WLCCP-designierte Brücken-Auswahl.
  • Dieser Abschnitt beschreibt eine optionales Protokoll für die Auswahl einer WLCCP-designierten Brücke, das verwendet wird, um eine WLCCP-designierte Brücke für ein sekundäres Nicht-STP-LAN auszuwählen. Das Protokoll kann zum Beispiel verwendet werden, um eine automatische Redundanz für Nicht-STP Work Group Bridges zu ermöglichen.
  • Eine Nicht-STP-Sohn-802.11 Brücke ist mit einem Brückenprioritätswert von 0 (Standard) bis 7 konfiguriert. Eine Brücken-ID ist die Verkettung aus der Brückenpriorität und der WLCCP-Knoten-ID der jeweiligen Sohn-802.11-Brücke. Eine Brücken-ID weist eine relativ höhere Brückenpriorität auf, wenn sie lexikographisch höher ist. Die Sohn-Brücke mit der Brücken-ID mit der höchsten Priorität funktioniert als die WLCCP-designierte Brücke für ihr angeschlossenes sekundäres LAN.
  • Eine Nicht-STP-Sohn-Brücke überträgt periodisch SCM-Bekanntmachungsantwort-Nachrichten, die ihre Brücken-ID enthalten, an ihrem sekundären Ethernet-Port. Eine Sohn-802.11-Brücke muß ihren sekundären Ethernet-Port blockieren, wenn sie eine SCM-Bekanntmachungsantwort-Nachricht mit einer Brücken-ID mit einer höheren Priorität an dem Port empfängt. Eine Sohn-802.11-Brücke wird zu der aktiven WLCCP-designierten Brücke für ihr angeschlossenes sekundäres LAN, wenn sie keine SCM-Bekanntmachungsantwort-Nachricht an ihrem Ethernet-Port mit einer Brücken-ID mit einer höheren Priorität innerhalb von WLCCP_BRG_ELECT_HOLDDOWN Sekunden empfängt, nachdem sie mit dem Senden von SCM-Bekanntmachungen beginnt.
  • – 802 Multicast-Adressenregistrierung.
  • Ein MN muß das Multicast Flooding Flag in seinen Registrierungsanfragenachrichten auf EIN setzen, wenn das Multicast-Flooding an irgendeinem seiner sekundären Ports aktiviert ist. Das Multicast-Flooding wird an einem logischen sekundären AP-Port dynamisch aktiviert, wenn eine Registrierungsanfrage an dem Port empfangen wird, bei der das Multicast Flooding Flag auf EIN gesetzt ist. Deshalb ist das Multicast-Flooding an einem sekundären Port aktiviert, wenn es an irgendeinem anderen AP oder sekundären LAN in dem Unterbaum aktiviert ist, der an dem Port wurzelt.
  • Ein AP muß eine – wenn möglich leere – WTLV_MCAST_ADDR_LIST TLV in einer Registrierungsanfrage enthalten, bei der das Multicast Flooding Flag auf AUS gesetzt ist. Die TLV enthält die Sammelliste von 802-Multicast-Adressen, die an den sekundären Ports des AP aktiviert sind. Die Sammelliste von aktivierten 802-Multicast-Adressen umfasst jegliche benutzerkonfigurierte Liste von aktivierten Multicast-Adressen sowie Multicast-Adressen, die von MNs registriert wurden.
  • Eine Multicast-Adresse wird dynamisch an einem sekundären Port eines AP aktiviert, wenn sie in einer WTLV_MCAST_ADDR_LIST TLV in einer Registrierungsanfrage oder in einem MULTICAST_802_ADDRESS_LIST-Element in einer (erneuten) 802.11-Verbindungsnachricht oder in einem 802.11- Aktionsrahmen enthalten ist. Eine dynamisch aktivierte Multicast-Adresse wird gealtert und verworfen, wenn sie nach der maximalen AP-Registrierungslebenszeit nicht erneut registriert wird.
  • Das 802-Multicast-Flooding ist standardmäßig an allen sekundären AP-Ports aktiviert. Das 802-Multicast-Flooding zu einem sekundären LAN wird lokal an dem sekundären Ethernet-Port der designierten Brücke aktiviert bzw. deaktiviert.
  • – IP-Multicast-Adressenregistrierung.
  • Das "IGMP Snooping" wird im Allgemeinen dazu verwendet, automatisch abzuleiten, welche IP-Multicast-Adressen an einem Port "aktiv" sind (d. h., welche IP-Multicast-Adressen an dem Port weitergeleitet werden sollen). Das IGMP Snooping kann global aktiviert werden oder es kann an jedem (d. h., sekundären) AP-Port aktiviert werden. Wenn das IGMP Snooping aktiviert ist, dann werden nur IP-Multicast-Pakete mit "aktiven" Multicast-IP-Adressen an dem sekundären Port weitergeleitet.
  • Wenn das IGMP Snooping an einem sekundären AP-Port deaktiviert ist, dann muß das IP Multicast Flooding Flag in den Registrierungsanfragenachrichten des AP auf EIN gesetzt sein, damit alle Multicast-IP-Pakete zu dem sekundären Port geflutet werden. Das IP-Multicast-Flooding wird dynamisch an einem logischen sekundären AP-Port aktiviert, wenn eine Registrierungsanfrage an dem Port empfangen wird, bei der das IP Multicast Flooding Flag auf EIN gesetzt ist. Deshalb ist das IP-Multicast-Flooding an einem sekundären Port dann aktiviert, wenn es an irgendeinem anderen AP oder in irgendeinem anderen sekundären LAN in dem Unterbaum aktiviert ist, der an dem Port wurzelt.
  • Standardmäßig werden IGMP-Aufzeichnungen einfach eingehend zu dem primären LAN weitergeleitet, um IP-Multicast-Mitgliedschaftsinformationen zu jedem AP auf dem eingehenden Pfad weiterzureichen. Wenn eine zuverlässige IP-Multicast-Registrierung benötigt wird, kann ein AP eine WTLV_IP_MCAST_ADDR_LIST TLV in einer Registrierungsanfrage enthalten, bei der das IP Multicast Flooding Flag auf AUS gesetzt ist.
  • Die TLV enthält die Gesamtliste von IP-Multicast-Adressen, die an den sekundären Ports des AP aktiv sind.
  • [Eine WLCCP-Unterstützung wird für das IP-Multicast-Filtern nicht benötigt, wenn die IGMP-Aufzeichnungen einfach nach innen gerichtet zu dem primären LAN weitergeleitet werden.]
  • – Zuverlässiger Pfadaktualisierungsmechanismus.
  • Dieser Abschnitt beschreibt einen optionalen "zuverlässigen" WLCCP-"Pfadaktualisierungs"-Mechanismus, der verwendet wird, um verlorene Pfadaktualisierungsnachrichten wieder herzustellen.
  • Ein neuer AP sendet eine einzige Pfadaktualisierungs-Anfragenachricht, um den rückwärtsgelernten Weiterleitungspfad für einen MN in Zwischen-Brücken und -Switches zu aktualisieren, wenn sich der MN verbindet. Der Weiterleitungspfad für den MN wird in Zwischen-Brücken/-Switches NICHT korrekt aktualisiert werden, wenn die Pfadaktualisierungsnachricht verloren geht.
  • Der zuverlässige Pfadaktualisierungsmechanismus erfordert es, dass irgendein primärer AP-Ethernet-Port auf einer dedizierten Ethernet-Verbindung existieren muß. Zum Beispiel können zwei Wurzel-APs nicht in denselben Ethernet-Hub gesteckt werden. Mit dieser Einschränkung sollte ein "alter AP" an seinem primären Port keine Rahmens für einen MN empfangen, der sich nicht in seinem Unterbaum befindet.
  • Der Mechanismus wird wie folgt implementiert:
    APs müssen MN IRRs für MNs verwalten, die sich nicht in ihrem Unterbaum befinden.
  • Eine MN-IRR wird für einen gewissen Schwellenwertzeitraum (z. B. 1 Minute) in einen "Pfadaktualisierung wartend"-Zustand versetzt, nachdem ein Sohn-MN deregistriert worden ist, wenn eine Pfadaktualisierungsnachricht für den MN nicht empfangen wird. Der wartende Zustand endet, wenn der Schwellenwertzeitraum abläuft, eine Pfadaktualisierung empfangen wird oder eine Pfadüberprüfungsantwort anzeigt, dass der MN das Teilnetz verlassen hat. (Es sei angemerkt, dass eine Pfadaktualisierungsnachricht vor einer Deregistrierungsnachricht empfangen werden kann.)
  • Ein alter Vater-AP erzeugt eine Pfadüberprüfungs-Anfragenachricht für einen MN, wenn er a) eine MN IRR für den MN besitzt, der sich in dem wartenden Pfadaktualisierungszustand befindet, und b) einen Daten-Rahmen an seinem primären Port empfängt, der für den MN bestimmt ist. Die Pfadüberprüfungsanfrage wird zu dem Vater-SCM des alten AP gesendet.
  • Der Vater-SCM erzeugt eine Pfadüberprüfungs-Antwortnachricht, wenn er eine Pfadüberprüfungsanfrage empfängt. Wenn der SCM einen neueren abgehenden Pfad zu dem MN aufweist, dann sendet er die Pfadüberprüfungsantwort zu dem neuen Vater-AP; ansonsten sendet er eine Pfadüberprüfungsantwort zu dem alten Vater-AP, um anzuzeigen, dass der MN nicht mehr länger in dem Teilnetz registriert ist.
  • Der neue Vater-AP sendet eine Pfadaktualisierungs-Anfragenachricht zu dem alten Vater-AP, nachdem er feststellt, dass der MN immer noch verbunden ist.
  • – Erweiterter Dienstsatz für einen MN.
  • Eine 802.11 Service Set ID (SSID) identifiziert einen erweiterten Dienstsatz (Extended Service Set) (ESS), der als ein "drahtloser Zugangsbereich" für eine 802.11-Station betrachtet werden kann. Ein Campusnetz kann mehrere sich überlappende ESSs aufweisen. Ein ESS kann mehrere Teilnetze überspannen. Ein AP kann mit mehreren SSIDs konfiguriert sein, um Zugang zu mehreren ESSs bereitzustellen.
  • Die nachfolgenden Zugangsparameter sind für jede AP SSID konfiguriert:
    Authentifizierungskriterien (z. B. ein benötigter Authentifizierungsalgorithmus)
    Proxy MIP Flag (aktiviert oder deaktiviert).
    VLAN ID (optional).
  • Wenn das Proxy MIP aktiviert ist, dann kann eine optionale "Heimatagentenadressen- und Teilnetzmaske" für die SSID konfiguriert werden.
  • Die VLAN- und Proxy-MIP-Zugangsparameter für einen einzelnen ESS können in jedem AP anders konfiguriert sein. Zum Beispiel kann die SSID "FOO" in einem ersten AP mit einer VLAN ID konfiguriert sein, und die SSID "FOO" kann in einem zweiten AP mit einer Heimatagentenadresse konfiguriert sein.
  • Eine SSID kann mit einer "virtuellen Heimatagentenadresse" konfiguriert sein, so dass die Proxy MIP MNs einem "virtuellen" MIP-"Heimatteilnetz" zugewiesen werden können. [In einer einfachen "nahtlosen Roaming"-Installation können alle Proxy MIP MNs einem einzigen virtuellen Heimatteilnetz über eine zentral konfigurierte Proxy MIP SSID zugewiesen werden.]
  • Authentifizierungsparameter sollten für eine SSID in einem ESS durchweg gleichbleibend konfiguriert sein.
  • Zu irgendeinem bestimmten Zeitpunkt ist jeder MN mit einem einzigen ESS assoziiert. Der physische Roaming-Bereich für einen MN ist auf diejenigen APs begrenzt, die mit der SSID für den MN konfiguriert sind. Der Abschnitt "Proxy MIP- und VLAN Integration" umfasst ein beispielhaftes ESS-Roaming-Szenario.
  • – WLCCP-Unterstützung für VLAN-Trunking.
  • Wenn das 802.1Q-VLAN-Trunking in einem AP aktiviert ist, dann muß ein AP jeden Knoten in seinem Unterbaum einer VLAN ID zuweisen. Alle APs und SCMs in dem WLCCP-Spannbaum für ein Teilnetz befinden sich in dem gleichen "nativen" VLAN wie der SCM. MNs und Ethernet-Stationen (d. h., in einem sekundären LAN) können sich in einem anderen VLAN befinden.
  • Alle APs in einem Teilnetz gehören zu demselben "nativen VLAN", mit einer Ausnahme. Eine WGB, die in einem "Client-Modus" arbeitet, kann zu einem nicht-nativen VLAN gehören. Alle Ethernet-Stationen, die an der WGB angeschlossen sind, gehören zu demselben VLAN wie die WGB. [Eine WGB verbindet sich als eine Client-Station im "Client-Modus". Eine WGB kann im Client-Modus in einer 802.11-VLAN-Verbindungsleitung nicht an ihren Vater-AP angeschlossen werden.]
  • Ein Vater-AP weist einen Sohn-MN einer VLAN ID zu. Standardmäßig wird ein MN zu dem VLAN zugewiesen, das implizit oder explizit für die SSID des MN konfiguriert ist. Der Vater-AP muß die VLAN ID des MN in die Registrierungsanfragenachrichten für den MN einschließen. Ein Vater-AP kann einen MN einer anderen VLAN ID neu zuweisen, wenn er eine Registrierungsantwortnachricht empfängt, falls die Registrierungsantwortnachricht eine andere VLAN ID enthält oder die Registrierungsantwortnachricht eine WTLV_HOME_SUBNET TLV enthält.
  • Eine Registrierungsantwortnachricht wird eine andere VLAN ID enthalten, wenn ein AAA-Server die VLAN ID zuweist. Der zweite Fall wird in dem folgenden Abschnitt beschrieben.
  • Ein AP muß die Anzahl an MNs in seinem Unterbaum für jedes aktivierte VLAN "zählen". Ein VLAN ist an einem sekundären VLAN-Trunk-Port eines AP "aktiv", wenn es ein oder mehrere registrierte Stationen in dem Unterbaum gibt, der an dem Fort wurzelt, die zu dem VLAN gehören. Ein Austritts-Multicast-VLAN-Filter an jedem sekundären VLAN-Trunk-Port wird verwendet, um Multicast-Übertragungen für inaktive VLANs zu verwerfen.
  • Proxy MIP wird verwendet, um "Proxy" Mobile IP Dienste für IP MNs bereitzustellen, die nicht direkt Mobile IP unterstützen.
  • [Im Augenblick stellt das Proxy MIP keine nahtlose Inter-Teilnetz-Mobilität für Nicht-IP-Anwendungen bereit. Das Proxy MIP kann erweitert werden, um eine nahtlose Mobilität für jede Ethernet-basierte Anwendung bereitzustellen, indem rückwärtskompatible Erweiterungen zu dem Standard-MIP hinzugefügt werden. Solche MIP-Erweiterungen erfordern minimale WLCCP-Änderungen und beeinträchtigen nicht die WLCCP-Topologie.]
  • – Proxy-MIP-Registrierung und -Deregistrierung.
  • Der SCM für jedes Teilnetz verwaltet den Mobile IP Registrierungszustand für Proxy MIP MNs. Ein "fremder SCM" löst Proxy MIP Registrierungsanfragen für einen MN aus, wenn er das fremde Teilnetz zum ersten Mal besucht, und periodisch danach, um FA/HA-Mobilitätsbindungen für den MN aufrecht zu erhalten. [Der SCM kann keine MIP-Registrierung auslösen, bis die kompletten Heimat-Teilnetz-Bindungen (d. h., die HA-Adresse und die MN IP Adresse) für den MN in dem SCM erstellt sind.] Ein "Heimat-SCM" löst eine Proxy MIP Deregistrierungsanfrage für einen MN aus, wenn dieser zum ersten Mal aus einem fremden Teilnetz heraus zurück in sein Heimat-Teilnetz roamt.
  • MIP Registrierungsanfragen-Rahmen müssen zu einem MIP FA mit der Quell-Ethernet-Adresse des jeweiligen MN übertragen werden, damit der FA die Ethernet-Adresse des MN entdecken kann. Deshalb muß ein Vater-AP Proxy MIP Registrierungsanfragen übertragen, um ein inkorrektes "Rückwärtslernen" in irgendwelchen transparenten Zwischen-Brücken oder -Switches zu vermeiden. Ein Vater-AP erzeugt eine MIP-Registrierungsanfrage, wenn er eine Anzeige von dem SCM empfängt.
  • Ein "Proxy MIP MN" ist ein MN, der Proxy MIP Dienste benötigt. Ein Proxy MIP MN muß mit einer SSID konfiguriert sein, bei der Proxy MIP aktiviert ist. Die SSID eines MN ist in den 802.11-Anfragenachrichten bezüglich einer (erneuten) Verbindung enthalten; deshalb kann der Vater-AP für einen MN sofort feststellen, ob der MN eventuell Proxy MIP Dienste benötigt. Der Vater-AP muß das Proxy MIP Flag in einer Registrierungsanfrage für einen MN auf EIN setzen, wenn Proxy MIP für die SSID des MN aktiviert ist. Der SCM nimmt eine WTLV_MIP4_REG_REQ TLV in der Registrierungsantwort auf, um den Vater-AP zu veranlassen, eine MIP-Registrierungs-(oder -Deregistrierungs-)Anfrage zu senden.
  • Ein SCM befindet sich NICHT in dem MIP-Weiterleitungspfad für einen Proxy MIP MN in einem fremden Teilnetz. IP-Pakete für den MN werden zwischen dem Heimat-Teilnetz und dem fremden Teilnetz über einen MIP-Tunnel zwischen dem MIP HA und FA weitergeleitet. Der FA leitet IP-Rahmen abgehend zu der Unicast-802-Adresse des MN weiter. Die Proxy MIP Entität in dem Vater-AP des MN leitet IP Rahmen ausgehend von dem MN eingehend zu der Unicast-802-Adresse des FA (d. h., Rückwärtstunnelung) oder zu der Unicast-802-Adresse des Standard-Routers (d. h., Dreiecks-Routing) weiter.
  • – SSID/Heimatagent-Datenbank.
  • Die SSID/HA-Datenbank enthält eine Liste von MIP HAs, auf die jede SSID zugreifen kann, welche in einem AP in dem SWAN-Netz so konfiguriert ist, dass Proxy MIP aktiviert ist. Einträge in der SSID/HA-Datenbank werden automatisch von APs bestückt, wie dies unten beschrieben wird. Ein MN ist nicht dynamisch an ein Heimat-Teilnetz auf der Basis seiner Quell-IP-Adresse gebunden, außer er ist a) autorisiert, seine SSID zu verwenden (d. h., über RADIUS), und b) ein MIP HA für das Heimat-Teilnetz befindet sich in der Liste von zugänglichen HAs für die SSID des MN.
  • Jede SSID, die in einem AP konfiguriert ist, ist entweder implizit oder explizit an ein Standard-VLAN oder an ein MIPv4-HA/Teilnetz-Maskenpaar gebunden. Wenn eine Proxy MIP SSID an ein Standard-VLAN gebunden ist, dann muß der AP versuchen, automatisch den HA für dieses VLAN zu entdecken, indem er HA-Bekanntmachungen überwacht, die in dem VLAN übertragen werden. Ein AP muß auch versuchen, die Teilnetz-Maske für das VLAN zu entdecken. Ein AP kann die Teilnetzmaske für jedes VLAN entdecken, indem er eine ICMP-Teilnetzmasken-Anfrage-Nachricht auf dem VLAN rundsendet oder indem er Teilnetzinformationen in Cisco-CPD-Nachrichten überwacht.
  • Ein AP, der mit einer Proxy MIP SSID konfiguriert ist, muß eine WTLV_PMIP_SSID_LIST Container TLV in seinen Registrierungsanfragenachrichten enthalten. Die Container-TLV enthält eine Liste von WTLV_SSID TLVs, bei denen auf jede SSID TLV eine 0 oder mehr WTLV_MIPV4_AGENT TLVS folgen. Jede MIPV4_AGENT TLV enthält die IP-Adresse, die Teilnetzmaske und die Fähigkeiten eines HA, der für die jeweilige SSID zugänglich ist. Das Teil netzmasken-Feld für einen HA wird auf '0' gesetzt, wenn sie unbekannt ist. Der SCM vereinigt die Liste von Proxy MIP SSIDs und HAs aus allen APs in seinem Bereich und leitet die sich ergebende Liste an Proxy MIP SSIDs und assoziierten HAs zu dem CCM weiter. Der CCM verwendet die Informationen, um automatisch die SSID/HA-Datenbank und die "Heimatagent-Datenbank" zu bestücken, die unten beschrieben wird.
  • – Heimatagent-Datenbank.
  • Der CCM unterhält eine Heimatagent-Datenbank, die eine Liste von MIPv4-HA/Teilnetz-Maskenpaaren enthält. Einträge in der Liste werden statisch konfiguriert und/oder automatisch bestückt von APs. Der CCM verwendet die Datenbank, um den MIP HA für einen Proxy MIP MN zu bestimmen, wenn er eine Registrierungsanfrage empfängt, bei der das Proxy-MIP Flag auf EIN gesetzt ist und die eine WTLV_HOME_SUBNET TLV aufweist. Die HOME_SUBNET TLV enthält eine IP-Adresse eines Proxy MIP MN, die durch "Belauschen" der Quell-IP-Adresse in Paketen entdeckt wurde, die von dem MN gesendet wurden. Der CCM ermittelt den HA für den MN, indem er die Teilnetzadresse des MN mit der Teilnetzadresse eines HA abgleicht. Ein Suchalgorithmus der Art "längster übereinstimmender Präfix" kann verwendet werden, wenn einige Teilnetzmasken nicht bekannt sind. Der MN muß autorisiert sein, Zugang zu dem Heimat-Teilnetz des HA zu erhalten, wie dies oben beschrieben ist.
  • – Proxy-MIP/VLAN-Integration.
  • Ein AP, der an dem Netz an einem primären VLAN-Trunk-Port angeschlossen ist, weist eine Schicht-2-"VLAN-Verbindung" zu mehreren Proxy MIP "Heimat-Teilnetzen" auf. Wenn ein Vater-AP eine VLAN-Verbindung zu einem Heimat-Teilnetz eines Proxy MIP MN aufweist, dann ist der Proxy MIP MN zu der entsprechenden VLAN ID zugewiesen; anderenfalls ist der Proxy MIP MN dem nativen VLAN zugewiesen, selbst wenn das native VLAN nicht das Heimat-Teilnetz ist.
  • Jeder AP muß eine "VLAN-Tabelle" mit einem Eintrag für jede VLAN ID verwalten, die in dem AP aktiviert ist. Ein VLAN ist als "Proxy MIP aktiviert" markiert, wenn 1 oder mehr Proxy MIP SSIDs an das VLAN gebunden sind. Jeder VLAN-Tabelleneintrag für ein VLAN mit aktiviertem Proxy MIP muß die Adresse und die Teilnetzmaske eines oder mehrerer MIPv4 HAs enthalten.
  • Die SWAN-Infrastruktur wird alle existierenden Heimat-Teilnetz-Bindungen für einen Proxy MIP MN in einer WTLV_HOME_SUBNET TLV in einer Registrierungsantwortnachricht für den MN zurücksenden. Der MN ist "zuhause", wenn die HA-Adresse in der Registrierungsantwort mit irgendeiner HA-Adresse in der VLAN-Tabelle übereinstimmt. In diesem Fall wird der MN der VLAN ID zugewiesen, die in dem übereinstimmenden Eintrag enthalten ist. Eine MIP-"Deregistrierungs"-Nachricht wird erzeugt, wenn ein Proxy MIP MN zum ersten Mal in den Bereich eines SCM roamt und der MN an sein Heimat-Teilnetz über VLAN-Trunking gebunden ist.
  • – Heimat-Teilnetz-Bindungen.
  • Die "Heimat-Teilnetz-Bindungen" für einen Proxy MIP MN umfassen die MIP HA Adresse, die Teilnetzmaske und die IP-Adresse für den MN. Die HA-Bindungen für einen MN können statisch konfiguriert oder automatisch abgeleitet werden, wie dies oben beschrieben ist. Der CCM verwaltet die "Master-Kopie" der Heimat-Teilnetz-Bindungen für jeden aktiven Proxy MIP MN. Die Proxy MIP Client-Entität in einem SCM muß die Heimat-Teilnetz-Bindungen für einen Proxy MIP MN bestimmen, bevor sie eine MIP-Registrierungsanfrage für den MN erzeugen kann.
  • Ein Proxy MIP MN wird einem Heimat-Teilnetz mit dem folgenden priorisierten Regeln (von der niedrigsten zu der höchsten) zugewiesen:
    • 1) Ein MN wird dem Standard-VLAN oder der Heimat-Teilnetz-Adresse zugewiesen, das bzw. die für seine SSID in dem Vater-AP konfiguriert ist.
    • 2) Wenn ein AP eine IP-Adresse eines Proxy MIP MN entdeckt, dann wird der MN dem Heimat-Teilnetz zugewiesen, das seiner IP-Adresse entspricht.
    • 3) Der MN wird einem statisch konfigurierten Heimat-Teilnetz und MIP HA(s) zugewiesen.
  • Ein Proxy MIP MN mit existierenden MIP-Heimat-Teilnetz-Bindungen ist immer an sein augenblickliches Heimat-Teilnetz gebunden – selbst wenn der MN mit einem AP verbunden ist, der eine passende SSID aufweist, die mit einer VLAN ID oder einer Heimatagentenadresse für ein anderes Teilnetz konfiguriert ist (siehe den Abschnitt mit dem Titel "Proxy MIP- und -VLAN-Integration"). Proxy MIP wird verwendet, um Zugang zu dem Heimat-Teilnetz zu erhalten, wenn der MN an einem AP in einem fremden Teilnetz angeschlossen ist (d. h., einem AP, der an dem Heimat-Teilnetz nicht in einer LAN-Verbindung oder einer VLAN-Verbindungsleitung angeschlossen ist).
  • Eine WTLV_HOME_SUBNET TLV wird verwendet, um Heimat-Teilnetz-Bindungen für einen Proxy MIP MN zu erstellen. Die TLV enthält die folgenden Felder: a) MIPv4 HA, b) Teilnetzmaske und c) MN IP-Adresse. Die Felder für die Teilnetzmaske und die MN IP-Adresse können Null sein, wenn die Werte nicht bekannt sind. Ein MN kann nicht an ein Heimat-Teilnetz gebunden werden, bis seine IP-Adresse entdeckt wird.
  • Die MN-Heimat-Teilnetz-Zuweisung schreitet wie folgt voran. (Es sei angemerkt, dass eine Registrierungsanfrage für einen MN immer die SSID des MN in einer WTLV_SSID TLV enthält.)
  • Wenn ein Proxy MIP MN zu einem Vater-AP roamt, muß der AP eine WTLV_HOME_SUBNET TLV in der anfänglichen Registrierungsanfragenachricht für den MN einschließen. Die HOME_SUBNET TLV muß die "Standard-MIP-HA"-Adresse und die IP-Adresse des MN, falls bekannt, enthalten. Der Standard-MIP-HA ist entweder a) der HA, der für die SSID des Proxy MIP MN konfiguriert ist, oder b) er ist der HA, der an das VLAN gebunden ist, das für die SSID des Proxy MIP MN konfiguriert ist. Die Standard-MIP-HA-Adresse wird verwendet, um dynamisch das Heimat-Teilnetz für einen MN zu erstellen, der keine existierenden Heimat-Teilnetz-Bindungen aufweist. Die anfängliche Registrierungsanfrage wird zu dem am nächsten liegenden gemeinsamen Vorgänger-CM – dem "gemeinsamen CM" – weitergeleitet.
  • Der gemeinsame CM leitet alle existierenden Heimat-Teilnetz-Bindungen für den Proxy MIP MN an den Vater-AP des MN weiter, und zwar in einer WTLV_HOME_SUBNET TLV in der entsprechenden Registrierungs antwortnachricht. Die abgehende Antwortnachricht erstellt die Bindungen in jedem CM und AP auf dem Pfad zu dem MN. Die existierenden Bindungen haben Vorrang vor den Bindungen, die von dem Vater-AP erstellt werden. Es sei angemerkt, dass die "existierenden Bindungen" statisch konfiguriert oder dynamisch erstellt worden sein können (d. h., von einem alten Vater-AP).
  • Der CCM ist der "gemeinsame CM", wenn der Proxy MIP MN keine existierenden Heimat-Teilnetz-Bindungen aufweist. In diesem Fall wird die HA IP-Adresse in der WTLV_HOME_SUBNET TLV in der Registrierungsanfrage des Proxy MIP MN verwendet, um den MIP HA für den MN zu bestimmen. Die Heimat-Teilnetz-Bindungen werden in einer WTLV_HOME_SUBNET TLV in der Registrierungsantwort, die von dem CCM erzeugt wird, zurückgesendet.
  • Ein Vater-AP kann entdecken, dass ein MN eine IP-Adresse verwendet, die nicht zu seinem aktuellen Heimat-Teilnetz gehört. In diesem Fall muß der Vater-AP sofort eine Aktualisierungsregistrierungsanfrage erzeugen, die die IP-Adresse in einer WTLV_HOME_SUBNET TLV enthält, um den MN dynamisch dem Heimat-Teilnetz zuzuweisen, das seiner IP-Adresse entspricht.
  • Der CCM verwendet die SSID/HA-Datenbank, um zu verifizieren, dass der MN berechtigt ist, auf das Heimat-Teilnetz zuzugreifen, das seiner IP-Adresse entspricht. Wenn die Heimat-Teilnetz-Zuweisung autorisiert ist, dann sind die Heimat-Teilnetz-Bindungen in einer WTLV_HOME_SUBNET TLV in der entsprechenden Registrierungsantwort enthalten, die von dem CCM erzeugt wird.
  • Es sei angemerkt, dass ein Vater-AP konsequent einen Proxy MIP MN dem Heimat-Teilnetz zuweist, das in einer WTLV_IPV4_HOME_SUBNET TLV in einer Registrierungsantwortnachricht für den MN enthalten ist. Ein Proxy MIP MN ist "zuhause", wenn die HA-Adresse in der Registrierungsantwortnachricht mit einer HA-Adresse in der VLAN-Tabelle des AP übereinstimmt. In diesem Fall wird der MN der entsprechenden VLAN ID in dem übereinstimmenden Tabelleneintrag zugewiesen. Der Vater-AP erzeugt eine MIP-Deregistrierungsanfrage-Nachricht für einen MN, wenn er eine Registrierungsantwort mit einer WTLV_MIP4_REG_REQ TLV empfängt und der MN "zuhause" ist.
  • Dynamisch zugewiesene Heimat-Teilnetz-Bindungen für einen MN werden gealtert und verworfen, wenn der MN inaktiv wird. Deshalb kann sich das Heimat-Teilnetz für einen Proxy MIP MN nach einer gewissen Zeitspanne der Inaktivität (d. h., auf ein optimaleres Teilnetz) ändern.
  • Ein MN kann an ein "virtuelles Heimat-Teilnetz" gebunden werden, indem APs mit einer Proxy MIP SSID konfiguriert werden, die an das virtuelle Heimat-Teilnetz gebunden ist.
  • [Die "IPv4 Subnet Selection Option for DHCP" (IPv4 Teilnetz-Auswahloption für DHCP), RFC 3011 [6] wird verwendet, um die IP-Adresse für einen DHCP MN in einem fremden Teilnetz aufrecht zu erhalten.]
  • – Proxy MIP Unicast-Weiterleitung.
  • Standardmäßig wird das "Dreiecks-Routing" verwendet, um Pakete für einen Proxy MIP-Knoten in einem fremden Teilnetz weiterzuleiten: Pakete, die in einem Heimat-Teilnetz übertragen werden und die für einen MN in einem fremden Teilnetz bestimmt sind, werden von einem HA eingekapselt und zu dem MN getunnelt. Pakete, die von einem MN in einem fremden Teilnetz übertragen werden, werden zu der MAC-Adresse eines IP-Gateway in dem fremden Teilnetz gesendet. Das Gateway benutzt das normale IP-Routing, um die Pakete zu der Ziel-IP-Adresse zuzustellen.
  • Als eine Option kann die "MIP-Rückwärtstunnelung" durch die Proxy MIP SSID aktiviert sein. Wenn die Rückwärtstunnelung für eine SSID eines Proxy MIP MN aktiviert ist, dann werden die Pakete, die von dem MN in ei nem fremden Teilnetz übertragen werden, eingekapselt und eingehend zu dem HA des MN weitergeleitet, wie dies in RFC 3024 spezifiziert ist.
  • [Die Rückwärtstunnelung wird für Unicast-IP-Pakete aus mehreren Gründen benötigt. Der DHCP-Server für ein "privates Teilnetz" kann eine nicht routbare "private IP-Adresse" einem Proxy MIP MN zuordnen, der mit dem Teilnetz assoziiert ist. Der Router für ein privates Teilnetz enthält typischerweise einen Network Address Translator (NAT). Ein NAT ermöglicht es einer Station mit einer privaten Adresse, auf andere öffentliche Netze zuzugreifen, indem er die private Adresse der Station in eine routbare "öffentliche Adresse" in IP-Paketen umsetzt, die von der Station gesendet und empfangen werden. Die Port Address Translation (PNAT) wird verwendet, um viele private Adressen in eine einzige öffentliche NAT-Adresse zu multiplexen. Wenn ein Proxy MIP MH mit einer privaten Heimatadresse zu einem fremden Teilnetz roamt, dann müssen Pakete, die von dem MH übertragen werden, zu seinem Heimat-Teilnetz in einem Rückwärts-MIP-Tunnel weitergeleitet werden, um jegliche notwendige NAT-Umsetzung zu ermöglichen. Eine private IP-Adresse darf KEINE unzweideutige "Heimat-IP-Adresse" sein, wenn sich mehrere private Teilnetze in demselben Campusnetz den gleichen IP-Adressenraum teilen.
  • Ein Campusnetz kann "sichere Teilnetze" enthalten, die von einer "Firewall"-Logik geschützt werden. Paketen, die von einem MN in einem fremden Teilnetz übertragen werden, kann es eventuell nicht erlaubt sein, durch eine Firewall hindurchzugehen, die zwischen dem fremden Teilnetz und dem Heimatteilnetz existiert.]
  • – Proxy MIP-Multicast-Weiterleitung.
  • Gemäß RFC 2002 muß ein Standard-Mobile IP-MN in einem fremden Teilnetz IGMP-Mitgliedschaftsaufzeichnungs-Nachrichten erzeugen, um an einer IP-Multicast-Gruppe teilnehmen zu können. Die Mitgliedschaftsaufzeichnungen können entweder auf das fremde Teilnetz übertragen werden oder können zu dem MIP HA des MN weitergeleitet werden.
  • APs verwenden das "IGMP Snooping ", um IP-Gruppenmitgliedschafts-Informationen für einen MN abzuleiten. Ein AP sendet eine allgemeine IGMP- Anfrage zu einem MN, wenn er sich verbindet, um IGMP-Aufzeichnungen abzurufen.
  • Ein Vater-AP kann so konfiguriert sein, dass er IGMP-Mitgliedschaftsaufzeichnungen und IP-Multicast-Pakete für einen Proxy MIP MN in einem fremden Teilnetz auf eine der folgenden Arten und Weisen verarbeitet:
    Ein AP kann die Mitgliedschaftsaufzeichnungen zu dem HA des MN über den lokalen FA weiterleiten. Der MIP HA ist für das Einkapseln und das Weiterleiten von Multicast-Paketen, die in dem Heimatteilnetz des MN übertragen werden, zu dem MN in dem fremden Teilnetz verantwortlich, wie dies in RFC 2002 definiert ist. Wenn der HA IP-Multicast-Pakete zu dem MN tunnelt, dann ist die Proxy MIP Entität in einem Vater-AP dafür verantwortlich, den "inneren Einkapselungs-Header" aus einem Multicast-Paket zu entfernen, das von dem HA zu einem Proxy MIP MN in einem fremden Teilnetz weitergeleitet wird. Der Vater-AP kann dann das sich ergebende Multicast-IP-Paket zu einer Unicast-802-Adresse des MN senden. [Der Vater-AP kann das Multicast-IP-Paket nicht zu einer Multicast-802-Adresse senden, weil dies fälschlicherweise von MNs in einem anderen Broadcast-Bereich empfangen werden wird.] Multicast-Pakete, die von einem Proxy MIP MN in einem fremden Teilnetz übertragen werden, werden zu dem Heimatteilnetz des MN über einen MIP-"Rückwärtstunnel" weitergeleitet, wie dies in RFC 3024 beschrieben ist.
    Ein AP kann Mitgliedschaftsaufzeichnungen auf das lokale "fremde" LAN übertragen. Multicast-Router sind dann verantwortlich für das Weiterleiten von Multicast-Paketen zu dem fremden Teilnetz des MN. Der AP muß (d. h., selektiv) die Multicast-Pakete zu dem MN weiterleiten. Multicast-Pakete, die von einem Proxy MIP MN in einem fremden Teilnetz gesendet werden, werden auf das lokale, fremde Teilnetz übertragen. Ein Multicast-Router ist verantwortlich für das Weiterleiten der Multicast-Pakete zu dem Heimat-Teilnetz.
  • – Proxy-MIP-Broadcast-Bereiche.
  • Im Augenblick entspricht ein 802.11-Broadcast-Bereich einem VLAN. Proxy-MIP-Knoten sollten in einen Broadcast-Bereich aufgeteilt werden, der einem Heimat-Teilnetz entspricht. 802.11-Broadcast-Bereiche sollten so verallgemeinert werden, dass eine gemeinsame Funkschnittstelle für sowohl das VLAN als auch die Proxy MIP Broadcast-Bereiche verwendet wird. Wenn Proxy MIP MNs keine Broadcast-Nachrichten empfangen, dann kann ein einziger MIP Broadcast-Bereich dazu verwendet werden, alle Proxy MNs in fremden Teilnetzen zu gruppieren, die die gleiche 802.11-Broadcast-Verschlüsselungs-Suite gemeinsam benutzen. IP-Multicast-Pakete müssen je nach Notwendigkeit in einen Proxy MIP Broadcast-Bereich kopiert und übertragen werden. Es sei angemerkt, dass es nicht notwendig ist, Standard-MIP-MNs in solche Broadcast-Bereiche aufzuteilen.]
  • – IP-Adressenregistrierung.
  • Die IP-Adresse jeder MN-, AP- und CM-Schnittstelle wird optional bei dem CCM registriert, sobald sie entdeckt wird. IP/802-Adressenpaare werden in Registrierungsantwortnachrichten zu jedem AP und CM auf dem Pfad zu einem Knoten verteilt. Die IP/802-Adressenbindungen werden verwendet, um das automatische ARP-Filtern (siehe unten) zu ermöglichen.
  • – Kontextaufzeichnungen.
  • Jeder WLCCP CM nimmt Kontext- und Konfigurationsinformationen für jeden Knoten in seinem Bereich in einen Cachespeicher auf. In dem vorliegenden Dokument enthält eine "Kontextaufzeichnung" Kontext- und Konfigurationsinformationen, die transferiert werden, wenn eine Station von einem alten AP zu einem neuen AP roamt. Ein "Kontextmanager" in jedem AP oder CM verwaltet Kontextaufzeichnungen. Eine Kontextaufzeichnung wird als ein opakes Objekt in WLCCP-Registrierungs- und Kontextnachrichten transferiert. [Im Augenblick enthält eine Kontextaufzeichnung lediglich RADIUS-Konfigurationsinformationen.]
  • – Lateraler Kontexttransfer.
  • Eine Kontextnachricht kann verwendet werden, um einen dynamischen Kontext eines MN "lateral" von einem Knoten auf dem "alten" Zweig zu einem Knoten auf dem "neuen" Zweig weiterzuleiten (z. B. von einem alten SCM zu einem neuen SCM), wenn der MN roamt. Der am nächsten liegende gemeinsame Vorgänger-CM ermöglicht automatisch den lateralen Kontexttransfer, indem er die alten und neuen Bindungen des MN jeweils in Registrierungsantwort- und Deregistrierungsanfrage-Nachrichten weiterleitet. Zum Beispiel kann ein SCM die Adresse des "alten AP" zu dem "neuen AP" in einer Registrierungsantwort-Nachricht weiterleiten. Der am nächsten liegende gemeinsame Vorgänger-CM fungiert als eine vertrauenswürdige dritte Partei für die laterale Nachrichtenauthentifizierung, wie dies in dem Abschnitt mit dem Titel "WLCCP-Nachrichtenauthentifizierung" beschrieben ist.
  • Kontextinformationen können lateral in entweder einer Kontextanfrage- oder -antwort-Nachricht transferiert werden. Zum Beispiel kann ein alter AP asynchron Kontextinformationen zu einem neuen AP in einer Anfragenachricht weiterleiten. Als ein zweites Beispiel kann ein neuer SCM eine Kontextanfrage an einen alten SCM senden, um Kontextinformationen "anzufordern". Der alte CM sendet die Anfrage-Kontextinformationen in der entsprechenden Kontextantwortnachricht zurück.
  • – Dynamische ARP-Filterung.
  • Die IP-Adresse jedes Knotens in dem Unterbaum, der an einem "Wurzel-HP" wurzelt, ist bei der SWAN-Infrastruktur registriert. Die IP-Adresse eines MN wird zu dem neuen Vater-AP jedes Mal dann transferiert, wenn der MN roamt. Wenn die "ARP Translation" aktiviert ist, dann muß ein AP Broadcast-ARP-Anfragen filtern, die an sekundären 802.11-Ports übertragen werden. Eine ARP-Anfrage wird verworfen, wenn die Ziel-IP-Adresse nicht zu einem Knoten in seinem Unterbaum gehört; anderenfalls wird dann, wenn die Ziel-IP-Adresse zu einem Knoten in dem Unterbaum gehört, die Broadcast-Ziel-MAC-Adresse in die Unicast-MAC-Adresse des Knotens umgesetzt. Der sich ergebende Unicast-Rahmen wird dann wie alle anderen Unicast-Rahmen weitergeleitet.
  • – RADIUS-Abrechnung.
  • Ein RADIUS-Abrechnungs-Client in einem CLM unterhält eine einzige RADIUS-Abrechnungssitzung für jeden MN. Ein Vater-AP leitet periodisch Abrechnungsstatistiken eingehend in einer WTLV_ACCOUNTING TLV weiter, die in einer WLCCP-Kontextanfrage-Nachricht enthalten ist. Das WLCCP-Registrierungsprotokoll wird verwendet, um die Abrechnungssitzung zu transferieren, wenn ein MN roamt. Alle "restlichen" Abrechnungsstatistiken werden eingehend in Deregistrierungsantwort- und Abtrennanfrage-Nachrichten weitergeleitet, wenn ein MN roamt oder dessen Verbindung getrennt wird. Wenn ein MN zu einem "neuen" lokalen Kontrollbereich roamt, dann muß entweder a) eine neue Abrechnungssitzung an dem neuen LCM gestartet werden oder b) die Abrechnungssitzung muß von dem alten LCM zu dem neuen LCM über einen lateralen Kontexttransfer transferiert werden.
  • MN-Unterstützung für WLCCP
  • MNs nehmen nicht direkt am WLCCP teil. Statt dessen können MNs WLCCP-802.11-Elemente unterstützen, die Teilnetz- und Pfadkosteninformationen übermitteln. Die Elemente ermöglichen Folgendes:
    Ein MN kann einen Vater-AP auswählen, der den kostengünstigsten Pfad zu dem primären LAN in dem Heimat-Teilnetz des MN bereitstellt.
    • – Ein MN kann schnell feststellen, wann er zu einem anderen Teilnetz geroamt ist.
    • – Ein Standard-Mobile IP MN kann schnell einen MIP-Fremdagenten entdecken.
    • – Ein MN kann zuverlässig seine IP-Adresse registrieren.
    • – Ein MN kann zuverlässig seine aktivierten Multicast-Adressen registrieren.
  • 802.11-Elemente, die verwendet werden, um WLCCP-Informationen zu übermitteln, sind in dem Abschnitt mit dem Titel "WLCCP 802.11-Elemente" definiert.
  • Die obige Beschreibung eines bevorzugten Ausführungsbeispiels der Erfindung ist zu Zwecken der Veranschaulichung und der Beschreibung präsentiert worden. Sie ist nicht dazu gedacht, die Erfindung auf die präzise, offenbarte Form zu erschöpfen oder zu beschränken. Offensichtliche Modifikationen oder Variationen sind im Hinblick auf die obigen Lehren möglich. Das Ausführungsbeispiel wurde ausgewählt und beschrieben, um die beste Veranschaulichung der Prinzipien der Erfindung und ihrer praktischen Anwendung bereitzustellen, um dadurch einen Durchschnittsfachmann auf diesem Gebiet in die Lage zu versetzen, die Erfindung in verschiedenen Ausführungsbeispielen und mit verschiedenen Modifikationen zu verwenden, wie diese für die spezielle, in Erwägung gezogene Verwendung geeignet sind. Alle diese Modifikationen und Variationen liegen im Schutzbereich der Erfindung, wie dieser von den angehängten Ansprüchen bestimmt wird, wenn diese gemäß der Bedeutung interpretiert werden, in der sie angemessen, recht und billig berechtigt sind.

Claims (57)

  1. Verfahren zum Aufbau einer sicheren Verbindung für einen mobilen Knoten (616) mit einem Netz, das eine Vielzahl von Zugriffspunkten (608, 610) aufweist, mit den folgenden Schritten: Verbinden mit einem ersten Zugriffspunkt (608); Authentifizieren (102) des mobilen Knotens mittels eines erweiterbaren Authentifizierungsprotokolls durch den ersten Zugriffspunkt (608); Erstellen eines Netz-Sitzungsschlüssels (434); und Registrieren des mobilen Knotens in der Netz-Infrastruktur; wobei der Netz-Sitzungsschlüssel verwendet wird, um einen Haupt-Anfrageschlüssel (418) und einen Basis-Übergangsschlüssel (420) zu erstellen; wobei der Basis-Übergangsschlüssel (420) als Gegenmodus-Schlüsselgenerator verwendet wird, um neue paarweise Übergangsschlüssel bereit zu stellen; wobei der Haupt-Anfrageschlüssel von dem mobilen Knoten verwendet wird, um zu belegen, dass er eine geeignete Authentifizierung für eine Sitzung aufweist; wobei das Roaming zu einem zweiten Zugriffspunkt (610) einen komprimierten Satz von Nachrichtenaustausch mit einbezieht, um den Besitz eines neuen Übergangsschlüssels sowie das Liefern eines Gruppen-Übergangsschlüssels durch den zweiten Zugriffspunkt (610) zu belegen.
  2. Verfahren nach Anspruch 1, das des Weiteren das Senden des Netz-Sitzungsschlüssels an einen Subnet Context Manager (604) umfasst.
  3. Verfahren nach Anspruch 1 oder 2, wobei das erweiterbare Authentifizierungsprotokoll 802.1X-konform ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren Authentifizierungsschlüssel-Auffrischungen mittels des Haupt-Anfrageschlüssels umfasst.
  5. Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren das Ableiten von paarweisen Übergangsschlüsseln mittels des Basis-Übergangsschlüssels (420) umfasst.
  6. Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren das Liefern des Gruppen-Übergangsschlüssels in einer erneuten Verbindungsanfrage umfasst, um Nachrichten zu komprimieren und zu optimieren.
  7. Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren das Berechnen eines Haupt-Anfrageschlüssels und eines Basis-Übergangsschlüssels aus dem Netz-Sitzungsschlüssel mittels einer Pseudo-Random-Funktion umfasst.
  8. Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren das Senden einer erneuten Verbindungsanfrage (1512) umfasst, wobei die erneute Verbindungsanfrage eine erneute Schlüssel-Anfrage-Nummer und ein authentifiziertes Element umfasst.
  9. Verfahren nach Anspruch 8, das des Weiteren das Verifizieren umfasst, dass die erneute Schlüssel-Anfrage-Nummer der erneuten Verbindungsanfrage größer ist als eine vorhergehende erneute Schlüssel-Anfrage-Nummer.
  10. Verfahren nach Anspruch 8 oder 9, wobei die erneute Verbindungsanfrage des Weiteren Wiedergabeschutz aufweist.
  11. Verfahren nach Anspruch 10, wobei der Wiedergabeschutz einen Zeitstempel aufweist.
  12. Verfahren nach Anspruch 10, wobei der Wiedergabeschutz eine Random Challenge (zufällige Herausforderung) aufweist.
  13. Verfahren nach einem der Ansprüche 8 bis 12, wobei das authentifizierte Element die von dem mobilen Knoten definierte Sicherheitspolitik authentifiziert.
  14. Verfahren nach Anspruch 1, wobei das Roamen zu einem zweiten Zugriffspunkt (610) umfasst, dass sich der mobile Knoten (616) erneut mit dem zweiten Zugriffspunkt verbindet, wobei das erneute Verbinden umfasst: Senden einer erneuten Verbindungsanfrage (512) von dem mobilen Knoten an den zweiten Zugriffspunkt, wobei die erneute Verbindungsanfrage eine Identifizierung des mobilen Knotens, eine erneute Schlüssel-Anfrage-Nummer (1532) und ein Authentifizierungselement aufweist; Validieren der aktuellen Sicherheitsverbindung mit dem Netz mittels des Haupt-Anfrageschlüssels; Sicherstellen, dass ein neuer Übergangsschlüssel verwendet wird, um eine 802.11-Verbindung mit dem zweiten Zugriffspunkt zu sichern mittels einer inkrementellen erneuten Schlüssel-Anfrage-Nummer; Senden einer Antwort (1520), wobei die Antwort ein Authentifizierungselement aufweist, an den mobilen Knoten, wobei das Authentifizierungselement das Liefern des Gruppen-Übergangsschlüssels umfasst, und Belegen des Besitzes eines paarweisen Übergangsschlüssels durch Verwenden des Schlüssels, um das Element zu authentifizieren; Verwenden eines erweiterbaren Authentifizierungsprotokolls über den Local Area Network Schlüssel; und Bestätigen der Antwort (1522) durch Verifizieren des neuen paarweisen Übergangsschlüssels auf einen zweiten berechneten paarweisen Übergangsschüssel.
  15. Verfahren nach Anspruch 14, das des Weiteren das Validieren der Antwort durch Verifizieren des neuen paarweisen Übergangsschlüssels umfasst.
  16. Verfahren nach Anspruch 15, wobei das Validieren des Antwortschritts des Weiteren das Verifizieren eines in der Antwort enthaltenen Zeitstempels umfasst.
  17. Verfahren nach einem der Ansprüche 14 bis 16, wobei das Authentifizierungselement einen aktuellen neuen paarweisen Übergangsschlüssel verwendet.
  18. Verfahren nach einem der Ansprüche 14 bis 17, wobei der Validierungsschritt von einem der Gruppe bestehend aus einem Subnet Context Manager (604) und dem Zugriffsserver (602) durchgeführt wird.
  19. Verfahren nach einem der Ansprüche 14 bis 18, wobei die Validierungsanfrage das Verifizieren umfasst, dass ein Zeitstempel der erneuten Verbindungsanfrage innerhalb eines konfigurierbaren Werts liegt.
  20. Verfahren nach einem der Ansprüche 14 bis 19, wobei der Validierungsschritt des Weiteren das Verifizieren umfasst, dass eine Sequenznummer für die Antwort größer ist als ein vorhergehender Wert.
  21. Verfahren nach einem der Ansprüche 14 bis 20, wobei der Validierungsschritt das Senden einer Anfrage an den Subnet Context Manager (604) umfasst, um die erneute Verbindungsanfrage zu validieren.
  22. Verfahren nach Anspruch 21, das des Weiteren das Empfangen einer Sitzungs-Zeitüberschreitung des mobilen Knotens und eines Basis-Übergangsschlüssels von dem Subnet Context Manager (604) umfasst.
  23. Verfahren nach Anspruch 22, das des Weiteren das Erzeugen eines paarweisen Übergangsschlüssels umfasst, wobei der Sendeschritt des Weiteren umfasst: Authentifizieren der erneuten Schlüssel-Nummer und des Basis-Übergangsschlüssels, wodurch eine authentifizierte Antwort gebildet wird; und Senden der verschlüsselten Antwort.
  24. Verfahren nach einem der Ansprüche 14 bis 23, das des Weiteren umfasst: Berechnen eines Authentifizierungselements, wobei das Authentifizierungselement eine erneute Schlüssel-Anfrage-Nummer und ein neues Paar Übergangsschlüssel aufweist; Senden eines Anrufs für einen neuen paarweisen Übergangsschlüssel an einen Antwortenden (1514) und Benachrichtigen des Antwortenden, dass der Anfragende bereit ist, mittels des neuen paarweisen Übergangsschlüssels zu senden und zu empfangen; Empfangen eines Antwort-Authentifizierungselements (1520) von dem Antwortenden; und Verifizieren des Antwort-Authentifizierungselements (1522), wobei das Antwort-Authentifizierungselement das neue Paar Übergangsschlüssel und den Empfang des Gruppen-Übergangsschlüssels enthält.
  25. Verfahren nach Anspruch 24, das des Weiteren das Senden eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüssel-Bestätigungsnachricht umfasst.
  26. Verfahren nach Anspruch 24 oder 25, das des Weiteren das Inkrementieren der erneuten Schlüssel-Anfrage-Nummer vor dem Berechnen des Authentifizierungselements umfasst.
  27. Verfahren nach einem der Ansprüche 1 bis 26, das des Weiteren umfasst: Empfangen einer erneuten Schlüssel-Anfrage, wobei die erneute Schlüssel-Anfrage eine erneute Schlüssel-Anfrage-Nummer (1532) und ein Authentifizierungselement aufweist, das die Lieferung des Gruppen-Übergangsschlüssels enthält; Berechnen eines neuen Paars von Übergangsschlüsseln; und Senden eines Bereit-zum-Senden-und-Empfangen (1514) mit der Nachricht mit dem neuen Paar von Übergangsschlüsseln.
  28. Verfahren nach Anspruch 27, das des Weiteren das Empfangen eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüssel-Bestätigungsnachricht umfasst.
  29. Verfahren nach Anspruch 27 oder 28, das des Weiteren das Verifizieren umfasst, dass die erneute Schlüssel-Anfrage-Nummer größer ist als eine in den Cachespeicher aufgenommene erneute Schlüssel-Anfrage-Nummer.
  30. Verfahren nach einem der Ansprüche 27 bis 29, das des Weiteren das Verifizieren aller Attribute eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüsselanfrage umfasst.
  31. Verfahren nach einem der Ansprüche 27 bis 30, das des Weiteren das Aktualisieren einer in den Cachespeicher aufgenommenen erneuten Schlüssel-Anfrage-Nummer umfasst.
  32. Verfahren nach einem der Ansprüche 27 bis 31, wobei das Authentifizierungselement (1506) ein neues Initiator-Paar von Übergangsschlüsseln aufweist, wobei die Schritte des Weiteren das Vergleichen des neuen Paars von Übergangsschlüsseln mit dem neuen Initiator-Paar von Übergangsschlüsseln umfassen.
  33. Verfahren nach einem der Ansprüche 27 bis 32, wobei das Authentifizierungselement (1506) einen umhüllten Haupt-Gruppen-Übergangsschlüssel aufweist.
  34. Mobiler Knoten (616) mit: einer Einrichtung zur Verbindung mit einem ersten Zugriffspunkt (608), einer Einrichtung zum Authentifizieren (102) des mobilen Knotens mittels eines erweiterbaren Authentifizierungsprotokolls durch den ersten Zugriffspunkt (608); einer Einrichtung zur Erstellung eines Netz-Sitzungsschlüssels (434); und einer Einrichtung zum Registrieren des mobilen Knotens in der Netz-Infrastruktur; wobei der Netz-Sitzungsschlüssel verwendet wird, um einen Haupt-Anfrageschlüssel (418) und einen Basis-Übergangsschlüssel (420) zu erstellen (104); wobei der Basis-Übergangsschlüssel (420) als Gegenmodus-Schlüsselgenerator verwendet wird, um neue paarweise Übergangsschlüssel bereit zu stellen; wobei der Haupt-Anfrageschlüssel von dem mobilen Knoten verwendet wird, um zu belegen, dass er eine geeignete Authentifizierung für eine Sitzung aufweist; wobei das Roaming zu einem zweiten Zugriffspunkt (610) einen komprimierten Satz von Nachrichtenaustausch mit einbezieht, um den Besitz eines neuen Übergangsschlüssels sowie das Liefern eines Gruppen-Übergangsschlüssels durch den zweiten Zugriffspunkt (610) zu belegen.
  35. Mobiler Knoten nach Anspruch 34, der des Weiteren eine Einrichtung zum Senden des Netz-Sitzungsschlüssels an einen Subnet Context Manager (604) aufweist.
  36. Mobiler Knoten nach Anspruch 34 oder 35, wobei das erweiterbare Authentifizierungsprotokoll 802.1X-konform ist.
  37. Mobiler Knoten nach einem der Ansprüche 34 bis 36, der des Weiteren eine Einrichtung zum Authentifizieren von Schlüssel-Auffrischungen mittels des Haupt-Anfrageschlüssels aufweist.
  38. Mobiler Knoten nach einem der Ansprüche 34 bis 37, der des Weiteren eine Einrichtung zum Ableiten von paarweisen Übergangsschlüsseln mittels des Basis-Übergangsschlüssels aufweist.
  39. Mobiler Knoten nach einem der Ansprüche 34 bis 38, der des Weiteren eine Einrichtung zum Liefern des Gruppen-Übergangsschlüssels in einer erneuten Verbindungsanfrage aufweist, um Nachrichten zu komprimieren und zu optimieren.
  40. Mobiler Knoten nach einem der Ansprüche 34 bis 39, der des Weiteren eine Einrichtung zum Berechnen eines Haupt-Anfrageschlüssels und eines Basis-Übergangsschlüssels aus dem Netz-Sitzungsschlüssel mittels einer Pseudo-Random-Funktion aufweist.
  41. Mobiler Knoten nach einem der Ansprüche 34 bis 40, der des Weiteren eine Einrichtung zum Senden einer erneuten Verbindungsanfrage (1512) aufweist, wobei die erneute Verbindungsanfrage eine erneute Schlüssel-Anfrage-Nummer und ein authentifiziertes Element umfasst.
  42. Mobiler Knoten nach Anspruch 41, der des Weiteren eine Einrichtung zum Verifizieren aufweist, dass die erneute Schlüssel-Anfrage-Nummer der erneuten Verbindungsanfrage größer ist als eine vorhergehende erneute Schlüssel-Anfrage-Nummer.
  43. Mobiler Knoten nach Anspruch 41 oder 42, wobei die erneute Verbindungsanfrage des Weiteren eine Einrichtung zum Wiedergabeschutz aufweist.
  44. Mobiler Knoten nach Anspruch 43, wobei die Einrichtung für Wiedergabeschutz eine Einrichtung zur Verwendung eines Zeitstempels aufweist.
  45. Mobiler Knoten n ach Anspruch 43, wobei die Einrichtung für Wiedergabeschutz eine Einrichtung für eine Random Challenge (zufällige Herausforderung) aufweist.
  46. Mobiler Knoten nach einem der Ansprüche 41 bis 45, wobei das authentifizierte Element die von dem mobilen Knoten definierte Sicherheitspolitik authentifiziert.
  47. Mobiler Knoten nach einem der Ansprüche 34 bis 46, der des Weiteren eine Einrichtung zum Initiieren und Durchführen einer erneuten Schlüsselsequenz aufweist, mit: einer Einrichtung zum Berechnen (1502) eines Authentifizierungselements, wobei das Authentifizierungselement eine erneute Schlüssel-Anfrage-Nummer und eine Einrichtung für ein neues Paar Übergangsschlüssel aufweist zum Senden eines Anrufs für einen neuen paarweisen Übergangsschlüssel an einen Antwortenden (1506) und zum Benachrichtigen des Antwortenden, dass der Anfragende bereit ist, mittels des neuen paarweisen Übergangsschlüssels zu senden und zu empfangen; einer Einrichtung zum Empfangen eines Antwort-Authentifizierungselements (1520) von dem Antwortenden; und einer Einrichtung zum Verifizieren des Antwort-Authentifizierungselements (1522), wobei das Antwort-Authentifizierungselement das neue Paar Übergangsschlüssel und den Empfang des Gruppen-Übergangsschlüssels enthält.
  48. Mobiler Knoten nach Anspruch 47, der des Weiteren eine Einrichtung zum Senden eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüssel-Bestätigungsnachricht aufweist.
  49. Mobiler Knoten nach Anspruch 47 oder 48, der des Weiteren eine Einrichtung zum Inkrementieren der erneuten Schlüssel-Anfrage-Nummer vor dem Berechnen des Authentifizierungselements aufweist.
  50. Computerprogramm, Computerprogramm-Erzeugnis oder computerlesbares Medium, das Befehle zum Durchführen eines Verfahrens gemäß einem der Ansprüche 1 bis 33 aufweist.
  51. Vorrichtung zum Antworten auf eine erneute Schlüsselsequenz (1506), die aufweist: eine Einrichtung zum Empfangen einer erneuten Schlüssel-Anfrage, wobei die erneute Schlüssel-Anfrage eine erneute Schlüssel-Anfrage-Nummer und ein Authentifizierungselement aufweist, das die Lieferung des Gruppen-Übergangsschlüssels enthält; eine Einrichtung zum Berechnen eines neuen Paars von Übergangsschlüsseln; und eine Einrichtung zum Senden eines Bereit-zum-Senden-und-Empfangen mit der Nachricht mit dem neuen Paar von Übergangsschlüsseln.
  52. Vorrichtung nach Anspruch 51, die des Weiteren eine Einrichtung zum Empfangen eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüssel-Bestätigungsnachricht umfasst.
  53. Vorrichtung nach Anspruch 51 oder 52, die des Weiteren eine Einrichtung zum Verifizieren aufweist, dass die erneute Schlüssel-Anfrage-Nummer größer ist als eine in den Cachespeicher aufgenommene erneute Schlüssel-Anfrage-Nummer.
  54. Vorrichtung nach einem der Ansprüche 51 bis 53, die des Weiteren eine Einrichtung zum Verifizieren aller Attribute eines erweiterbaren Authentifizierungsprotokolls über eine Local Area Network Schlüsselanfrage aufweist.
  55. Vorrichtung nach einem der Ansprüche 51 bis 54, die des Weiteren eine Einrichtung zum Aktualisieren einer in den Cachespeicher aufgenommenen erneuten Schlüssel-Anfrage-Nummer aufweist.
  56. Vorrichtung nach einem der Ansprüche 51 bis 55, wobei das Authentifizierungselement ein neues Initiator-Paar von Übergangsschlüsseln aufweist, wobei die Schritte des Weiteren das Vergleichen des neuen Paars von Übergangsschlüsseln mit dem neuen Initiator-Paar von Übergangsschlüsseln umfassen.
  57. Vorrichtung nach einem der Ansprüche 51 bis 56, wobei das Authentifizierungselement einen umhüllten Haupt-Gruppen-Übergangsschlüssel aufweist.
DE60318244T 2002-11-26 2003-11-13 802.11-standard benutzung eines komprimierten reassoziationsaustauschs für schnelles weiterreichen Expired - Lifetime DE60318244T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US42971402P 2002-11-26 2002-11-26
US429714P 2002-11-26
US43941903P 2003-01-10 2003-01-10
US439419P 2003-01-10
US10/417,653 US7350077B2 (en) 2002-11-26 2003-04-17 802.11 using a compressed reassociation exchange to facilitate fast handoff
US417653 2003-04-17
PCT/US2003/036061 WO2004049740A2 (en) 2002-11-26 2003-11-13 802.11using a compressed reassociation exchange to facilitate fast handoff

Publications (2)

Publication Number Publication Date
DE60318244D1 DE60318244D1 (de) 2008-01-31
DE60318244T2 true DE60318244T2 (de) 2008-11-06

Family

ID=32329838

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60318244T Expired - Lifetime DE60318244T2 (de) 2002-11-26 2003-11-13 802.11-standard benutzung eines komprimierten reassoziationsaustauschs für schnelles weiterreichen

Country Status (8)

Country Link
US (4) US7350077B2 (de)
EP (1) EP1570625B1 (de)
CN (2) CN101742496B (de)
AT (1) ATE381842T1 (de)
AU (1) AU2003295466C1 (de)
CA (1) CA2507119C (de)
DE (1) DE60318244T2 (de)
WO (1) WO2004049740A2 (de)

Families Citing this family (504)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002322109A1 (en) * 2001-06-13 2002-12-23 Intruvert Networks, Inc. Method and apparatus for distributed network security
US7830787B1 (en) 2001-09-25 2010-11-09 Cisco Technology, Inc. Flooding control for multicast distribution tunnel
EP1303097A3 (de) * 2001-10-16 2005-11-30 Microsoft Corporation Virtuelles verteiltes Sicherheitsystem
US7471661B1 (en) * 2002-02-20 2008-12-30 Cisco Technology, Inc. Methods and apparatus for supporting proxy mobile IP registration in a wireless local area network
US7737134B2 (en) * 2002-03-13 2010-06-15 The Texas A & M University System Anticancer agents and use
US6965903B1 (en) 2002-05-07 2005-11-15 Oracle International Corporation Techniques for managing hierarchical data with link attributes in a relational database
GB0220660D0 (en) * 2002-09-05 2002-10-16 Nokia Corp Signal propogation delay routing
KR100480258B1 (ko) * 2002-10-15 2005-04-07 삼성전자주식회사 무선 근거리 네트워크에서 고속 핸드오버를 위한 인증방법
US6947950B2 (en) * 2002-11-06 2005-09-20 Oracle International Corporation Techniques for managing multiple hierarchies of data from a single interface
US7475241B2 (en) * 2002-11-22 2009-01-06 Cisco Technology, Inc. Methods and apparatus for dynamic session key generation and rekeying in mobile IP
AU2003279488A1 (en) * 2002-12-11 2004-06-30 Koninklijke Philips Electronics N.V. System and method for performing a fast handoff in a wireless local area network
US7457289B2 (en) 2002-12-16 2008-11-25 Cisco Technology, Inc. Inter-proxy communication protocol for mobile IP
US7870389B1 (en) 2002-12-24 2011-01-11 Cisco Technology, Inc. Methods and apparatus for authenticating mobility entities using kerberos
KR100510127B1 (ko) * 2002-12-31 2005-08-25 삼성전자주식회사 무선랜 환경에서 핸드오버 방법 및 모바일 노드의핸드오버 장치
US7395427B2 (en) * 2003-01-10 2008-07-01 Walker Jesse R Authenticated key exchange based on pairwise master key
US7263357B2 (en) * 2003-01-14 2007-08-28 Samsung Electronics Co., Ltd. Method for fast roaming in a wireless network
US7362742B1 (en) 2003-01-28 2008-04-22 Cisco Technology, Inc. Methods and apparatus for synchronizing subnet mapping tables
KR100929101B1 (ko) * 2003-02-17 2009-11-30 삼성전자주식회사 아이피 통신망에서 모바일 아이피의 홉 계산 방법
US20040236939A1 (en) * 2003-02-20 2004-11-25 Docomo Communications Laboratories Usa, Inc. Wireless network handoff key
EP1606904B1 (de) * 2003-03-14 2018-11-28 Thomson Licensing Flexible wlan-zugangspunktarchitektur mit der fähigkeit der berücksichtigung verschiedener benutzereinrichtungen
US20040184422A1 (en) * 2003-03-17 2004-09-23 Interdigital Technology Corporation Method and apparatus for performing a handoff in an inter-extended service set (I-ESS)
WO2004086783A1 (en) 2003-03-24 2004-10-07 Strix Systems, Inc. Node placement method within a wireless network, such as a wireless local area network
EP1606958A4 (de) * 2003-03-24 2011-04-13 Strix Systems Inc Selbstkonfigurierendes, selbstoptimierendes drahtloses lokales netzwerksystem
US7505432B2 (en) * 2003-04-28 2009-03-17 Cisco Technology, Inc. Methods and apparatus for securing proxy Mobile IP
US7949732B1 (en) 2003-05-12 2011-05-24 Sourcefire, Inc. Systems and methods for determining characteristics of a network and enforcing policy
JP4105722B2 (ja) * 2003-05-27 2008-06-25 富士通株式会社 通信装置
US8019082B1 (en) * 2003-06-05 2011-09-13 Mcafee, Inc. Methods and systems for automated configuration of 802.1x clients
CN1265589C (zh) * 2003-07-31 2006-07-19 华为技术有限公司 无线局域网中用户终端选择接入移动网的优化交互方法
US20050033701A1 (en) * 2003-08-08 2005-02-10 International Business Machines Corporation System and method for verifying the identity of a remote meter transmitting utility usage data
US20050036623A1 (en) * 2003-08-15 2005-02-17 Ming-Jye Sheu Methods and apparatus for distribution of global encryption key in a wireless transport network
US7233991B2 (en) * 2003-08-22 2007-06-19 Clearmesh Networks, Inc. Self-healing tree network
JP3888342B2 (ja) * 2003-08-29 2007-02-28 ブラザー工業株式会社 ネットワーク装置
US8694510B2 (en) 2003-09-04 2014-04-08 Oracle International Corporation Indexing XML documents efficiently
US8229932B2 (en) 2003-09-04 2012-07-24 Oracle International Corporation Storing XML documents efficiently in an RDBMS
US7530112B2 (en) 2003-09-10 2009-05-05 Cisco Technology, Inc. Method and apparatus for providing network security using role-based access control
US8027679B2 (en) * 2003-09-12 2011-09-27 Ntt Docomo, Inc. Secure intra- and inter-domain handover
US7640359B1 (en) 2003-09-19 2009-12-29 At&T Intellectual Property, I, L.P. Method, system and computer program product for facilitating the design and assignment of ethernet VLANs
US7624187B1 (en) 2003-09-19 2009-11-24 At&T Intellectual Property, I, L.P. Method, system and computer program product for providing Ethernet VLAN capacity requirement estimation
US7523484B2 (en) * 2003-09-24 2009-04-21 Infoexpress, Inc. Systems and methods of controlling network access
US7844266B2 (en) * 2003-09-30 2010-11-30 Intel Corporation Wireless network roaming timer method and apparatus
US20050130647A1 (en) * 2003-10-22 2005-06-16 Brother Kogyo Kabushiki Kaisha Wireless lan system, communication terminal and communication program
US7836490B2 (en) * 2003-10-29 2010-11-16 Cisco Technology, Inc. Method and apparatus for providing network security using security labeling
JP4784867B2 (ja) * 2003-11-10 2011-10-05 エスティー‐エリクソン、ソシエテ、アノニム 省電力モードで動作する無線装置に対してサービスを提供する方法及びシステム
US7505596B2 (en) * 2003-12-05 2009-03-17 Microsoft Corporation Automatic detection of wireless network type
US7002943B2 (en) * 2003-12-08 2006-02-21 Airtight Networks, Inc. Method and system for monitoring a selected region of an airspace associated with local area networks of computing devices
EP1549010B1 (de) * 2003-12-23 2008-08-13 Motorola Inc. Schlüsselaktualisierung in sicherer Multicastkommunikation
KR100744531B1 (ko) * 2003-12-26 2007-08-01 한국전자통신연구원 무선 단말기용 암호키 관리 시스템 및 방법
WO2005064892A1 (en) * 2003-12-30 2005-07-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for handling context of data packet flows
US7339914B2 (en) 2004-02-11 2008-03-04 Airtight Networks, Inc. Automated sniffer apparatus and method for monitoring computer systems for unauthorized access
US7440434B2 (en) * 2004-02-11 2008-10-21 Airtight Networks, Inc. Method and system for detecting wireless access devices operably coupled to computer local area networks and related methods
US7221927B2 (en) * 2004-02-13 2007-05-22 Trapeze Networks, Inc. Station mobility between access points
US7925778B1 (en) 2004-02-13 2011-04-12 Cisco Technology, Inc. Method and apparatus for providing multicast messages across a data communication network
US7477894B1 (en) * 2004-02-23 2009-01-13 Foundry Networks, Inc. Methods and apparatus for handling wireless roaming among and across wireless area networks
EP1721477B1 (de) * 2004-03-03 2013-12-11 The Trustees of Columbia University in the City of New York Verfahren und systeme zur reduktion der mac-schicht-weiterreichungslatenz in drahtlosen netzen
US7805603B2 (en) * 2004-03-17 2010-09-28 Intel Corporation Apparatus and method of protecting management frames in wireless LAN communications
US7689305B2 (en) * 2004-03-26 2010-03-30 Harman International Industries, Incorporated System for audio-related device communication
US7930277B2 (en) 2004-04-21 2011-04-19 Oracle International Corporation Cost-based optimizer for an XML data repository within a database
US20050238171A1 (en) * 2004-04-26 2005-10-27 Lidong Chen Application authentication in wireless communication networks
DE602005025334D1 (de) * 2004-05-07 2011-01-27 Panasonic Corp Drahtlose knotenvorrichtung und drahtloses mehrstrom-lan-system
EP1762114B1 (de) * 2004-05-24 2015-11-04 Google, Inc. Standortbasierte zugangskontrolle in einem drahtlosen netzwerk
US7447188B1 (en) * 2004-06-22 2008-11-04 Cisco Technology, Inc. Methods and apparatus for supporting mobile IP proxy registration in a system implementing mulitple VLANs
US20060013231A1 (en) * 2004-06-22 2006-01-19 Sbc Knowledge Ventures, Lp Consolidated ethernet optical network and apparatus
US8161184B2 (en) * 2004-06-25 2012-04-17 Apple Inc. Method and apparatus for facilitating long-lived DNS queries
ATE466455T1 (de) * 2004-07-02 2010-05-15 Alcatel Lucent Verfahren zum verbindungsaufbau zwischen knoten mit mehrfachen netzwerk-fähigkeiten
US20070208946A1 (en) * 2004-07-06 2007-09-06 Oracle International Corporation High performance secure caching in the mid-tier
US7451316B2 (en) * 2004-07-15 2008-11-11 Cisco Technology, Inc. Method and system for pre-authentication
US7539681B2 (en) * 2004-07-26 2009-05-26 Sourcefire, Inc. Methods and systems for multi-pattern searching
WO2006022469A1 (en) * 2004-08-25 2006-03-02 Electronics And Telecommunications Research Institute Method for security association negociation with extensible authentication protocol in wireless portable internet system
US7649836B2 (en) * 2004-09-02 2010-01-19 Intel Corporation Link state machine for the advanced switching (AS) architecture
TWI416885B (zh) * 2004-09-10 2013-11-21 Interdigital Tech Corp 於無線區域網路中實施智慧天線
US20060056345A1 (en) * 2004-09-10 2006-03-16 Interdigital Technology Corporation Method and system for supporting use of a smart antenna in a wireless local area network
US8504110B2 (en) * 2004-09-10 2013-08-06 Interdigital Technology Corporation Method and apparatus for transferring smart antenna capability information
AU2005284753B2 (en) * 2004-09-15 2010-05-20 Nokia Technologies Oy Requesting and/or allocating communication resources at a new access point before transmitting a reassociation request
CN101053210B (zh) * 2004-09-15 2010-08-25 诺基亚有限公司 用于进行通信的方法和用于通信的设备
US20060193300A1 (en) * 2004-09-16 2006-08-31 Airtight Networks, Inc. (F/K/A Wibhu Technologies, Inc.) Method and apparatus for monitoring multiple network segments in local area networks for compliance with wireless security policy
US7958208B2 (en) * 2004-09-22 2011-06-07 At&T Intellectual Property I, L.P. System and method for designing a customized switched metro Ethernet data network
US7639802B2 (en) * 2004-09-27 2009-12-29 Cisco Technology, Inc. Methods and apparatus for bootstrapping Mobile-Foreign and Foreign-Home authentication keys in Mobile IP
US20060072532A1 (en) * 2004-09-30 2006-04-06 Motorola, Inc. Method and system for proactive setup of multicast distribution tree at a neighbor cell or subnet during a call
US7236477B2 (en) * 2004-10-15 2007-06-26 Motorola, Inc. Method for performing authenticated handover in a wireless local area network
US7558388B2 (en) * 2004-10-15 2009-07-07 Broadcom Corporation Derivation method for cached keys in wireless communication system
US7669244B2 (en) * 2004-10-21 2010-02-23 Cisco Technology, Inc. Method and system for generating user group permission lists
US20060090003A1 (en) * 2004-10-22 2006-04-27 Microsoft Corporation Rendezvousing resource requests with corresponding resources
US8619774B2 (en) * 2004-10-26 2013-12-31 Cisco Technology, Inc. Method and apparatus for providing multicast messages within a virtual private network across a data communication network
US7697688B1 (en) 2004-10-27 2010-04-13 Marvell International Ltd. Pipelined packet encapsulation and decapsulation for temporal key integrity protocol employing arcfour algorithm
US7742594B1 (en) 2004-10-27 2010-06-22 Marvell International Ltd. Pipelined packet encryption and decryption using counter mode with cipher-block chaining message authentication code protocol
US7877796B2 (en) * 2004-11-16 2011-01-25 Cisco Technology, Inc. Method and apparatus for best effort propagation of security group information
US7502331B2 (en) * 2004-11-17 2009-03-10 Cisco Technology, Inc. Infrastructure-less bootstrapping: trustless bootstrapping to enable mobility for mobile devices
TWI268083B (en) * 2004-11-17 2006-12-01 Draytek Corp Method used by an access point of a wireless LAN and related apparatus
TWI271976B (en) * 2004-11-22 2007-01-21 Realtek Semiconductor Corp Wireless communication apparatus capable of performing load balancing and method thereof
US7721323B2 (en) 2004-11-23 2010-05-18 Cisco Technology, Inc. Method and system for including network security information in a frame
US7886145B2 (en) * 2004-11-23 2011-02-08 Cisco Technology, Inc. Method and system for including security information with a packet
US7369856B2 (en) * 2004-11-24 2008-05-06 Intel Corporation Method and system to support fast hand-over of mobile subscriber stations in broadband wireless networks
US7627547B2 (en) * 2004-11-29 2009-12-01 Oracle International Corporation Processing path-based database operations
US7734051B2 (en) * 2004-11-30 2010-06-08 Novell, Inc. Key distribution
US7827402B2 (en) 2004-12-01 2010-11-02 Cisco Technology, Inc. Method and apparatus for ingress filtering using security group information
EP1670179B1 (de) * 2004-12-09 2007-11-28 Research In Motion Limited Vorrichtung und Verfahren für zwei oder mehrere "delivery traffic indication message (DTIM)" Perioden in drahtlosen Netzen
JP2008523769A (ja) * 2004-12-13 2008-07-03 テルコーディア テクノロジーズ インコーポレイテッド アドホックネットワークのための軽いパケット廃棄検出
US7921076B2 (en) 2004-12-15 2011-04-05 Oracle International Corporation Performing an action in response to a file system event
US8131766B2 (en) * 2004-12-15 2012-03-06 Oracle International Corporation Comprehensive framework to integrate business logic into a repository
CN101120609A (zh) * 2004-12-21 2008-02-06 松下电器产业株式会社 接入网络系统、基站装置、网络连接装置、移动终端和验证方法
US8085727B2 (en) * 2004-12-23 2011-12-27 Avaya Inc. Method and apparatus to facilitate the closure of mobility tunnels
US7610610B2 (en) 2005-01-10 2009-10-27 Mcafee, Inc. Integrated firewall, IPS, and virus scanner system and method
US7499438B2 (en) * 2005-01-13 2009-03-03 2Wire, Inc. Controlling wireless access to a network
US7535880B1 (en) * 2005-01-13 2009-05-19 2Wire, Inc. Method and apparatus for controlling wireless access to a network
US8005032B2 (en) * 2005-01-21 2011-08-23 Research In Motion Limited Maintaining delivery traffic indication message (DTIM) periods on a per-wireless client device basis
US7593417B2 (en) 2005-01-21 2009-09-22 Research In Motion Limited Handling broadcast and multicast traffic as unicast traffic in a wireless network
JP4173866B2 (ja) * 2005-02-21 2008-10-29 富士通株式会社 通信装置
KR20060094453A (ko) * 2005-02-24 2006-08-29 삼성전자주식회사 Ｅａｐ 를 이용한 시간제 서비스에 대한 인증 방법 및 그시스템
FR2882599B1 (fr) * 2005-02-25 2007-05-04 Somfy Soc Par Actions Simplifi Systeme de communication avec comptabilite croisee et trame de communication associee
US20060199585A1 (en) * 2005-03-01 2006-09-07 Nokia Corporation Classmark provision for terminal-initiated handover
US7996558B2 (en) * 2005-03-01 2011-08-09 Industrial Technology Research Institute Methods and systems for a routing protocol
EP1865624A4 (de) * 2005-03-14 2009-04-15 Mitsubishi Electric Corp Schicht-2-mobilitäts-netzwerk
EP1867094A2 (de) 2005-03-15 2007-12-19 Trapeze Networks, Inc. System und verfahren zum verteilen von schlüsseln in einem drahtlosen netzwerk
CN101142784B (zh) * 2005-03-17 2012-12-19 韩国电子通信研究院 无线便携式因特网系统中用户站安全相关功能的协商方法
US7624271B2 (en) * 2005-03-24 2009-11-24 Intel Corporation Communications security
JP4679205B2 (ja) * 2005-03-31 2011-04-27 Ｎｅｃインフロンティア株式会社 認証システム、装置、方法、プログラム、および通信端末
US7706789B2 (en) * 2005-03-31 2010-04-27 Intel Corporation Techniques to manage roaming
US7606370B2 (en) * 2005-04-05 2009-10-20 Mcafee, Inc. System, method and computer program product for updating security criteria in wireless networks
US7757274B2 (en) 2005-04-05 2010-07-13 Mcafee, Inc. Methods and systems for exchanging security information via peer-to-peer wireless networks
US7822972B2 (en) * 2005-04-05 2010-10-26 Mcafee, Inc. Remotely configurable bridge system and method for use in secure wireless networks
US7761710B2 (en) * 2005-04-05 2010-07-20 Mcafee, Inc. Captive portal system and method for use in peer-to-peer networks
US7636940B2 (en) * 2005-04-12 2009-12-22 Seiko Epson Corporation Private key protection for secure servers
US8850194B2 (en) * 2005-04-19 2014-09-30 Motorola Solutions, Inc. System and methods for providing multi-hop access in a communications network
KR100628566B1 (ko) * 2005-04-25 2006-09-26 삼성전자주식회사 무선랜에서 보안 정보 형성 방법
US20060240802A1 (en) * 2005-04-26 2006-10-26 Motorola, Inc. Method and apparatus for generating session keys
US7443809B2 (en) * 2005-04-27 2008-10-28 Symbol Technologies, Inc. Method, system and apparatus for creating a mesh network of wireless switches to support layer 3 roaming in wireless local area networks (WLANs)
US20060245393A1 (en) * 2005-04-27 2006-11-02 Symbol Technologies, Inc. Method, system and apparatus for layer 3 roaming in wireless local area networks (WLANs)
US7515573B2 (en) * 2005-04-27 2009-04-07 Symbol Technologies, Inc. Method, system and apparatus for creating an active client list to support layer 3 roaming in wireless local area networks (WLANS)
JP4818639B2 (ja) * 2005-05-13 2011-11-16 株式会社エヌ・ティ・ティ・ドコモ データバックアップシステム
KR101253352B1 (ko) * 2005-05-13 2013-04-11 유니버시티 오브 매릴랜드 칼리지 팍 무선 분산 시스템의 단말 인증 방법
WO2006121307A1 (en) * 2005-05-13 2006-11-16 Samsung Electronics Co., Ltd. Authentication method for wireless distributed system
KR100736034B1 (ko) * 2005-05-18 2007-07-06 삼성전자주식회사 중계 포탈을 사용하여 유선 및 무선 네트워크에 데이터를송수신하는 방법
US20060268834A1 (en) * 2005-05-26 2006-11-30 Symbol Technologies, Inc. Method, system and wireless router apparatus supporting multiple subnets for layer 3 roaming in wireless local area networks (WLANs)
US7529203B2 (en) * 2005-05-26 2009-05-05 Symbol Technologies, Inc. Method, system and apparatus for load balancing of wireless switches to support layer 3 roaming in wireless local area networks (WLANs)
KR101248906B1 (ko) * 2005-05-27 2013-03-28 삼성전자주식회사 무선 랜에서의 키 교환 방법
US7606178B2 (en) * 2005-05-31 2009-10-20 Cisco Technology, Inc. Multiple wireless spanning tree protocol for use in a wireless mesh network
US7653011B2 (en) * 2005-05-31 2010-01-26 Cisco Technology, Inc. Spanning tree protocol for wireless networks
US20060285519A1 (en) * 2005-06-15 2006-12-21 Vidya Narayanan Method and apparatus to facilitate handover key derivation
CN101204038A (zh) * 2005-06-16 2008-06-18 法国电信公司 鉴权协议转换方法
US7716724B2 (en) * 2005-06-16 2010-05-11 Verizon Business Global Llc Extensible authentication protocol (EAP) state server
US20070002833A1 (en) * 2005-06-30 2007-01-04 Symbol Technologies, Inc. Method, system and apparatus for assigning and managing IP addresses for wireless clients in wireless local area networks (WLANs)
US7813511B2 (en) 2005-07-01 2010-10-12 Cisco Technology, Inc. Facilitating mobility for a mobile station
EP1900245B1 (de) * 2005-07-06 2012-09-19 Nokia Corporation Sicherer sitzungsschlüsselkontext
KR100703416B1 (ko) * 2005-07-06 2007-04-03 삼성전자주식회사 통신 시스템에서 네트워크 재진입 절차 수행 완료 통보 시스템 및 방법
US20070008903A1 (en) * 2005-07-11 2007-01-11 Kapil Sood Verifying liveness with fast roaming
US8230221B2 (en) * 2005-08-15 2012-07-24 Telefonaktiebolaget L M Ericsson (Publ) Routing advertisement authentication in fast router discovery
US20070053354A1 (en) * 2005-08-18 2007-03-08 Interdigital Technology Corporation Method and system for securing wireless transmission of an aggregated frame
US20070047477A1 (en) * 2005-08-23 2007-03-01 Meshnetworks, Inc. Extensible authentication protocol over local area network (EAPOL) proxy in a wireless network for node to node authentication
US7870246B1 (en) 2005-08-30 2011-01-11 Mcafee, Inc. System, method, and computer program product for platform-independent port discovery
US20070074198A1 (en) * 2005-08-31 2007-03-29 Computer Associates Think, Inc. Deciding redistribution servers by hop count
US20070066308A1 (en) * 2005-09-06 2007-03-22 Oleg Andric Method and apparatus for removing phantom children in an ad-hoc communication system
EP1929738B1 (de) * 2005-09-08 2013-01-16 Nortel Networks Limited Lastausgleich für eine funkschnittstellen-protokollarchitektur mit mehreren heterogenen bitübertragungsschichtmoden
GB2430580B (en) * 2005-09-13 2008-04-09 Roke Manor Research A method of authenticating access points on a wireless network
US7660318B2 (en) * 2005-09-20 2010-02-09 Cisco Technology, Inc. Internetworking support between a LAN and a wireless mesh network
JP2007096845A (ja) * 2005-09-29 2007-04-12 Nec Infrontia Corp 無線端末及び無線ｌａｎシステム
US20070081673A1 (en) * 2005-10-07 2007-04-12 Texas Instruments Incorporated CCM encryption/decryption engine
US8073841B2 (en) 2005-10-07 2011-12-06 Oracle International Corporation Optimizing correlated XML extracts
US8184615B2 (en) * 2005-10-12 2012-05-22 Qualcomm Incorporated Wireless terminal methods and apparatus for establishing connections
WO2007044986A2 (en) 2005-10-13 2007-04-19 Trapeze Networks, Inc. System and method for remote monitoring in a wireless network
US7724703B2 (en) 2005-10-13 2010-05-25 Belden, Inc. System and method for wireless network monitoring
US8638762B2 (en) 2005-10-13 2014-01-28 Trapeze Networks, Inc. System and method for network integrity
US7573859B2 (en) 2005-10-13 2009-08-11 Trapeze Networks, Inc. System and method for remote monitoring in a wireless network
US7716721B2 (en) * 2005-10-18 2010-05-11 Cisco Technology, Inc. Method and apparatus for re-authentication of a computing device using cached state
KR101137340B1 (ko) * 2005-10-18 2012-04-19 엘지전자 주식회사 릴레이 스테이션의 보안 제공 방법
US8356053B2 (en) 2005-10-20 2013-01-15 Oracle International Corporation Managing relationships between resources stored within a repository
US7626963B2 (en) * 2005-10-25 2009-12-01 Cisco Technology, Inc. EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure
US7808930B2 (en) * 2005-10-26 2010-10-05 Cisco Technology, Inc. Dynamic multipoint tree rearrangement
EP1780941B1 (de) * 2005-10-31 2009-07-22 PacketFront Systems AB Netzwerkkonfiguration
US7471664B2 (en) * 2005-11-02 2008-12-30 Intel Corporation Network management policy and compliance in a wireless network
CN101313526B (zh) * 2005-11-02 2015-04-22 美商内数位科技公司 用于为无线分散式系统实施自主通道协调的方法和系统
DE102006014350A1 (de) * 2005-11-04 2007-05-10 Siemens Ag Verfahren und Server zum teilnehmerspezifischen Aktivieren eines netzbasierten Mobilitätsmanagements
CN1964259B (zh) * 2005-11-07 2011-02-16 华为技术有限公司 一种切换过程中的密钥管理方法
US8046833B2 (en) * 2005-11-14 2011-10-25 Sourcefire, Inc. Intrusion event correlation with network discovery information
US20070110024A1 (en) * 2005-11-14 2007-05-17 Cisco Technology, Inc. System and method for spanning tree cross routes
US7733803B2 (en) * 2005-11-14 2010-06-08 Sourcefire, Inc. Systems and methods for modifying network map attributes
US7957380B2 (en) * 2005-11-21 2011-06-07 Cisco Technology, Inc. Support of unidirectional link in IS-IS without IP encapsulation and in presence of unidirectional return path
US8949455B2 (en) 2005-11-21 2015-02-03 Oracle International Corporation Path-caching mechanism to improve performance of path-related operations in a repository
WO2007062326A2 (en) * 2005-11-23 2007-05-31 Tcm Mobile, Llc Wlan mobile phone and wireless network
WO2007065987A1 (fr) * 2005-12-05 2007-06-14 France Telecom Procede de reconstruction d'un reseau ad hoc et des nœuds du reseau correspondant
US7710933B1 (en) 2005-12-08 2010-05-04 Airtight Networks, Inc. Method and system for classification of wireless devices in local area computer networks
KR100785785B1 (ko) * 2005-12-08 2007-12-13 한국전자통신연구원 고속 단말 이동성을 지원하는 이동단말의 이더넷 데이터송수신 방법 및 시스템
DE102005059827B4 (de) * 2005-12-14 2010-09-23 Siemens Ag Verfahren zum Verwalten eines Zählerstandes in einem Kommunikationsnetz
US8270947B2 (en) * 2005-12-19 2012-09-18 Motorola Solutions, Inc. Method and apparatus for providing a supplicant access to a requested service
FR2895186A1 (fr) * 2005-12-20 2007-06-22 France Telecom Procede et systeme de mise a jour des conditions d'acces d'un dispositif de telecommunication a des services delivres par un reseau de telecommunication
US7706800B2 (en) * 2005-12-28 2010-04-27 Intel Corporation System, apparatus and method of hand over in wireless communication system
US7483409B2 (en) 2005-12-30 2009-01-27 Motorola, Inc. Wireless router assisted security handoff (WRASH) in a multi-hop wireless network
US20070159997A1 (en) 2006-01-10 2007-07-12 Hsiu-Ping Tsai Wireless Security Setup between Station and AP Supporting MSSID
US8090807B2 (en) * 2006-01-23 2012-01-03 Lg Electronics Inc. Home code setting method for home network system
DE102006006549A1 (de) * 2006-02-13 2007-08-16 Siemens Ag Verfahren zur Übermittlung von Daten in einem Kommunikationsnetz
JP4829635B2 (ja) 2006-02-17 2011-12-07 キヤノン株式会社 通信装置、通信方法、ネットワークを構成する方法、通信システム
US7978725B2 (en) * 2006-03-06 2011-07-12 Cisco Technology, Inc. Dynamic modification of contention-based transmission control parameters achieving load balancing scheme in wireless mesh networks
US20070218908A1 (en) * 2006-03-06 2007-09-20 Samsung Electronics Co., Ltd Apparatus and method for supporting optimum network reentry procedure in multihop relay broadband wireless access (BWA) communication system
WO2007110094A1 (en) * 2006-03-27 2007-10-04 Telecom Italia S.P.A. System for enforcing security policies on mobile communications devices
US7925765B2 (en) * 2006-04-07 2011-04-12 Microsoft Corporation Cooperative diagnosis in a wireless LAN
US7948922B2 (en) * 2006-04-18 2011-05-24 Cisco Technology, Inc. Blocked redundant link-aware spanning tree protocol enhancement
US7558266B2 (en) 2006-05-03 2009-07-07 Trapeze Networks, Inc. System and method for restricting network access using forwarding databases
US8966018B2 (en) 2006-05-19 2015-02-24 Trapeze Networks, Inc. Automated network device configuration and network deployment
US7904078B2 (en) * 2006-05-19 2011-03-08 Sony Ericsson Mobile Communications Ab Mobile peer-to-peer networks
US9198084B2 (en) * 2006-05-26 2015-11-24 Qualcomm Incorporated Wireless architecture for a traditional wire-based protocol
US20080045149A1 (en) * 2006-05-26 2008-02-21 Dinesh Dharmaraju Wireless architecture for a traditional wire-based protocol
JP4187010B2 (ja) * 2006-05-31 2008-11-26 ブラザー工業株式会社 ネットワーク機器及び情報処理装置並びにプログラム
EP2031803B1 (de) * 2006-06-05 2012-05-30 Hitachi, Ltd. Relaisnetzwerksystem und endgeräteadaptervorrichtung
US9191799B2 (en) 2006-06-09 2015-11-17 Juniper Networks, Inc. Sharing data between wireless switches system and method
US9258702B2 (en) 2006-06-09 2016-02-09 Trapeze Networks, Inc. AP-local dynamic switching
US8818322B2 (en) 2006-06-09 2014-08-26 Trapeze Networks, Inc. Untethered access point mesh system and method
US8224322B2 (en) 2006-06-12 2012-07-17 Lemko Corporation Roaming mobile subscriber registration in a distributed mobile architecture
US8223748B2 (en) * 2006-06-14 2012-07-17 Cisco Technology, Inc. Enhanced refresh in SIP network
CN101090351B (zh) * 2006-06-14 2010-04-21 华为技术有限公司 一种WiMAX网络中功能实体的迁移方法
WO2008027106A1 (en) * 2006-06-23 2008-03-06 Roamware, Inc. Method and system for providing inbound traffic redirection solution
US20080002607A1 (en) * 2006-06-30 2008-01-03 Ramakrishnan Nagarajan Technique for handling layer 2 roaming in a network of wireless switches supporting layer 3 mobility within a mobility domain
US7804806B2 (en) * 2006-06-30 2010-09-28 Symbol Technologies, Inc. Techniques for peer wireless switch discovery within a mobility domain
US7826869B2 (en) * 2006-07-07 2010-11-02 Symbol Technologies, Inc. Mobility relay techniques for reducing layer 3 mobility control traffic and peering sessions to provide scalability in large wireless switch networks
US20080008128A1 (en) * 2006-07-07 2008-01-10 Symbol Technologies, Inc. Techniques for resolving wireless client device layer 3 mobility state conflicts between wireless switches within a mobility domain
KR100823277B1 (ko) * 2006-07-07 2008-04-21 삼성전자주식회사 모바일 네트워크 서비스에 대한 정보를 관리하는 방법 및장치
US7961690B2 (en) * 2006-07-07 2011-06-14 Symbol Technologies, Inc. Wireless switch network architecture implementing mobility areas within a mobility domain
US8085790B2 (en) * 2006-07-14 2011-12-27 Cisco Technology, Inc. Ethernet layer 2 protocol packet switching
US20080020758A1 (en) * 2006-07-20 2008-01-24 Symbol Technologies, Inc. Query-response techniques for reduction of wireless client database size to provide scalability in large wireless switch networks supporting layer 3 mobility
US7613150B2 (en) * 2006-07-20 2009-11-03 Symbol Technologies, Inc. Hitless restart mechanism for non-stop data-forwarding in the event of L3-mobility control-plane failure in a wireless switch
US7639648B2 (en) * 2006-07-20 2009-12-29 Symbol Technologies, Inc. Techniques for home wireless switch redundancy and stateful switchover in a network of wireless switches supporting layer 3 mobility within a mobility domain
US8107396B1 (en) * 2006-07-24 2012-01-31 Cisco Technology, Inc. Host tracking in a layer 2 IP ethernet network
US20080025256A1 (en) * 2006-07-26 2008-01-31 Boris Ginzburg Multicasting techniques in wireless networks
US7948988B2 (en) 2006-07-27 2011-05-24 Sourcefire, Inc. Device, system and method for analysis of fragments in a fragment train
US8537716B2 (en) * 2006-07-28 2013-09-17 Ca, Inc. Method and system for synchronizing access points in a wireless network
US7966489B2 (en) * 2006-08-01 2011-06-21 Cisco Technology, Inc. Method and apparatus for selecting an appropriate authentication method on a client
EP1885086B1 (de) * 2006-08-01 2011-01-26 Alcatel Lucent Verfahren und Netzknoten zur Verkehrsüberwachung eines privaten-VLANs
US9049253B2 (en) * 2006-08-09 2015-06-02 Cisco Technology, Inc. Resetting / restarting SIP endpoint devices
US7872994B2 (en) * 2006-08-11 2011-01-18 Cisco Technology, Inc. SIP out-of-dialog REFER mechanism for handoff between front-end and back-end services
DE102006038037A1 (de) * 2006-08-14 2008-02-21 Siemens Ag Verfahren und System zum Bereitstellen eines zugangsspezifischen Schlüssels
US7793103B2 (en) * 2006-08-15 2010-09-07 Motorola, Inc. Ad-hoc network key management
US7970938B1 (en) * 2006-08-16 2011-06-28 Vmware, Inc. IP subnet discovery with ranked results
US8903365B2 (en) * 2006-08-18 2014-12-02 Ca, Inc. Mobile device management
US7768952B2 (en) * 2006-08-18 2010-08-03 WI-FI Rail, Inc. System and method of wirelessly communicating with mobile devices
US20080049676A1 (en) * 2006-08-23 2008-02-28 Futurewei Technologies, Inc. Method and system for resource allocation in a wireless communication network
EP1892913A1 (de) 2006-08-24 2008-02-27 Siemens Aktiengesellschaft Verfahren und Anordnung zum Bereitstellen eines drahtlosen Mesh-Netzwerks
US8743778B2 (en) * 2006-09-06 2014-06-03 Devicescape Software, Inc. Systems and methods for obtaining network credentials
US8549588B2 (en) * 2006-09-06 2013-10-01 Devicescape Software, Inc. Systems and methods for obtaining network access
US8554830B2 (en) * 2006-09-06 2013-10-08 Devicescape Software, Inc. Systems and methods for wireless network selection
US9326138B2 (en) * 2006-09-06 2016-04-26 Devicescape Software, Inc. Systems and methods for determining location over a network
US7734052B2 (en) * 2006-09-07 2010-06-08 Motorola, Inc. Method and system for secure processing of authentication key material in an ad hoc wireless network
US7499547B2 (en) * 2006-09-07 2009-03-03 Motorola, Inc. Security authentication and key management within an infrastructure based wireless multi-hop network
US8578159B2 (en) * 2006-09-07 2013-11-05 Motorola Solutions, Inc. Method and apparatus for establishing security association between nodes of an AD HOC wireless network
US7707415B2 (en) * 2006-09-07 2010-04-27 Motorola, Inc. Tunneling security association messages through a mesh network
JP4864797B2 (ja) 2006-09-11 2012-02-01 Ｋｄｄｉ株式会社 Ｐ−ｃｓｃｆ高速ハンドオフシステム及びｐ−ｃｓｃｆ高速ハンドオフ方法
US8340110B2 (en) 2006-09-15 2012-12-25 Trapeze Networks, Inc. Quality of service provisioning for wireless networks
US20080070544A1 (en) * 2006-09-19 2008-03-20 Bridgewater Systems Corp. Systems and methods for informing a mobile node of the authentication requirements of a visited network
KR20090067221A (ko) * 2006-09-21 2009-06-24 인터디지탈 테크날러지 코포레이션 그룹 단위 비밀키 발생
CN100488305C (zh) * 2006-09-23 2009-05-13 西安西电捷通无线网络通信有限公司 一种网络接入鉴别与授权方法以及授权密钥更新方法
CA2672908A1 (en) * 2006-10-06 2008-04-17 Sourcefire, Inc. Device, system and method for use of micro-policies in intrusion detection/prevention
US8036215B2 (en) 2006-10-10 2011-10-11 Cisco Technology, Inc. Refreshing a session initiation protocol (SIP) session
US9183321B2 (en) * 2006-10-16 2015-11-10 Oracle International Corporation Managing compound XML documents in a repository
US7827177B2 (en) * 2006-10-16 2010-11-02 Oracle International Corporation Managing compound XML documents in a repository
US7797310B2 (en) 2006-10-16 2010-09-14 Oracle International Corporation Technique to estimate the cost of streaming evaluation of XPaths
JP4841519B2 (ja) * 2006-10-30 2011-12-21 富士通株式会社 通信方法、通信システム、鍵管理装置、中継装置及びコンピュータプログラム
US8549122B2 (en) * 2006-12-04 2013-10-01 Oracle International Corporation System and method for communication agent within a fully distributed network
US7873061B2 (en) 2006-12-28 2011-01-18 Trapeze Networks, Inc. System and method for aggregation and queuing in a wireless network
US9392434B2 (en) 2007-01-22 2016-07-12 Qualcomm Incorporated Message ordering for network based mobility management systems
US8107960B2 (en) * 2007-01-23 2012-01-31 Toshiba America Research, Inc. Prioritized query
US8356176B2 (en) * 2007-02-09 2013-01-15 Research In Motion Limited Method and system for authenticating peer devices using EAP
KR100856520B1 (ko) * 2007-02-21 2008-09-04 삼성전자주식회사 와이맥스 이동통신 시스템에서 핸드오버를 수행하기 위한시스템 및 방법
US8670408B2 (en) * 2007-02-27 2014-03-11 Huawei Technologies Co., Ltd. Method and system for association in relay network
US8069352B2 (en) * 2007-02-28 2011-11-29 Sourcefire, Inc. Device, system and method for timestamp analysis of segments in a transmission control protocol (TCP) session
US20080220716A1 (en) * 2007-03-06 2008-09-11 Institute For Information Industry Communication system and handshake method thereof
US20100290621A1 (en) * 2007-03-12 2010-11-18 Nortel Networks Limited Tunneling support for mobile ip using a key for flow identification
US8175272B2 (en) * 2007-03-12 2012-05-08 Motorola Solutions, Inc. Method for establishing secure associations within a communication network
US20080225723A1 (en) * 2007-03-16 2008-09-18 Futurewei Technologies, Inc. Optical Impairment Aware Path Computation Architecture in PCE Based Network
US7684355B2 (en) * 2007-03-19 2010-03-23 Cisco Technology, Inc. Transparent wireless bridge route aggregation
US20080240105A1 (en) * 2007-03-28 2008-10-02 Vmonitor, Inc. System and method for extending a serial protocol to create a network in a well monitoring environment
US9319220B2 (en) * 2007-03-30 2016-04-19 Intel Corporation Method and apparatus for secure network enclaves
US8059595B2 (en) * 2007-04-06 2011-11-15 Qualcomm Incorporated Handoff of data attachment point
US8180323B2 (en) * 2007-04-09 2012-05-15 Kyocera Corporation Non centralized security function for a radio interface
US10091648B2 (en) 2007-04-26 2018-10-02 Qualcomm Incorporated Method and apparatus for new key derivation upon handoff in wireless networks
US8948046B2 (en) 2007-04-27 2015-02-03 Aerohive Networks, Inc. Routing method and system for a wireless network
US8127353B2 (en) * 2007-04-30 2012-02-28 Sourcefire, Inc. Real-time user awareness for a computer network
EP1993268A3 (de) * 2007-05-18 2009-07-01 Huawei Technologies Co., Ltd. Verfahren, System und Relaisvorrichtung für Paketsendung
US20080298592A1 (en) * 2007-05-29 2008-12-04 Mohamed Khalid Technique for changing group member reachability information
JP5073816B2 (ja) * 2007-06-06 2012-11-14 テレコム・イタリア・エッセ・ピー・アー ワイヤレスネットワークにわたる情報パケットの転送及びその転送を実施するルーティングノードを管理する方法
US7907735B2 (en) * 2007-06-15 2011-03-15 Koolspan, Inc. System and method of creating and sending broadcast and multicast data
CN101083839B (zh) * 2007-06-29 2013-06-12 中兴通讯股份有限公司 在不同移动接入系统中切换时的密钥处理方法
CN101102600B (zh) * 2007-06-29 2012-07-04 中兴通讯股份有限公司 在不同移动接入系统中切换时的密钥处理方法
US7986940B2 (en) * 2007-07-05 2011-07-26 Azurewave Technologies, Inc. Automatic wireless network linking method with security configuration and device thereof
WO2009011055A1 (ja) * 2007-07-19 2009-01-22 Panasonic Corporation 無線端末装置、無線接続方法及びプログラム
US8667144B2 (en) * 2007-07-25 2014-03-04 Qualcomm Incorporated Wireless architecture for traditional wire based protocol
US7885233B2 (en) * 2007-07-31 2011-02-08 Symbol Technologies, Inc. Forwarding broadcast/multicast data when wireless clients layer 3 roam across IP subnets in a WLAN
US20110004913A1 (en) * 2007-07-31 2011-01-06 Symbol Technologies, Inc. Architecture for seamless enforcement of security policies when roaming across ip subnets in ieee 802.11 wireless networks
US7840708B2 (en) * 2007-08-13 2010-11-23 Cisco Technology, Inc. Method and system for the assignment of security group information using a proxy
EP2026610B1 (de) * 2007-08-14 2014-02-26 Alcatel Lucent Verfahren und Gerät für den Wiederanlauf im Funkverbindungsausfall ("Radio link failure recovery") in einem drahtlosen Kommunikationsnetz
US8315206B2 (en) * 2007-09-05 2012-11-20 Nec Corporation Proxy mobile IP system, access gateway and method for determining the order of registration notification messages used therefor
US8902904B2 (en) 2007-09-07 2014-12-02 Trapeze Networks, Inc. Network assignment based on priority
US8509128B2 (en) 2007-09-18 2013-08-13 Trapeze Networks, Inc. High level instruction convergence function
US7774490B2 (en) * 2007-09-20 2010-08-10 Microsoft Corporation Crisscross cancellation protocol
US9198033B2 (en) * 2007-09-27 2015-11-24 Alcatel Lucent Method and apparatus for authenticating nodes in a wireless network
US7970894B1 (en) 2007-11-15 2011-06-28 Airtight Networks, Inc. Method and system for monitoring of wireless devices in local area computer networks
CN101436930A (zh) * 2007-11-16 2009-05-20 华为技术有限公司 一种密钥分发的方法、系统和设备
CN101442516B (zh) * 2007-11-20 2012-04-25 华为技术有限公司 一种dhcp认证的方法、系统和装置
US8238942B2 (en) 2007-11-21 2012-08-07 Trapeze Networks, Inc. Wireless station location detection
JP2009130603A (ja) * 2007-11-22 2009-06-11 Sanyo Electric Co Ltd 通信方法およびそれを利用した基地局装置、端末装置、制御装置
KR100937874B1 (ko) * 2007-12-17 2010-01-21 한국전자통신연구원 센서 네트워크에서의 라우팅 방법
TWI351849B (en) * 2007-12-31 2011-11-01 Ind Tech Res Inst Apparatus and method for transmitting streaming se
US8150357B2 (en) 2008-03-28 2012-04-03 Trapeze Networks, Inc. Smoothing filter for irregular update intervals
KR101466889B1 (ko) * 2008-04-03 2014-12-01 삼성전자주식회사 모바일 아이피 방식의 무선통신시스템에서 세션 식별자를검색하기 위한 시스템 및 방법
US8811294B2 (en) * 2008-04-04 2014-08-19 Qualcomm Incorporated Apparatus and methods for establishing client-host associations within a wireless network
US8418163B2 (en) * 2008-04-16 2013-04-09 Ciena Corporation Stacked hardware abstraction layer methods for maintaining software/hardware backward compatibility
US8474043B2 (en) * 2008-04-17 2013-06-25 Sourcefire, Inc. Speed and memory optimization of intrusion detection system (IDS) and intrusion prevention system (IPS) rule processing
US8046420B2 (en) 2008-04-23 2011-10-25 Lemko Corporation System and method to control wireless communications
US8218502B1 (en) * 2008-05-14 2012-07-10 Aerohive Networks Predictive and nomadic roaming of wireless clients across different network subnets
US9009310B1 (en) * 2008-06-12 2015-04-14 Hlt Domestic Ip Llc System and method for provisioning of internet access services in a guest facility
JP4578539B2 (ja) * 2008-06-17 2010-11-10 株式会社バッファロー 無線通信システム、無線ｌａｎ接続装置、無線ｌａｎ中継装置
US8340667B2 (en) 2008-06-26 2012-12-25 Lemko Corporation System and method to control wireless communications
US8706105B2 (en) 2008-06-27 2014-04-22 Lemko Corporation Fault tolerant distributed mobile architecture
US8107409B2 (en) * 2008-07-11 2012-01-31 Lemko Corporation OAMP for distributed mobile architecture
US7855988B2 (en) 2008-07-14 2010-12-21 Lemko Corporation System, method, and device for routing calls using a distributed mobile architecture
US8326977B2 (en) * 2008-07-16 2012-12-04 Fujitsu Limited Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
US20100017486A1 (en) * 2008-07-16 2010-01-21 Fujitsu Limited System analyzing program, system analyzing apparatus, and system analyzing method
US8245039B2 (en) * 2008-07-18 2012-08-14 Bridgewater Systems Corp. Extensible authentication protocol authentication and key agreement (EAP-AKA) optimization
US8978105B2 (en) 2008-07-25 2015-03-10 Trapeze Networks, Inc. Affirming network relationships and resource access via related networks
US8510577B2 (en) * 2008-07-28 2013-08-13 Microsoft Corporation Reducing power consumption by offloading applications
US8045463B2 (en) 2008-07-30 2011-10-25 Microsoft Corporation Path estimation in a wireless mesh network
US8036161B2 (en) * 2008-07-30 2011-10-11 Symbol Technologies, Inc. Wireless switch with virtual wireless switch modules
US8516246B2 (en) * 2008-08-07 2013-08-20 Gilat Satellite Networks Ltd. Network binding
US20100037045A1 (en) * 2008-08-07 2010-02-11 Sean Kendall Schneyer Method and apparatus for creating an instance id based on a unique device identifier
US7958112B2 (en) 2008-08-08 2011-06-07 Oracle International Corporation Interleaving query transformations for XML indexes
US8537721B2 (en) * 2008-08-11 2013-09-17 Koninklijke Philips N.V. Method for scheduling transmissions of global beacons in body area networks
CN100581169C (zh) * 2008-08-21 2010-01-13 西安西电捷通无线网络通信有限公司 一种基于单播会话密钥的组播密钥分发方法及其更新方法
US8238298B2 (en) 2008-08-29 2012-08-07 Trapeze Networks, Inc. Picking an optimal channel for an access point in a wireless network
JP5239665B2 (ja) * 2008-09-12 2013-07-17 富士通株式会社 無線ｌａｎシステムにおけるハンドオーバ方法およびその方法において使用される装置
WO2010045089A1 (en) 2008-10-08 2010-04-22 Sourcefire, Inc. Target-based smb and dce/rpc processing for an intrusion detection system or intrusion prevention system
US20100263022A1 (en) * 2008-10-13 2010-10-14 Devicescape Software, Inc. Systems and Methods for Enhanced Smartclient Support
JP5632380B2 (ja) * 2008-10-13 2014-11-26 デバイススケープ・ソフトウェア・インコーポレーテッド ネットワークを識別するためのシステム及び方法
US9674892B1 (en) 2008-11-04 2017-06-06 Aerohive Networks, Inc. Exclusive preshared key authentication
CN101754420B (zh) * 2008-12-04 2012-10-17 华为技术有限公司 一种发起分组数据网络去连接的方法、装置与系统
CN101431518B (zh) * 2008-12-09 2011-06-01 西安西电捷通无线网络通信股份有限公司 一种认证关联套件的发现与协商方法
US9398089B2 (en) 2008-12-11 2016-07-19 Qualcomm Incorporated Dynamic resource sharing among multiple wireless devices
US7936754B2 (en) * 2008-12-12 2011-05-03 At&T Intellectual Property I, L.P. Methods and apparatus to dynamically store network routes for a communication network
KR101556906B1 (ko) * 2008-12-29 2015-10-06 삼성전자주식회사 선인증을 통한 이종 무선 통신망 간의 핸드오버 방법
US8483194B1 (en) 2009-01-21 2013-07-09 Aerohive Networks, Inc. Airtime-based scheduling
US8102849B2 (en) 2009-02-12 2012-01-24 Qualcomm, Incorporated Association procedure to enable multiple multicast streams
US20100205321A1 (en) * 2009-02-12 2010-08-12 Qualcomm Incorporated Negotiable and adaptable periodic link status monitoring
US7894342B2 (en) * 2009-02-27 2011-02-22 Cisco Technology, Inc. Efficient pruning of virtual services in bridged computer networks
US8374502B2 (en) * 2009-02-27 2013-02-12 Futurewei Technologies, Inc. Open shortest path first extensions in support of wavelength switched optical networks
JP5332840B2 (ja) * 2009-04-08 2013-11-06 ソニー株式会社 無線通信装置、無線通信システム、無線通信方法及びプログラム
CN102106124B (zh) * 2009-04-16 2013-08-28 华为技术有限公司 路由方法、装置及系统
US8560696B2 (en) 2009-04-28 2013-10-15 Intel Corporation Transmission of advanced-MAP information elements in mobile networks
CN101588244A (zh) * 2009-05-08 2009-11-25 中兴通讯股份有限公司 对网络设备进行鉴权的方法及系统
US8929878B2 (en) * 2009-05-20 2015-01-06 Qualcomm Incorporated Transaction management
US8077633B2 (en) 2009-05-29 2011-12-13 Cisco Technology, Inc. Transient loop prevention in a hybrid layer-2 network
US8737238B2 (en) * 2009-06-11 2014-05-27 Nec Corporation Congestion detecting method and communication node
US9002357B2 (en) * 2009-06-26 2015-04-07 Qualcomm Incorporated Systems, apparatus and methods to facilitate handover security
US9451452B2 (en) 2009-06-29 2016-09-20 Motorola Solutions, Inc. Method of triggering a key delivery from a mesh key distributor
US9264248B2 (en) * 2009-07-02 2016-02-16 Qualcomm Incorporated System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment
US11115857B2 (en) 2009-07-10 2021-09-07 Extreme Networks, Inc. Bandwidth sentinel
US9900251B1 (en) 2009-07-10 2018-02-20 Aerohive Networks, Inc. Bandwidth sentinel
US8458322B2 (en) * 2009-07-24 2013-06-04 Cisco Technology, Inc. Dynamic management of maintenance association membership in a computer network
JP5446650B2 (ja) * 2009-09-17 2014-03-19 沖電気工業株式会社 通信データ新規性確認システム並びに送信端末及び受信端末
CN102026171B (zh) * 2009-09-17 2013-06-12 国基电子（上海）有限公司 安全控制远程无线设备的方法
DE102009041821A1 (de) * 2009-09-18 2011-03-24 Phoenix Contact Gmbh & Co. Kg Netzwerk
JP2013505612A (ja) * 2009-09-21 2013-02-14 テレフオンアクチーボラゲット エル エム エリクソン（パブル） モバイルネットワークにおけるキャッシング
US8830866B2 (en) * 2009-09-30 2014-09-09 Apple Inc. Methods and apparatus for solicited activation for protected wireless networking
US8873523B2 (en) * 2009-09-30 2014-10-28 Apple Inc. Methods and apparatus for solicited activation for protected wireless networking
US8532272B2 (en) 2009-10-21 2013-09-10 Comcast Cable Communications, Llc Service entry device
KR101225185B1 (ko) 2009-10-23 2013-01-22 한국전자통신연구원 네트워크 주소 변환 방법
FR2952499A1 (fr) * 2009-11-12 2011-05-13 France Telecom Procede d'allocation de ressources de transmission de donnees, procede de basculement, point d'acces, terminal, programme d'ordinateur et signal correspondants
US9582238B2 (en) * 2009-12-14 2017-02-28 Qualcomm Incorporated Decomposed multi-stream (DMS) techniques for video display systems
US8630416B2 (en) * 2009-12-21 2014-01-14 Intel Corporation Wireless device and method for rekeying with reduced packet loss for high-throughput wireless communications
US8189608B2 (en) * 2009-12-31 2012-05-29 Sonicwall, Inc. Wireless extender secure discovery and provisioning
JP5293649B2 (ja) * 2010-03-09 2013-09-18 セイコーエプソン株式会社 無線通信システム、無線通信端末、及び無線通信方法
EP2559217B1 (de) 2010-04-16 2019-08-14 Cisco Technology, Inc. System und verfahren zur netzwerk angriffserkennung in nahezu echtzeit, und system und verfahren zur gemeinsamen erkennung mittels erkennunsrouting
US8433790B2 (en) 2010-06-11 2013-04-30 Sourcefire, Inc. System and method for assigning network blocks to sensors
US8671182B2 (en) 2010-06-22 2014-03-11 Sourcefire, Inc. System and method for resolving operating system or service identity conflicts
CN101883115B (zh) * 2010-06-25 2013-04-17 北京交通大学 接入认证方法及系统
US8671187B1 (en) 2010-07-27 2014-03-11 Aerohive Networks, Inc. Client-independent network supervision application
US8464061B2 (en) 2010-08-30 2013-06-11 Apple Inc. Secure wireless link between two devices using probes
US9794220B2 (en) 2010-08-31 2017-10-17 Comcast Cable Communications, Llc Wireless extension of broadband access
CN103081415B (zh) * 2010-09-03 2016-11-02 日本电气株式会社 控制装置、通信系统、通信方法和其上记录有通信程序的记录介质
US9002277B2 (en) 2010-09-07 2015-04-07 Aerohive Networks, Inc. Distributed channel selection for wireless networks
US8700021B2 (en) * 2010-09-09 2014-04-15 Kaseya International Limited Method and apparatus of providing messaging service and callback feature to mobile stations
US8934420B2 (en) * 2010-10-12 2015-01-13 Cisco Technology, Inc. Multiple wired client support on a wireless workgroup bridge
US8520676B2 (en) * 2010-11-09 2013-08-27 Cisco Technology, Inc. System and method for managing acknowledgement messages in a very large computer network
US8542836B2 (en) 2010-12-01 2013-09-24 Juniper Networks, Inc. System, apparatus and methods for highly scalable continuous roaming within a wireless network
US9059896B2 (en) * 2010-12-08 2015-06-16 At&T Intellectual Property I, L.P. Server-side network probe
US8503309B2 (en) 2010-12-17 2013-08-06 Cisco Technology, Inc. Dynamic expelling of child nodes in directed acyclic graphs in a computer network
US9065876B2 (en) 2011-01-21 2015-06-23 Qualcomm Incorporated User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9413803B2 (en) 2011-01-21 2016-08-09 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US20130013318A1 (en) 2011-01-21 2013-01-10 Qualcomm Incorporated User input back channel for wireless displays
US8964783B2 (en) 2011-01-21 2015-02-24 Qualcomm Incorporated User input back channel for wireless displays
US8493950B1 (en) * 2011-01-28 2013-07-23 Sprint Communications Company L.P. Ethernet backhaul for wireless base stations
US10108386B2 (en) 2011-02-04 2018-10-23 Qualcomm Incorporated Content provisioning for wireless back channel
US8674957B2 (en) 2011-02-04 2014-03-18 Qualcomm Incorporated User input device for wireless back channel
US9503771B2 (en) 2011-02-04 2016-11-22 Qualcomm Incorporated Low latency wireless display for graphics
EP2676399A4 (de) 2011-02-14 2016-02-17 Devicescape Software Inc Systeme und verfahren zur netzwerkpflege
US8595359B2 (en) 2011-03-08 2013-11-26 Cisco Technology, Inc. Efficient message distribution for directed acyclic graphs
US9210045B2 (en) 2011-03-08 2015-12-08 Cisco Technology, Inc. Gravitational parent selection in directed acyclic graphs
US8601034B2 (en) 2011-03-11 2013-12-03 Sourcefire, Inc. System and method for real time data awareness
US8730811B2 (en) * 2011-04-07 2014-05-20 Hewlett-Packard Development Company, L.P. Managing network traffic
US8971289B2 (en) 2011-05-24 2015-03-03 Cisco Technology, Inc. Maintaining point of presence for clients roaming within a layer 2 domain
US9935848B2 (en) 2011-06-03 2018-04-03 Oracle International Corporation System and method for supporting subnet manager (SM) level robust handling of unkown management key in an infiniband (IB) network
TWI486084B (zh) * 2011-06-24 2015-05-21 Accton Technology Corp Wireless connection point and wireless mobile device connection control method
CN102869012B (zh) * 2011-07-05 2018-11-06 横河电机株式会社 无线局域网接入点设备和系统以及相关方法
WO2013009850A1 (en) 2011-07-11 2013-01-17 Oracle International Corporation System and method for using at least one of a multicast group and a packet process proxy to support a flooding mechanism in a middleware machine environment
US8654649B2 (en) 2011-07-27 2014-02-18 Cisco Technology, Inc. Reduced topology routing in shared media communication networks
US9148781B2 (en) * 2011-07-28 2015-09-29 Hewlett-Packard Development Company, L.P. Wireless transmission of data packets based on client associations
CN103051595B (zh) * 2011-10-13 2017-03-15 中兴通讯股份有限公司 一种标识网中映射表项的整合方法及装置
JP5708445B2 (ja) * 2011-10-31 2015-04-30 富士通株式会社 登録方法、登録プログラムおよび登録装置
US10091065B1 (en) 2011-10-31 2018-10-02 Aerohive Networks, Inc. Zero configuration networking on a subnetted network
US9104836B2 (en) * 2011-11-21 2015-08-11 Cisco Technology, Inc. Dynamically mapping network trust relationships
KR101807523B1 (ko) * 2011-12-13 2017-12-12 삼성전자주식회사 무선 통신 시스템에서 무선 망 제공자를 확인하기 위한 장치 및 방법
US9525998B2 (en) 2012-01-06 2016-12-20 Qualcomm Incorporated Wireless display with multiscreen service
US9173185B1 (en) * 2012-04-10 2015-10-27 Sprint Spectrum L.P. Methods and systems for managing registration signaling based on off-time duration
WO2013153233A1 (en) * 2012-04-13 2013-10-17 Anyfi Networks Ab End-to-end security in an ieee 802.11 communication system
US9077772B2 (en) * 2012-04-20 2015-07-07 Cisco Technology, Inc. Scalable replay counters for network security
US9515920B2 (en) * 2012-04-20 2016-12-06 Futurewei Technologies, Inc. Name-based neighbor discovery and multi-hop service discovery in information-centric networks
US9529878B2 (en) 2012-05-10 2016-12-27 Oracle International Corporation System and method for supporting subnet manager (SM) master negotiation in a network environment
US9504089B2 (en) * 2012-05-14 2016-11-22 Broadcom Corporation System and method for wireless station bridging
US8855116B2 (en) 2012-05-15 2014-10-07 Cisco Technology, Inc. Virtual local area network state processing in a layer 2 ethernet switch
US8787375B2 (en) 2012-06-14 2014-07-22 Aerohive Networks, Inc. Multicast to unicast conversion technique
US20140071885A1 (en) * 2012-09-10 2014-03-13 Qualcomm Incorporated Systems, apparatus, and methods for bridge learning in multi-hop networks
US8902732B2 (en) * 2012-09-24 2014-12-02 Silver Spring Networks, Inc. System and method for managing access point failover within a wireless mesh network
US20140112307A1 (en) * 2012-10-19 2014-04-24 Electronics And Telecommunications Research Institute User terminal and communication apparatus for preventing interuption of communication in information centric network and method thereof
CN103781149B (zh) * 2012-10-26 2017-04-26 华为技术有限公司 业务报文转发处理方法、系统和接入点ap
US9743434B2 (en) * 2012-10-30 2017-08-22 Lg Electronics Inc. Method and device for fast link synchronization in WLAN system
US8874788B2 (en) * 2012-11-05 2014-10-28 Cisco Technology, Inc. Push-based short-cut requests within a directed acyclic graph
US9491001B2 (en) 2012-11-07 2016-11-08 Cisco Technology, Inc. Work group bridge nomadic roaming
US9654604B2 (en) * 2012-11-22 2017-05-16 Intel Corporation Apparatus, system and method of controlling data flow over a communication network using a transfer response
RU2628486C2 (ru) * 2013-01-03 2017-08-17 Хуавей Текнолоджиз Ко., Лтд. Системы и способы доступа к сети
US9826399B2 (en) * 2013-01-04 2017-11-21 Apple Inc. Facilitating wireless network access by using a ubiquitous SSID
RU2628321C2 (ru) * 2013-01-30 2017-08-15 Телефонактиеболагет Л М Эрикссон (Пабл) Генерирование защитного ключа для двойного соединения
US9326144B2 (en) * 2013-02-21 2016-04-26 Fortinet, Inc. Restricting broadcast and multicast traffic in a wireless network to a VLAN
US9953317B2 (en) * 2013-03-13 2018-04-24 Shopkeep.Com, Inc. Method and system for secure key rotation
US10389650B2 (en) 2013-03-15 2019-08-20 Aerohive Networks, Inc. Building and maintaining a network
US9413772B2 (en) 2013-03-15 2016-08-09 Aerohive Networks, Inc. Managing rogue devices through a network backhaul
US9210623B2 (en) 2013-03-15 2015-12-08 Cisco Technology, Inc. Wireless client association and traffic context cookie
US9800660B2 (en) * 2013-03-21 2017-10-24 Panasonic Intellectual Property Management Co., Ltd. Communication device, communication system and communication method
US9729433B2 (en) * 2013-05-01 2017-08-08 Commscope Technologies Llc Enhanced route tracing
US20140334336A1 (en) * 2013-05-10 2014-11-13 Relay2, Inc. Multi-Tenant Virtual Access Point- Network Resources Virtualization
US9854456B2 (en) * 2013-05-16 2017-12-26 Qualcomm, Incorporated Method and apparatus for managing multi-hop relay networks
US20160174253A1 (en) * 2013-07-12 2016-06-16 Mediatek Singapore Pte. Ltd. Method of channel access control in wireless local area networks
US9444766B2 (en) * 2013-08-02 2016-09-13 International Business Machines Corporation Identifying a port associated with a network node to which a selected network link is connected
US9247440B2 (en) * 2013-08-15 2016-01-26 Qualcomm Incorporated Automatic configuration of a network device
US9241350B1 (en) * 2013-08-16 2016-01-19 Sprint Communications Company L.P. Access network type identification in mobile internet protocol (MIP) registration (RRQ)
US10069675B2 (en) * 2013-08-30 2018-09-04 Nec Corporation Method for operating a distributed computing system and a distributed computing system
CN104469695B (zh) * 2013-09-12 2019-02-05 华为技术有限公司 网络接入方法、近距离通信服务器、中继终端及终端
IL229153B (en) 2013-10-30 2019-02-28 Verint Systems Ltd Systems and methods for protocol-based identification of rogue base stations
WO2015082753A1 (en) 2013-12-04 2015-06-11 Nokia Technologies Oy Access point information for wireless access
WO2015085321A1 (en) * 2013-12-06 2015-06-11 Mobile Iron, Inc. Mobile device traffic management
WO2015096905A1 (en) * 2013-12-24 2015-07-02 Telefonaktiebolaget L M Ericsson (Publ) A method and apparatus for detecting that an attacker has sent one or more messages to a receiver node
JP6221786B2 (ja) * 2014-01-31 2017-11-01 富士通株式会社 中継装置、通信システム、および、通信方法
US8856308B1 (en) * 2014-03-20 2014-10-07 Union Bay Networks, Inc. Cloud scale automatic identity management
JP6273972B2 (ja) * 2014-03-31 2018-02-07 富士通株式会社 情報処理装置、送受信装置、及び情報処理装置の制御方法
US10504148B2 (en) 2014-05-23 2019-12-10 Qualcomm Incorporated Peer-to-peer relaying of discovery information
US10142847B2 (en) * 2014-05-23 2018-11-27 Qualcomm Incorporated Secure relay of discovery information in wireless networks
KR20170120200A (ko) * 2014-06-12 2017-10-30 콘비다 와이어리스, 엘엘씨 콘텍스트 인식 이웃 발견
GB201410623D0 (en) * 2014-06-13 2014-07-30 Hagan Chris Wireless access point allocation and transfer
US10057766B2 (en) * 2014-10-21 2018-08-21 Qualcomm Incorporated Methods and systems for authentication interoperability
US9769661B2 (en) * 2015-04-06 2017-09-19 Qualcomm, Incorporated Wireless network fast authentication / association using re-association object
US9853883B2 (en) * 2015-05-08 2017-12-26 Cisco Technology, Inc. Device mobility in a mesh network
CN104954374B (zh) * 2015-06-15 2018-11-20 上海网车科技有限公司 一种车联网通信协议的设计方法
US9775181B2 (en) 2015-06-25 2017-09-26 Qualcomm Incorporated Reducing re-association time for STA connected to AP
CN108028000A (zh) * 2015-06-25 2018-05-11 迪堡多富公司 自动银行业务机固件流控制
CN105188047A (zh) * 2015-08-26 2015-12-23 广东欧珀移动通信有限公司 一种wifi无线漫游上网的方法及移动终端
CN105228213B (zh) * 2015-09-30 2019-03-12 青岛海信移动通信技术股份有限公司 一种移动设备进行中继的方法和装置
US9985945B2 (en) * 2015-10-22 2018-05-29 Sap Se Spoofing protection protocol for network-connected things
CN108293183B (zh) * 2015-11-18 2021-06-01 上海诺基亚贝尔股份有限公司 E-utran与wlan之间的切换
CN105407095B (zh) * 2015-11-26 2019-03-05 深圳市风云实业有限公司 不同网络间安全通信装置及其通信方法
KR101716983B1 (ko) * 2015-12-24 2017-03-15 서울대학교산학협력단 클러스터 트리 구조의 무선 통신 네트워크에서 자가 망 치료 방법
US20180013798A1 (en) * 2016-07-07 2018-01-11 Cisco Technology, Inc. Automatic link security
US10432465B2 (en) 2016-10-21 2019-10-01 Charter Communications Operating, Llc Automatic provisioning of a network access point
US11696250B2 (en) * 2016-11-09 2023-07-04 Intel Corporation UE and devices for detach handling
CN108076495B (zh) * 2016-11-16 2022-03-25 北京新岸线移动多媒体技术有限公司 无线网络中实现跨小区切换的方法、系统及装置
CN110024325B (zh) * 2016-11-26 2021-01-29 华为技术有限公司 用于设备之间mka协商的系统、方法和设备
CN106792684B (zh) * 2016-12-13 2020-04-14 国家电网有限公司信息通信分公司 一种多重防护的无线网络安全防护系统及防护方法
JP6585111B2 (ja) * 2017-03-15 2019-10-02 株式会社東芝 無線通信システム
US10172020B2 (en) * 2017-04-06 2019-01-01 Common Networks, Inc. Systems and methods for networking and wirelessly routing communications
BR112019024018A2 (pt) 2017-05-15 2020-06-09 Mixhalo Corp sistemas e métodos para fornecer áudio e dados em tempo real
EP3425867B1 (de) * 2017-07-05 2021-01-13 Nxp B.V. Kommunikationsvorrichtungen und zugehöriges verfahren
CN109429243B (zh) 2017-08-22 2022-12-27 阿里巴巴集团控股有限公司 监测配网设备的网络接入状态的方法、装置和系统
US10820242B2 (en) 2017-08-31 2020-10-27 Hewlett Packard Enterprise Development Lp Reroute network traffic from millimeter-wave link to WLAN transmission
US10470086B2 (en) 2017-09-12 2019-11-05 Cisco Technology, Inc. Stateful application identification while roaming
US10285108B1 (en) 2017-10-12 2019-05-07 Cisco Technology, Inc. Proactive roaming handshakes based on mobility graphs
WO2019084340A1 (en) * 2017-10-26 2019-05-02 Sophos Limited SYSTEM AND METHOD FOR PROVIDING SECURE VLAN IN A WIRELESS NETWORK
US11070392B2 (en) 2017-10-27 2021-07-20 Hilton International Holding Llc System and method for provisioning internet access
EP3697137A4 (de) * 2017-11-02 2021-06-30 LG Electronics Inc. Verfahren zum senden oder empfangen eines rahmens in wlan und vorrichtung dafür
US11122500B2 (en) * 2018-01-16 2021-09-14 Cisco Technology, Inc. Using a blockchain for optimized fast-secure roaming on WLANs
CN108259185B (zh) * 2018-01-26 2021-06-15 湖北工业大学 一种群组通信中抗泄漏的群密钥协商系统及方法
CN109379345B (zh) * 2018-09-28 2021-02-19 创新先进技术有限公司 敏感信息传输方法及系统
GB201816809D0 (en) * 2018-10-16 2018-11-28 Palantir Technologies Inc Establishing access systems
US20200162926A1 (en) * 2018-11-15 2020-05-21 Mediatek Inc. Detection And Prevention Of Broadcast And Multicast Packet Attacking For Uncovering And Disconnecting Attackers In Wireless Communications
US11824732B2 (en) * 2018-12-28 2023-11-21 Intel Corporation Techniques for artificial intelligence capabilities at a network switch
US11032669B2 (en) * 2019-01-15 2021-06-08 T-Mobile Usa, Inc. Multi-Bluetooth listeners with authenticated levels and power adjustment
US12063547B2 (en) 2019-02-07 2024-08-13 Hyundai Motor Company Method and apparatus for mutual coexistence communication in wireless LAN
CN111857941B (zh) * 2019-04-30 2021-09-03 华为技术有限公司 一种安全策略管理方法及装置
CN111901116B (zh) * 2019-05-05 2023-05-30 厦门雅迅网络股份有限公司 一种基于eap-md5改进协议的身份认证方法及系统
CN110445874B (zh) * 2019-08-14 2020-09-01 京东数字科技控股有限公司 一种会话处理方法、装置、设备和存储介质
US11219078B2 (en) 2019-09-05 2022-01-04 Apple Inc. System and method for enhanced high throughput (EHT) stations
EP4029208A1 (de) * 2019-09-11 2022-07-20 Carrier Corporation Bluetooth-mesh-routing mit subnetzen
CN113411194A (zh) * 2020-03-16 2021-09-17 瑞昱半导体股份有限公司 物联网网络系统及其组网方法
CN113812103B (zh) * 2020-04-16 2024-05-28 北京小米移动软件有限公司 管理消息帧传输方法、装置及存储介质
CN113542197A (zh) * 2020-04-17 2021-10-22 西安西电捷通无线网络通信股份有限公司 一种节点间保密通信方法及网络节点
US11558349B2 (en) * 2020-08-10 2023-01-17 Arista Networks, Inc. MAC mobility for 802.1x addresses for virtual machines
US12114202B2 (en) 2020-08-27 2024-10-08 Samsung Electronics Co., Ltd. Method and apparatus of supervised learning approach for reducing latency during context switchover in 5G MEC
CN114338356B (zh) * 2020-09-29 2023-07-28 华为技术有限公司 一种网络修复方法、电子设备及移动设备
US11700282B2 (en) 2020-10-26 2023-07-11 Netskope, Inc. Dynamic hyper context-driven microsegmentation
US11539731B2 (en) 2020-10-26 2022-12-27 Netskope, Inc. Dynamic hyper context-driven microsegmentation
US20240205155A1 (en) * 2022-12-19 2024-06-20 Nokia Solutions And Networks Oy Protocol agnostic cognitive congestion control

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5673031A (en) 1988-08-04 1997-09-30 Norand Corporation Redundant radio frequency network having a roaming terminal communication protocol
US5790536A (en) 1989-01-31 1998-08-04 Norand Corporation Hierarchical communication system providing intelligent data, program and processing migration
US5428636A (en) 1993-05-03 1995-06-27 Norand Corporation Radio frequency local area network
US5394436A (en) 1991-10-01 1995-02-28 Norand Corporation Radio frequency local area network
US6374311B1 (en) 1991-10-01 2002-04-16 Intermec Ip Corp. Communication network having a plurality of bridging nodes which transmit a beacon to terminal nodes in power saving state that it has messages awaiting delivery
US5940771A (en) 1991-05-13 1999-08-17 Norand Corporation Network supporting roaming, sleeping terminals
US5504746A (en) 1991-10-01 1996-04-02 Norand Corporation Radio frequency local area network
US6084867A (en) 1991-10-01 2000-07-04 Intermec Ip Corp. Apparatus and method of routing data in a radio frequency local area network
EP1246404B1 (de) 1991-10-01 2006-03-22 Broadcom Corporation Lokales Funkfrequenznetzwerk
US5539922A (en) * 1992-01-03 1996-07-23 Motorola, Inc. Multiple tree hierarchical portable communication system and method
US6701361B1 (en) 1996-08-22 2004-03-02 Intermec Ip Corp. Enhanced mobility and address resolution in a wireless premises based network
US6078575A (en) * 1996-10-01 2000-06-20 Lucent Technologies Inc. Mobile location management in ATM networks
US6167438A (en) * 1997-05-22 2000-12-26 Trustees Of Boston University Method and system for distributed caching, prefetching and replication
US6259791B1 (en) * 1998-02-26 2001-07-10 Motorola, Inc. Method and apparatus in a wireless messaging system for controlling a hierarchical provision of service
US20020002678A1 (en) * 1998-08-14 2002-01-03 Stanley T. Chow Internet authentication technology
AU2020300A (en) * 1998-10-23 2000-05-15 L-3 Communications Corporation Apparatus and methods for managing key material in heterogeneous cryptographic assets
US6581093B1 (en) * 1998-10-29 2003-06-17 International Business Machines Corporation Policy validation in a LDAP directory
TW453070B (en) * 2000-01-17 2001-09-01 Accton Technology Corp Wireless network communication system and method with double packet filtering function
FI20000760A0 (fi) * 2000-03-31 2000-03-31 Nokia Corp Autentikointi pakettidataverkossa
JP3628250B2 (ja) 2000-11-17 2005-03-09 株式会社東芝 無線通信システムで用いられる登録・認証方法
US7082473B2 (en) * 2001-02-01 2006-07-25 Lucent Technologies Inc. System and method for optimizing open shortest path first aggregates and autonomous network domain incorporating the same
US20020120844A1 (en) * 2001-02-23 2002-08-29 Stefano Faccin Authentication and distribution of keys in mobile IP network
US7043024B1 (en) * 2001-04-18 2006-05-09 Mcafee, Inc. System and method for key distribution in a hierarchical tree
US7483411B2 (en) * 2001-06-04 2009-01-27 Nec Corporation Apparatus for public access mobility LAN and method of operation thereof
US7389412B2 (en) * 2001-08-10 2008-06-17 Interactive Technology Limited Of Hk System and method for secure network roaming
US7007040B1 (en) * 2001-12-04 2006-02-28 General Dynamics C4 Systems, Inc. Method and apparatus for storing and updating information in a multi-cast system
US20030112977A1 (en) * 2001-12-18 2003-06-19 Dipankar Ray Communicating data securely within a mobile communications network
KR100470915B1 (ko) * 2001-12-28 2005-03-08 한국전자통신연구원 Ｉｐ계층에서의 패킷 보안을 위한 인터넷 정보보호시스템의 제어 방법
US6965674B2 (en) * 2002-05-21 2005-11-15 Wavelink Corporation System and method for providing WLAN security through synchronized update and rotation of WEP keys
US7266838B2 (en) * 2002-10-31 2007-09-04 Hewlett-Packard Development Company, L.P. Secure resource
US7340247B1 (en) * 2003-05-29 2008-03-04 Airespace, Inc. Wireless network infrastructure including wireless discovery and communication mechanism

Also Published As

Publication number Publication date
US7844057B2 (en) 2010-11-30
AU2003295466A1 (en) 2004-06-18
EP1570625A2 (de) 2005-09-07
CA2507119C (en) 2015-10-06
CA2507119A1 (en) 2004-06-10
US20050220054A1 (en) 2005-10-06
US20090262718A1 (en) 2009-10-22
US7561549B2 (en) 2009-07-14
ATE381842T1 (de) 2008-01-15
EP1570625B1 (de) 2007-12-19
CN101742496A (zh) 2010-06-16
AU2003295466B2 (en) 2009-07-23
US20040103282A1 (en) 2004-05-27
WO2004049740A3 (en) 2004-08-12
DE60318244D1 (de) 2008-01-31
CN100579304C (zh) 2010-01-06
CN101742496B (zh) 2016-08-10
CN1503595A (zh) 2004-06-09
US20070288997A1 (en) 2007-12-13
US7350077B2 (en) 2008-03-25
WO2004049740A2 (en) 2004-06-10
US7706345B2 (en) 2010-04-27
AU2003295466C1 (en) 2010-01-07

Similar Documents

Publication Publication Date Title
DE60318244T2 (de) 802.11-standard benutzung eines komprimierten reassoziationsaustauschs für schnelles weiterreichen
AU2004231612B2 (en) 802.11 using a compressed reassociation exchange to facilitate fast handoff
US8817757B2 (en) Zero-configuration secure mobility networking technique with web-based authentication interface for large WLAN networks
DE102006038591B4 (de) Verfahren und Anordnung zum Bereitstellen eines drahtlosen Mesh-Netzwerks
EP2052517B1 (de) Verfahren und system zum bereitstellen eines zugangsspezifischen schlüssels
DE60114789T2 (de) Authentifizierung in einem paketdatennetz
DE60218289T2 (de) Verfahren zum speichern und verteilen von verschlüsselungsschlüsseln
EP1529374B1 (de) Verfahren und system für gsm-authentifizierung bei wlan-roaming
DE602004011573T2 (de) Verbesserungen der authentifikation und autorisierung in heterogenen netzwerken
DE60302882T2 (de) Sicherheitsübertragungsprotokoll für ein mobilitäts-ip-netzwerk
RU2407181C1 (ru) Аутентификация безопасности и управление ключами в инфраструктурной беспроводной многозвенной сети
KR101481558B1 (ko) 이기종 무선접속망간 보안연계 설정 방법
DE102006004868B4 (de) Verfahren und Server zum Bereitstellen eines Mobilitätsschlüssels
US11962685B2 (en) High availability secure network including dual mode authentication
US20060072759A1 (en) Methods and apparatus for bootstrapping mobile-foreign and foreign-home authentication keys in mobile IP
EP1887758B1 (de) Verwendung eines komprimierten Reassoziationsaustauschs zur Ermöglichung einer schnellen Weiterleitung
CN100415034C (zh) 一种使移动节点实现自代理功能的方法
DE102021113263A1 (de) Extreme-High-Throughput-Fast-Initial-Link-Setup-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen
CH694678A5 (de) Verfahren und System für GSM-Authentifizierung bei WLAN Roaming.

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, 80639 M