EP1769619A2 - Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung - Google Patents

Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung

Info

Publication number
EP1769619A2
EP1769619A2 EP05763995A EP05763995A EP1769619A2 EP 1769619 A2 EP1769619 A2 EP 1769619A2 EP 05763995 A EP05763995 A EP 05763995A EP 05763995 A EP05763995 A EP 05763995A EP 1769619 A2 EP1769619 A2 EP 1769619A2
Authority
EP
European Patent Office
Prior art keywords
homed
connection
paths
conversion
components
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
EP05763995A
Other languages
English (en)
French (fr)
Inventor
Wolfgang Schrüfer
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
Siemens AG
Nokia Siemens Networks GmbH and Co KG
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 Siemens AG, Nokia Siemens Networks GmbH and Co KG filed Critical Siemens AG
Priority to EP05763995A priority Critical patent/EP1769619A2/de
Publication of EP1769619A2 publication Critical patent/EP1769619A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • 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
    • 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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2521—Translation architectures other than single NAT servers
    • H04L61/2532—Clique of NAT servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/677—Multiple interfaces, e.g. multihomed nodes

Definitions

  • the present invention relates to a method for the construction of multi-homed connections, whereby a conversion of communication addresses takes place in the connection path.
  • the invention relates to a method for establishing an SCTP connection with multiple paths in IP networks with Network Address Translation (NAT).
  • NAT Network Address Translation
  • IP Internet Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • Efforts have therefore been and are being made to create communication protocols which, based on the base protocols, enable applications which are implemented on endpoints and other network components to define a plurality of their own communication addresses for a connection .
  • Multiple communication addresses can For example, be provided by way of multiple network cards. If a network component for a connection can use a plurality of its own (and possibly remote) communication addresses, one often speaks of multihoming or of multi-homed connections.
  • IP communication networks An example of such a communication protocol with extended capabilities for use in IP communication networks is the Session Control Transmission Protocol SCTP, defined in IETF RFC 2960.
  • FIG. 1 shows an exemplary IP communications network 100 having a first endpoint or host A 102 and a second endpoint or host B 112, each having two (global) IP addresses 104A, 104B and 114A, 114B.
  • a (SCTP) connection between the endpoints is formed by two paths 108A, 108B, which are preferably different, i. via various routers 106A, 106B through the communication network, which may also include a wide area network WAN 110.
  • the protocol SCTP or a similar communication protocol manages and uses these two paths, for example in such a way that the failure of one path, for example if one of the routers 106 fails, does not interrupt the end-to-end communication since the other path is immediately available can be used.
  • the number of paths is not limited to two.
  • a major disadvantage of the multi-homed connections is that they can not be established regularly if a conversion of the communication addresses takes place in the connection path, as known for IP communication networks as Net ⁇ Address Translation (NAT), defined in IETF RFC 1631
  • NAT Net ⁇ Address Translation
  • the implementation of a communication address in IP communication networks can take place, for example, by changing an IP address or a port number or by changing both address components.
  • a recipient address and / or a sender address of the implementation subject It is therefore an object of the invention to specify a method for setting up a multi-homed connection, if an implementation of the communication addresses takes place in the connection path.
  • This object is achieved by a method for setting up a multi-homed connection with a number n of paths between two components of a communication network.
  • the components each have at least n communication addresses, and in the connection path, the communication addresses of at least one of the first components are converted.
  • the method comprises the following steps:
  • Construction of the multi-homed connection by setting up the n paths on the basis of the determined implementation relationships.
  • the conversion relationship is often characterized by the fact that a local communication address of a first component is converted into a global communication address. Only knowing this global address allows other components to address this first component. However, it is not necessary for the other components to have the complete conversion relationship, i. in addition to the global also the local communication address, know. For successful connection establishment, it suffices if the address translating component, e.g. a router that knows the full implementation relationship.
  • n conversion relationships can be determined in full or in part, for example, using one of the following methods: exchanging messages or test messages for k
  • the present invention further relates to components of a communication network having software or hardware means for carrying out the method according to the invention.
  • a communication protocol which can be expanded particularly advantageously when used in conjunction with the present invention, is the Stream Control Transmission Protocol SCTP.
  • a particular advantage of the invention is that it is possible to use multi-homed connections also via address translators, e.g. NAT routers that support only the standard address translation procedures. In the case of IP networks, this means that no changes have to be made to the NAT routers, so that the invention can be used immediately without changing the network infrastructure. Only the endpoints of SCTP associations must support the process.
  • the invention can also be advantageously used for dynamic reconfiguration of communication addresses, for example IP addresses, without an existing connection being interrupted. This can be advantageous, for example, when exchanging physical network cards, with dynamic address changes or with cordless applications.
  • FIG. 1 shows a schematic representation of an IP network with a connection with two paths via routers without address conversion.
  • FIG. 2 shows a schematic representation of an IP network with a connection with two paths via routers with address conversion.
  • 3A-C show a schematic representation of the sequence of preparation of the connection of FIG. 2.
  • FIG. 1 shows the IP communication network 100, in which, according to the state of the art, there are no difficulties between the first end point 102 and the second end point 112, each having two (global) IP addresses 104A, 104B and 114A, 114B have a SCTP connection or SCTP connection formed by two paths 108A, 108B.
  • FIG. 2 shows a situation similar to Fig. 1, but with NAT routers 206A and 206B instead of routers 106A and 106B.
  • FIG. 2 shows an exemplary IP communication network 200 with the first endpoint or host A 102 and the second endpoint or host B 112.
  • Host B 112 has two global IP addresses Bl (114A) and B2 (114B). In order to simplify the illustration, FIG. 2 omits the representation of the ports.
  • connection from A is established by using the first address of A, Al as the sender address of the connection request message and the second address of A, A2 being entered in a message field of this message.
  • B Upon receipt of this message at B, there is all the necessary information to build up both paths.
  • B would receive the translated first address GA1 and the unreacted local address LA2, so that the second path 208B can not be established.
  • the first NAT router 206A also has no way to determine the translation of the address LA2 to the address GA2 in the second router.
  • FIGS. 3A-C show an exemplary procedure, according to which two single-homed connections are initially set up (FIGS. 3A-B) and subsequently linked or merged into a common SCTP association.
  • FIGS. 3A-C show an exemplary procedure, according to which two single-homed connections are initially set up (FIGS. 3A-B) and subsequently linked or merged into a common SCTP association.
  • the representation of the WAN 110 and the addresses 204, 114, 216 has been dispensed with in FIGS. 3A-C.
  • the first address translation is determined in the example of FIG. 3 by establishing a first connection 318 from the first local address LA1 of host A to the first (global) address B1 of host B. It is assumed that the routing of this connection 318 takes place via the first NAT router 206A.
  • the compound is a classic "singles homed" compound or association.
  • the following table illustrates the relationships for compound 318:
  • LAl first local address of host A
  • Bl first (global) address of host B
  • LPAl first local port of host A (to LAl)
  • PBl first port of host B (to Bl)
  • GAl first global address
  • VTAl Verification Tag of Host A for the first
  • VTBl Verification tag from host B for the first one
  • the verification tags VTA1, VTB1 acquire their significance later in connection with the connection of the two connections and are explained in more detail in connection with FIG. 3C.
  • Figure 3B shows the second step of building the multi-homed connection, determining the second address translation
  • the second address translation is determined in the example of FIG. 3 by establishing a second connection 320 from the second local address LA2 of host A to the second (global) address B2 of host B. It is assumed that the routing of this connection 320 takes place via the second NAT router 206B.
  • the compound is also a classical "single-homed" compound or association. alternative can be a single-homed connection type "merge only" er ⁇ separately (this type will be explained in more detail below)
  • the following table illustrates the relationship 'for Ver ⁇ bond 320:
  • LA2 second local address of host A
  • B2 second (global) address of host B
  • LPA2 second local port of host A (to LA2)
  • PB2 second port of host B (to B2)
  • GA2 second global address
  • VTA2 Verification Tag of Host A for the second
  • Connection VTB2 Verification tag from Host B for the second
  • FIG. 3C shows the merging or linking of the two connections or associations 318 and 320 to the desired SCTP association 208 with the paths 208A and 208B.
  • host A 102 sends an SCTP chunk ASCONF over the first connection 318, as defined in the following Internet draft of the IETF: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg -addip- sctp-09.txt (hereinafter referred to as addip-draft), extended by a parameter, which indicates to host B 112 that a parallel association (here: second connection 310) should be included as an additional address.
  • This parameter referred to below as the "Merge SCTP Endpoint" uses the verification tags that were assigned to the individual connections or associations 318 and 320 during the setup.
  • the ASCONF chunk is defined as follows (Excerpt from the above mentioned IETF Draft, with translations from English):
  • TLV Type-Length-Value
  • the ASCONF chunk is used to send to the remote endpoint a configuration change request which must be confirmed.
  • the information contained in an ASCONF chunk takes the form of a type length value (TLV) for all variable parameters, as described in chapter 3.2.1 of RFC 2960. 0 1 2 3
  • Serial Number 32 bits (unsigned integer)
  • This value represents a serial number for the ASCONF chunk.
  • the valid rank of Serial Number is from 0 to 4294967295 (2 ** 32 - 1). Serial Numbers wrap back to 0 after reaching 4294967295.
  • Serial Number represents a serial number or serial number for the ASCONF chunk.
  • the valid range of the serial number is 0 .. 4294967295 (2 ** 32 - 1).
  • Serial numbers are mapped back to 0 after they reach 4294967295.
  • This field contains an address parameter, either IPv6 or IPv4, from RFC2960 [6].
  • the address is at the address of the ASCONF chunk, the address MUST be considered part of the peer endpoint (the receiver of the ASCONF chunk). This field may be used by the receiver of the ASCONF to help in finding the association.
  • This parameter MUST be present in every ASCON message, i.e. it is a mandatory TLV parameter.
  • This field [address parameter] represents an address parameter, either according to IPv6 or IPV4, from RFC 2960.
  • the address is an address of the sender of the ASCONF chunk and must be part of the association by the partner endpoint (the receiver of the ASCONF chunk ) are interpreted. This field can be used by the receiver of the ASCONF to find the association.
  • the parameter must be included in every ASCONF message, i. it is a mandatory or required TLV parameter.
  • Host Name Address parameter is not allowed and must be ignored if it was received in an ASCONF message.
  • ASCONF parameter TLV format
  • Each address configuration is represented by a TLV parameter as defined in Section 3. 2.
  • One or more requests may be present in ASCONF Chunk.
  • Each address configuration change is represented by a TLV parameter as per Section 3.2 [of the draft].
  • One or more requirements may be contained in an ASCONF chunk.
  • the ASCONF Chunk is assigned an ASCONF ACK chunk, which is defined as follows (Excerpt from above, IETF Draft, with translations from English):
  • ASCONF Chunk This chunk is used by ASCONF Chunk to acknowledge the reeeption. It carries zero or more results for any ASCONF Parameters that were processed by the receiver.
  • This chunk [ASCONF-ACK] is used by the receiver of an ASCONF chunk to confirm the reception. It transports zero or more results for any ASCONF parameters processed by the receiver.
  • Serial Number 32 bits (unsigned integer)
  • This value represents the serial number for the received ASCONF chunk that is acknowledged by this chunk. This value is copied to the received ASCONF Chunk.
  • Serial Number represents the serial number or serial number of the received ASCONF chunk. This value is copied from the received ASCONF chunk.
  • the ASCONF Parameter Response is used in the ASCONF-ACK to report Status of ASCONF processing.
  • a responding endpoint does not include any error Cause, a success is indicated.
  • a sender of ASCONF-ACK MAY indicate complete success of all TLVs in ASCONF by returning the Chunk Type, Chunk Flags, Chunk Length (set to 8) and the Serial Number.
  • the ASCONF parameter response is used in the ASCONF ACK to report the status of ASCONF processing.
  • a result is displayed if an answering endpoint does not provide an error cause or error reason. Therefore, a transmitter of an ASCONF ACK can indicate the complete success of all TLVs in an ASCONF by reporting only the chunk type, the chunk flags, the chunk length (set to 8), and the serial number.
  • an ABORT can be sent by the recipient of an invalid parameter.
  • This 12-byte parameter is used to inform the partner side that a parallel association should be included as an additional address.
  • the parallel association must be resolved by the receiver of this parameter when the address is linked.
  • the resolution is signaled by sending an ABORT known from the SCTP for this parallel association.
  • the known from the addip-draft parameter Delete IP Address can not be used unver ⁇ changes, since no communication address - as previously customary - may be included in a parameter. Instead, the path to be removed is uniquely identified by the known conversion relationship and the sender address of the packet containing the parameter, and the following parameter can be used, for example:
  • This 4-byte ASCONF parameter is used to signal to the partner that the source address (+ port) of the chunk containing this parameter should be removed from the list of valid IP addresses. If it is the last path, the ASCONF must be rejected.
  • the parameter Primary Address known from addip-draft can not be used unchanged for the same reason. Instead, the path to be identified is uniquely identified by the known conversion relationship and the sender address of the packet containing the parameter, and the following parameter can be used, for example:
  • This 4-byte ASCONF parameter is used to signal to the partner that the source address (+ port) of the chunk containing this parameter should be set as the primary path.
  • the parameter MERGE ONLY can be used in an INIT / INIT-ACK chunk to create a (single-homed) association only for Purpose of determining the address translation relationship.
  • This temporary association should not serve the transport of data, but only the implementation relationship für ⁇ run and then linked to the parallel association:
  • This 4-byte INIT / INI-ACK parameter is used to signal to the partner that the new association is formed only temporarily to extend another association by one more path.
  • the Advertised Receiver Window Credit, Number of Inbound / Outbound Streams and Initial TSN parameters should be set by the
  • Transmitters are set to 0 and ignored by the receiver of the Merge OnIy parameter.
  • I Source Port Number LPAl
  • Destination Port Number PBl
  • I Remote Verification Tag of Parallel Association VTB2
  • I Own Verification Tag of Parallel Association VTA2
  • Host B checks the verification tags. If the second association 320 was constructed as a "merge only" type, this criterion can also be checked. It can also be checked whether the second association is active.
  • the verification of the verification tags serves to ensure security by preventing unauthorized components from associating with the association.
  • Compound 320 e.g. By sending an ABORT chunk over the link 320, the port GA2 with associated port GPA2 takes over as the second address (and thus as the second path) for the first link 318, thus becoming the two-threaded association 208. Host B then signals successful completion of this link via first path 208A of association 208, for example by means of the following ASCONF-ACK chunk: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  • IChunkType 0x80
  • Flags 0
  • Chunk Length 20
  • I Serial Number 1 I
  • one of the paths 208A, 208B may be designated as the primary path.

