-
ERFINDUNGSGEBIET
-
Die
vorliegende Erfindung betrifft ein Multicastingsteuerverfahren in
Kommunikationsnetzen, insbesondere ein 802.1X-Protokoll-basiertes
Multicastingsteuerverfahren.
-
Allgemeiner
Stand der Technik
-
In
Kommunikationsnetzen ist es für
eine Datenweiterleiteinrichtung wie etwa eine Vermittlung oder einen
Router zur Datensicherheit und Ausnutzung von Netzressourcen vorteilhaft,
Netzdaten durch Teilnehmergruppen weiterzuleiten. Beispielsweise
wird unter der Annahme, daß eine
Multicast-Gruppe G in einem Kommunikationsnetz existiert, eine Anforderungsnachricht
eine bestimmte Zeitperiode nach dem Weiterleiten der Daten durch den
Router für
die Multicast-Gruppe
G geschickt, um zu verifizieren, ob irgendein Mitglied der Multicast-Gruppe
G noch existiert, und Mitglieder in der Multicast-Gruppe G senden
wieder IGPM-(Internet Group Management Protocol)-Nachrichten, um
auf die Anforderungsnachricht zu antworten; falls in dem Netz kein
Mitglied der Multicast-Gruppe existiert, erhält der Router keine Antwort
und versucht dann, wieder abzufragen, und wenn er immer noch keine Nachricht
erhält,
geht er davon aus, daß in
dem Netz kein Mitglied der Multicast-Gruppe G existiert und hört dann
damit auf, Daten für
die Multicast-Gruppe G
weiterzuleiten. Wegen der Tatsache, daß die Datenweiterleitung mit
dem Multicast-Gruppenmanagementverfahren im Vergleich zum Rundsendemodus spezifischer
ist, sind Datensicherheit und Weiterleitungseffizienz höher.
-
Traditionelle
LANs, die das IEEE 802.1x-Protokoll verwenden, können jedoch nur eine portbasierte
Multicastingsteuerung implementieren, d.h., Teilnehmer zu Multicast-Gruppen
hinzufügen
durch das Hinzufügen
von Ports zu jenen Multicast-Gruppen. Wenn eine Anforderung zum
Beitreten zu einer Multicast-Gruppe von einem Teilnehmerendgerät gesendet
wird, fügt
die Netzvermittlungseinrichtung entsprechend dem Umstand die MAC-Adresse
des Endgeräts
zu der Multicast-Gruppe hinzu, damit der Teilnehmer zu der Multicast-Gruppe
hinzugefügt
wird. Ein derartiges Verfahren liefert nur Portnummer und MAC-Adresse
des Teilnehmerendgeräts
anstatt Teilnehmerinformationen, weshalb eine etwaige Steuerung
hinsichtlich des Teilnehmers aufgrund eines Mangels an Teilnehmerinformationen
nicht ausgeführt
werden kann. Das Dokument D1 (WO 02 45334 A) offenbart ein Verfahren
zum Bereitstellen eines sicheren Multicasting über ein lokales Netz, das eine Prozedur
betrifft, während
derer ein Teilnehmer einer Multicastgruppe beitritt. Obwohl das IEEE802.1X-Protokoll
ein portbasiertes Netzzugangssteuerungsprotokoll ist, das das Teilnehmermanagement
unterstützt
und Mehrfach-Teilnehmer-Authentifizierung durch einen einzelnen
Port akzeptiert, kann diese Fähigkeit
nicht dazu genutzt werden, um das Hinzufügen von Teilnehmern zu einer Multicast-Gruppe
zu steuern, was zu Unsteuerbarkeit beim Hinzufügen von Teilnehmern zu einer
Multicast-Gruppe führt.
-
Kurze Darstellung
der Erfindung
-
Die
Aufgabe der Erfindung besteht in der Bereitstellung eines 802.1X-Protokoll-basierten
Multicastingsteuerverfahrens zur Implementierung der Steuerbarkeit
beim Hinzufügen
eines Teilnehmers zu einer Multicast-Gruppe.
-
Zur
Lösung
der obigen Aufgabe wird ein Verfahren zur Multicastingkontrolle
auf Basis des 802.1X-Protokolls bereitgestellt, welches folgende Schritte
umfasst:
-
Schritt 1:
Für einen
Teilnehmer wird eine 802.1X-Authentifizierung durchgeführt, und
Informationen (101) über
den authentifizierten Teilnehmer werden gespeichert,
-
Schritt 2:
Eine von dem per 802.1X authentifizierten Teilnehmer gesendete Anforderungsnachricht
für den
Beitritt in eine Multicastgruppe wird abgefangen,
-
Schritt 3:
Die Portnummer (102), die MAC-Adresse (103) und
die Multicast-IP-Adresse (104) des Teilnehmers werden aus
der abgefangenen Nachricht erhalten,
-
Schritt 4:
Anhand der Portnummer (102) und MAC-Adresse (103)
werden in dem per 802.1X authentifizierten Ergebnis entsprechende
Kontonummerinformationen (101) des Teilnehmers gesucht,
-
Schritt 5:
Die Kontonummerinformationen (101) des Teilnehmers und
die Multicast-IP-Adresse (104) werden authentifiziert,
und anschließend
wird der Teilnehmer in die Multicastgruppe aufgenommen, falls die
Authentifizierung erfolgreich bestanden wurde; andernfalls wird
die Anforderung des Teilnehmers zurückgewiesen.
-
In
Schritt 5: Der Authentifizierungsserver am 802.1X-Authentifizierungsende
wird verwendet, um die Kontonummerinformationen (101) des
Teilnehmers und die Multicast-IP-Adresse (104) zu authentifizieren.
-
Die
Authentifizierungen von Kontonummerinformationen und der Multicast-IP-Adresse
(104) des Teilnehmers werden implementiert, indem verifiziert
wird, ob die Multicast-IP-Adresse
(102) authorisiert ist, die Kontonummerinformationen (101)
zu empfangen.
-
Wenn
die 802.1X-Authentifizierung portbasiert ist, wird, wenn ein an
den Port angeschlossener Teilnehmer eine Anforderung stellt, einer
Multicast-Gruppe beizutreten, zuerst die MAC-Adresse (103)
des Teilnehmers gesucht; wenn die MAC-Adresse (103) gefunden
ist, werden die Kontonummer informationen (101) des Teilnehmers
entsprechend der MAC-Adresse
(103) und der Portnummer (102) gesucht;
wenn
die 802.1X-Authentifizierung MAC-basiert ist, werden, wenn ein an
den Port angeschlossener Teilnehmer eine Anforderung stellt, einer
Multicast-Gruppe beizutreten, die Kontonummerinformationen (101) des
Teilnehmers entsprechend der MAC-Adresse (103) und der
Portnummer (102) direkt gesucht.
-
Der
Teilnehmer tritt der Multicast-Gruppe durch das IGPM-Protokoll bei.
-
Wenn
gemäß dem Verfahren
der vorliegenden Erfindung ein durch das 802.1X-Protokoll authentifizierter
Teilnehmer anfordert, einer Multicast-Gruppe beizutreten, wird die
Anforderungsnachricht zum Beitritt zur Multicast-Gruppe zuerst abgefangen,
und dann werden Portnummer, MAC-Adresse und Kontonummerinformationen
des Teilnehmers der abgefangenen Nachricht entnommen, anstatt daß der Teilnehmer
direkt zu der Multicast-Gruppe hinzugefügt wird, dann werden die entsprechenden Teilnehmerinformationen
aus dem 802.1X-authentifizierten
Ergebnis entsprechend der Portnummer und der MAC-Adreß-Informationen
gesucht, und die Kontonummer und die Multicast-IP-Adresse des Teilnmehmers
werden wieder authentifiziert, und dann wird der Teilnehmer zu der
Multicast-Gruppe hinzugefügt,
falls die Authentifizierung erfolgreich bestanden wurde, andernfalls
wird die Anforderung des Teilnehmers zurückgewiesen. Die Lösung kann
gesteuertes Multicasting, Authentifizierung der Legalität des Hinzufügens zum
Multicasting und Abrechnung implementieren; außerdem erfordert das Verfahren
keine Modifikation an Multicasting-Client-Software oder Server-Software,
stattdessen ist nur eine einfache Konfiguration am 802.1X-Geräteende und
Authentifizierungsserver am Authentifizierungsende erforderlich,
ist es vorteilhaft für
den Schutz existieren der Investitionen und Kompatibilität an existierender
Software.
-
Kurze Beschreibung
der Zeichnungen
-
1 zeigt
die Architektur des 802.1X-Protokolls;
-
2 zeigt
die Architektur des 802.1X-Authentifizierungs-basierten gesteuerten
Multicasting;
-
3 zeigt
den Authentifizierungsprozeß des
802.1X-Authentifizierungs-basierten gesteuerten Multicasting;
-
4 ist
das Flußdiagramm
einer Ausführungsform
des Verfahrens gemäß der vorliegenden Erfindung.
-
Ausführliche
Beschreibung der Ausführungsform
-
Die
vorliegende Erfindung wird unter Bezugnahme auf die Zeichnungen
näher beschrieben.
-
Unter
Bezugnahme auf 1, in der das in 1 gezeigte
IEEE802.1X-Protokoll ein portbasiertes Netzzugangssteuerprotokoll
ist und zum Authentifizieren und Steuern des Client-Zugangs auf
einer physikalischen Ebene von Netzgeräten verwendet wird. Es gibt
in 1 drei Entitäten:
802.1X-Client-Ende, 802.1X-Geräteende
und Authentifizierungsende. Authentifizierungsinformationen werden durch
das EAP (extensible authentication protocol) zwischen Authentifizierungs-Servern
des Authentifizierungsendes und 802.1X-Geräteende ausgetauscht. EAPOL
dient als das Authentifizierungsprotokoll zwischen 802.1X-Client-Ende
und 802.1X-Geräteende. Üblicherweise
ist das 802.1X-Geräteende auf
der Zugangsebene des Netzes implementiert; das 802.1X-Client-Ende
ist im PC des Teilnehmers installiert; das 802.1X-Authentifizierungs-
Serversystem befindet sich üblicherweise
im AAA-Center (Accounting, Authentication, and Authorization). Innerhalb
des 802.1X-Geräteendes
gibt es gesteuerte Ports und ungesteuerte Ports. Die ungesteuerten Ports
befinden sich immer in einem unverbundenen Zwei-Wege-Zustand und
werden hauptsächlich
zum Übertragen
von EAPOL-Frames verwendet; deshalb können EAPOL-Frames jederzeit über die
ungesteuerten Ports empfangen und gesendet werden. Die gesteuerten
Ports werden nur dann geöffnet,
wenn die Authentifizierung bestanden ist, um Netzressourcen und
Dienste zu übertragen.
Entsprechend der Anwendungsumgebung können die gesteuerten Ports
als gesteuerte Zwei-Wege-Ports oder gesteuerte Ein-Wege-Ports konfiguriert
sein. Wenn mit der obigen Architektur das 802.1X-Geräteende mit
einer Ethernet-Schalter- oder Breitbandzugangseinrichtung implementiert
ist, kann jede mit Ports mit einer Ethernet-Schalter- oder Breitbandzugangseinrichtung
verbundene Teilnehmereinrichtung des Client-Endes auf interne Netzressourcen
zugreifen, wenn sie die Authentifizierung bestanden hat; ansonsten
kann nicht sie auf interne Netzressourcen zugreifen. Die obigen
Ports physische oder logische sein, beispielsweise besteht eine
typische Anwendung darin, einen Client-PC mit einem physischen Port
des Ethernet-Schalters
zu verbinden.
-
Gegenwärtig kann
das Radius-Protokoll auch zwischen dem 802.1X-Geräteende und
dem Authentifizierungsserver in der in 1 gezeigten Architektur
arbeiten; somit ist der Authentifizierungsserver ein Radius-Server,
und das 802.1X-Geräteende
kann als ein mit dem Radius-Server verbundender Client angesehen
werden.
-
Von
oben betrachtet wird in der in 1 gezeigten
Architektur das 802.1X-Protokoll ausgelöst, um den Teilnehmer zu authentifizieren,
wenn der Ethernet-Schalter die von einem 802.1X-Client-Ende geschickte
EAPOL-Start-Nachricht
zu dem 802.1X-Geräteende überträgt. Nachdem
der Authentifizierungsserver am Authentifizierungsende den Teilnehmer
erfolgreich authentifiziert, werden gesteuerte Ports des 802.1X-Geräteendes
geöffnet,
um Netzressourcen und Dienste für
den Teilnehmer zu übertragen.
Somit ist der Teilnehmer online. Wenn der Host eines online-Teilnehmers
zu einer Multicast-Gruppe hinzufügen
möchte,
sendet der Host eine IGMP-Nachricht (unter der Annahme, daß das IGMP-Protokoll
verwendet wird, tatsächlich
ist es nicht auf das Protokoll beschränkt) an den Ethernet-Schalter (Geräteende)
durch Multicasting-Client-Software, um den Beitritt zu der Multicast-Gruppe anzuzeigen,
weshalb der Ethernet-Schalter damit beginnt, die Daten der Multicast-Gruppe
an den Host des Teilnehmers weiterzuleiten.
-
Infolgedessen
wird eine Netzverbindung zu dem Teilnehmer durch das 802.1X-Protokoll
hergestellt, solange der Teilnehmer die 802.1X-Protokoll-basierte
Authentifizierung besteht. Wenn der Teilnehmer auf dieser Grundlage
den Beitritt zu einer Multicast-Gruppe anfordert, können die
MAC-Adresse und die Portnummer des Hosts des Teilnehmers aus der
durch die Verbindung übertragenen
Nachricht oder Anforderung des Teilnehmers erhalten werden. Auf
diese Weise können
detaillierte Informationen des Teilnehmers aus den authentifizierten
Daten des Teilnehmers gemäß der MAC-Adresse
und der Portnummer erhalten werden, um die Steuerung der Multicasting-Hinzufügung zu
implementieren und das Unsteuerbarkeitsproblem der Multicasting-Hinzufügung gemäß traditioneller
Verfahren zu lösen.
-
Das
Grundprinzip der vorliegenden Erfindung ist in 2 gezeigt.
Der in 2 gezeigte Ethernet-Schalter ist so ausgelegt,
daß er
das in 1 gezeigte Client-Ende anschließt und das in 1 gezeigte
Geräteende
implementiert. Deshalb wird das Ethernet-Schalter verwendet, um
das Ein-/Ausschalten des Netzanschlusses zum Client zu steuern.
Weil die Ports am Ethernet-Schalter für nicht authentifizierte Teilnehmer
nicht zur Verfügung
stehen, aber automatisch und dynamisch konfiguriert und zum Zugriff
auf Netzressourcen für
authentifizierte Teil nehmer verwendet werden können, liefert der in 2 gezeigte
802.1X-Protokoll-basierte Ethernet-Schalter dem Betreiber Betriebsmerkmale.
Der Ethernet-Schalter als 802.1X-Geräteende in 2 verwendet
ein Radius-Protokollmodul zum Übertragen
von Authentifizierungsinformationen zu dem Radius-Server als Authentifizierungsende.
Das 802.1X-Authentifizierungsmodul wird verwendet, um von dem Teilnehmer
von dem entsprechenden Port an dem Ethernet-Schalter gesendete 802.1X-Protokoll-basierte
Authentifizierungsinformationen zu übertragen, und überträgt die Authentifizierungsinformationen
(die detaillierte Informationen des Teilnehmers enthalten, wie etwa
Benutzername und Paßwort
usw.) an den Authentifizierungsserver am Authentifizierungsende
zur Authentifizierung durch das Radius-Authentifizierungsmodul.
Wenn der Teilnehmer die Authentifizierung besteht, enthalten die
authentifizierten Informationen detaillierte Informationen des Teilnehmers,
und das 802.1X-Authentifizierungsmodul startet einen Portdienstkanal
(was dem Anschließen
an den Schalter K1 in 2 entspricht) für den Teilnehmer.
Auf diese Weise kann der Teilnehmer auf Netzressourcen durch diesen
Portdienstkanal zugreifen, d.h., eine 802.1X-Protokollbasierte Netzverbindung
wird für
den Teilnehmer hergestellt. Wenn der Teilnehmer auf der Basis der
obigen 802.1X-Verbindung durch den Portdienstkanal eine Anforderungsnachricht
sendet (unter der Annahme, das es eine IGMP-basierte Nachricht ist),
einer Multicast-Gruppe beizutreten, kann das Multicastingsteuermodul
in dem Ethernet-Schalter so konfiguriert sein, daß es die
IGMP-Nachricht abfängt,
um so die MAC-Adresse und die Portnummer des Teilnehmers in der
IGMP-Nachricht zu erhalten und gleichzeitig eine Multicast-IP-Adresse
zu erhalten, und erhält dann
die Kontonummerinformationen des Teilnehmers (Benutzername, Paßwort usw.)
durch die 802.1X-Verbindung für
den Teilnehmer entsprechend der MAC-Adresse und Portnummer, als
nächstes wird
eine gesteuerte Multicastingverbindung entsprechend den Teilnehmerinformationen
und der Multicast-IP-Adresse hergestellt, d.h., das Multicastingsteuermodul
steuert soweit erforderlich das Ein-/Ausschalten des Multicastingschalters
K2. Dadurch erhält
man durch die Kombination aus Multicasting und 802.1X-authentifizierten
Port und MAC-Adresse des Teilnehmers eine Steuerbarkeit bei Multicasting-Hinzufügung. Was
den Fall in 2 anbetrifft, steuert das 802.1X-Authentifizierungsmodul
den Schalter K1 des Portdienstkanals, und das Multicastingsteuermodul
steuert den Multicastingschalter K2 des Portdienstkanals.
-
4 ist
das Flußdiagramm
einer Ausführungsform
des Verfahrens gemäß der vorliegenden Erfindung.
Wegen des in 4 beschriebenen 802.1X-Authentifizierungsbasierten
gesteuerten Multicasting-Authentifizierungsprozesses wird bitte
auf 3 verwiesen. Es sei angemerkt, daß bei der
in 4 gezeigten Ausführungsform davon ausgegangen
wird, daß zum
Hinzufügen
eines Teilnehmers zu der Multicast-Gruppe das IGMP-Protokoll verwendet wird
und daß das
Multicastingsteuermodul in dem Ethernet-Schalter im voraus konfiguriert ist,
die von dem Teilnehmer gesendete IGMP-Nachricht abzufangen. Wie
in 4 gezeigt, sendet in Schritt 1 der Teilnehmer
eine EAPOL-Nachricht,
um die 802.1X-Protokoll-Authentifizierung am 802.1X-Geräteende zu
Beginn von online auszulösen,
d.h., die EAPOL-Nachricht wird zu dem 802.1X-Authentifizierungsmodul
in dem Ethernet-Schalter (Geräteende) übertragen;
in Schritt 2 sendet das 802.1X-Authentifizierungsmodul
die Authentifizierungsinformationen des Teilnehmers an den Radius-Server
am Authentifizierungsende zur Authentifizierung über das Radius-Modul. Wenn
die Authentifizierung erfolgreich bestanden ist, werden die authentifizierten
Teilnehmerinformationen im Ethernet-Schalter gespeichert (z.B. in
dem 802.1X-Authentifizierungsmodul). Diese beiden Schritte sind
in erster Linie ausgelegt, um einen Teilnehmerauthentifizierungsprozeß zu absolvieren und
den Teilnehmer online zu bringen. Wenn der authenti fizierte Teilnehmer
in Schritt 3 eine IGMP-Nachricht sendet, um den Beitritt
zu einer Multicast-Gruppe anzufordern, fängt das Multicastingsteuermodul
in Schritt 4 die IGMP-Nachricht ab; hier fügt das Multicastingsteuermodul
diesen Teilnehmer der Multicast-Gruppe nicht direkt hinzu, stattdessen
sendet es die aus der IGMP-Nachricht erhaltenen Portnummer- and
MAC-Adreßinformationen
des Teilnehmers an das 802.1X Authentifizierungsmodul, und eine
Multicast-IP-Adresse wird gleichzeitig aus der IGMP-Nachricht erhalten,
das 802.1X-Authentifizierungsmodul sucht nach entsprechenden Kontonummerinformationen
des Teilnehmers in dem 802.1X-authentifizierten Ergebnis entsprechend Port-
und MAC-Adreßinformationen
und liefert dann die Kontonummerinformationen des Teilnehmers zurück an das
Multicastingsteuermodul; in Schritt 6, sendet das Multicastingsteuermodul
die Kontonummerinformationen und Multicast-IP-Adresse des Teilnehmers
an den Radius-Server am Authentifizierungsende wieder zur Authentifizierung über das
Radius-Module, d.h., der Radius-Server authentifiziert den Teilnehmer
entsprechend den Kontonummerinformationen und der Multicast-IP-Adresse
des Teilnehmers durch Verifizieren, ob die Multicast-IP-Adresse
authorisiert ist, die Kontonummer zu empfangen; wenn die Authentifizierung
erfolgreich bestanden ist, wird der Teilnehmer in Schritt zu der Multicast-Gruppe
hinzugefügt;
ansonsten wird die Aufforderung des Teilnehmers zurückgewiesen. Nachdem
der Teilnehmer zu der Multicast-Gruppe hinzugefügt worden ist, behält das Multicastingsteuermodul
die Multicastingverbindung bei, bis die Teilnehmeranforderung austritt.
-
Es
sei angemerkt, daß,
weil die 802.1X-Protokollbasierte Authentifizierung an existierenden Ethernet-Schaltern portbasiert
oder MAC-Adreß-basiert
sein kann, die beiden Fälle
getrennt behandelt werden sollten. Bei einem portbasierten Authentifizierungsmodus
steuert das 802.1X-Modul für
jeden Port nur einen einzelnen authenti fizierten Teilnehmer und
hält dadurch
nur eine 802.1X-Verbindung
aufrecht; wenn jedoch die 802.1-Authentifizierung bestanden wird,
kann der Port mit mehreren Client-PCs verbunden werden. Wenn irgendeiner
der an diesen Port angeschlossenen Client-PCs anfordert, einer Multicast-Gruppe beizutreten,
wird infolgedessen das MAC-Substitutionsverfahren verwendet, d.h.,
der Ethernet-Schalter weist das 802.1X-Modul an zu verifizieren,
ob die MAC-Adresse
des Teilnehmers existiert; wenn ja, dann zeigt das an, daß der Teilnehmer die
Authentifizierung bestanden hat, das 802.1X-Modul schickt die MAC-Adresse
des authentifizierten Teilnehmers an den Ethernet-Schalter zurück. Das Multicastingsteuermodul
sucht dann nach den Kontonummerinformationen des Teilnehmers entsprechend
der zurückgeschickten
MAC-Adresse und Portnummer.
-
Im
MAC-Adreß-basierten
Authentifizierungsmodus hat das 802.1X-Modul jeden an den Port angeschlossenen
PC authentifiziert und entsprechende Verbindungen stehen zur Verfügung. Wenn
ein an den Port, angeschlossener Teilnehmer anfordert, einer Multicast-Gruppe
beizutreten, fragt der Ethernet-Schalter deshalb die MAC-Adresse
des Teilnehmers direkt im 802.1X-Modul ab; wenn das 802.1X-Modul
die MAC-Adresse zurückschickt, sucht
der Ethernet-Schalter deshalb nach den Kontonummerinformationen
des Teilnehmers gemäß der MAC-Adresse
und Portnummer. Deshalb kann jeder Teilnehmer einen entsprechenden
802.1X-Anschluß gemäß der jeweiligen
MAC-Adresse und Portnummer finden, d.h., die Kontonummerinformationen
des Teilnehmers können
erhalten werden.
-
Die
in 4 gezeigte Ausführungsform verwendet einen
Radius-Server zur Verwaltung der Informationen des Teilnehmers.
Deshalb verwendet die Ausführungsform
auch den Radius-Server zum Steuern des Hinzufügens eines Teilnehmers zum
Multicasting. Genauer gesagt wird dies implementiert, indem ein
gesteuerter Multicasting- Eigenschaftspunkt in
dem Radius-Server hinzugefügt
wird, d.h., die Kontonummer des Teilnehmers wird auf dem Radius-Server
konfiguriert, und dann wird der Multicasting-Mehrwertdienst zu der Kontonummer hinzugefügt. Mit
diesem Eigenschaftspunkt können
eine oder mehrere Multicast-Adressen für den Teilnehmer hinzugefügt werden.
Wenn der Radius-Server eine Authentifizierungsanforderung erhält, die
die Kontonummerinformationen und Multicast-IP-Adresse des Teilnehmers
enthält,
wird, wenn die gesteuerte Multicasting-Eigenschaft zur Verfügung steht,
der Radius-Server verifizieren, ob die Multicast-IP-Adresse authorisiert
ist; wenn sie nicht authorisiert ist, gibt der Radius-Server eine
Nachricht "Authentifizierung
bestanden" zurück, ansonsten
gibt der Radius-Server eine Nachricht "Authentifizierung nicht bestanden" zurück.
-
Infolgedessen
kann der Multicasting-Eigenschaftspunkt an das Konto des Teilnehmers
als eine Mehrwertdiensteigenschaft angehängt werden, d.h., der Teilnehmer
wird zuerst hinzugefügt,
und dann wird ein Multicastingkanal für den Teilnehmer gestartet.
Auf diese Weise kann der Multicasting-Mehrwertdienst für Betreiber
gemäß der vorliegenden
Erfindung implementiert werden, um die Multicasting-Mehrwertdienstabrechnung
von der elementaren 802.1X-Zugangs-Authentifizierungsverbindungsabrechnung
zu trennen, damit die Verrechnung zwischen verschiedenen Service
Providers vereinfacht wird.