The present invention relates to a method for operating a network, particularly an IP (Internet Protocol) network or mobile network, wherein a network address and at least one port range associated to the network address and comprising ports or port numbers are assigned to a client by an address and/or port range manager. Further, the present invention relates to a network, particularly an IP (Internet Protocol) network or mobile network, wherein a network address and at least one port range associated to the network address and comprising ports or port numbers are assigned to a client by an address and/or port range manager.
Methods for operating a network and according networks of the above mentioned type are known from multiple use cases. With regard to such methods and networks there is existing a general aim to enlarge the address space using parts of port numbers. The IETF (Internet Engineering Task Force) has started discussing a scheme for enlarging the IP address space using parts of the port numbers, similar to what Network Address Translators (NAT) do, see M. Boucadair, J-L. Grimault, P. Levis, A. Villefranque: DHCP Options for Conveying Port Mask and Port Range Router IP Address, Internet draft, draft-boucadair-dhc-port-range-01.txt. This allows to assign the same IP address to several customers (HGWs—Home Gatways) or hosts and differentiate the routing and forwarding based on the IP address and part of the port numbers of that communication.
So far the IETF has proposed a DHCP (Dynamic Host Configuration Protocol) extension and PPP (Point-to-Point Protocol) extensions to assign IP address and port ranges to hosts and sites, see M. Boucadair, P. Levis, G. Bajko, T. Savolainen: IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion, Internet draft, draft-boucadair-port-range-01.txt and O. Maennel, R. Bush, L. Cittadini, S. Bellovin: The A+P Approach to the IPv4 Address Shortage, Internet draft, draft-ymbk-aplusp-03.txt. However, since the deployments are very different for different users, customers with several users etc., more means for managing port assignment appear to be required. Measurements showed that different clients need different range sizes at different times. This implies that dynamic port range assignment seems to be needed for
The existing means are sufficient to assign and re-assign port ranges. However, a client cannot immediately switch from one port range to another one, because most applications cannot change port numbers while using them. Without interrupting existing connections, a client can only start allocating new ports in a new range and wait until ports in an old range are not used anymore. Consequently, a client needs to wait until applications have closed all ports in the old port range.
Further details regarding port range configuration options for PPP are obtainable from M. Boucadair, P. Levis, J-L. Grimault, A. Villefranque: Port Range Configuration Options for PPP IPCP, Internet draft, draft-boucadair-pppext-portrange-option-00.txt.
Further, U.S. Pat. No. 7,031,275 is explaining an address management for mobile nodes.
It is an object of the present invention to improve and further develop a method for operating a network and an according network for allowing an efficient use of available port space without requesting clients to interrupt ongoing sessions.
In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1 and a network comprising the features of claim 28.
According to claim 1 the method is characterized in that one or more port ranges will be marked by the manager with an attribute that signals to the client not to allocate any more ports or port numbers in marked port ranges.
According to claim 28 a network is characterized by means for marking one or more port ranges by the manager with an attribute that signals to the client not to allocate any more ports or port numbers in marked port ranges.
According to the invention it has been recognized that by marking one or more port ranges with an attribute that signals to the client not to allocate any more ports or port numbers in marked port ranges a simple identification of one or more port ranges is possible that should not be used anymore by the client. By the use of such an attribute the client is informed about port ranges which shall no longer be used and can stop allocating any more ports or port numbers in marked port ranges. Thus, specific port ranges can be disabled gradually. The marking will be performed by the manager as instance which is responsible for address and/or port range assignment. By such a specific and dynamic port range management a very efficient use of available port space can be performed without requesting clients to interrupted ongoing sessions.
Preferably the marking could be performed by the manager before or during an assignment or a reassignment process. After an according assignment or reassignment process the client will be actually informed about the availability of individual port ranges and can act accordingly.
While the client is using a port range, several reasons may occur that make it desirable to change an actual assignment. There could be a situation that the client is observing that there are only few unused numbers left in the used port range and that it may soon happen that no further port numbers would be available for requesting applications. In order to avoid this situation, the client could request an assignment of more port numbers at the manager. Thus, a reassignment process could be initiated by the client.
In another situation a reassignment process could be initiated by the manager in response to any according information received by the manager.
In a concrete use case the manager could monitor the usage of ports or port numbers by a client or by the clients and could detect that there are only a few unused port numbers left in the port range assigned to the client. In this situation the manager could decide to assign a wider port range to the client before port numbers run out. In another situation the manager could detect that the client is only using a small part of the port range assigned to him and could decide to assign the client a smaller port range.
Within another situation the manager could monitor a degree of fragmentation of a port space formed by the ports or port numbers and/or of an address space formed by the network addresses. In this situation the manager could identify a need to reassign the port range of the client in order to reduce fragmentation of the port and/or address space.
For providing a very simple reassignment the manager could send a message to the client, the message containing at least one port range marked with the attribute or containing at least two port ranges, the originally assigned port range marked with the attribute and at least one new port range. The at least one new port range will form the port range or port ranges to be used from now on.
Within a further preferred embodiment of the invention the manager could define a time period until which the originally assigned port range is still valid. After said time period the originally assigned port range could definitely expire.
For simply informing the client about the invalidity of a port range the manager could to the client that a port range is no longer assigned to the client. Such a signalling could be initiated if the manager is detecting that no port number of the originally assigned port range is in use anymore.
On the other hand the client could to the manager that a port range is no longer in use. In other words the client could send an explicit to the manager that it is not using the initial port range anymore and that the manager can assign it to other clients.
Within a further preferred embodiment the method according to the invention can also be used for reducing or trimming already assigned port ranges. In such a case the manager could divide a single port range into two or more consecutive port ranges. Then, the manager could reassign the single port range as a set of port ranges to the client with one or more of the port ranges marked with the attribute, i.e. as not to be used anymore. After such a reassignment the client could back that one or more ranges are not used anymore.
Within a preferred embodiment the manager or an according manager function could be provided at a BRAS (Broadband Remote Access Server). In other words, a broadband operator could manage an IP address and port range manager for broadband access, wherein the manager could be provided at a BRAS.
In other embodiments the manager or an according manager function could be provided at a MSAN (Multi Service Access Node) or DSLAM (Digital Subscriber Line Access Multiplexer).
Another preferred embodiment of the invention could be realized in a scenario wherein the manager or an according manager function could be provided at a SGSN (Serving GPRS Support Node) or GGSN (Gateway GPRS Support Node) within mobile networks.
Depending on the individual scenario the client could be a home router or the gateway of a large enterprise. Further, the client could be located on a UE (User Equipment).
When operating as a home router the client could act as NAT (Network Address Translator) for devices within a home network.
For providing a very comfortable and reliable method for operating a network policies could be configured into the client and/or the manager for customized handling of the assignment or reassignment process. Preferably, the policies could define an individually available port range or port number of a client. Such an individually available port range or port number of a client could depend on the client status. Good clients or clients which are paying more than other clients could request higher numbers of ports, for example.
Within a further preferred embodiment the policies could define a usage level, at which the client is allowed to request for a larger port range than originally assigned.
The signalling between a client and the manager could be done through different or various protocols. Within a concrete embodiment a signalling between the client and the manager could be performed by DHCP (Dynamic Host Configuration Protocol) extensions, PPP (Point-to-Point Protocol) extensions, Web Services, TR-69 (Technical Report 069) or another protocol for address and port pool management. The used protocol could be dependent on the individual use case.
Within a concrete embodiment Port Mask DHCP option could contain a Mask Flags (MF) field for marking a port range with the attribute. Such a Mask Flags (MF) field could have a length of one or two bytes.
In practise the Mask Flags (MF) field could contain a flag for the manager (MD) for indicating to the client not to allocate any more ports or port number in the respective port range. Additionally or alternatively the Mask Flags (MF) field could contain a flag for the client (MA) for indicating to the manager that the port range is not in use anymore.
Within a simple embodiment the same flag could be used for indicating by the manager to the client not to allocate any more ports or port numbers in the respective port range and for indicating by the client to the manager that the port range is not in use anymore. However, using different flags would have the advantages of cleaner and more flexible signalling.
Within another preferred embodiment a Port Mask DHCP option with a definable DID (DHCP option ID) or two definable DIDs could be used for indicating by the manager to the client not to allocate any more ports or port numbers in the respective port range and for indicating by the client to the manager that the port range is not in use anymore. In this case one or two new DIDs could be assigned. One DID for both purposes would be possible, but preferably, two DIDs should be assigned, one for signalling that a range is not to be used anymore and one for signalling that a range is not in use anymore.
Within a further preferred embodiment a definable PPP (Point-to-Point Protocol) IPCP (Internet Protocol Configuration Protocol) option, preferably a Port Range Usage (PRU) Option with two additional flags, could be used for indicating by the manager to the client not to allocate any more ports or port number in the respective port range and for indicating by the client to the manager that the port range is not in use anymore.
The present invention allows to postpone the deallocation of port ranges until the respective ports are closed. The client has the possibility to actively confirm the release of port ranges.
A user can actively close all ports in anticipation of an exceeding demand of ports from new applications to be started. All ports are released voluntarily in expectation of goodwill to get a larger port range assigned.
The client could carry out a partial release of a requested port range, hence splitting the port range in used and unused ports.
The present invention is providing a dynamic port range assignment or reassignment.
According to the present invention marking of a port range in a message to the client as not to be used anymore is possible. According to a further aspect of the invention sending a from the client that a port range is not in use anymore and configuring policies into the client and the server for customized handling of the different cases and defining the behaviour of giving out port ranges is preferred.
Thus, address and port range managers can more efficiently and flexibly manage the address and port number space, unused port ranges can more quickly be used again and therefore the one achieves a multiplexing gain, and fragmentation of port number space can be reduced.
The invention is providing means for marking a port range size as not to be used anymore and is providing means for a client to a port range ready to be reassigned.
There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claims subordinate to patent claim 1 on the one hand, and to the following explanation of preferred examples of embodiments of the invention, illustrated by the drawing on the other hand. In connection with the explanation of preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will we explained. In the drawing
An embodiment of the invention provides a way for a port range assignment server to tag a port range with an attribute that signals the client not to allocate any more ports in this range. Such a can be sent when a server signals more than one port range to a client. A most simple embodiment would be adding a flag to one or more port ranges during the (re-)assignment process that marks these ranges as not to be used anymore. A client receiving the would then stop allocating port numbers in the marked ranges. When the client does not use an address range anymore, it signals back that the port range is not in use anymore and can be re-assigned. This can be done individually for each range as soon as it is not used anymore or at once when all marked ranges are not used anymore.
The method can also be used for reducing—trimming—already assigned port ranges. For this purpose, the server divides the single port range into two or more consecutive port ranges and reassigns the single port range as a set of port ranges to the client with one or more of the port ranges marked as not to be used anymore. Again, the client would back that one or more ranges are not used anymore.
A concrete embodiment according to
1) When a client requests an IP address with a port range including the number of ports, the BRAS assigns it and signals the assigned port range to the client. The port range specified by the client could be a preferred port range indicated by a min value and a max value of the port range or just the number of ports.
2) While the client is using the port range, several reasons may occur that make it desirable to change the assignment.
3) The BRAS sends a message to the client. The message contains two port ranges, the originally assigned one with a mark not to use it anymore and a new range to be used from now on.
4) The client only allocates new port numbers in the new range.
5) Either the BRAS detects that no port number of the initial port range is in use anymore—through monitoring—and signals to the client that the initially assigned range is not anymore assigned to the client. Or the client send an explicit that it is not using the initial range anymore and the BRAS can assign it to other clients.
In other embodiments, the IP address and port range manager can be located at a MSAN/DSLAM (Multi Service Access Node/Digital Subscriber Line Access Multiplexer), or any other infrastructure equipment. A client may also be a single host or the gateway of a large enterprise. The scheme also applies to mobile networks, where the server is located on the SGSN (Serving GPRS Support Node) or GGSN (Gateway GPRS Support Node), and the client on a UE (User Equipment).
The signaling between client and server can be done through different protocols including DHCP extensions, PPP extensions, Web Services, TR-69, or another protocol for address and port pool management.
The process on the BRAS for deciding on how many ports to give away is based on policies configured into the BRAS from a management station. That might depend on the customer status. Good customers, customer paying more, etc. might request higher numbers. Also it can depend on the current level of free addresses and ports. When there are only a few ports left, the IP address and port range manager will give out port ranges more restrictive. Also the mechanisms according to step 5) above, requires configuration on the BRAS to behave in one or the other way, also including the configuration of the client.
The policies will also be configured into the client. Those policies tell the client how large of a space he is allowed to request, at what usage level the client should ask for more port space (see step 2a above). For example that can be if only 80% of the ports are used, the client asks already for more, or the client only asks for more if he fully used up his space.
An embodiment of DHCP signaling can be based on the already mentioned reference: M. Boucadair, J-L. Grimault, P. Levis, A. Villefranque: DHCP Options for Conveying Port Mask and Port Range Router IP Address, Internet draft, draft-boucadair-dhc-port-range-01.txt. In this reference a new Port Mask DHCP option for port range signaling is suggested. The format of the Port Mask DHCP option is:
The DHCP Option ID (DID) identifies the option as the one used for port range signaling. For each port range a pair of a Port Mask (MP) and a Mask Locator (ML) is contained. Length n indicates the number of bytes contained. Length n is always a multiple of 4, because each MP and ML have a length of 2 bytes. For signaling port ranges not to be used or not in use anymore, a new option can be used that in addition to MP and ML contains a Mask Flags (MF) field:
Alternative 1 (One Byte MF)
Alternative 2 (Two Byte MF)
The MF field could be defined to have a length of one byte or two bytes. The length n would then always be a multiple of 5 or 6, respectively. The MF field contains a flag for the server (MD) for indicating to the client that the range is not to be used anymore, and a flag for the client (MA) for indicating to the server that the range is not in use anymore. In order to save flags, the same flag could be used for both purposes, although using different flags would have the advantages of cleaner and more flexible signaling.
An embodiment of the one byte MF flag field would be
Instead of adding a flag field to the port range signaling DHCP Option, another DHCP Option with another DID, but the same format as suggested in the last mentioned reference can be used. In this case one or two new DIDs need to be assigned. One DID for both purposes would be possible, but preferably, two new DIDs would be assigned, one for signaling that a range is not to be used any more and one for signaling that a range is not in use anymore.
In case of port range signaling using PPP as described in the already mentioned reference: M. Boucadair, P. Levis, J-L. Grimault, A. Villefranque: Port Range Configuration Options for PPP IPCP, Internet draft, draft-boucadair-pppext-portrange-option-00.txt, a new PPP IPCP (IP Configuration Protocol) option needs to be defined. An embodiment would be a Port Range Usage (PRU) Option with the following format:
Analogously to the description of the DHCP extension above, two new flags would be defined:
Bit 16: MD flag
Bit 17: MA flag
IPCP configure requests and acknowledgements as described in the last mentioned reference will then have an PRU option in addition to the PRV (Port Range Value) and the PRM (Port Range Mask) option that describe the port range.
Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Number | Date | Country | Kind |
---|---|---|---|
09008747.9 | Jul 2009 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2010/004019 | 7/5/2010 | WO | 00 | 3/19/2012 |