Landscapes

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

Abstract

Die Erfindung ein Verfahren zum Aufbau einer multi-homed Verbindung mit einer Anzahl n von Pfaden zwischen zwei Komponen- ten eines Kommunikationsnetzes. Dabei weisen die Komponenten jeweils mindestens n Kommunikationsadressen auf, und im Verbindungsweg findet eine Umsetzung der Kommunikationsadressen zumindest einer ersten der Komponenten statt. Das Verfahren weist die folgenden Schritte auf: Ermitteln von n Umsetzungsbeziehungen von für die n Pfade vorgesehenen n Kommunikationsadressen durch die Komponenten; und Aufbau der multi-homed Verbindung durch Aufbau der n Pfade anhand der ermittelten Umsetzungsbeziehungen. Die n Umsetzungsbeziehungen jeweils ganz oder teilweise werden durch Austauschen von Nachrichten bzw. Testnachrichten für k (k = 1..n) Kommunikationsadressen zwischen den Komponenten ausgetauscht werden, welche k Umsetzungsbeziehungen liefern. Dabei werden die Nachrichten bzw. Testnachrichten so gewählt, dass die Umsetzung der Kommunikationsadressen für Nachrichten bzw. Testnachrichten identisch ist zur Umsetzung der Kommunikationsadressen für die späteren Pfade der multi-homed Verbindung. Alternativ können Umsetzungsbeziehungen ermittelt werden durch Aufbau von m (m = 1..n) single-homed Verbindungen zwischen den Komponenten aufgebaut werden. Dabei kann vorzugsweise, um einen mehrmali- gen Auf- und Abbau von Verbindungen bzw. Pfaden zu verhindern, vorgesehen werden, die single-homed Verbindungen als Pfade zu der multi-homed Verbindung verknüpft werden.

