Patent Application
20060259625
The present invention generally relates to network communication and more particularly to the issue of providing connectivity between networks of different address realms.
In network communication, there is a general demand for providing connectivity between different networks, especially when the networks have different address realms. For example, this would normally be the case when a node in a private network wants to connect to a host in a public network. The private network usually has internal addresses that cannot be used outside the network, for privacy reasons or simply because the internal addresses are invalid for use outside the private network. Other examples include connectivity between networks of different public domains, between different private networks and between networks with different address schemes such as IP version 4 and IP version 6.
The demand for network connectivity is a generic issue. However, there is a current situation, which demands resolution in the near future. With the explosive growth of Internet Protocol (IP) networks such as the Internet, intranets and other networks, the limited IP address space offered by the current version of the IP protocol, IPv4, becomes a real challenge. With a 32-bit address field, it is possible to assign 232 different addresses, which are about 4 billion globally unique addresses. The next version of the IP protocol, IPv6, will have a 128-bit address field, thus providing a significantly higher number of globally unique IP addresses. The challenge is that there is a limited number of IPv4 addresses available to the operators for their new networks, and IPv6 is not yet supported by more than a very limited set of nodes within the Internet. Also, a large number of legacy networks including Internet subnets will likely be using IPv4 or older versions of the IP protocol for many years to come.
For mobile or cellular networks, telecom vendors and operators are facing a great challenge deploying support for an expected vast number of IP-enabled mobile terminals in 2.5 and 3G networks. The IPv4 address space is apparently not large enough to cover the needs when a massive deployment of 2.5 and 3G networks takes place within the near future. Today, network operators that apply for address ranges for their new cellular networks receive address spaces far below the expected number of users. The ratio can be as low as a few thousand addresses for an expected customer base of millions of subscribers.
To meet the demand for addresses, telecom vendors are pushing the introduction of IPv6 into terminals as the standard protocol to use within next generation cellular networks. IPv6, fully deployed would naturally solve the address space problem, but unfortunately, IPv6 is not widely deployed in the Internet yet, and it is expected that this deployment will be quite slow, at least in the near future.
IPv6 is not directly compatible with IPv4 and therefore when an IPv6 host wants to communicate with an IPv4 host there will be compatibility problems. The only way an IPv6 host can communicate with a host that only supports IPv4 is by means of in some way using an IPv4 address. Thus, by introducing IPv6 to 3G terminals the address space problem is only partially solved.
This poses a potential serious threat to the successful deployment of 3G networks and their success with customers. It is highly important not to limit access to services and applications used in the Internet to avoid diminishing the appreciation from potential customers.
Since IPv6 is not fully deployed in the Internet, vendors will have to use migration schemes for providing connectivity between different networks.
There are a number of existing schemes for both extending an address realm and for translating between different address realms.
For example, there are a number of existing proposals that make address translations between different address realms. These solutions, all different versions of Network Address Translators (NATs), have in common that hosts in one (e.g. private) address space are temporarily assigned addresses belonging to another (e.g. public) address space. An overview of these different schemes can be found in [1], and a discussion of implementation issues can be found in [2].
The problem with the current proposed NAT schemes is that they all limit service provisioning in some way [1]. Either they scale badly and hence do not solve the problem of the limited address space or they do not allow communication to be initiated both to and from 3G hosts or they require deployment of specific software modules called Application Level Gateways (ALGs).
The ALGs are modules that reside in the network and that parse the payload in IP packets and rewrites application level information to reflect the NAT functionality. Even though ALGs are available for some applications, primarily for use with firewall software on LINUX platforms, they are impossible to deploy and maintain in an operator environment simply because no one can assume responsibility for these modules. In a 3G network, the NATs would typically be manufactured and provided by telecom vendors. This hardware and software environment will be highly specialized and there will be little or no correlation between platforms from different vendors. Therefore, ALGs will have to be developed for each platform.
It is highly unlikely that the application developers will have the required skills or be willing to perform this development and maintain distribution of version upgrades as application versions change the ALG's operation. Similarly, the equipment vendors cannot muster the necessary resources to scan the Internet for all new software that is released and either obtain specifications or reverse engineer applications in order to build ALGs for their own equipment and keep up with software revisions. Finally, the operators and ISPs (Internet Service Providers) will not want to create huge development organizations to take on this task instead of buying functioning concepts from vendors and concentrate on their core business.
Realm Specific IP (RSIP) takes a different approach than NAT to provide connectivity between different realms [3, 4]. RSIP uses a special node that is aware of the different realms and can distinguish between the two. In general terms, RSIP uses two entities, a RSIP server and a RSIP client. The RSIP server is present in both realms and can provide router functionality between the realms. It can also be the node assigning public addresses to private hosts. The RSIP client is a node within the private realm that can temporarily use a public address when conmunicating with public hosts. Hence, RSIP makes use of public addresses for both parties when communicating between the private and public realms, and does not perform any address translation. An advantage of RSIP is that there is no need to deploy ALGs for applications since public realm addresses are used even for private clients. However, plain RSIP does not allow public-realm initiated connections. For example, Realm Specific Address and Port IP (RSAP-IP) cannot handle public-realm initiated communication, since port translation is required. RSAP-IP temporarily assigns a free port on the RSIP server to each private realm client that wants to communicate with the public realm. Since there is no correlation between the temporarily assigned port and the port on which the private client would listen for connection requests and there is no mechanism for distributing information to public realm hosts about any legacy port numbers corresponding to specific services, it is impossible for the public realm hosts to connect to the correct port on the RSIP server.
A novel approach, called REBEKAH-IP, builds on two earlier proposals RSIP and bi-directional NAT, and adds additional extensions for satisfying three demands, scalability, avoiding using ALGs and allowing private-realm initiated communication as well as public-realm initiated communication [5, 6]. This solution is also subject of our co-pending U.S. Provisional Patent Application 60/370,812 and corresponding International Patent Application PCT/US03/09834. However, the REBEKAH-IP solution shows the undesirable property of possible irresolvable ambiguities and connection blocking.
There is also ongoing work at Columbia University [7] with a scheme that encapsulates IP addresses in a new header format. However, this scheme requires all hosts in the Internet to be upgraded which is not a feasible solution.
The present invention overcomes these and other drawbacks of the prior art arrangements.
It is a general object of the invention to provide an improved scheme for supporting connectivity between networks of different address realms.
It is particularly important to minimize connection blocking. It is important to provide enhanced scalability, for example to enable support of a large number of private nodes by means of a limited number of available public addresses. In other words, it is desirable to improve the multiplexation characteristics of an intermediate communication gateway.
It is an object of the invention to provide an improved method and system for enabling establishment of a connection between different address realms, generally referred to as an outside address realm and an inside address realm, through an intermediate communication gateway.
Yet another object of the invention is to provide a gateway resource manager for supporting minimized connection blocking and/or enhanced scalability.
Still another object of the invention is to provide a communication terminal that supports improved connectivity between networks of different address realms.
It is also an object of the invention to provide an improved method of configuring an inside-realm communication node.
These and other objects are met by the invention as defined by the accompanying patent claims.
The invention generally concerns the issue of providing connectivity between different address realms, generally referred to as an inside realm and an outside realm. When an application, generally referred to as a process, in an inside-realm node wants to communicate with another process in an outside-realm node, it opens a communication port often referred to as a socket, which includes parameters such as source address and port, and destination address and port. The addresses identify the communication network interfaces of the nodes and the port numbers identify the processes in the nodes, keeping in mind that a given node may have a plurality of simultaneously communicating processes. In the prior art, including the REBEKAH-IP solution, the inside-realm nodes themselves select, randomly and independently of each other, port number for communication with the outside realm. It has been recognized that this prior art approach may lead to connection blocking, since there is a risk that two inside-realm nodes with the same allocated outside-realm address select the same port number for communication to the same outside-realm process, which would result in a collision or clash, forcing the gateway to block one of the connections.
A basic idea according to the present invention is to avoid all addressing ambiguities and let a gateway resource manager or equivalent central entity (a central configuration server) assign not only the address but also which source port number to use for each communication or flow. This means that the focus is shifted from a) assigning addresses to inside-realm nodes to b) centrally addressing distributed processes in the inside-realm nodes. Consequently, at the core we find a centralized port number allocation mechanism, in clear contrast to the prior art arrangements in which the port number information is not known at the time of address assignment.
When an inside-realm node, e.g. a private-realm terminal, wants to connect to an outside-realm node, e.g. a host on the public Internet, the inside-realm node preferably starts by requesting configuration. It is assumed that the connection is to be established through an intermediate gateway, which has a pool of so-called outside-realm gateway addresses for enabling outside-realm representation of inside-realm nodes. In response to the configuration request initiated from the inside-realm node, an outside-realm gateway address and an inside node port number are centrally allocated to the inside-realm node, and establishment of the connection is initiated at least partly based on the allocated address and port number. The allocated address and port number are signaled back to the requesting inside-realm node in a configuration reply, allowing the inside-realm node to configure its communication interface accordingly.
Alternatively, the allocation is centrally initiated without the need for any request from the inside-realm node, e.g. if the gateway system wants to “force” the inside-realm node to open a specific port.
Preferably, the central address and port number allocation is performed by identifying an outside-realm gateway address and an inside node (source) port number that together with predetermined connection information, typically derivable from the configuration request, define a unique socket parameter combination, also referred to as an outside-realm gateway state representation, that has no counterpart in any existing gateway connection state. The predetermined connection information generally includes outside node (destination) address information, e.g. known through a DNS (Domain Name Server) query, and/or outside node (destination) port information, e.g. a well-known standard port number. In this way, the central gateway resource manager will be able to allocate combinations of socket addresses and ports such that collisions are avoided. In particular, all source port numbers for a given outside-realm address can now be used for distinguishing different connections, which is a major advantage compared to prior art solutions.
Although any general signaling protocol/mechanism can be used by the invention, it has been recognized that it may be beneficial to convey the configuration parameters in a special DNS type record or by carefully re-using an existing DNS type record.
The invention offers the following advantages:
Other advantages offered by the present invention will be appreciated upon reading of the below description of the embodiments of the invention.
The invention, together with further objects and advantages thereof, will be best understood by reference to the following description taken together with the accompanying drawings, in which:
General Overview
In general, there is a demand for providing connectivity between different address realms, more generally referred to as an outside realm and an inside realm. To this end, there is normally provided an intermediate communication gateway, which has been assigned a pool of outside-realm gateway addresses for enabling outside-realm representation of inside-realm nodes. In many practical applications, the inside realm is a private address realm, whereas the outside realm is a public address realm. In other applications, however, the inside realm and the outside realm may both be different private address realms, different public realms or different protocol realms.
In this respect, a public realm network is generally a network having communication nodes together with an associated network address space consisting of globally unique network addresses. A private realm network on the other hand is a network having nodes together with an associated network address space consisting of possibly non-unique network addresses, in the sense that two nodes in different instances of a private realm may be assigned the same network address. It is also possible that the private realm uses a different protocol and or addressing scheme than the public realm. For example, the private realm can use IPv6 addresses and the public realm can use IPv4 addresses. In the context of this invention, it even holds true that two or more nodes within the same private realm can be assigned the same network address, which can also be assigned to other nodes in other networks. However, it holds true that the addressing within a particular realm enables traffic to be delivered within the realm. A communication gateway is thus generally a network element that is connected to both an inside realm and an outside realm. As previously mentioned, there are different types of gateways, especially substitution style gateways (including e.g. different flavors of NAT) and relaying style gateways (including e.g. different flavors of RSIP). It should also be understood that the overall gateway function may include packet forwarding on any network layer or combination of network layers.
For a better understanding of the invention, it may be useful to begin with a brief introduction of a basic model of an exemplary gateway providing connectivity between an inside realm and an outside realm, referring to
For a relaying style gateway, a gateway connection state is normally defined by an outside n-tuple and a virtual point-to-point interface towards a communication node on the inside realm. In general, an n-tuple is a set of n information elements that typically includes: (a source network address, a source port number, a destination network address, a destination port number, and a protocol number). An outside n-tuple is typically an n-tuple with the source and destination network addresses belonging to the outside realm. An example of a virtual point-to-point interface is an IP-in-IP tunnel in which, in the inside-bound direction, a packet is encapsulated in another packet, with the destination address equal to the inside node's private address, and the source address equal to the inside gateway address, and in the outside-bound direction the incoming packet is decapsulated, whereby an inner packet is extracted. In another example, instead of IP encapsulation and decapsulation, there could be a layer 2 point-to-point link between the gateway and the communication node on the inside realm (for example, in a GPRS system, the PDP Context layer). It should be understood that other mechanisms for establishing an inside-realm routing/switching path between the gateway and the inside-realm node can be utilized by the invention. For example, it is possible to employ a shared media interface together with routing or switching mechanisms able to forward traffic to an inside-realm node.
In a relaying style gateway, the two basic processes for enabling proper packet forwarding for communication flows are defined as:
There may be partially complete gateway connection states, i.e. states which represent connections that currently are in the process of being established, but which have not yet collapsed into a complete gateway connection state for a gateway session. Such partially complete gateway states are sometimes referred to as gateway gates or pinholes.
In a relaying style gateway, a gateway gate is a gateway connection state with an outside n-tuple that has one or more unspecified connection variables. When the gateway receives an inside-bound packet matching the specified values of the partially complete outside n-tuple, that n-tuple is completed in the sense that the up-to-now unspecified values of the partially complete n-tuple are fixed to the corresponding values associated with the packet.
Problem Analysis
The inventors have recognized that although the REBEKAH-IP proposal disclosed in references [5, 6] indeed provides excellent scalability and also allows public-realn initiated communication, there is a risk of addressing collisions that will result in connections being blocked. Even though these collisions are rare, they constitute an undesirable side effect of the otherwise ingenious REBEKAH-IP solution.
In REBEKAH-IP there is a possibility for irresolvable ambiguities to occur when inside-realm (private) nodes initiate communication to outside-realm (public) nodes. If such an ambiguity occurs, the resulting action would be to block some communication attempts. This in turn would have a negative impact on the perceived level of service from the end-users.
In particular, these ambiguities or collisions may occur for inside-realm initiated communication when using relaying or tunneling style gateways based on for example RSIP. When an inside-realm node wants to initiate communication with an outside-realm node, it sends the destination address (or normally the domain name of the destination node) and/or port number in a resource allocation request to the overall gateway function, which then attempts to identify an outside gateway address for the inside-realm node, which in combination with the received destination address and/or port number is unique. If it is assumed, for illustrative reasons, that all gateway addresses in the gateway address pool have been traversed without finding a completely “free” address, it may be necessary to select an outside-realm gateway address that has previously been allocated to another inside-realm node communicating with the very same outside-realm node. The only parameter left to distinguish the two connections would then be the port number for the inside-realm nodes. In the prior art, the port number for an inside-realm node is unknown at the time of the address assignment, and only made known to the gateway later on when the first data packet arrives. Consequently there will be a collision or clash if the two inside-realm nodes happen to select the same port number, which means that the gateway has to block the later of the two connections and request the corresponding inside-realm node to re-open the socket with a new port number.
For a detailed understanding of the above chain of events reference is made to
An exemplary sequence for supporting a communication flow from inside-realm nodes A1 and A2 to outside node B through the gateway could be:
To eliminate this problem, a basic idea according to the invention is to let the configuration server/gateway resource manager assign not only the outside-realm gateway address but also which source port number to use for the communication, thus avoiding all addressing ambiguities for inside-realm initiated communication. This is preferably accomplished in the following illustrative manner, referring to the exemplary flow diagram of
It is envisaged that the central gateway system may want to force an inside-realm node to open a certain port for communication, without the need for an explicit request from the inside-realm node. In that case, the gateway resource manager itself initiates the central port and address allocation.
The gateway resource manager preferably identifies an outside-realm socket address and a source port number that in combination with predetermined connection information included in and/or derivable from the initial configuration request define a set of socket parameters that has no counterpart in any existing gateway connection state. This unique set of socket parameters, including the allocated socket address and source port number, is generally referred to as an outside-realm gateway state representation, and forms the basis for establishing the new gateway connection state (S4). More particularly, the new gateway connection state is established based on the identified outside-realm gateway state representation, and a corresponding inside-realm gateway state representation such as a virtual point-to-point interface between the gateway and the inside-realm node.
The gateway resource manager should be able to handle both a configuration request including a destination network address such as an IP address as well as a configuration request including a destination name such as a FQDN (Fully Qualified Domain Name). In the latter case, a DNS-query or similar identifier-to-address query may be performed to obtain the destination address to be used by the gateway resource manager in the allocation procedure.
In a typical implementation, the resource manager requests that the gateway establishes the new connection state based on a complete outside-realm representation and a corresponding inside-realm node identifier. Alternatively, the resource manager requests establishment of a partially complete connection state, which is subsequently completed when the inside-realm node has been configured, the virtual point-to-point interface on the inside-realm has been established and the inside-realm node has eventually communicated complementary connection (socket) information to the gateway in the first packet. In the latter case, the destination port number does not even have to be known at the time of allocation of socket address and source port number. The gateway resource manager may still ensure that there will be no collisions even without information of the destination port number by simply not assigning the same source address/port pair to two terminals that want to establish contact with the same destination host. In other words, this corresponds to treating the situation in the same manner as when the destination port number is the same in both configuration requests.
The idea of not only assigning the addresses but also which source port numbers to use for the communication implies that the inventive mechanism in some sense can be regarded as Centrally Assigned Process Addressing (CAPA), since the centralized port assignment in combination with the centralized address assignment pin-points individual processes in the inside-realm nodes.
The major changes introduced by the invention in relation to the previously described signaling sequence diagram of
In this example, it is assumed that each inside-realm node already knows the destination network address so that the configuration request already includes predetermined connection information in the form of a destination network address aOB and/or a destination port number pB, typically both a destination address and a destination port number, as illustrated in
Provided that both destination address aOB and destination port number pB are known by the gateway resource manager, the step-wise state set-up in the gateway may be eliminated if desired, and hence there is no need for process c any longer.
In a sense, the idea is to jointly allocate, based on predetermined connection information, an outside-realm gateway address and an inside node (source) port number that in combination with the predetermined connection information define an outside n-tuple that has no counterpart in a predetermined set of existing gateway connection states. As previously mentioned, the predetermined connection information typically includes at least one of outside node (destination) address information and outside node (destination) port information. If both the destination address and destination port are included in the predetermined connection information, the outside n-tuple will be complete. Otherwise, it will be partially complete. In the gateway, a gateway connection state is established based on the at least partially complete outside n-tuple. The allocated gateway address and port number are sent back to the requesting inside-realm node in a configuration/allocation reply. After configuration, the inside-realm node can start the actual data packet transmission towards the intended outside-realm node via the intermediate gateway.
General Discussion
For illustrative reasons, consider the following. The port range for an individual host is 216—the first 1024 ports being reserved by the IANA [8]. In a worst case scenario, all private hosts in a network will try to connect to the same public IP address on the same port number (the same process). In this case, the CAPA mechanism will unambiguously allow (216−1024)×N (the number of available public IPv4 addresses to the GW) simultaneous flows. In the best case scenario, all connections from private hosts will be to separate combinations of public IP addresses and port numbers. In this case, CAPA will unambiguously support (216−1024)×N×(232−N)×(216−1024) simultaneous flows. A simple partial derivative with respect to N to find the maximum yields a theoretical value of ˜262 simultaneous flows through a single CAPA gateway.
However, this is an unrealistic value since it occurs when a single CAPA gateway has half the IPv4 32 bit address space, but with a more realistic value of 1000 addresses (for a cellular 3G operator for example) the outcome is ˜1.8*1022 simultaneous uniquely distinguishable flows.
Note however that there is a further limitation to the number of flows that can be supported. CAPA is not meant to be a globally permanent solution and already deployed hosts in the public Internet each occupies an IP address. These hosts cannot take advantage of the increased address space as introduced by CAPA. Thus there is a limitation of 216*N possible connection for these hosts. For hosts in CAPA domains however, the scalability goes way beyond this limitation.
For example, an IPv6 system using CAPA could be configured as follows. For communication between two CAPA domains, use IPv6 and IP in IP tunneling across any IPv4 domain. Use standard IPv6 routing mechanisms and the IPv6 stacks in the hosts. For terminal-initiated (from the inside-realm) communication to the public IPv4 realm, use CAPA and assign IPv4 addresses and sender port numbers centrally to avoid ambiguities and achieve optimum scalability.
For network-initiated traffic (from the outside-realm), use REBEKAH-IP and assign IPv4 addresses to the terminals, thus allowing all forms of push services, notification services and instant messaging services among other services. In the latter case, since the inside-realm host need already be configured with a network address in order to accept incoming connection requests, the overall gateway resource manager also needs a mechanism by which inside-realm hosts are allowed to request only an IP address from the gateway resource manager.
Communication from hosts with unique public IPv4 addresses are not subject to address ambiguities since the sender port will never be the same for two concurrent flows from the same host. Furthermore, there is no chance of address ambiguities from hosts behind various forms of NATs either, since when using these schemes either the sender IP address, port number or address/port number will be unique.
As previously mentioned, the basic gateway functions in the gateway 30 are supported by the outside-bound and inside-bound processes 32, 34 and the packet-forwarding element 36. The gateway connection states of the gateway 30 may be implemented in a state database 38 that operates as the gateway routing table.
The above process of increasing the multiplexing characteristics of the gateway by central and intelligent allocation of socket address and source port number may be based on a comparison in relation to existing gateway connection states. Referring to the simplified block diagram of
It should be clear that the way the configuration request is transferred to the gateway resource manager (directly, via the gateway and/or DNS-server, and so forth) is not critical, as long as the central gateway resource manager eventually receives the connection information required for identifying a unique combination of socket parameters. The same applies to the configuration reply, as long as the relevant socket parameters are eventually transferred to the requesting inside-realm node. Among other things, the way in which the invention is embodied depends on other system design criteria such as the sequence of steps for opening sockets in a particular programming API. Therefore, the client configuration can be co-located with the name resolution step (DNS lookup) or separated completely.
It should also be understood from the above examples that the management and allocation functions in the overall gateway system may be implemented in one or more processes, running on a single node or physically separated into several nodes. For example, the gateway and the associated resource manager may be separated or co-located, all depending on the particular system design specifications. The gateway resource manager function and the associated DNS function may be implemented in separate nodes, or alternatively implemented together, for example in a modified DNS-server.
In general, the gateway resource manager may be implemented as software, hardware, firmware or any combination thereof. In the case of a software-implementation, the steps, functions and actions related to the resource manager are mapped into a computer program, which when being executed by a computer or equivalent processing system effectuates the relevant resource allocation.
Example of More Detailed System Implementation
Terminal Implementation
It has turned out to be advantageous to define a new CAPA specific DNS record type, which is utilized for conveying the socket parameters to the terminals during configuration. Alternatively, however, for minimizing the impact on the terminals an existing record type such as the SRV record [9] could be used. However, in this latter case, it is important to stress that the SRV record is an existing record type that has a purpose other than use with CAPA. There is a possibility that using an existing record such as the SRV record can create problems when terminals interpret the data wrongly or DNS servers use the SRV record in a different way. This problem could be reduced by defining a field in the SRV record type that clearly distinguishes the usage of the record for CAPA signaling, in effect temporarily making it a CAPA specific record. It should also be stressed that the implementation of the returned DNS record as the signaling method is not by any means the only way CAPA signaling can be realized. It is possible to use modified RSIP signaling or any other signaling protocol/mechanism to obtain the configuration parameters. In fact, this is very much an issue for implementing CAPA in specific environments where the signaling can be piggybacked on other signaling, thus reducing overall call setup latency or obtaining other advantages.
Naturally, every practical implementation has to be customized and optimized with respect to system specific circumstances and design criteria.
The query to the GRM/DNS from the private terminal may then request the CAPA record type. In the returned record there will eventually be fields that identify which source IP address and port number to use, as well as information on the destination address.
The following is an example output from the DNS using a new CAPA record as well as A record information when the terminal wants to contact host apricot.ee.unsw.edu.au:
This reply is interpreted by the resolver as “configure your interface with the IP address 129.94.230.85 and use port number 8500 for the opened socket. The IP address of the remote host (apricot) is 129.94.230.79”.
An exemplary process flow for an inside-realm host/terminal is shown in the schematic flow diagram of
In this particular implementation the interaction between terminal and server utilizes the standard DNS function rather than introducing explicit signaling.
The selected illustrative method requires only moderate changes to the terminal since the only hard demand is that the DNS resolver (an application that queries DNS) can ask for and understand CAPA records in addition to the usual A or AAAA records. The acquiring of the sender IP address and port number can also be implemented using explicit signaling with the GRM. When using explicit signaling, it is possible to implement the information retrieval either by modifying the resolver or by modifying the socket API implementation to include the signaling phase when applications open up sockets. However, such a way of implementation would have a larger impact on the terminals since the operating system would require substantial changes.
Gateway Resource Manager Implementation
An exemplary implementation of the gateway resource manager, which may also be referred to as a process-addressing manager, is based on a standard implementation of DNS with extensions to manage the dynamic address and port assignments and the signaling with the gateway. In an exemplary implementation, the gateway uses standard layer three and/or four switching functions for mapping the addresses and port numbers to tunnels.
An example of a decision process in the gateway resource manager is shown in the schematic flow diagram of
In step S21, the gateway resource manager receives a destination FQDN and a source IP address. The resource manager utilizes DNS functionality for a DNS lookup to obtain the destination IP address that corresponds to the FQDN, as indicated in step S22. For example, the DNS functionality could be integrated in the gateway resource manager or provided in the form of a separate DNS server with which the resource manager communicates to obtain the destination IP address. Upon a query, the resource manager determines if the query came from within the private domain or from the public domain, as indicated in steps S23/S27. In step S23, it is investigated if the request originates from the private realm. If true, the next step S24 is to assign an address and also a port number to use for the private host/terminal. The selection process can be implemented using a number of different algorithms for optimization of speed and so forth. In the exemplary implementation we opted for a rotating IP address list and the first free port number as follows:
If the private host has already been assigned an IP address, use it. Else, select first IP address from list, and move that address to end of list so that it is not selected again until all other IP addresses in list have been selected once. This spreads the assignment of IP addresses evenly over the available range. Secondly, select first unused port number for the selected IP address. If no free port number is available, repeat with next address in list.
The next step S25 is to inform the border gateway of the selected combination of source and destination IP addresses and the corresponding private address so the gateway can update its routing table with a mapping to the correct tunnel. This process can also be implemented in several ways, using different algorithms depending on optimization for hardware and so forth.
In this example implementation we do not actually update the routing table until the terminal has been properly configured, the corresponding point-to-point interface in the private realm has been established, and the first packet is received by the gateway. Instead we use a separate list for pending connections (with partially complete connection states) until a tunnel has been established and the source and destination ports are signaled in the packet flow.
Next, in step S26, the resource manager returns the record to the querying source host/terminal, and the combination of known parameters (socket addresses and ports) is marked as occupied.
When the first datagram/packet belonging to the session arrives at the border gateway the outstanding parameter(s) will be identified and the combination of all four (sender and receiver address and port numbers) will be uniquely mapped to the associated tunnel.
If it is determined, in step S23, that the request does not originate from the private realm (false), the flow proceeds with step S27. In step S27, it is investigated whether the request originates from the public realm and the destination terminal is within the private realm. If true, a public address for representing the private destination terminal is assigned in step S28, and a binding is made with the public source host. The next step S29 is to notify the gateway of the binding. In step S30, the resource manager returns the record to the querying public source host.
Step S31 represents a standard DNS situation with a regular DNS lookup and reply, when a private terminal wants to communicate with another private terminal.
In short, steps S24-26 correspond to the CAPA mechanism, whereas steps S28-30 more or less correspond to the REBEKAH-IP mechanism.
If the query originated from the public realm (e.g. Internet), the combination of sender address and port number will be unique and if originated from the private realm, the parameter selection process explained above will also have made the combination unique so the gateway can easily identify the new flow.
During the remainder of the session, the border gateway will read the combination of sender and receiver addresses and port numbers and base its routing on this combination for traffic coming from the public domain. Traffic from the private domain will simply be forwarded according to standard IP forwarding mechanisms.
With reference once again to
The embodiments described above are merely given as examples, and it should be understood that the present invention is not limited thereto. Further modifications, changes and improvements which retain the basic underlying principles disclosed and claimed herein are within the scope of the invention.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE03/01261 | 8/8/2003 | WO | 9/28/2005 |
| Number | Date | Country | |
|---|---|---|---|
| 60459346 | Apr 2003 | US |
