EP1854267A1 - Verfahren zum einrichten einer kommunikationsbeziehung in zumindest einem kommunikationsnetz - Google Patents

Verfahren zum einrichten einer kommunikationsbeziehung in zumindest einem kommunikationsnetz

Info

Publication number
EP1854267A1
EP1854267A1 EP06707796A EP06707796A EP1854267A1 EP 1854267 A1 EP1854267 A1 EP 1854267A1 EP 06707796 A EP06707796 A EP 06707796A EP 06707796 A EP06707796 A EP 06707796A EP 1854267 A1 EP1854267 A1 EP 1854267A1
Authority
EP
European Patent Office
Prior art keywords
dhcp
communication
okn
access
communication device
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.)
Withdrawn
Application number
EP06707796A
Other languages
English (en)
French (fr)
Inventor
Friedrich Armbruster
Stephan Binde
Chlodwig NEUHÄUSLER
Christelle Sippel
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Nokia Siemens Networks GmbH and Co KG
Nokia Solutions and Networks SpA
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 Nokia Siemens Networks GmbH and Co KG, Nokia Solutions and Networks SpA filed Critical Nokia Siemens Networks GmbH and Co KG
Publication of EP1854267A1 publication Critical patent/EP1854267A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types

Definitions

  • the multiplexer devices In current communication networks, in particular subscriber access networks - also referred to as access networks - several subscribers or subscribers associated communication devices via multiplexer devices - also known as DSLAM or Digital Subscriber Line Access Multiplexer - connected to a higher-level communication network - also known as the backbone.
  • the task of the multiplexer devices is to forward information from all participants to the backbone network and to provide information from the backbone network directly to the individual subscribers.
  • the multiplexer device In order to avoid an unnecessary overload of the capacity of the respective data transmission paths and thus a blockade of the communication device, the multiplexer device is designed so that in the upstream direction, ie. H. from the individual communication devices in the direction of the higher-level communication network, all information to be transmitted is forwarded in the downstream direction, i. H. from the superordinate network in the direction of the individual communication devices, but only information that is addressed directly to the individual subscribers to be forwarded. This means that transmitted in the parent communication network broadcast information is not transmitted from the respective multiplexer device
  • such an access network consists of 4096 subscribers which, for example, transmit a resource request at the same time with the data rate x bit / s to the superordinate communication network, a transmission load of 4096 * x bit / s arises in the upstream direction. If, on the part of the superordinate communication network, each subscriber with a corresponding corresponding broadcasting cast message at the same rate x bit / s sends a response, for example, creates a transmission load in the downstream direction of 4096 * 4096 * x bit / s. This leads in no time to an overload of the multiplexer.
  • the DHCP protocol (RFC 2131) is a typical application for assigning subscribers, inter alia, an address designed according to the Internet protocol - also referred to below as an IP address - by means of which the respective subscribers are entitled to access information on the Internet Exchange context of a communication relationship.
  • IP addresses are maintained in a pooled DHCP server and assigned to a participant establishing a communication relationship only when required. Since it is relatively unlikely that all participants will be active at the same time (especially as part of an online service), the pool of IP addresses held in the pool may be less than the total number of potential users.
  • this communication device Since the communication device assigned to the respective subscriber (also referred to as host) has not yet assigned an IP address when switching on, ie at the beginning of establishing a communication relationship, this communication device uses a DHCP discovery command to send out a corresponding request or message by broadcasting - Process or broadcast sent to active DHCP server. To identify the requesting communication device, the respective MAC address is inserted in the sent request messages. In response, all active DHCP servers that still have freely assignable IP addresses in the pool send out a corresponding response or return message (DHCP-OFFER) by means of broadcast in the direction of the requesting communication device. The requesting communication device or host selects an offer (DHCPREQUEST) and in turn makes this known to all DHCP servers via broadcast. The selected DHCP server confirms by sending the communication device shared IP address (DHCPACK) - then all other DHCP servers withdraw their offer.
  • DHCPREQUEST an offer
  • the requesting communication device or host can also be sent further data relevant to the network access, eg., the subnet mask, the domain name server addresses, and the default gateway.
  • DHCP client Within the framework of the DHCP protocol, which is to assign an IP address to the subscribers or to the communication devices assigned to them, there are two possibilities, such as responses or return messages of the DHCP server, which assigns the IP addresses, to the requesting communication device (DHCP client).
  • the answer On the one hand, the answer is addressed directly to the respective subscriber or communication device or, on the other hand, the answer is sent back as a broadcast.
  • forwarding directly addressed return messages is not a problem.
  • a direct addressed to a participant answer (unicast) is forwarded by the multiplexer (DSLAM) directly to the respective addressed, connected participants, so that this participant with the assigned IP address for the network is authorized access - d. H.
  • DSLAM multiplexer
  • the technical problem arises that the multiplexer devices which can not forward messages transmitted in the context of a broadcast transmission method or broadcast to all communication devices connected to a multiplexer, since otherwise the risk of overloading exists.
  • the incoming broadcasting at a multiplexer broadcast messages are discarded, ie the respective subscriber is not assigned an IP address.
  • DHCP responses in which the sent in the context of a broadcast return messages (DHCP responses) are present, especially when in a network behind the multiplexer ie the immediately following superordinate communication network additional network elements are arranged, which have no information or overview of the structure of the multiplexer network or subscriber access network and therefore basically forward DHCP responses as a broadcast to ensure that all in Subscriber access network arranged participants or communication devices receive these answers or feedback.
  • the transmission of the broadcast DHCP responses can alternatively also be avoided by implementing DHCP relays in the individual multiplexer devices in accordance with RFC 3046.
  • DHCP relays communicate directly with the individual DHCP servers and have a database with the respectively required subscriber information.
  • the configuration of DHCP relays is associated with a high technical and economic effort, which is not desirable by many network operators.
  • the invention is thus based on the object of further improving the establishment of communication relationships in subscriber access networks, in particular the allocation of IP addresses in the context of the DHCP protocol, in particular while avoiding the previously used PPPoE protocol.
  • the object is achieved on the basis of the features of the preamble of patent claim 1 by its characterizing features.
  • the essential aspect of the method according to the invention is that the information representing the communication-relationship-initiating communication device is stored in the communication network and that the feedback transmitted by means of the broadcast transmission method is detected and target information contained in the detected return-message is compared with the stored information , Upon detection of at least partial coincidence of the information being compared, the feedback is relayed to the initiating communication device represented by the matching information.
  • the essential advantage of the method according to the invention is that it is possible to dispense with the inflexible PPPoE access protocol for the establishment of communication relationships, ie for the allocation of IP addresses, and that the more flexible DHCP protocol can be used.
  • Advantageously occurring overloads of multiplexer devices (DSLAMs) are avoided in the context of the DHCP protocol in that broadcast information is purposefully and intelligently converted into unicast traffic. This makes it possible to make Internet protocols such as DHCP and ARP (Address Resolution Protocol) available in an adequate manner and without configuration effort for the network operators.
  • DSLAMs multiplexer devices
  • ARP Address Resolution Protocol
  • FIG. 1 shows in a block diagram a connection scenario arranged in a subscriber access network for carrying out the method according to the invention
  • FIG. 1 shows a block diagram of a plurality of subscribers or associated communication devices KE 1 .. n arranged in a subscriber access network ACCESS, which call via respective connection lines to corresponding connection units AE 1 .. n of a multiplexer MUX - also called DSLAM ( Digital Subscriber Line Access Multiplexer) - are connected.
  • the multipurpose device MUX is connected via a further connection device AA or uplink to a superordinate communication network OKN configured according to the Internet protocol.
  • a DHCP server Dynamic Host Configuration Protocol
  • a control device CONT controlling the implementation of the method according to the invention is arranged, to which memory means MEM are assigned.
  • the DISCOVER message is first transmitted to the multiplexer MUX, from which the message is to be forwarded by broadcast to the higher-level communication network OKN.
  • mac xl - the communication device KEl emitting the DHCP DISCOVER message together with an information representing the respective port of the communication device KEl
  • DHCP-OFFER received at the multiplexer MUX Messages are checked by the controller CONT.
  • the controller CONT the controller CONT.
  • the destination address or MAC address contained in the DHCP-OFFER message is used in the usual conciliation procedure with database Entries compared and optionally forwarded directly to the respective communication device KEl ... n.
  • the DHCP-OFFER message is forwarded by the multiplexer MUX as a unicast only to the subscribers stored in the memory MEM-here KE1-so that flooding or overloading of the multiplexer MUX with broadcast messages is prevented.
  • the communication device KEl can check whether an IP address should be requested from this DHCP server. If required, a DHCP REQUEST message is subsequently sent to this DHCP server - see FIG. 4.
  • This DHCP REQUEST message is detected by the control device CONT arranged in the multiplexer MUX and corresponding information in the context of the method according to the invention Broadcast flag in the DHCP data field - set in the message. This ensures that all responses from the DHCP server are also sent back in the form of a broadcast. In this way it is achieved that the answers of the DHCP server not directly to the respective requesting participants KEl ... n but in the broadcast again the way back via the multiplexer MUX are transmitted.
  • the DHCP ACK message is evaluated in the same manner as the previously received DHCP OFFER messages: detecting the subscriber sender address (chaddr) contained in the message and comparing it with the subscriber addresses MAC stored in the memory MEM and forwarding the DHCP ACK message to the corresponding one Port index (vcxlndex) when determining a match.
  • ARP Address Resolution Protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Zum Einrichten einer Kommunikationsbeziehung wird von einer Kommunikationseinrichtung (KEl...n) zumindest eine die Einrichtung der Kommunikationsbeziehung initiierende Meldung (DHCP-DISCOVER) in zumindest ein Kommunikationsnetz (ACCESS, OKN) ausgesendet und zumindest eine korrespondierende Rück-Meldung (DHCP-OFFER) mit Hilfe eines Rundsende-Übertragungsverfahrens in Richtung der initiierenden Kommunikationseinrichtung (KEl...n) übermittelt. Erfindungsgemäß werden die initiierende Kommunikationseinrichtung (KEl...n) repräsentierende Informationen (vcxlndex, MAC) in dem zumindest einen Kommunikationsnetz gespeichert. Die zumindest eine mit Hilfe des Rundsende-Übertragungsverf ahrens übermittelte Rück-Meldung wird detektiert und darin enthaltene Ziel-Informationen (chaddr) mitden gespeicherten Informationen (vcxlndex, MAC) verglichen. Bei Feststellung einer zumindest teilweisen Übereinstimmung der miteinander verglichenen Informationen wird die zumindest eine Rück-Meldung an die durch die übereinstimmenden Informationen repräsentierte, initiierende Kommunikationseinrichtung weitervermittelt.