Description

Beschreibung
Verfahren zum Aufbau von multi-homed Verbindungen in Netzwer¬ ken mit Adreßumsetzung
Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Aufbau von multi-homed Verbindungen, wobei im Verbindungsweg eine Umsetzung von Kommunikationsadressen stattfindet. Insbe¬ sondere bezieht sich die Erfindung auf ein Verfahren zum Auf- bau einer SCTP-Verbindung mit mehreren Pfaden in IP-Netzwer- ken mit Network Adress Translation (NAT) .
Kommunikationsnetze, in denen Kommunikationsprotokolle zum Einsatz kommen, bei denen sogenannte single-homed Verbindun- gen stets von genau einem Endpunkt zu genau einem anderen Endpunkt führen, sind heutzutage sehr weit verbreitet. Ein Beispiel für ein solches Kommunikationsprotokoll ist das In¬ ternetprotokoll IP mit den darauf aufsetzenden Protokollen TCP und UDP. In diesen Protokollen werden Endpunkte durch ei- ne IP-Adresse und eine Port-Nummer identifiziert.
Häufig sind, wie im Fall der weitverbreiteten IP-Kommunika- tionsnetze, zusätzliche Maßnahmen erforderlich, um für an das Kommunikationsnetz angeschlossene Endpunkte und andere Netz- werkkomponenten eine zuverlässige Kommunikationsverbindung zu schaffen, etwa die redundante Ankopplung an das Kommunikati¬ onsnetz. Dabei sind jedoch die Basisprotokollmechanismen sel¬ ten geeignet, diese redundante Ankopplung effizient zu ver¬ walten und zu nutzen, da die Basisprotokollmechanismen nur single-homed Verbindungen vorsehen.
Es wurden und werden daher Anstrengungen unternommen, Kommu¬ nikationsprotokolle zu schaffen, die - basierend auf den Ba¬ sisprotokollen - Applikationen, die auf Endpunkten und ande- ren Netzwerkkomponenten implementiert sind, die Möglichkeit geben, mehrere eigene Kommunikationsadressen für eine Verbin¬ dung zu definieren. Mehrere Kommunikationsadressen können beispielsweise im Wege mehrerer Netzwerkkarten vorgesehen werden. Kann eine Netzwerkkomponente zu einer Verbindung meh¬ rere eigene (und ggf. entfernte) Kommunikationsadressen nut¬ zen, spricht man häufig von Multihoming bzw. von multi-homed Verbindungen.
Ein Beispiel für ein solches Kommunikationsprotokoll mit er¬ weiterten Fähigkeiten zum Einsatz in IP-Kommunikationsnetzen ist das Session Control Transmission Protocol SCTP, definiert in IETF RFC 2960.
Fig. 1 zeigt ein beispielhaftes IP-Kommunikationsnetzwerk 100 mit einem ersten Endpunkt bzw. Host A 102 und einem zweiten Endpunkt bzw. Host B 112, die jeweils über zwei (globale) IP- Adressen 104A, 104B und 114A, 114B verfügen. Eine (SCTP) Ver¬ bindung zwischen den Endpunkten wird durch zwei Pfade 108A, 108B gebildet, die vorzugsweise verschieden sind, d.h. über verschiedene Router 106A, 106B durch das Kommunikationsnetz, welches auch ein Weitverkehrsnetz WAN 110 einschließen kann, verlaufen. Das Protokoll SCTP oder ein ähnliches Kommunikati¬ onsprotokoll verwaltet und nutzt diese beiden Pfade bei¬ spielsweise derart, daß der Ausfall eines Pfades, etwa bei Ausfall eines der Router 106, die Ende-zu-Ende-Kommunikation nicht unterbricht, da sofort der andere Pfad genutzt werden kann. Die Zahl der Pfade ist dabei nicht auf zwei beschränkt.
Ein großer Nachteil der multi-homed Verbindungen liegt darin, daß diese regelmäßig nicht aufgebaut werden können, wenn im Verbindungsweg eine Umsetzung der Kommunikationsadressen stattfindet, wie z.B. für IP-Kommunikationsnetzwerke als Net¬ work Address Translation (NAT) bekannt, definiert in IETF RFC 1631. Allgemein kann die Umsetzung einer Kommunikationsadres¬ se in IP-Kommunikationsnetzwerken beispielsweise durch Verän¬ derung einer IP-Adresse oder einer Portnummer oder durch Ver- änderung beider Adreßbestandteile erfolgen. Dabei kann eine Empfängeradresse und/oder eine Absenderadresse der Umsetzung unterliegen. Es ist daher eine Aufgabe der Erfindung, ein Verfahren zum Aufbau einer multi-homed Verbindung anzugeben, wenn im Ver¬ bindungsweg eine Umsetzung der Kommunikationsadressen statt- findet.
Diese Aufgabe wird gelöst durch ein Verfahren zum Aufbau ei¬ ner multi-homed Verbindung mit einer Anzahl n von Pfaden zwi¬ schen zwei Komponenten eines Kommunikationsnetzes. Dabei wei- sen die Komponenten jeweils mindestens n Kommunikationsadres¬ sen auf, und im Verbindungsweg findet eine Umsetzung der Kom¬ munikationsadressen zumindest einer ersten der Komponenten statt. Das Verfahren weist die folgenden Schritte auf:
Ermitteln von n Umsetzungsbeziehungen von für die n Pfade vorgesehenen n Kommunikationsadressen durch die Komponen¬ ten; und
Aufbau der multi-homed Verbindung durch Aufbau der n Pfa¬ de anhand der ermittelten Umsetzungsbeziehungen.
Die Umsetzungsbeziehung ist dabei häufig dadurch charakteri¬ siert, daß eine lokale Kommunikationsadresse einer ersten Komponente in eine globale Kommunikationsadresse umgesetzt wird. Erst die Kenntnis dieser globalen Adresse ermöglicht es anderen Komponenten, diese erste Komponente zu adressieren. Hierzu ist es allerdings nicht erforderlich, daß die anderen Komponenten die komplette Umsetzungsbeziehung, d.h. neben der globalen auch noch die lokale Kommunikationsadresse, kennen. Für einen erfolgreichen Verbindungsaufbau genügt es, wenn die adreßumsetzende Komponente, z.B. ein Router, die vollständige Umsetzungsbeziehung kennt.
Dabei können die n Umsetzungsbeziehungen jeweils ganz oder teilweise beispielsweise nach einem der folgenden Verfahren ermittelt werden: - Austauschen von Nachrichten bzw. Testnachrichten für k
(k = l..n) Kommunikationsadressen zwischen den Komponen¬ ten, welche k Umsetzungsbeziehungen liefern. Dabei werden die Nachrichten bzw. Testnachrichten so gewählt, daß die Umsetzung der Koπununikationsadressen für Nachrichten bzw. Testnachrichten identisch ist zur Umsetzung der Kommuni¬ kationsadressen für die späteren Pfade der multi-homed Verbindung.
Aufbau von m (m = l..n) single-homed Verbindungen zwi¬ schen den Komponenten. Dabei kann vorzugsweise vorgesehen werden, diese single-homed Verbindungen in einem weiteren Schritt als neue Pfade mit der multi-homed Verbindung zu verknüpfen.
Die vorliegende Erfindung betrifft ferner Komponenten eines Kommunikationsnetzes, die über Software- oder Hardwaremittel verfügen, um das erfindungsgemäße Verfahren auszuführen.
Ein Kommunikationsprotokoll, das bei Anwendung im Zusammen¬ hang mit der vorliegenden Erfindung besonders vorteilhaft er¬ weitert werden kann, ist das Stream Control Transmission Pro- tocol SCTP.
Ein besonderer Vorteil der Erfindung ist darin zu sehen, daß es möglich ist, multi-homed Verbindungen auch über Adreßum- setzer, z.B. NAT-Router, die nur die standardisierten Adre- ßumsetzungsverfahren unterstützen, aufzubauen. Das bedeutet im Fall der IP-Netzwerke, daß an den NAT-Routern keine Verän¬ derungen vorgenommen werden müssen, so daß die Erfindung un¬ mittelbar ohne Änderung der Netzinfrastruktur angewendet wer¬ den kann. Lediglich die Endpunkte von SCTP-Assoziationen müs¬ sen das Verfahren unterstützen.
Die Erfindung kann vorteilhaft auch zur dynamischen Umkonfi- gurierung von Kommunikationsadressen, z.B. IP-Adressen, ver¬ wendet werden, ohne daß eine bestehende Verbindung unterbro¬ chen wird. Dies kann zum Beispiel beim Tausch physikalischer Netzwerkkarten, bei dynamischen Adreßwechseln oder bei schnurlosen Anwendungen vorteilhaft sein. Im folgenden wird die Erfindung in Ausführungsbeispielen an¬ hand von Zeichnungen näher erläutert.
Fig. 1 zeigt in schematischer Darstellung ein IP-Netzwerk mit einer Verbindung mit zwei Pfaden über Router ohne Adreßumset- zung.
Fig. 2 zeigt in schematischer Darstellung ein IP-Netzwerk mit einer Verbindung mit zwei Pfaden über Router mit Adreßumset- zung. Fig. 3A-C zeigen in schematischer Darstellung den Ablauf der Erstellung der Verbindung aus Fig. 2.
Fig. 1 zeigt, wie bereits erläutert, das IP-Kommunikations- netzwerk 100, in dem es gemäß des Standes der Technik keine Schwierigkeiten bereitet, zwischen dem ersten Endpunkt 102 und dem zweiten Endpunkt 112, die jeweils über zwei (globale) IP-Adressen 104A, 104B und 114A, 114B verfügen, eine durch zwei Pfade 108A, 108B gebildete SCTP Verbindung bzw. SCTP As¬ soziation aufzubauen.
Fig. 2 zeigt eine ähnliche Situation wie Fig. 1, allerdings mit NAT Routern 206A und 206B anstelle der Router 106A und 106B. Im Detail zeigt Fig. 2 ein beispielhaftes IP-Kommunika- tionsnetzwerk 200 mit dem ersten Endpunkt bzw. Host A 102 und dem zweiten Endpunkt bzw. Host B 112. Host A 102 verfügt da¬ bei über zwei nur lokal gültige IP-Adressen LAl (204A) , LA2 (204B) (im Beispiel wurden die IP-Adressen LAl = 10.1.1.1 und LA2 = 10.2.2.2 gewählt), welche, durch NAT-Router 206A und 206B in globale Adressen GAl (216A), GA2 (216B) umgewertet werden (im Beispiel wurden die IP-Adressen GAl = 139.21.5.5 und GA2 = 140.20.6.6 gewählt) . Host B 112 verfügt über zwei globale IP-Adressen Bl (114A) und B2 (114B) . Zur Vereinfa¬ chung der Darstellung wurde in Fig. 2 auf die Darstellung der Ports verzichtet.
Eine SCTP Assoziation zwischen den Endpunkten A und B wird durch zwei Pfade 208A, 208B gebildet, wobei der erste Pfad 208A die lokale Adresse LAl des Host A über den ersten NAT- Router Nl (206A) , die Umsetzungsbeziehung LAl <==> GAl und das optionale WAN 110 mit der ersten Adresse Bl des Host B verbindet. Der zweite Pfad 208B verbindet die lokale Adresse LA2 des Host A über den zweiten NAT-Router N2 (206B), die Um¬ setzungsbeziehung LA2 <==> GA2 und das optionale WAN 110 mit der zweiten Adresse B2 des Host B.
Für die Anordnung des Host A in einem separaten Netz mit nur lokal gültigen IP-Adressen LAl, LA2 kann es verschiedene
Gründe geben. Ein möglicher Grund ist die Knappheit globaler IP-Adressen, die es erforderlich macht, mit dieser Ressource sparsam umzugehen und beispielsweise große Unternehmensnetze als private Netze mit privaten, d.h. nur lokal gültigen und aus dem Internet nicht adressierbaren Adressen auszugestal¬ ten. Ein weiterer möglicher Grund sind Sicherheitserwägungen, denn in vielen Fällen ist bereits die Ausgestaltung eines Netzes als privates Netz, ggf. ergänzt um NAT-Router mit Fi¬ rewall-Funktionen oder separate Firewalls, ein signifikanter Sicherheitsgewinn.
Allerdings ist es mit dem Protokoll SCTP gemäß RFC 2960 nicht möglich, eine SCTP Assoziation mit zwei Pfaden 208A, 208B ge¬ mäß Fig. 2 aufzubauen, denn im SCTP Verbindungsaufbau werden die weiteren Absenderadressen in einem Nachrichtenfeld der Verbindungsanforderungsnachricht über den ersten Pfad über¬ tragen.
Im Beispiel der Fig. 1 wird die Verbindung von A aus aufge- baut, indem die erste Adresse von A, Al, als Absenderadresse der Verbindungsanforderungsnachricht verwendet wird und die zweite Adresse von A, A2, in ein Nachrichtenfeld dieser Nach¬ richt eingetragen wird. Bei Empfang dieser Nachricht bei B liegen dort alle erforderlichen Informationen zum Aufbau bei- der Pfade vor. Im Beispiel der Fig. 2 hingegen würde B die umgesetzte erste Adresse GAl und die nicht umgesetzte lokale Adresse LA2 emp¬ fangen, so daß der zweite Pfad 208B nicht aufgebaut werden kann. Der erste NAT-Router 206A hat auch keine Möglichkeit, die Umsetzung der Adresse LA2 auf die Adresse GA2 im zweiten Router zu ermitteln.
Um die Verbindung gemäß Fig. 2 dennoch aufbauen zu können, werden zunächst die Adreßumsetzungsbeziehungen LAl <==> GAl und LA2 <==> GA2 ermittelt, um anschließend die zwei-pfadige SCTP Assoziation erstellen zu können.
Fig. 3A-C zeigen einen beispielhaften Ablauf, demgemäß zu¬ nächst zwei single-homed Verbindungen aufgebaut werden (Fig. 3A-B) und anschließend zu einer gemeinsamen SCTP Assoziation verknüpft bzw. verschmolzen werden. Zur Vereinfachung der Darstellung wurde dabei in Fig. 3A-C auf die Darstellung des WAN 110 und der Adressen 204, 114, 216 verzichtet.
Fig. 3A zeigt den ersten Schritt des Aufbaus der multi-homed Verbindung, die Ermittlung der ersten Adreßumsetzung LAl <==> GAl. Die erste Adreßumsetzung wird im Beispiel der Fig. 3 ermittelt, indem eine erste Verbindung 318 von der ersten lokalen Adresse LAl von Host A zur ersten (globalen) Adresse Bl von Host B aufgebaut wird. Dabei sei angenommen, daß das Routing dieser Verbindung 318 über den ersten NAT- Router 206A erfolgt. Die Verbindung ist eine klassische "sin- gle-homed" Verbindung bzw. Assoziation. Folgende Tabelle ver¬ anschaulicht die Zusammenhänge für Verbindung 318:
Darin bedeuten: LAl: erste lokale Adresse des Host A Bl: erste (globale) Adresse des Host B LPAl: erster lokaler Port des Host A (zu LAl) PBl: erster Port des Host B (zu Bl) GAl: erste globale Adresse, LAl <==> GAl VTAl: Verification Tag von Host A für die erste
Verbindung
VTBl: Verification Tag von Host B für die erste
Verbindung
Die Verification Tags VTAl, VTBl erlangen später im Zusammen¬ hang mit der Verknüpfung der beiden Verbindungen ihre Bedeu- tung und werden im Zusammenhang mit Fig. 3C näher erläutert. Im Ergebnis des Schrittes der Fig. 3A ist nunmehr die erste Adreßumsetzungsbeziehung LAl <==> GAl ermittelt.
Fig. 3B zeigt den zweiten Schritt des Aufbaus der multi-homed Verbindung, die Ermittlung der zweiten Adreßumsetzung
LA2 <==> GA2. Die zweite Adreßumsetzung wird im Beispiel der Fig. 3 ermittelt, indem eine zweite Verbindung 320 von der zweiten lokalen Adresse LA2 von Host A zur zweiten (globalen) Adresse B2 von Host B aufgebaut wird. Dabei sei angenommen, daß das Routing dieser Verbindung 320 über den zweiten NAT- Router 206B erfolgt. Die Verbindung ist ebenfalls eine klas¬ sische "single-homed" Verbindung bzw. Assoziation. Alternativ kann eine single-homed Verbindung vom Typ "merge only" er¬ stellt werden (dieser Typ wird weiter unten näher erläutert) Folgende Tabelle veranschaulicht die Zusammenhänge' für Ver¬ bindung 320:
Darin bedeuten: LA2: zweite lokale Adresse des Host A B2: zweite (globale) Adresse des Host B LPA2: zweiter lokaler Port des Host A (zu LA2) PB2: zweiter Port des Host B (zu B2) GA2: zweite globale Adresse, LA2 <==> GA2 VTA2: Verification Tag von Host A für die zweite
Verbindung VTB2: Verification Tag von Host B für die zweite
Verbindung
Im Ergebnis des Schrittes der Fig. 3B ist nunmehr auch die zweite Adreßumsetzungsbeziehung LA2 <==> GA2 bekannt.
Fig. 3C zeigt die Verschmelzung bzw. Verknüpfung der beiden Verbindungen bzw. Assoziationen 318 und 320 zu der angestreb¬ ten SCTP Assoziation 208 mit den Pfaden 208A und 208B. Im be¬ vorzugten Ausführungsbeispiel sendet Host A 102 hierzu über die erste Verbindung 318 einen SCTP Chunk ASCONF, wie in fol¬ gendem Internet Draft der IETF definiert: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip- sctp-09.txt (im folgenden als addip-draft bezeichnet), erwei¬ tert um einen Parameter, welcher Host B 112 anzeigt, daß eine parallele Assoziation (hier: zweite Verbindung 310) als zu¬ sätzliche Adresse eingebunden werden soll. Dieser Parameter, im folgenden als "Merge SCTP Endpoint" bezeichnet, nutzt die Verification Tags, die den einzelnen Verbindungen bzw. Asso¬ ziationen 318 und 320 beim Aufbau zugeordnet wurden.
Der ASCONF Chunk ist wie folgt definiert (Auszug aus o.g. IETF Draft, mit Übersetzungen aus dem Englischen) :
Stewart, et al. Expires December 9, 2004 [Page 5]
Internet-Draft SCTP Dynamic Address Reconf iguration June 2004 3.1.1 Address Conf iguration Change Chunk (ASCONF)
This chunk is used to communicate to the remote endpoint one of the configuration change requests that MUST be acknowledged. The information carried in the ASCONF Chunk uses the form of a Type-Length-Value (TLV), as described in "3.2.1 Optional/
Variable-length Parameter Format" in RFC2960 [6], for all variable Parameters .
Der ASCONF Chunk wird verwendet, um dem entfernten Endpunkt eine Kon figurationsänderungsanf orderung zu senden, welche bestätigt wer¬ den muß. Die in einem ASCONF Chunk enthaltene Information nutzt für alle variablen Parameter die Form eines Typen-Längen-Werts (TLV), wie in Kapitel 3.2.1 des RFC 2960 beschrieben. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
I τYPe = OxCl I Chunk Flags | Chunk Length | I Serial Number I
I Address Parameter I
I ASCONF Parameter #1 I
\ \
/ /
\ \ I ASCONF Parameter #N I
Serial Number : 32 bits (unsigned integer)
This value represents a Serial Number for the ASCONF Chunk. The valid ränge of Serial Number is from 0 to 4294967295 (2**32 - 1) . Serial Numbers wrap back to 0 after reaching 4294967295.
Dieser Wert [Serial Number] repräsentiert eine Seriennummer bzw. Se¬ rial Number für den ASCONF Chunk. Der gültige Bereich der Seriennum- mer ist 0.. 4294967295 (2**32 - 1) . Seriennummern werden zurück auf 0 abgebildet, nachdem sie 4294967295 erreichen.
Address Parameter : 8 or 20 bytes (depending on type)
This field contains an address parameter, either IPv6 or IPv4, from RFC2960 [6] . The address is an address of the sender of the ASCONF chunk, the address MUST be considered part of the association by the peer endpoint (the receiver of the ASCONF chunk) . This field may be used by the receiver of the ASCONF to help in finding the association. This parameter MUST be present in every ASCONF message i.e. it is a mandatory TLV parameter. Dieses Feld [Address Parameter) repräsentiert einen Adreßparameter, entweder gemäß IPv6 oder IPV4, aus RFC 2960. Die Adresse ist eine Adresse des Senders des ASCONF Chunks, und muß als Teil der Assozia¬ tion durch den Partner-Endpunkt (den Empfänger des ASCONF Chunks) interpretiert werden. Dieses Feld kann durch den Empfänger des ASCONF genutzt werden, um die Assoziation zu finden. Der Parameter muß in jeder ASCONF Nachricht enthalten sein, d.h. es handelt sich um einen vorgeschriebenen bzw. erforderlichen TLV Parameter.
Note the host name address parameter is NOT allowed and MUST be ignored if received in any ASCONF message.
Es sei darauf hingewiesen, daß der Host Name Address Parameter nicht erlaubt ist und ignoriert werden muß, falls er in einer-ASCONF Nach- rieht empfangen wurde..
ASCONF Parameter: TLV format
Each Address configuration change is represented by a TLV parameter as defined in Section 3 . 2 . One or more requests may be present in an ASCONF Chunk . Jeder Adreßkonfigura tionswechsel wird durch einen TLV Parameter ge¬ mäß Abschni tt 3.2 [des draft] repräsentiert . Ein oder mehrere Anfor¬ derungen können in einem ASCONF Chunk enthal ten sein .
Dem ASCONF Chunk ist ein ASCONF ACK Chunk zugeordnet, der wie folgt definiert ist (Auszug aus o . g . IETF Draft, mit Überset¬ zungen aus dem Englischen) :
3 . 1 . 2 Address Configuration Acknowledgment Chunk (ASCONF-ACK)
This chunk is used by the receiver of an ASCONF Chunk to acknowledge the reeeption. It carries zero or more results for any ASCONF Parameters that were processed by the receiver .
Dieser Chunk [ASCONF-ACK] wird vom Empfänger eines ASCONF Chunk ver¬ wendet, um den Empfang zu bestätigen . Er transportiert null oder mehr Ergebnisse für beliebige ASCONF Parameter, die durch den Emp¬ fänger verarbeitet wurden .
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
I τYPe = 0x80 I Chunk Flags | Chunk Length |
I Serial Number |
I ASCONF Parameter Responsetl I
\ \
/ / \ \
I ASCONF Parameter Response#N |
Serial Number : 32 bits (unsigned integer)
This value represents the Serial Number for the received ASCONF Chunk that is acknowledged by this chunk. This value is copied front the received ASCONF Chunk.
Dieser Wert [Serial Number]repräsentiert die Seriennummer bzw. Se¬ rial Number des empfangenen ASCONF Chunks. Dieser Wert wird aus dem empfangenen ASCONF Chunk kopiert.
ASCONF Parameter Response : TLV format
The ASCONF Parameter Response is used in the ASCONF-ACK to report Status of ASCONF processing. By default, if a responding endpoint does not include any Error Cause, a success is indicated. Thus a sender of an ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) and the Serial Number.
Die ASCONF Parameterantwort wird in dem ASCONF-ACK verwendet, um den Status der ASCONF Verarbeitung zu melden. Standardmäßig wird ein Er- folg angezeigt, falls ein antwortender Endpunkt keinen Error Cause bzw. Fehlergrund mitliefert. Daher kann ein Sender einer ASCONF-ACK den vollständigen Erfolg aller TLVs in einer ASCONF anzeigen, indem er nur den Chunk Type, die Chunk Flags, die Chunk Länge (auf 8 ge¬ setzt) und die Seriennummer zurückmeldet.
Folgende neue Parameter werden (zusätzlich oder anstelle zu den beispielsweise durch o.g. draft bereits vorgesehenen SCTP Parametern) definiert, um das Verknüpfen bzw. Verschmelzen (MERGE) von Verbindungen bzw. Assoziationen zu unterstützen (Tabelle 1: Parameter für ASCONF Chunks; Tabelle 2: Parameter für INIT/INIT-ACK Chunks) :
Neue Parameter-Typen
Address Configuration Parameters Parameter Type Merge SCTP Endpoint 0xC005
Delete SCTP Path 0xC006
Set Primary Path 0xC007
Tabelle 1 : Parameter zur Verwendung im ASCONF Parameter
Address Configuration Parameters Parameter Type
Merge OnIy 0xC005
Tabelle 2: Parameter zur Verwendung im INIT/INIT-ACK chunk
Wie bei SCTP üblich kann vorgesehen werden, daß durch den Empfänger eines ungültigen Parameters ein ABORT gesendet wer- den kann .
Die neuen Parameter werden im folgenden näher erläutert (Dar¬ stellung der Parameter£c,gemäß der IETF Konventionen) : Merge SCTP Endpoint (IP Address + Port)
Dieser 12 Byte lange Parameter wird benutzt, um der Partnerseite den Wunsch mitzuteilen, daß eine parallele Assoziation als zusätzliche Adres¬ se eingebunden werden soll .
0 1 2 3
0 1 2 3 4 5 6 7 8 9.0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 I Type = 0xC005 | Length = 12 I
I Remote Verification Tag of parallel Association |
I Own Verification Tag of parallel Association | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die parallele Assoziation muß durch den Empfänger dieses Parameters auf¬ gelöst werden, wenn die Adresse verknüpft wird. Die Auflösung wird durch das Senden eines aus dem SCTP bekannten ABORT für diese parallele Assozi- ation signalisiert. Um einen bestehenden Pfad wieder abzubauen, kann der aus dem addip-draft bekannte Parameter Delete IP Address nicht unver¬ ändert verwendet werden, da keine Kommunikationsadresse — wie bisher üblich — in einem Parameter eingebunden werden darf. Anstelle dessen wird der zu entfernende Pfad durch die bekannte Umsetzungsbeziehung und die Absenderadresse des Pa¬ ketes, das den Parameter enthält, eindeutig identifiziert, und es kann beispielsweise der folgende Parameter verwendet werden:
Delete SCTP Path
Dieser 4 Byte ASCONF Parameter wird verwendet, um dem Partner zu signali¬ sieren, daß die Quelladresse (+ Port) des Chunks, welcher diesen Parame- ter enthält, aus der Liste der gültigen IP Adressen entfernt werden soll. Falls es sich um den letzten Pfad handelt, ist die ASCONF zurückzuweisen.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
I Type =0xC006 | Length = 4 I
Um einen Pfad als primär bzw. bevorzugt zu kennzeichnen, kann aus gleichem Grunde der aus dem addip-draft bekannte Parame¬ ter Set Primary Address nicht unverändert verwendet werden. Anstelle dessen wird der zu kennzeichnende Pfad durch die be¬ kannte Umsetzungsbeziehung und die Absenderadresse des Pake¬ tes, das den Parameter enthält, eindeutig identifiziert, und es kann beispielsweise der folgende Parameter verwendet wer¬ den:
Set Primary Path Dieser 4 Byte ASCONF Parameter wird verwendet, um dem Partner zu signali¬ sieren, daß die Quelladresse (+ Port) des Chunks, welcher diesen Parame¬ ter enthält, als primärer Pfad gesetzt werden soll.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
I Type =0xC007 | Length = 4 I
Der Parameter MERGE ONLY kann in einem INIT/ INIT-ACK Chunk genutzt werden, um eine (single-homed) Assoziation nur zum Zweck der Ermittlung der Adreßumsetzungsbeziehung aufzubauen. Diese temporäre Assoziation soll dabei nicht dem Transport von Daten dienen, sondern nur die Umsetzungsbeziehung durch¬ laufen und anschließend mit der parallelen Assoziation ver- knüpft werden:
Merge OnIy
Dieser 4 Byte INIT/INI-ACK Parameter wird verwendet, um dem Partner zu signalisieren, daß die neue Assoziation nur temporär gebildet wird, um eine andere Assoziation um einen weiteren Pfad zu erweitern.
Anmerkung: Diese Assoziation soll nicht der Datenübertragung dienen.
Die Parameter Advertised Receiver Window Credit, Number of Inbound/Outbound Streams und Initial TSN sollten durch den
Sender auf 0 gesetzt werden und durch den Empfänger des Merge OnIy Parameters ignoriert werden.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
I Type =0xC005 I Length = 4 I
Die in Fig. 3C dargestellte Verknüpfung der beiden Verbindun¬ gen 318 und 320 aus Fig. 3B zu der Assoziation 208 kann nun erfolgen, indem Host A über die erste Verbindung 318 einen ASCONF Chunk mit folgendem Format an Host B sendet:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 SCTP Common Header:
I Source Port Number = LPAl | Destination Port Number = PBl | +-+-+-+-+-+-+-+-+-+-+-+-+-+ — ι— +-+-+-+-+-+-+-+-+ — i— +-+-+-+-+-+-+-+
I Verification Tag = VTBl I
+-+-+-+-+-+-+-+-+-+-+-+-+-+—h-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Checksum I
+-+-+-+-+-+-+-+-+-+-+-+-+-+—ι—+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mit SCTP ASCONF Chunk:
+-+-+-+-+-+-+-+-+-+-+-+-+-+—i—+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IChunkType =0xCl | Flags = 0 | Chunk Length = 20 |
I Serial Number = 1 I
IParameter Typ Merge = 0xC005 I Length = 12 I
I Remote Verification Tag of parallel Association = VTB2 | I Own Verification Tag of parallel Association = VTA2 | Bei Host B werden die Verification Tags überprüft. Wurde die zweite Assoziation 320 als "merge only" Typ aufgebaut, kann auch dieses Kriterium geprüft werden. Ebenso kann überprüft werden, ob die zweite Assoziation aktiv ist.
Die Prüfung der Verification Tags dient dabei der Sicherheit, indem so verhindert werden kann, daß sich unberechtigte Kom¬ ponenten in die Assoziation verbinden.
War die Überprüfung erfolgreich, beendet Host B die zweite
Verbindung 320, z.B. durch Senden eines ABORT Chunks über die Verbindung 320, übernimmt die Adresse GA2 mit zugeöhrigem Port GPA2 als zweite Adresse (und damit als zweiten Pfad) für die erste Verbindung 318, die auf diese Weise zur zweipfadi- gen Assoziation 208 wird. Den erfolgreichen Abschluß dieser Verknüpfung signalisiert Host B dann über den ersten Pfad 208A der Assoziation 208, beispielsweise mittels des folgen¬ den ASCONF-ACK Chunks: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
SCTP Common Header:
I Source Port Number = PBl | Destination Port Number = GPAl fr I Verification Tag = VTBl I
I Checksum | mit SCTP ASCONF-ACK Chunk:
IChunkType =0x80 | Flags = 0 | Chunk Length = 20 | I Serial Number = 1 I
Das Ergebnis ist die Assoziation 208 gemäß folgender Über¬ sicht:
Anschließend kann einer der Pfade 208A, 208B als primärer Pfad festgelegt werden.
Es sei darauf hingewiesen, daß die vorstehend beschriebenen Protokolle, Nachrichten, Nachrichtenelemente und Parameter lediglich eine von vielen möglichen Implementierungen der Er¬ findung wiedergeben. Es ist offensichtlich, daß die detail¬ liert beschriebenen SCTP Chunks und Parameter für andere Pro- tokolle entsprechend angepaßt werdenf:müssen, um die für diese Protokolle geltenden Konventionen, beispielsweise andere Quittungs- oder Sicherungsmechanismen, zu erfüllen. Ferner ist ausgehend von den beschriebenen Ausführungsbeispielen of¬ fensichtlich, wie die Lehre der vorliegenden Erfindung für SCTP unter Nutzung anderer Chunks und Parameter angewendet werden kann.

Claims

Patentansprüche
1. Verfahren zum Aufbau einer multi-homed Verbindung (208) mit einer Anzahl n von Pfaden zwischen zwei Komponenten (102, 112) eines Kommunikationsnetzes (100, 200), wobei die Komponenten (102, 112) jeweils mindestens n Kommuni¬ kationsadressen (204A, 204B, 114A, 114B) aufweisen und wobei im Verbindungsweg eine Umsetzung der Kommunikati¬ onsadressen (204A, 204B) zumindest einer ersten der Kom- ponenten (102) stattfindet, mit folgenden Verfahrens¬ schritten:
Ermitteln von n Umsetzungsbeziehungen von für die n Pfade vorgesehenen n Kommunikationsadressen durch die Komponen¬ ten, wobei zumindest eine Anzahl k der n Umsetzungsbezie- hungen ermittelt werden, indem für k Kommunikationsadres¬ sen Nachrichten zwischen den Komponenten ausgetauscht werden, welche k Umsetzungsbeziehungen liefern, wobei die Nachrichten so gewählt sind, daß die Umsetzung der Kommu¬ nikationsadressen für diese Nachrichten identisch ist zur Umsetzung der Kommunikationsadressen für Pfade der multi- homed Verbindung; und v Jt-.
Aufbau der multi-homed Verbindung durch Aufbau der n Pfa¬ de anhand der ermittelten Umsetzungsbeziehungen.
2. Verfahren nach Anspruch 1, bei dem zumindest eine Anzahl m der n Umsetzungsbeziehungen ermittelt werden, indem m single-homed Verbindungen zwischen den Komponenten aufge¬ baut werden.
3. Verfahren nach Anspruch 2, bei dem die multi-homed Ver¬ bindung aufgebaut wird, indem die m single-homed Verbin¬ dungen als m Pfade zu der multi-homed Verbindung ver¬ knüpft werden.
4. Verfahren nach einem der vorhergehenden Ansprüche, da¬ durch gekennzeichnet, daß die multi-homed Verbindung eine Verbindung gemäß des geeignet erweiterten Stream Control Transmission Protocol SCTP ist.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß das Protokoll SCTP mit folgenden Erweiterungen angewendet wird:
- Aufbau von single-homed Verbindungen mit Verification Tags; und
- Parameter Merge SCTP Endpoint in Chunks vom Typ ASCONF, in denen zumindest die Verification Tags zu verknüpfender single-homed Verbindungen übermittelt werden.
6. Komponente (102, 112) eines Kommunikationsnetzes (100, 200) , die mindestens n Kommunikationsadressen (204A, 204B, 114A, 114B) aufweist, wobei ein Verbindungsweg des Kommunikationsnetzes zwischen der Komponente und zumin¬ dest einer weiteren Komponenten eine Umsetzung von Kommu¬ nikationsadressen aufweist, wobei die Komponente (102, 112) ferner folgendes aufweist: - Mittel zum Ermitteln einer Anzahl n von Umsetzungsbezie¬ hungen von für n Pfade vorgesehenen n Kommunikationsad¬ ressen, umfassend Mittel zum Ermitteln zumindest einer Anzahl k der n Umsetzungsbeziehungen, welche Mittel zum Austauschen von Nachrichten für k Kommunikationsadressen zwischen der Komponenten und der weiteren Komponente zum Liefern von k Umsetzungsbeziehungen umfassen, wobei die Nachrichten so gewählt sind, daß die Umsetzung der Kommu¬ nikationsadressen für Nachrichten identisch ist zur Um¬ setzung der Kommunikationsadressen für Pfade der multi- homed Verbindung; und
Mittel zum Aufbau einer multi-homed Verbindung mit n Pfa¬ den durch Aufbau der n Pfade anhand der ermittelten Um¬ setzungsbeziehungen.
7. Komponente eines Kommunikationsnetzes nach Anspruch 6 mit Mitteln zum Ermitteln zumindest einer Anzahl m der n Um- Setzungsbeziehungen, welche Mittel zum Aufbau von m sin- gle-homed Verbindungen zwischen den Komponenten umfassen.
8. Komponente eines Kommunikationsnetzes nach Anspruch 7, bei der die Mittel zum Aufbau der multi-homed Verbindung Mittel zum Verknüpfen der m single-homed Verbindungen als m Pfade zu der multi-homed Verbindung umfassen.
9. Komponente eines Kommunikationsnetzes nach einem der An- sprüche 6 bis 8, dadurch gekennzeichnet, daß die Kompo¬ nente Mittel zum Aufbau von multi-homed Verbindungen ge¬ mäß des Stream Control Transmission Protocol SCTP auf¬ weist.
10. Komponente eines Kommunikationsnetzes nach Anspruch 9, dadurch gekennzeichnet, daß die Komponente das Protokoll SCTP mit folgenden Erweiterungen unterstützt: Aufbau von single-homed Verbindungen mit Verification Tags; und - Parameter Merge SCTP Endpoint in Chunks vom Typ ASCONF, in denen zumindest die Verification Tags zu verknüpfender single-homed Verbindungen übermittelt werden.
EP05763995A 2004-07-21 2005-06-29 Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung Withdrawn EP1769619A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05763995A EP1769619A2 (de) 2004-07-21 2005-06-29 Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP04017217A EP1619850A1 (de) 2004-07-21 2004-07-21 Verfahren und Vorrichtung zum Aufbau von multi-homed Verbindungen in Netzwerken mit Adressumsetzung
PCT/EP2005/053065 WO2006008224A2 (de) 2004-07-21 2005-06-29 Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung
EP05763995A EP1769619A2 (de) 2004-07-21 2005-06-29 Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung

Publications (1)

Publication Number Publication Date
EP1769619A2 true EP1769619A2 (de) 2007-04-04

Family

ID=34925853

Family Applications (2)

Application Number Title Priority Date Filing Date
EP04017217A Withdrawn EP1619850A1 (de) 2004-07-21 2004-07-21 Verfahren und Vorrichtung zum Aufbau von multi-homed Verbindungen in Netzwerken mit Adressumsetzung
EP05763995A Withdrawn EP1769619A2 (de) 2004-07-21 2005-06-29 Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP04017217A Withdrawn EP1619850A1 (de) 2004-07-21 2004-07-21 Verfahren und Vorrichtung zum Aufbau von multi-homed Verbindungen in Netzwerken mit Adressumsetzung

Country Status (3)

Country Link
EP (2) EP1619850A1 (de)
KR (1) KR20070038160A (de)
WO (1) WO2006008224A2 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011076931A1 (de) 2011-06-03 2012-12-06 Basf Se Wässrige Lösung, enthaltend Acrylsäure und deren konjugierte Base

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
EP1619850A1 (de) 2006-01-25
WO2006008224A2 (de) 2006-01-26
KR20070038160A (ko) 2007-04-09
WO2006008224A3 (de) 2006-07-13

Similar Documents

Publication Publication Date Title
DE602005003189T2 (de) Verfahren und System zum Aufbau eines bidirektionalen Tunnels
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
EP3357218B1 (de) Verfahren zur industriellen kommunikation über tsn
US20060018301A1 (en) Method of establishing multi-homed connections in networks with address conversion
DE60022391T2 (de) System und verfahren zur erzielung einer robusten ip/udp/rtp-paketkopf-komprimierung in der gegenwart unzuverlässiger netze
DE60017442T2 (de) Spärliche rückkoppelung in drahtlosen systemen die hohe verzögerung und niedrige bandbreite aufweisen
DE60300299T2 (de) System zur Auswahl von Quell-Adressen geeignet für eine Umgebung mit mehreren Heimatnetzen
DE60300035T2 (de) Kommunikationssystem zum Aufbauen einer PPPoE ähnlichen Verbindung zwischen IEEE1394 basierten Peeren und IP basierten Peeren
DE102015004668B4 (de) Aufgeteilte netzwerkadressenübersetzung
DE19849170A1 (de) Verfahren zum Einrichten eines Internet-Protokoll Netzwerkes
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
EP1287660A2 (de) Verfahren zum übertragen von sprachinformationen über ein internetprotokoll
DE10231958B4 (de) Verfahren und System zum Übertragen von Datenpaketen über ein Netzwerk an ausgewählte mehrere Bestimmungsorte, sowie computerlesbares Medium
EP1266493B1 (de) Verfahren und anordnung zum übertragen eines datenpakets von einer ersten vermittlungseinheit an eine zweite vermittlungseinheit in einem datennetz
EP1769619A2 (de) Verfahren zum aufbau von multi-homed verbindungen in netzwerken mit adressumsetzung
EP1227632B1 (de) Verfahren zum Betrieb eines Multimedia-Kommunikationsnetzwerkes
DE60320567T2 (de) Adressenverwaltungsverfahren
DE10119447A1 (de) Verfahren zum Vermitteln von Daten zwischen einem lokalen Netzwerk und einem externen Gerät und Router dafür
EP2036313B1 (de) Verfahren zur verwaltung von kommunikationsverbindungen über netzwerk-adressumsetzende nat netzknoten
EP3515034B1 (de) Verfahren, vorrichtungen, computerlesbare medien und systeme zum aufbau zertifizierter verbindungen mit endgeräten in einem lokalen netzwerk
EP1261175A2 (de) Verfahren zur Weiterleitung von Datenpaketen in Routern von Kommunikationsnetzen
WO2004100498A1 (de) Verfahren zum datenaustausch zwischen netzelementen in netzwerken mit verschiedenen adressbereichen
DE10015640A1 (de) Verfahren zur Signalisierung unterschiedlicher Kopfinformationen
EP1841164A1 (de) System, Verfahren und Verbindungseinheit zum dynamischen Konfigurieren von NAT-Routern
WO2005020534A1 (de) Verfahren und vorrichtung zur ubertragung von sicherheits- und nutzinformationen über getrennte gesicherte verbindung

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: 20070104

AK Designated contracting states

Kind code of ref document: A2

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

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

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

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

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

17Q First examination report despatched

Effective date: 20071127

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: 20080408