Description

Verfahren zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz
In aktuellen Kommunikationsnetzen, insbesondere Teilnehmerzugangsnetzen - auch als Access-Networks bezeichnet - sind mehrere Teilnehmer bzw. den Teilnehmern zugeordnete Kommunikationseinrichtungen über Multiplexereinrichtungen - auch als DSLAM bzw. Digital Subscriber Line Access Multiplexer bezeichnet - an ein übergeordnetes Kommunikationsnetz - auch als Backbone bezeichnet - angeschlossen. Aufgabe der Multiplexereinrichtungen ist es, Informationen von allen Teilnehmern an das Backbone-Netzwerk weiter zu leiten und Informationen aus dem Backbone-Netzwerk direkt an die einzelnen Teilnehmer zur Verfügung zu stellen. Um eine unnötige Überlastung der Kapazität der jeweiligen Datenübertragungswege und damit eine Blockade der Kommunikationseinrichtung zu vermeiden, ist die Multiplexereinrichtung so ausgelegt, dass in Upstream-Richtung, d. h. von den einzelnen Kommunikationseinrichtungen in Richtung des übergeordneten Kommunikationsnetzes, alle zu übermittelnden Informationen weitergeleitet werden, in Downstream-Richtung, d. h. vom übergeordneten Netz in Richtung der einzelnen Kommunikationseinrichtungen, jedoch nur Informationen, die direkt an die einzelnen Teilnehmer adressiert sind, weitergeleitet werden. Dies bedeutet, dass im übergeordneten Kommunikationsnetz ausgesendete Broadcast- Informationen nicht von der jeweiligen Multiplexereinrichtung an die jeweils angeschlossenen Teilnehmer übermittelt werden.
Besteht beispielsweise ein solches Zugangsnetzwerk aus 4096 Teilnehmern, welche beispielsweise zum selben Zeitpunkt eine Ressourcen-Anforderung mit der Datenrate x bit/s an das übergeordnete Kommunikationsnetz aussenden, so entsteht in Upstream-Richtung eine Übertragungslast von 4096 * x bit/s. Wird seitens des übergeordneten Kommunikationsnetzes jedem Teilnehmer mit einer entsprechenden korrespondierenden Broad- cast-Meldung mit der gleichen Rate x bit/s eine Rückantwort übermittelt, so entsteht beispielsweise eine Übertragungslast in Downstream-Richtung von 4096 * 4096 * x bit/s. Dies führt in kürzester Zeit zu einer Überlastung des Multiplexers .
In aktuellen Teilnehmerzugangsnetzen ist das DHCP-Protokoll (RFC 2131) eine typische Anwendung, um Teilnehmern unter anderem eine gemäß dem Internetprotokoll ausgestaltete Adresse - im folgenden auch als IP-Adresse bezeichnet - zuzuweisen, mittels der die jeweiligen Teilnehmer berechtigt sind, im Internet Informationen im Rahmen einer Kommunikationsbeziehung auszutauschen. Im Rahmen des DHCP-Protokolls werden IP- Adressen in einem Pool-DHCP-Server vorgehalten und nur bei Bedarf einem eine Kommunikationsbeziehung einrichtenden Teilnehmer zugewiesen. Da es relativ unwahrscheinlich ist, dass alle Teilnehmer gleichzeitig aktiv sind (besonders im Rahmen eines Online-Dienstes) kann der Vorrat der im Pool gehaltenen IP-Adressen kleiner sein als die Gesamtzahl aller möglichen Nutzer. Da die dem jeweiligen Teilnehmer zugeordnete Kommunikationseinrichtung (auch als Host bezeichnet) beim Einschalten, d.h. zu Beginn des Aufbaus einer Kommunikationsbeziehung noch keine IP-Adresse zugewiesen hat, wird durch diese Kommunikationseinrichtung über einen DHCP-Discovery-Befehl eine entsprechende Anforderung bzw. Meldung per Rundsende- Verfahren bzw. Broadcast an aktive DHCP-Server ausgesendet. Zur Identifizierung der anfordernden Kommunikationseinrichtung wird die jeweilige MAC-Adresse in die ausgesendeten Anforderungs-Meldungen eingefügt. Als Antwort werden durch alle aktiven DHCP-Server, die noch frei zuordenbare IP-Adressen im Pool haben, eine entsprechende Antwort bzw. Rück-Meldung (DHCP-OFFER) mittels Broadcast in Richtung der anfordernden Kommunikationseinrichtung ausgesendet. Die anfordernde Kommunikationseinrichtung bzw. Host wählt ein Angebot aus (DHCPREQUEST) und macht dies wiederum allen DHCP-Servern per Broadcast bekannt. Der ausgewählte DHCP-Server bestätigt durch Übersendung der für die Kommunikationseinrichtung zuge- teilten IP-Adresse (DHCPACK) - daraufhin ziehen alle anderen DHCP-Server ihr Angebot zurück.
Neben der zugeordneten IP-Adresse können der anfordernden Kommunikationseinrichtung bzw. Host auch weitere für den Netzzugang relevante Daten übermittelt werden, z. B. die Sub- netz-Maske, die Adressen der Domain Name Server und das Standard-Gateway .
Im Rahmen des DHCP-Protokolls, das den Teilnehmern bzw. den diesen zugeordneten Kommunikationseinrichtungen eine IP- Adresse zuweisen soll, gibt es zwei Möglichkeiten wie Antworten bzw. Rück-Meldungen des DHCP-Servers, der die IP-Adressen vergibt, an die anfordernde Kommunikationseinrichtung (DHCP- Client) ausgesendet werden. Zum einen ist die Antwort direkt an den jeweiligen Teilnehmer bzw. Kommunikationseinrichtung adressiert oder zum anderen wird die Antwort als Broadcast zurückgeschickt. Im ersten Fall ist die Weiterleitung der direkt adressierten Rück-Meldungen unproblematisch. Eine direkt an einen Teilnehmer adressierte Antwort (Unicast) wird durch die Multiplexereinrichtung (DSLAM) direkt zum jeweils adressierten, angeschlossenen Teilnehmer weitergeleitet, so dass dieser Teilnehmer mit der zugewiesenen IP-Adresse für das Netzwerk zugangsberechtigt ist - d. h. eine Kommunikationsbeziehung über das Kommunikationsnetz eingerichtet werden kann.
Im zweiten Fall tritt das technische Problem auf, dass die Multiplexereinrichtungen, die im Rahmen eines Rundsende- Übertragungsverfahrens bzw. Broadcasts ausgesendeten Meldungen nicht an sämtliche an einer Multiplexereinrichtung angeschlossenen Kommunikationseinrichtungen weiterleiten kann, da sonst die Gefahr der Überlastung gegeben ist. In diesem Fall werden die an einer Multiplexereinrichtung eingehenden Broad- cast-Meldungen verworfen, d. h. dem jeweiligen Teilnehmer wird keine IP-Adresse zugeteilt. Dieser Fall, bei dem die im Rahmen eines Broadcast ausgesendeten Rück-Meldungen (DHCP- Antworten) vorliegen, tritt insbesondere dann auf, wenn in einem Kommunikationsnetz hinter der Multiplexereinrichtung d. h. dem unmittelbar daran nachfolgenden übergeordneten Kommunikationsnetz zusätzliche Netzelemente angeordnet sind, die keine Informationen bzw. Überblick über den Aufbau des Multi- plexernetzes bzw. Teilnehmerzugangsnetzes haben und daher grundsätzlich DHCP-Antworten als Broadcast weiterleiten, um sicherzustellen, dass alle im Teilnehmerzugangsnetz angeordneten Teilnehmer bzw. Kommunikationseinrichtungen diese Antworten bzw. Rückmeldungen empfangen.
Im aktuellen Kommunikationsnetz ist die oben geschilderte Problematik der Verwerfung von im Rahmen des Broadcasts übermittelter DHCP-Antworten bisher nicht aufgetreten, da zwischen Kommunikationseinrichtungen und übergeordneten Kommunikationsnetz einzurichtende Kommunikationsbeziehungen im Rahmen des Zugangsprotokolls PPPoE (PPP over Ethernet) eingerichtet wurden. Bei PPPoE werden DHCP-Antworten nur im Rahmen von Punkt-zu-Punkt-Verbindungen und nicht im Rahmen von Rund- sende-Übertragungsverfahren übermittelt .
Das Übermitteln der Broadcast-DHCP-Antworten kann alternativ auch durch die Realisierung von DHCP-Relays in den einzelnen Multiplexereinrichtungen entsprechend der RFC 3046 vermieden werden. Derartige DHCP-Relays kommunizieren direkt mit den einzelnen DHCP-Servern und besitzen eine Datenbasis mit den jeweils erforderlichen Teilnehmerinformationen. Die Konfigurierung von DHCP-Relays ist jedoch mit einem hohen technischen sowie wirtschaftlichen Aufwand verbunden, was von vielen Netzbetreibern nicht erwünscht ist.
Der Erfindung liegt somit die Aufgabe zugrunde, das Einrichten von Kommunikationsbeziehungen in Teilnehmerzugangsnetzen insbesondere die Zuteilung von IP-Adressen im Rahmen des DHCP-Protokolls insbesondere unter Vermeidung des bisher eingesetzten PPPoE-Protokolls weiter zu verbessern. Die Aufgabe wird ausgehend von den Merkmalen des Oberbegriffs des Patentanspruchs 1 durch dessen kennzeichnende Merkmale gelöst. Beim erfindungsgemäßen Verfahren zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz wird von einer Kommunikationseinrichtung zumindest eine die Einrichtung der Kommunikationsbeziehung initiierende Meldung in das Kommunikationsnetz ausgesendet und zumindest eine korrespondierende Rück-Meldung mit Hilfe eines Rundsende- Übertragungsverfahrens über das Kommunikationsnetz in Richtung der initiierenden Kommunikationseinrichtung übermittelt. Der wesentliche Aspekt des erfindungsgemäßen Verfahren besteht darin, dass die die Kommunikationsbeziehung initiierende Kommunikationseinrichtung repräsentierende Informationen im Kommunikationsnetz gespeichert werden und dass die mit Hilfe des Rundsende-Übertragungsverfahrens übermittelte Rückmeldung detektiert und in der detektierten Rück-Meldung enthaltene Ziel-Informationen mit den gespeicherten Informationen verglichen werden. Bei Feststellen einer zumindest teilweisen Übereinstimmung der miteinander verglichenen Informationen wird die Rückmeldung an die durch die übereinstimmenden Informationen repräsentierte, initiierende Kommunikationseinrichtung weitervermittelt.
Der wesentliche Vorteil des erfindungsgemäßen Verfahrens besteht darin, dass für das Einrichten von Kommunikationsbeziehungen, d. h. für die Zuteilung von IP-Adressen auf das unflexible PPPoE-Zugangsprotokoll verzichtet werden kann und das flexiblere DHCP-Protokoll eingesetzt werden kann. Vorteilhaft werden im Rahmen des DHCP-Protokolls eventuell auftretende Überlastungen von Multiplexereinrichtungen (DSLAMs) dadurch vermieden, daß Broadcast-Informationen gezielt und intelligent in Unicast-Datenverkehr umgewandelt werden. Damit ist es möglich, Internetprotokolle wie beispielsweise DHCP und ARP (Address Resolution Protocol) in adäquater Weise und ohne Konfigurationsaufwand für die Netzbetreiber nutzbar zu machen . Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens sowie eine Kommunikationsanordnung und eine Kommunikationsvorrichtung für eine Kommunikationsanordnung zum Einrichten einer Kommunikationsbeziehung sind den weiteren Ansprüchen zu entnehmen.
Im Folgenden wird das erfindungsgemäße Verfahren anhand mehrerer Zeichnungen näher erläutert. Dabei zeigen
FIG 1 in einem Blockschaltbild ein in einem Teilnehmeranschlussnetz angeordnetes Anschlussszenario zur Durchführung des erfindungsgemäßen Verfahrens,
FIG 2 bis 5 den chronologischen Verlauf von im Rahmen des erfindungsgemäßen Verfahrens übermittelten DHCP- Meldungen
FIG 1 zeigt in einem Blockschaltbild mehrere in einem Teilnehmerzugangsnetz bzw. Access-Network ACCESS angeordnete Teilnehmer bzw. diesen zugeordnete Kommunikationseinrichtungen KEl.. n, welche über jeweilige Verbindungsleitungen an entsprechende Anschlusseinheiten AEl.. n einer Multiplexerein- richtung MUX - auch als DSLAM bezeichnet (Digital Subscriber Line Access Multiplexer) - angeschlossen sind. Die MuI- tiplexereinrichtung MUX ist über eine weitere Anschlusseinrichtung AA bzw. Uplink mit einem übergeordneten gemäß dem Internet-Protokoll ausgestalten Kommunikationsnetz OKN verbunden. In dem übergeordneten Kommunikationsnetz OKN ist ein DHCP-Server (Dynamic Host Configuration Protocol) angeordnet, In der Multiplexereinrichtung MUX ist eine die Durchführung des erfindungsgemäßen Verfahrens steuernde Steuervorrichtung CONT angeordnet, welcher Speichermittel MEM zugeordnet sind.
Für die folgenden Ausführungen sei angenommen, dass zwischen der ersten Kommunikationseinrichtung KEl und dem übergeordneten Kommunikationsnetz OKN eine Kommunikationsbeziehung bzw. eine gemäß dem Internetprotokoll ausgestaltete Netzwerkbeziehung eingerichtet werden soll, wobei der ersten Kommunikationseinrichtung für die Einrichtung der Netzwerkverbindung eine entsprechende IP-Adresse durch den DHCP-Server zugewiesen werden soll.
Gemäß FIG 2 wird durch die erste Kommunikationseinrichtung - auch als Client bezeichnet - im Rahmen des DHCP-Protokolls
(RFC 2131) eine „DHCP-DISCOVER-Meldung" mittels Rundsende- Übertragungsverfahren bzw. Broadcast in das übergeordnete Kommunikationsnetz OKN übermittelt, wodurch ein zur Antwort bereiter DHCP-Server ausfindig gemacht werden soll. Gemäß FIG 2 wird die von der ersten Kommunikationseinrichtung KEl ausgesendete DHCP-DISCOVER-Meldung zunächst an die Multiplexer- einrichtung MUX übermittelt, von welcher die Meldung mittels Broadcast an das übergeordnete Kommunikationsnetz OKN weitergeleitet werden soll. Erfindungsgemäß ist die in der MuI- tiplexereinrichtung MUX angeordnete Steuervorrichtung CONT derart ausgestaltet, dass die MAC-Adresse - hier mac=xl - der die DHCP-DISCOVER-Meldung aussendenden Kommunikationseinrichtung KEl zusammen mit einer den jeweiligen Anschluss der Kommunikationseinrichtung KEl repräsentierenden Information
(auch als Anschlussindex „vcxlndex" bezeichnet) - hier vcxln- dex=vil - in einem Datenfeld tabl...n des der Steuereinrichtung CONT zugeordneten Speichers MEM gespeichert wird.
Als Rückantwort wird von dem im übergeordneten Kommunikationsnetz OKN angeordneten DHCP-Server eine entsprechende Rückmeldung - hier DHCP-OFFER - mittels Broadcast über das übergeordnete Kommunikationsnetz OKN in Richtung der anfordernden Kommunikationseinrichtung KEl übermittelt - siehe FIG 3. An der Multiplexereinrichtung MUX empfangenen DHCP-OFFER- Meldungen werden durch die Steuereinrichtung CONT überprüft. Für den Fall, dass die DHCP-OFFER-Meldung vom DHCP-Server in Form eines Unicast ausgesendet wurde, wird die in der DHCP- OFFER-Meldung enthaltene Ziel-Adresse bzw. MAC-Adresse im Rahmen des üblichen Vermittlungsverfahrens mit Datenbank- Einträgen verglichen und gegebenenfalls direkt an die jeweilige Kommunikationseinrichtung KEl...n weitergeleitet.
Wurde die DHCP-OFFER-Meldung vom DHCP-Server im Rahmen eines an alle Teilnehmer KEl.. n gerichteten Broadcast ausgesendet, so wird erfindungsgemäß durch die Steuereinrichtung CONT, die in der DHCP-OFFER-Meldung enthaltene Teilnehmerabsenderadresse (hier die im Rahmen des DHCP-Protokolls übermittelte Ziel- Adresse, chaddr) mit dem im Speicher MEM gespeicherten Teilnehmeradressen MAC verglichen, wobei bei Feststellen einer Übereinstimmung die DHCP-OFFER-Meldung an den ebenfalls im Speicher MEM gespeicherten, zugehörigen Anschlussindex (hier vcxlndex=vil) weitergeleitet. Erfindungsgemäß wird die DHCP- OFFER-Meldung durch die Multiplexereinrichtung MUX als Uni- cast nur an den im Speicher MEM gespeicherten Teilnehmer - hier KEl - weitergeleitet, so dass eine Überflutung bzw. Ü- berlastung der Multiplexereinrichtung MUX mit Broadcast- Meldungen verhindert wird.
Nach Empfang der DHCP-OFFER-Meldung kann durch die Kommunikationseinrichtung KEl überprüft werden, ob von diesem DHCP- Server eine IP-Adresse angefordert werden soll. Bei Bedarf wird anschließend eine DHCP-REQUEST-Meldung an diesen DHCP- Server abgesendet - siehe FIG 4. Diese DHCP-REQUEST-Meldung wird durch die in der Multiplexereinrichtung MUX angeordnete Steuereinrichtung CONT detektiert und im Rahmen des erfindungsgemäßen Verfahrens eine entsprechende Information - hier das Broadcast-Flag in dem DHCP-Datenfeld - in der Meldung gesetzt. Dadurch wird erreicht, dass alle Antworten des DHCP- Servers ebenfalls in Form eines Broadcasts zurückgesendet werden. Auf diese Weise wird erreicht, dass die Antworten des DHCP-Servers nicht direkt zu den jeweiligen anfordernden Teilnehmern KEl...n sondern im Rahmen des Broadcast wieder den Weg zurück über die Multiplexereinrichtung MUX übermittelt werden. Damit ist gewährleistet, dass die vom DHCP-Server ausgesendeten DHCP-ACK-Meldungen durch die Steuereinrichtung CONT erfasst, ausgewertet und die in den DHCP-ACK-Meldungen enthaltenen bzw. zugewiesenen IP-Adressen IP im Speicher MEM gespeichert werden bevor die DHCP-ACK-Meldung mit der zugewiesenen IP-Adresse - hier IP=yl - an die entsprechende Kommunikationseinrichtung KEl weitergeleitet wird - siehe FIG 5. Die DHCP-ACK-Meldung wird in der gleichen Art und Weise wie die zuvor empfangenen DHCP-OFFER-Meldungen ausgewertet: Erfassen der in der Meldung enthaltenen Teilnehmerabsendeadresse (chaddr) und Vergleich mit den im Speicher MEM gespeicherten Teilnehmeradressen MAC und Weiterleitung der DHCP-ACK- Meldung an den entsprechend zugehörigen Anschlussindex (vcxlndex) bei Feststellen einer Übereinstimmung.
Nach Abschluss des DHCP-Protokolls, d. h. nach Zuordnung einer IP-Adresse IP zu der jeweiligen Kommunikationseinrichtung KEl ist diese prinzipiell von allen in dem zumindest einen Kommunikationsnetz OKN angeordneten Kommunikationseinrichtungen identifizier- bzw. adressierbar, d.h. es können Kommunikationsbeziehung von und zu der Kommunikationseinrichtung KEl...n eingerichtet werden. Sollen von einer im übergeordneten Kommunikationsnetz OKN angeordneten Kommunikationseinrichtung - nicht dargestellt - Informationen beispielsweise zur ersten Kommunikationseinrichtung KEl übermittelt werden, so ist für die Informationsübermittlung nicht nur die IP-Adresse - hier IP=yl - der zu adressierenden Kommunikationseinrichtung - hier KEl - sondern auch dessen Hardware - bzw. MAC-Adresse - hier MAC=xl - erforderlich. Diese kann abgefragt werden, indem eine ARP-Anfrage (Address Resolution Protocol) mit der spezifizierten IP-Adresse als Broadcast an alle erreichbaren Teilnehmer ausgesendet wird - siehe FIG 6. Üblicherweise wird diese Anfrage von der durch die IP-Adresse adressierten Kommunikationseinrichtung beantwortet und die MAC-Adresse in die Antwort eingefügt. Wie bereits erläutert, werden im Rahmen eines Broadcasts ausgesendete Anfragen bzw. Meldungen durch die Multiplexereinrichtungen MUX zur Vermeidung von Überlastung verworfen, d. h. ARP-Anfragen werden durch die Multiplexereinrichtungen MUX nicht weitergeleitet und damit entsprechend nicht beantwortet. Gemäß einer vorteilhaften Wei- terbildung des erfindungsgemäßen Verfahrens werden an einer Multiplexereinrichtung MUX eintreffende ARP-Anfragen bzw- ARP-REQUEST durch die Steuereinrichtung CONT erfasst und die in den ARP-Anfragen enthaltenen bzw. spezifizierten IP- Adressen mit dem vorher im Rahmen des erfindungsgemäßen Verfahrens aus dem DHCP-ACK-Meldungen ausgelesenen und im Speicher MEM gespeicherten IP-Adressen IP der einzelnen Teilnehmer bzw. Kommunikationseinrichtungen KEl...n verglichen. Bei Feststellen einer Übereinstimmung der in einer ARP-REQUEST- Meldung spezifizierten IP-Adresse mit einer im Speicher MEM gespeicherten IP-Adresse wird die ARP-Anfrage an den entsprechenden Anschlussindex (vcxlndex) der jeweiligen Kommunikationseinrichtung - hier KEl mit vclndex=vil - weitergeleitet. Durch die an diesen Anschluss angeschlossene Kommunikationseinrichtung KEl kann anschließend die ARP-REQUEST-Meldung des Netzwerk-Rechner beantwortet werden, d. h. eine entsprechende ARP-RESPONSE-Meldung mit darin eingefügter MAC-Adresse der ersten Kommunikationseinrichtung KEl ausgesendet werden.

Claims

Patentansprüche
1. Verfahren zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz (ACCESS, OKN) , bei dem von einer Kommunikationseinrichtung (KEl...n) zumindest eine die Einrichtung der Kommunikationsbeziehung initiierende Meldung (DHCP-DISCOVER, DHCP-REQUEST) in das zumindest eine Kommunikationsnetz (ACCESS, OKN) ausgesendet und zumindest eine korrespondierende Rück-Meldung (DHCP-OFFER, DHCP-ACK) mit Hilfe eines Rundsende-Übertragungsverfahrens über das zumindest eine Kommunikationsnetz (ACCESS, OKN) in Richtung der initiierenden Kommunikationseinrichtung (KEl...n) übermittelt wird, dadurch gekennzeichnet, dass die die Kommunikationsbeziehung initiierende Kommunikationseinrichtung (KEl...n) repräsentierende Informationen
(vcxlndex, MAC) in den zumindest einen Kommunikationsnetz
(ACCESS, OKN) gespeichert werden, dass die zumindest eine mit Hilfe des Rundsende- Übertragungsverfahrens übermittelte Rück-Meldung (DHCP-OFFER, DHCP-ACK) detektiert und in der detektierten Rück-Meldung
(DHCP-OFFER, DHCP-ACK) enthaltene Ziel-Informationen (chaddr) mit den gespeicherten Informationen (vcxlndex, MAC) verglichen werden, dass bei Feststellung einer zumindest teilweisen Übereinstimmung der miteinander verglichenen Informationen (chaddr, vcxlndex, MAC) die zumindest eine Rück-Meldung (DHCPOFFER, DHCP-ACK) an die durch die übereinstimmenden Informationen repräsentierte, initiierende Kommunikationseinrichtung
(KEl...n) weitervermittelt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das zumindest ein Kommunikationsnetz (ACCESS, OKN) als paket- oder zellenorientiertes Kommunikationsnetz ausgestaltet ist.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Kommunikationsnetz (ACCESS, OKN) gemäß dem Internet- Protokoll ausgestaltet ist, wobei durch die von der Kommunikationseinrichtung (KEl...n) ausgesendete Meldung (DHCP- REQUEST) eine IP-Adresse angefordert wird und in der korrespondierenden Rückmeldung (DHCP-ACK) zumindest eine angeforderte IP-Adresse (IP) eingefügt ist.
4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die Einrichtung der Kommunikationsbeziehung im Rahmen des DHCP-Protokolls erfolgt.
5. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die MAC-Adresse (MAC) und/oder eine den Anschluß (vcxln- dex) der initiierenden Kommunikationseinrichtung (KEl...n) repräsentierende Information gespeichert wird.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass die im Rahmen des DHCP-Protokolls der initiierenden Kommunikationseinrichtung (KEl...n) zugeteilte IP-Adresse (IP) im Kommunikationsnetz (ACCESS, OKN) gespeichert wird.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass im Rahmen des Address-Resolution-Protokolls mittels Rundsende-Verfahrens ausgesendete ARP-Meldungen (ARP-REQUEST) detektiert und in den ARP-Meldungen (ARP-REQUEST) enthaltene IP-Adressen mit den den zumindest einen Kommunikationsnetz (ACCESS, OKN) gespeicherten IP-Adressen (IP) verglichen werden, dass bei zumindest teilweiser Übereinstimmung der miteinander verglichenen Informationen die ARP-Meldung (ARP-REQUEST) an die durch die übereinstimmende IP-Adresse repräsentierte Kommunikationseinrichtung (KEl...n) weitervermittelt wird.
8. Kommunikationsanordnung zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz (ACCESS, OKN) , mit zumindest einer zumindest einem Kommunikationsnetz zugeordneten Kommunikationseinrichtung (KEl...n) , mit in der zumindest einen Kommunikationseinrichtung (KEl...n) vorgesehenen Mitteln zum Aussenden zumindest einer die Einrichtung der Kommunikationsbeziehung initiierenden Meldung
(DHCP-DISCOVER) an das zumindest eine Kommunikationsnetz
(ACCESS, OKN), und mit in dem zumindest einem Kommunikationsnetz (ACCESS, OKN) angeordneten Mitteln (DHCP) zur Übermittlung zumindest einer korrespondierenden Rückmeldung (DHCP-OFFER) mit Hilfe eines Rundsende-Übertragungsverfahrens über das zumindest eine Kommunikationsnetz (ACCESS, OKN) in Richtung der initiierenden Kommunikationseinrichtung (KEl...n) , dadurch gekennzeichnet, dass in dem zumindest einem Kommunikationsnetz (ACCESS, OKN)
- Speichermittel (MEM) vorgesehen sind, in welcher die die Kommunikationsbeziehung initiierende Kommunikationseinrichtung (KEl...n) repräsentierende Informationen (vcxlndex, MAC) gespeichert werden,
- Vergleichs-Mittel (CONT) vorgesehen sind, durch welche die zumindest eine mit Hilfe des Rundsende-
Übertragungsverfahrens übermittelte Rück-Meldung (DHCP- OFFER) detektiert und in der detektierten Rück-Meldung
(DHCP-OFFER) enthaltene Ziel-Informationen mit (chaddr) den gespeicherten Informationen (vcxlndex, MAC) verglichen werden, dass die Vergleichsmittel (CONT) derart ausgestaltet sind, dass bei zumindest teilweiser Übereinstimmung der miteinander verglichen Informationen (chaddr, vcxlndex, MAC) die zumindest eine Rück-Meldung (DHCP-OFFER) an die durch die überein- stimmenden Informationen repräsentierte, initiierende Kommunikationseinrichtung (KEl...n) weitervermittelt wird.
9. Kommunikationsanordnung nach Anspruch 8, dadurch gekennzeichnet, dass das zumindest ein Kommunikationsnetz (ACCESS, OKN) als paket- oder zellenorientiertes Kommunikationsnetz ausgestaltet ist.
10. Kommunikationsanordnung nach Anspruch 9, dadurch gekennzeichnet, dass das zumindest eine Kommunikationsnetz (ACCESS, OKN) gemäß dem Internet-Protokoll ausgestaltet ist, wobei durch die von der Kommunikationseinrichtung (KEl...n) ausgesendete Meldung (DHCP-REQUEST) eine IP-Adresse angefordert wird und in der korrespondierenden Rückmeldung (DHCP-ACK) zumindest eine angeforderte IP-Adresse (IP) eingefügt ist.
11. Kommunikationsanordnung nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass das zumindest eine Kommunikationsnetz (ACCESS, OKN) und die Speicher- und Vergleichsmittel derart ausgestaltet sind, dass die Einrichtung der Kommunikationsbeziehung im Rahmen des DHCP-Protokolls erfolgt.
12. Kommunikationsanordnung nach Anspruch 11, dadurch gekennzeichnet, dass die Speichermittel (MEM) derart ausgestaltet sind, die im Rahmen des DHCP-Protokolls der initiierenden Kommunikationseinrichtung (KEl...n) zugeteilte IP-Adresse (IP) gespeichert wird.
13. Kommunikationsanordnung nach 12, dadurch gekennzeichnet, dass die Speicher- und Vergleichsmittel (MEM, CONT) derart ausgestaltet sind, dass im Rahmen des Address-Resolution- Protokolls mittels Rundsende-Verfahrens ausgesendete ARP- Meldungen (ARP-REQUEST) detektiert und in den ARP-Meldungen (ARP-REQUEST) enthaltene IP-Adressen mit den den zumindest einen Kommunikationsnetz (ACCESS, OKN) gespeicherten IP- Adressen (IP) verglichen werden, dass bei zumindest teilweiser Übereinstimmung der miteinander verglichen Informationen die ARP-Meldung (ARP-REQUEST) an die durch die übereinstimmende IP-Adresse repräsentierte Kommunikationseinrichtung (KEl...n) weitervermittelt wird.
14. Kommunikationsvorrichtung (MUX) für eine Kommunikationsanordnung zum Einrichten einer Kommunikationsbeziehung in zumindest einem mit der Kommunikationsvorrichtung (MUX) verbindbaren Kommunikationsnetz (ACCESS, OKN) , mit zumindest einer mit der Kommunikationsvorrichtung (MUX) verbindbaren und dem zumindest einem Kommunikationsnetz
(ACCESS, OKN) zuordenbaren Kommunikationseinrichtung (KEl...n) , mit in der zumindest einen Kommunikationseinrichtung (KEl...n) vorgesehenen Mitteln zum Aussenden zumindest einer die Einrichtung der Kommunikationsbeziehung initiierenden Meldung
(DHCP-DISCOVER) in das zumindest eine Kommunikationsnetz
(ACCESS, OKN), und mit in dem zumindest einem Kommunikationsnetz (ACCESS, OKN) angeordneten Mitteln (DHCP) zur Übermittlung zumindest einer korrespondierenden Rückmeldung (DHCP-OFFER) mit Hilfe eines Rundsende-Übertragungsverfahrens über das zumindest eine Kommunikationsnetz (ACCESS, OKN) in Richtung der initiierenden Kommunikationseinrichtung (KEl...n) , dadurch gekennzeichnet, dass in der Kommunikationsvorrichtung (MUX)
- Speichermittel (MEM) vorgesehen sind, in welcher die die Kommunikationsbeziehung initiierende Kommunikationseinrichtung (KEl...n) repräsentierende Informationen (vcxlndex, MAC) gespeichert werden, und
- den Speichermitteln (MEM) zugeordnete Vergleichs-Mittel (CONT) vorgesehen sind, durch welche die zumindest eine mit
Hilfe des Rundsende-Übertragungsverfahrens übermittelte Rück-Meldung (DHCP-OFFER) detektiert und in der detektier- ten Rück-Meldung (DHCP_OFFER) enthaltene Ziel-Informationen (chaddr) mit den gespeicherten Informationen (vcxlndex,
MAC) verglichen werden, dass die Vergleichsmittel (CONT) derart ausgestaltet sind, dass bei zumindest teilweiser Übereinstimmung der miteinander verglichenen Informationen (chaddr, vcxlndex, MAC) die zumindest eine Rück-Meldung (DHCP-OFFER) an die an die Kommunikationsvorrichtung (MUX) angeschlossene, durch die übereinstimmenden Informationen repräsentierte, initiierende Kommunikationseinrichtung (KEl...n) weitervermittelt wird.
EP06707796A 2005-02-15 2006-01-23 Verfahren zum einrichten einer kommunikationsbeziehung in zumindest einem kommunikationsnetz Withdrawn EP1854267A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005006889A DE102005006889B4 (de) 2005-02-15 2005-02-15 Verfahren, Kommunikationsanordnung und Kommunikationsvorrichtung zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz
PCT/EP2006/050372 WO2006087254A1 (de) 2005-02-15 2006-01-23 Verfahren zum einrichten einer kommunikationsbeziehung in zumindest einem kommunikationsnetz

Publications (1)

Publication Number Publication Date
EP1854267A1 true EP1854267A1 (de) 2007-11-14

Family

ID=36263969

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06707796A Withdrawn EP1854267A1 (de) 2005-02-15 2006-01-23 Verfahren zum einrichten einer kommunikationsbeziehung in zumindest einem kommunikationsnetz

Country Status (5)

Country Link
US (1) US20080298273A1 (de)
EP (1) EP1854267A1 (de)
CN (1) CN101120580A (de)
DE (1) DE102005006889B4 (de)
WO (1) WO2006087254A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8918624B2 (en) * 2008-05-15 2014-12-23 International Business Machines Corporation Scaling and managing work requests on a massively parallel machine
US8812469B2 (en) * 2008-05-15 2014-08-19 International Business Machines Corporation Configurable persistent storage on a computer system using a database
DE102008026708B4 (de) * 2008-06-04 2014-01-23 Iprm Intellectual Property Rights Management Ag Vorrichtung zur Bestimmung des Blutvolumens und/oder Blutvolumenstroms und Verfahren zum Betreiben derselben
US10142160B1 (en) 2011-10-04 2018-11-27 Big Switch Networks, Inc. System and methods for managing network hardware address requests with a controller
US8856384B2 (en) * 2011-10-14 2014-10-07 Big Switch Networks, Inc. System and methods for managing network protocol address assignment with a controller
CN102801716B (zh) * 2012-08-01 2015-04-08 杭州迪普科技有限公司 一种dhcp防攻击方法及装置
CN103944867B (zh) * 2013-01-23 2017-09-12 华为技术有限公司 动态主机配置协议报文的处理方法、装置和系统
CN106603743A (zh) * 2016-12-16 2017-04-26 合网络技术（北京）有限公司 一种基于dhcp协议定制的广播请求响应方法、系统及终端

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1123154C (zh) * 1996-12-09 2003-10-01 摩托罗拉公司 路由选择动态主机配置协议分组的装置和方法
WO2000079733A2 (en) * 1999-06-23 2000-12-28 At & T Wireless Services, Inc. Methods and apparatus for reducing traffic over a communication link in a computer network
US6603758B1 (en) * 1999-10-01 2003-08-05 Webtv Networks, Inc. System for supporting multiple internet service providers on a single network
US7007080B2 (en) * 1999-12-23 2006-02-28 Solution Inc Limited System for reconfiguring and registering a new IP address for a computer to access a different network without user intervention
US20020013858A1 (en) * 2000-02-09 2002-01-31 Anderson Keith R. ARP caching apparatus and method
US7356841B2 (en) * 2000-05-12 2008-04-08 Solutioninc Limited Server and method for providing specific network services
US7058059B1 (en) * 2001-02-20 2006-06-06 At&T Corp. Layer-2 IP networking method and apparatus for mobile hosts
GB0106919D0 (en) * 2001-03-20 2001-05-09 Marconi Comm Ltd Access networks
GB0107638D0 (en) * 2001-03-27 2001-05-16 Marconi Comm Ltd Access networks
US7016353B2 (en) * 2001-06-13 2006-03-21 Telcordia Technologies, Inc. Method and system for dynamically assigning IP addresses in wireless networks
JP4339536B2 (ja) * 2001-11-02 2009-10-07 ソニー株式会社 アドレス自動割り当て装置及びその制御方法並びにプログラム
US7093030B1 (en) * 2002-05-02 2006-08-15 At & T Corp. Internetworking driver with active control
US20040073800A1 (en) * 2002-05-22 2004-04-15 Paragi Shah Adaptive intrusion detection system
ATE387049T1 (de) * 2002-07-08 2008-03-15 Packetfront Sweden Ab Dynamische portkonfiguration eines netzwerkgerätes
US7337224B1 (en) * 2002-10-24 2008-02-26 Cisco Technology, Inc. Method and apparatus providing policy-based determination of network addresses
US7490351B1 (en) * 2003-03-12 2009-02-10 Occam Networks Controlling ARP traffic to enhance network security and scalability in TCP/IP networks
US7293282B2 (en) * 2003-07-03 2007-11-06 Time Warner Cable, Inc. Method to block unauthorized access to TFTP server configuration files
EP1499066B1 (de) * 2003-07-14 2010-02-24 Alcatel Lucent Verfahren zum Aufbau einer Verbindung
US7318148B2 (en) * 2003-07-31 2008-01-08 Sap Ag Automatically configuring a computer
CN100547980C (zh) * 2003-09-18 2009-10-07 联想（新加坡）私人有限公司 一种信息处理装置以及控制方法
US7577146B2 (en) * 2003-10-31 2009-08-18 Redback Networks Inc. Network element modifying the DHCP lease timer
US7342925B2 (en) * 2004-11-30 2008-03-11 At&T Corp. Technique for automated MAC address cloning

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006087254A1 *

Also Published As

Publication number Publication date
DE102005006889B4 (de) 2007-01-11
US20080298273A1 (en) 2008-12-04
DE102005006889A1 (de) 2006-08-24
WO2006087254A1 (de) 2006-08-24
CN101120580A (zh) 2008-02-06

Similar Documents

Publication Publication Date Title
DE102005006889B4 (de) Verfahren, Kommunikationsanordnung und Kommunikationsvorrichtung zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
EP1360820B1 (de) Verfahren und anordnung zum ermitteln der virtuellen adresse eines endgerätes
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
EP1820324B1 (de) VERFAHREN ZUR KONFIGURIERUNG EINES GERAETES MIT DHCP UEBER PPPoE
EP1317820B1 (de) Verfahren zum aufbau von verbindungen mit vorgegebener dienstgüte für ein paketorientiertes kommunikationsnetz mit einem resourcenmanager
EP1897340A1 (de) Vorrichtung und verfahren zum adress-mapping
WO2002051187A1 (de) Verfahren zum verteilen einer gruppennachricht in einem funkkommunikationssystem sowie zugehöriges funkkommunikationssystem
EP1525714B1 (de) Konfiguration eines auf einem breitband kabelverteilnetz beruhenden telefoniezugangsnetzes und einer zugehörigen paketbasierten vermittliungsstelle
EP1902571B1 (de) Verfahren, kommunikationsanordnung und kommunikationsvorrichtung zum einrichten einer kommunikationsbeziehung
EP1916822A1 (de) Verfahren und System für einen Kommunikationsknoten mit mehreren Netzwerkschnittstellen
DE69938391T2 (de) Telefonvermittlungsstelle mit integrierten internetzugriffservern
EP1099326A2 (de) Verfahren zur verbindung von endgeräten mit externen modems
EP2311240B1 (de) Verfahren zur endpunkt-adressierung sowie dafür eingerichtetes netzwerk und zugangsknoten
EP2649751B1 (de) Verfahren und system zur überwachung eines kommunikationssystems
DE10046311B4 (de) Verfahren für eine Zuweisung von Knotennummern zu Netzknoten eines Netzwerks
DE10151743A1 (de) Verfahren zur Durchführung von augenblicklichem Nachrichtenverkehr (Instant Messaging) mit paketvermittelten Daten
WO2006034948A1 (de) Nutzung von presence-informationen (statusinformationen) zur erweiterung einer bestehenden kommunikationsverbindung
EP1098496A2 (de) Umgekehrte Maskierung fuer die Zugreifbarkeit auf Datenendstationen in privaten IPv4-Netzen
DE102008055967B4 (de) Verfahren zur Endpunkt-Adressierung sowie dafür eingerichtetes Netzwerk und Zugangsknoten
EP1559241A1 (de) Verfahren und vorrichtung zum austausch von daten mittels einer tunnelverbindung
EP2887604B1 (de) Verfahren und Telekommunikationsnetz zur Erhöhung der Sicherheit beim paketorientierten Datenaustausch
DE102021114033A1 (de) Aufbau einer Kommunikationsverbindung in einem Weitverkehrsnetz
DE19827791B4 (de) Verfahren zum Betrieb eines Telekommunikationsnetzes
DE10148627B4 (de) Verfahren und Anordnung zum Ermitteln der virtuellen Adresse eines Endgerätes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070917

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SIPPEL, CHRISTELLE

Inventor name: NEUHAEUSLER, CHLODWIG

Inventor name: ARMBRUSTER, FRIEDRICH

Inventor name: BINDE, STEPHAN

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080929

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090210