WO2022154700A1

WO2022154700A1 - Allocation of a public ip address and a public port number to a node implementing a service

Info

Publication number: WO2022154700A1
Application number: PCT/SE2021/050021
Authority: WO
Inventors: Tero Kauppinen; Miika KOMU; Timo SIMANAINEN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-01-18
Filing date: 2021-01-18
Publication date: 2022-07-21

Abstract

A service accessing system comprises a service record handler (24) of an address allocation system (22) and a node (16) implementing a container (33) for a service (34), the node (16) being operative to send a service message to the service record handler (24) and the service record handler (24) being operative to receive the service message, analyse the content of the service message for assessing whether the service message is a request to allocate a public IP address and public port number to the service (34),obtain a public IP address and a public port number for the service if it is and make the obtained public IP address and public port number available for communications involving the service (34).

Description

ALLOCATION OF A PUBLIC IP ADDRESS AND A PUBLIC PORT NUMBER TO A NODE IMPLEMENTING A SERVICE

TECHNICAL FIELD

The invention relates to networks using services such as Virtualized Network functions. More particularly, the invention relates to a service record handler, a method, computer program and computer program product for making a public IP address and public port number available for communications involving a service, a node implementing a container for a service, a method, computer program and computer program product for triggering an allocation of a public IP address and a public port number to a service as well as to a service accessing system comprising a service record handler of an address allocation system and a node implementing a container for a service.

BACKGROUND

Communication networks, such as mobile communication networks, have increased in popularity for using a wide variety of services, such as voice and/ or video, gaming, chatting and interactions with social media sites etc. These networks are then often operated by an operator and include a number of nodes cooperating for rendering different services to users of the network.

Furthermore, the rendering of such services via a network also often involves computer processing.

Lately, due to a variety of reasons, it has become attractive to move a Network Function from a Physical form, for instance deployed on a physical multi-service edge router platform, to a deployment on a Cloud where the Network function may run on Commercial off-the-shelf (COTS) Hardware. The function may run in a virtualized form as a virtual machine (VM) or container along with other services co-hosted on a single COTS server.

The way that some of this is done has been standardized, for instance by the European Telecommunications Standards Institute (ETSI) as a concept called network functions virtualization (NFV) in which virtual network functions (VNFs) are realized. These may additionally be realized in a so- called Kubernetes system.

Moreover, in a cloud system, one service is usually distributed to multiple instances of virtual machines or containers. These instances are dynamically created and destroyed. Furthermore, incoming requests are forwarded to a service by a traffic distributor, such as by a load balancer based on a load balancing decision. The services are thereby provided in a private addressing space, i.e. they have private Internet Protocol (IP) addresses and port numbers, while the traffic distributor is typically implemented in both the private and public addressing space, i.e. it has both a public and a private IP address and port number.

It may be of interest to make some virtual network functions (VNFs) to have their own publicly reachable IP addresses and port numbers even though Network Address Translators (NATs) are employed commonly in Kubernetes networks (according to the so called “no-NAT” requirement). For example, this may occur if a VNF needs to complete a self-registration process, i.e., register its own IP address and port to an external node.

One situation where such self-registration may be needed is in the case streaming of data (e.g. audio or video) that a single stream needs to be handled by a single service instance. This may require that the service instance knows the public address and port (so-called no NAT requirement), and requests the stream to that specific address and port. This is hard to implement if the service can only be reached via a traffic distributor.

There is therefore a need for allocating a public address and public port number to a service and making them available so that direct communication involving the service can be carried out without the use of a traffic distributor.

SUMMARY

One object of the invention is to enable an allocation of a public address and public port number to a service.

This object is according to a first aspect achieved by a service record handler of an address allocation system, where the service record handler comprises a processor acting on computer instructions. Through these computer instructions the service record handler is operative or configured to:

• receive a service message from a node implementing a container for a service,

• analyse the content of the service message for determining if the service message is a request to allocate a public IP address and a public port number to the service,

• obtain a public IP address and a public port number for the service, if the service message is considered to be such a request, and

• make the obtained public IP address and public port number available for use in communications to and from the service.

The object is according to a second aspect achieved through a method of making a public IP address and public port number available for communications involving a service, which method is carried out by a service record handler of an address allocation system and comprises:

• receiving a service message from a node implementing a container for a service,

• analysing the content of the service message for determining if the service message is a request to allocate a public IP address and public port number to the service,

• obtaining a public IP address and a public port number for the service if the service message is considered to be such a request, and

The object is according to a third aspect achieved through a computer program for making a public IP address and public port number available for communications involving a service. The computer program comprises computer program code which when run by a processor forms a service record handler of an address allocation system, where the service record handler is configured to:

• analyse the content of the service message for determining if the service message is a request to allocate a public IP address and public port number to the service,

• obtain a public IP address and a public port number for the service if the service message is considered to be such a request, and

• make the obtained public IP address and public port number available for communication to and from the service. The object is according to a fourth aspect achieved through a computer program product for making a public IP address and public port number available for communications involving a service, where the computer program product comprises a data carrier with computer program code according to the third aspect.

The service may be a dynamically created service, such as a dynamically created virtual network function (VNF). The virtual network function when created may additionally initially only be set to communicate using IP addresses and port numbers in a private addressing space of a network comprising the node.

The node implementing the service may thus be a node in a network, such as a computer network or communication network, like a mobile communication network, which mobile communication network may as an example be a fifth-generation mobile communication network.

The service record handler of the address allocation system may be a Domain Name Server. The address allocation system may furthermore comprise a network address translator.

In case the address allocation system comprises a network address translator, the obtaining of a public IP address and a public port number for the service may comprise sending a request for allocation of a public IP address and a public port number destined for the network address translator if the service message is considered to be a request to allocate a public IP address and public port number to the service and receiving a public IP address and public port number allocated to the service from the network address translator as a response to the request.

The address allocation system may additionally comprise a resource manager. If this is the case, the sending of a request for allocation of a public IP address and a public port number that is destined for the network address translator may be made to the resource manager, thereby triggering the resource manager to request and receive an allocated public IP address and public port number from the network address translator and forward them to the service record handler.

A querying entity may query the service record handler about the public IP address and public port number allocated to the service, which querying entity may be the node implementing the container for the service or a client device desiring to access the service. Such a client device may be a user terminal of the network. Alternatively, the client device may be a node implementing the container for another service.

In a variation of the first aspect, the service record handler is further configured to send the allocated public IP address and the public port number to the querying entity.

In a corresponding variation of the second aspect, the method further comprises sending the allocated public IP address and the public port number to the querying entity.

It is additionally possible that the public IP address and the public port number are sent as at least one response to at least one query from the querying entity. It is additionally possible that the public port number is sent as a response to a service query and the public IP address is sent as a response to a Domain Name Server Query.

The service message may be a service update request comprising a service record with a port setting and the service message may be considered to be a request to allocate a public IP address and public port number to the service if the port setting is a pre-defined port setting representing a request to allocate a public IP address and public port number to the service. It is additionally possible that the pre-defined port setting is a zero-port setting.

The service record handler may additionally comprise a group of service records, which may be records of services being set up or run on behalf of client devices.

In this case the service message may additionally be a service query comprising a service name with a service prefix and the service message may be considered to be a request to allocate a public IP address and public port number to the service, if the service message is a service query for which the service prefix is missing in the service records of the group of service records.

The above-mentioned object is according to a fifth aspect also achieved by a node implementing a container for a service. The node comprises a processor acting on computer instructions. Through these computer instructions the node is operative or configured to: send a service message to a service record handler of an address allocation system, where the service message comprises content that identifies the message as a request for public IP address and public port number allocation to the service. Thereby the service message triggers the service record handler to obtain a public IP address and a public port number for the service.

The object is according to a sixth aspect also achieved by a method of triggering an allocation of a public IP address and public port number to a service. The method is carried out by a node implementing a service for a container and the method comprises: sending a service message to a service record handler of an address allocation system, where the service message comprises content that identifies the message as a request for public IP address and public port number allocation to the service. Thereby the service message triggers the service record handler to obtain a public IP address and a public port number for the service.

The object is according to a seventh aspect achieved by a computer program for triggering an allocation of a public IP address and a public port number to a service. The computer program comprises computer program code which when run by a processor forms a node implementing a service for a container where the node is configured to: send a service message to a service record handler of an address allocation system, where the service message comprises content that identifies the message as a request for public IP address and public port number allocation to the service. Thereby the service message triggers the service record handler to obtain a public IP address and a public port number for the service.

The object is according to an eighth aspect achieved by a computer program product for triggering an allocation of a public IP address and a public port number to a service, the computer program product comprising a data carrier with computer program code according to the seventh aspect.

Also in the fifth and sixth aspects, the node implementing the service may be a node in a computer network or a communication network, where the communication network may be a computer communication network or a mobile communication network, such as a fifth-generation mobile communication network.

The service message may be a service update request comprising a service record comprising a pre-defined port setting that identifies the message as a request for public IP address and public port number allocation to the service. It is additionally possible that the pre-defined port setting is zero. According to one variation of the fifth aspect, the node may furthermore be operative to receive the public IP address and the public port number from the service record handler.

According to a corresponding variation of the sixth aspect, the method further comprises receiving the public IP address and the public port number from the service record handler.

According to another variation of the fifth aspect, the node is further configured to send at least one query to the service record handler and receive the public IP address and public port number as at least one response to the at least one query.

According to a corresponding variation of the sixth aspect, the method further comprises sending at least one query to the service record handler and receiving the public IP address and public port number as at least one response to the at least one query.

The at least one query may comprise a service query, the response to which comprises the public port number. The at least one query may additionally or instead comprise at least one domain name server query, the response to which comprises the public IP address.

According to yet another variation of the fifth aspect, the node is further configured to register the service at a client device using the public IP address and public port number.

According to a corresponding variation of the sixth aspect, the method further comprises registering the service at a client device using the public IP address and public port number. A ninth aspect is concerned with a service accessing system comprising a service record handler of an address allocation system and a node implementing a container for a service, where the node comprises a processor acting on computer instructions, through which instructions the node is configured to; send a service message to the service record handler, and the service record handler comprises a processor acting on computer instructions, through which instructions the service record handler is operative to: receive the service message, analyse the content of the service message for determining if the service message is a request to allocate a public IP address and public port number to the service, obtain a public IP address and a public port number for the service if the service message is considered to be such a request, and make the obtained public IP address and public port number available for communications to and from the service.

The service accessing system may additionally comprise a network address translator of the address allocation system as well as a resource manager of the address allocation system.

The invention according to the above-mentioned aspects has a number of advantages. It allows direct access of a service from outside a private addressing space of the network without the use of a traffic distributor.

It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in more detail in relation to the enclosed drawings, in which:

Fig. 1 schematically shows an example of communication network that comprises various nodes, where one node has a first implementation of a container for a service and another node is a service record handler, Fig. 2 schematically shows the node with a second implementation of a container for a service,

Fig. 3 shows a block schematic of another way of realizing the node implementing a container for a service,

Fig. 4 shows a block schematic of one way of realizing the service record handler,

Fig. 5 shows a block schematic of another way of realizing the service record handler,

Fig. 6 schematically shows a service message according to a first embodiment,

Fig. 7 shows a step in a method of triggering an allocation of a public IP address and port number for accessing a service according to the first embodiment,

Fig. 8 shows a flow chart of a number of steps in a method of making a public IP address and public port number available for communications involving a service according to the first embodiment,

Fig. 9 shows the payload of a service message according to a second embodiment,

Fig. io shows a flow chart of a number of methods steps in a method of triggering an allocation of a public IP address and port number for accessing a service according to the second embodiment,

Fig. n schematically shows a flow chart of a number of steps in the method of making a public IP address and public port number available for communications involving a service according to the second embodiment, Fig. 12 shows a signalling chart according to the second embodiment with signals exchanged between nodes in or connected to the communication network,

Fig. 13 shows a signalling chart according to a third embodiment with signals exchanged between nodes in or connected to the communication network,

Fig. 14 shows a computer program product comprising a data carrier with computer program code for realizing the node implementing the container for the service, and

Fig. 15 shows a computer program product comprising a data carrier with computer program code for realizing the service record handler.

DETAILED DESCRIPTION

In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits and methods are omitted so as not to obscure the description of the invention with unnecessary detail.

Fig. 1 schematically shows a network, which in the present example is a communication. Furthermore, the communication network is in this case a mobile communication network MN 10 comprising a base station BS 12, a traffic distributor realized as a load balancer LB 14, a Serving gateway SGW 16, a PDN gateway PGW 18, where PDN is an acronym for Packet Data Network, and a Gateway GPRS Support Node (GGSN) 20, where GPRS is an acronym for General Packet Radio Service. GGSN 20 is provided in order to allow communication with entities outside of the network 10. The GGSN 20 is shown as being connected to one such external entity 32. There is furthermore a mobile station MS 30 wirelessly communicating with the base station 12. The mobile station 30 more particularly comprises a client CL 31 to be used for such communication.

In the mobile communication network 10 there is also an address allocation system AAS 22 comprising a service record handler SRH 24, a resource manager RM 26 and a network address translator NAT 28, where the service record handler 24 is a device set to handle records associated with services, such as Virtual Network Functions (VNFs) implemented in network nodes. A service record handler may as an example be a Domain Name Server (DNS). The records may comprise service records and/or DNS records. The mobile communication network 10 may furthermore be a fifth generation (5G) mobile communication network.

Aspects of the disclosure will in the following be described in relation to functionality of the mobile communication network 10 having been moved to the cloud. However, the invention is not limited to being applied for a mobile communication network, but may for instance be applied for any type of network such as a computer network . The mobile communication network is thus merely one example of a network in which aspects of the disclosure may be used.

The base station 12, which is often termed eNodeB or just NodeB, is furthermore provided in a part of the mobile communication network 10 termed access network or radio access network, while the other devices and nodes are provided in a part of the mobile communication network 10 termed a core network, which in this example may be a so-called Evolved Packet Core (EPC) Network.

A user Ui of the mobile communication network 10 is equipped with the mobile station 30, often termed a terminal, via which he or she may communicate with other users and entities via the mobile communication network 10. The user Ui may for instance want to communicate with the external entity 32, for which a communication session maybe set up via the base station 12 and core network nodes. As mentioned earlier, the client 31, which maybe an application in the mobile station 30, is typically involved in this communication. A session may here be any type of communication such as a session involving a web browser used to visit a social media site, for instance for streaming media content from the media site, or a voice or video communication session, such as a voice or video conferencing session. The session may also be a session involving more than one data stream.

The SGW 16 is a node implementing a first realization of a container 33 for a service, which container comprises a number of services. There is here a first service SRV134 and a second service SRV2 36 in the container 33, where both services maybe Virtual Network Functions (VNFs). Although it is not shown in fig. 1 also the PGW 18 may be a node implementing a container comprising a number of services.

Fig. 2 schematically shows a second realization of the container 33, where in this case there is a first proxy sidecar PS1 38 associated with the first service 34. The second service has here been omitted. It should be realized that it is also possible with a second proxy sidecar associated with the second service.

Fig. 3 shows a block schematic of another way of realizing the node 16 implementing the container 33 for the services. It may be provided in the form of a processor PR 40 connected to a program memory M 42. The program memory 42 may comprise a number of computer instructions 43 implementing the functionality of the node, and especially for implementing the container for the services. The node thus comprises a processor 40 acting on computer instructions 43 for implementing the functionality of the node, which functionality comprises the functionality of providing a container for a service.

Fig. 4 shows a block schematic of one way of realizing the service record handler 24. The service record handler 24 may likewise be realized in the form of a processor PR 44 connected to a program memory M 46. The program memory 46 may comprise a number of computer instructions 47 implementing the functionality of the service record handler 24. The service record handler 24 thus comprises a processor 44 acting on computer instructions 47 for implementing functionality of the service record handler 24.

Fig. 5 shows a block schematic of an alternative realisation of the service record handler 24. It may comprise a Message Handling Unit MHU 48, a Message Analysing Unit MAU 50, an Address Obtaining Unit AOU 52 and a Record Handling Unit RHU 54.

The units and elements in Fig. 5 may be provided as software blocks for instance as software blocks in a program memory or as hardware blocks.

As mentioned earlier various types of processing is performed for a session, such as a communication and/or service session involving the mobile station 30 and the external entity 32, as well as for other types of activities in the communication network 10. Such processing maybe allocated to the cloud.

In this several instances of a service may be instantiated in the network nodes, such as SGW and PGW, and accessed by the client 31 in the mobile station 30 via the load balancer 14. These services maybe realized as virtualized network functions (VNFs) in containers, for instance using Kubernetes. Fig. 1 schematically shows two such services 34 and 36 provided in the container 33 in the SGW node 16. In a cloud system, one service is usually distributed to multiple instances of virtual machines or containers. These instances are dynamically created and destroyed. Incoming requests are forwarded to a service instance based on a load balancing decision by a traffic distributor, such as the load balancer 14. The services are thereby provided in a private addressing space, i.e. they have private Internet Protocol (IP) addresses and port numbers, while the traffic distributor is typically implemented in both the private and public addressing space, i.e. it has both public and a private IP addresses and port numbers, It is thereby possible to access a cloud service, such as the first service 34, using the load balancer 14, which may be seen as a proxy with a public IP address and a public port number.

As was mentioned earlier, it maybe desirable to allow the client 31 to directly access a service, such as service 34, However, the load balancer 14 is connected to multiple containers, and the external user of the cloud does not know beforehand which container he/she will access because the load balancer picks one randomly.

In order to be directly accessed from outside the private addressing space, the services would need to receive public addresses and port numbers, which typically requires the use of the network address translator 28. The service instances are therefore considered to be placed behind the network address translator 28.

For instance, in the case streaming of data (e.g. audio or video), it is very likely that a single stream needs to be handled by a single service instance. In the case of 5G, this may require that the service instance has a public IP address and a public port number (so-called no NAT requirement) and requests the stream to that specific address and port number. Kubernetes provides several different techniques to publish a service in a cluster such as: NodePort, LoadBalancer, ExternalName, and PortForwarding. However, none of these available options make it possible to publish a single instance of a specific service outside the cluster if the cluster is behind a NAT.

There is thus no easy way for the service (e.g., a container) or the client to learn the public IP address and public port number of the service instance when the service is behind a network address translator. The public IP address and the public port number can naturally be configured to the service when it is created, but this would normally require manual preconfiguration of the network address translator in order to make sure that the specified public IP address and public port number is allocated to the service correctly in the network address translator. This type of allocation is sometimes referred to as NAT allocation. This decouples NAT allocation and service configuration, which could potentially lead to insufficient usage of resources unless additional mechanisms are implemented to release the NAT allocation when the service no longer needs it. It would be better to dynamically allocate the NAT binding when the service requests it, and to free resources when the service does not need them anymore.

Kubernetes provides also other techniques to publish a service such as: NodePort, ExternalName, and PortForwarding. However, none of these available options make it possible to publish a single instance of a specific service outside the cluster if the cluster is behind a network address translator.

NAT traversal protocols (like STUN or ICE) cannot handle situations where both endpoints are using NAPT (which is common in Kubernetes environments). If, however, the solution proposed below is used, the service to be accessed can trigger the allocation of a publicly reachable address and port, in which case such NAT traversal protocols would not be needed.

There is thus a need for assigning a public IP address and a public port number to a service that is located behind a NAT.

Aspects of this disclosure are directed towards providing a node implementing a container for a service, a service record handler as well as a service accessing system comprising the service record handler and the node implementing a container for a service. The service accessing system may additionally comprise the network address translator and optionally also the resource manager of the address allocation system.

How this issue is addressed according to a first embodiment will now be described with reference also being made to fig. 6, 7 and 8, where fig. 6 shows a service message SM, fig. 7 shows a step in a method of triggering an allocation of a public IP address and port number for accessing a service and being carried out by the node implementing the container for the service and fig. 8 shows a number of method steps in a method of making a public IP address and public port number available for communications involving a service and being carried out by the service record handler.

The service record handler 24 typically has a group of service records for services with ongoing communication sessions, where such a service record has a service name and target name. These records may be records of services being set up or run on behalf of client devices. The target name is a name of the device or node harbouring the service and the service name is a name of the service including a service prefix, such as TCP (Transmission Control Protocol), UDP (User Datagram Protocol) or Stream Control Transmission Protocol (SCTP). The node may have dynamically created the service 34 in the container 33 The service 34 when created may additionally only be set to communicate using IP addresses and port numbers in a private addressing space of the communication network 10. There may thus initially be no way for the client 31 to directly access the service 34.

The operation may start by the node implementing the service 34, which in this case is the SGW 16, sending a service message SM 55 concerning the service 34 to the service record handler 24 in the address allocation system 22, step 56, which service message SM maybe a service query (SRV query) or a service update request (SRV update request). The service message 55 is sent in a private addressing space of the mobile communication network 10 and therefore comprises a private destination IP address PRAD and a private destination port number PRPD of the service record handler 24 and a private source address PRAS and a private source port number PRPS associated with the service 34. The private source address PRAS and private source port number PRPS may additionally be a private IP address and a private port number of the container 33. Furthermore, the service message 55 may be sent by the first service 34 itself. The service message 55 is a service message that has a payload PL or content, which content identifies the message as being a request for public IP address and public port number allocation to the service 34. Thereby the content is a trigger for the service record handler 24 to obtain a public IP address and a public port number for the service 34. Such triggering information is thus coded into the payload PL of the service message 55.

The service message 55 is then received by the message handling unit 48 of the service record handler 24, step 60. which service message 55 is thus received from the node implementing the container 33 for the service 34. The message handling unit 48 then provides at least the payload PL of the message 55 to the message analysing unit 50. The message analysing unit 50 analyses the payload PL or content of the service message SM for assessing whether the service message 55 is a request to allocate a public IP address and public port number to the service 34, step 62, i.e. if to determine if the service message 55 is a request to allocate an IP address and a port number in a public addressing space. The analysis thus involves an analysis of the payload PL.

As was mentioned above, the service message SM may be a service query (SRV query) or a service update request (SRV update request), where an SRV query comprises a service name having a service prefix, while a SRV update request comprises a service record comprising a service name also having a service prefix and a target name.

In the case of an SRV query the service name is investigated, while in the case of an SRV update request the target name is investigated.

An SRV update request is considered to be a request to allocate a public IP address and a public port number if the target name field has a pre-defined port setting that represents a request for public IP address and public port allocation. According to one variation a zero port number is such a predefined port setting.

An SRV query may on the other hand be considered to be a request to allocate a public IP address and a public port number if the service message is a service query for which the service prefix is missing in the service records of the group of service records.

Both types of service messages are triggers for the service record handler 24 to initiate the obtaining of a public IP address and a public port number for the service.

If the service message SM is found to have content forming such a trigger, i.e. is considered to be a request for allocation of a public IP address and a public port number for the service, the address obtaining unit 52 continues and obtains a public IP address and a public port number for the service 34, step 64.

The obtaining may involve the address obtaining unit 52 sending a request for allocation of a public IP address and a public port number for the service, which request is destined for the network address translator 28, and receiving a public IP address and public port number allocated to the service as a response to the request.

More particularly, the obtaining may involve the address obtaining unit 52 requesting the address and port number from the resource manager 26, which may then reserve an IP address and a port number for the service 34 and send a request for the public IP address and public port to the network address translator 28. The network address translator 28 may then allocate a public IP address and a public port number to the service 34, i.e. an IP address and a port number in the public addressing space, and return this to the resource manager 26, which in turn may send the allocated public IP address and public port number to the record handling unit 54 of the service message handler. It can in this case thus be seen that the sending, by the service record handler 24, of a request for allocation of a public IP address and a public port number that is destined for the network address translator maybe made to the resource manager 26, thereby triggering the resource manager 26 to request and receive an allocated public IP address and public port number from the network address translator 28 and forward them to the service record handler 24.

The service record handler 24 then makes the obtained public IP address and public port number available for communications involving the service 34, step 66. It thus makes the public IP address and public port number available for use in communications to and from the service, This may involve the record handling unit 54 creating at least one record for the service 34 comprising the public IP address and the public port number. One such possible record is a service record that includes the public port number and another such record is a Domain Name Server (DNS) record for the service including the public address. Through the creation of the service record and/or the DNS record, a querying entity, such as a node or device where the client 31 is provided or the node implementing the container 33 for the service 34, may send at least one query to the service record handler 24 about the at least one record and thereby obtain the public IP address and public port number.

It is thereafter possible for the client 31 to directly access the service without having to go through the load balancer 14. With this scheme, the user knows exactly which container he/she will access, and no load balancer is really needed.

The service may as an example be responsible for handling one of a number of media streams that the client may access. The service may for instance be a conferencing application that needs to combine multiple video streams with accurate sync (between the different streams as well as lip-syncing the audio and video). Modifying multiple streams is easier if all the related streams are handled in the same service instance (container or virtual machine).

One example would be a sporting event or a musical event, where multiple streams are sent from different angles and a user could select which stream(s) heor she is willing to see. The streams could be combined in cloud, so user does not need to have anything more sophisticated than an Internet browser, because hoe or she only receives one video stream. Also, network usage could be saved, because it wouldn’t require sending of multiple video streams. Now a second embodiment will be described with reference being made to fig. 9, which shows the payload of a service message realized as a service update request SRV U, to fig. 10 which shows a flow chart of a number of methods steps in a method of triggering an allocation of a public IP address and port for accessing a service and being performed by the node implementing the container for the service, to fig. 11 that schematically shows a flow chart of a number of steps in the method of making a public IP address and public port number available for communication involving a service and being performed by the service record handler and to fig. 12 that shows a signalling chart with signals exchanged between nodes in or connected to the communication network.

The node implementing the container 33, which node again is the SGW 16, sends a service update request SRV U 94 concerning the service 34 to the service record handler 24 of the address allocation system 22, step 71, where the request is a message with a payload PL 67 that includes a service record SRVR 68. The service record 68 in turn comprises a service name SRVN 69 and a target name TN.

The service name may as an example look like: sip.udp.myserver.mycloud.net, where udp is the service prefix.

The target name may in turn look like: x target_container.private.net, where x is a port setting, preferably as one or more integers. If this port setting is a pre-defined port setting, the message represents a request for public IP address and public port allocation to the service. As was mentioned earlier, the pre-defined port setting may be a port number setting of zero. It is thus possible that x = o.

Through this pre-defined port setting the message 94 triggers the service record handler 24 to obtain a public IP address and a public port number for the service 34, It can thereby also be seen that the obtaining of a public IP address and a public port number for the service 34 is based on the service record SRVR.

As in the first embodiment the message handling unit 48 of the service record handler 24 receives the service message 94, step 80, which service message is thus the SRV update request SRV U

Thereafter the message analysing unit 50 analyses the content or payload 67 of the service message 94 for assessing whether it is a request to allocate a public IP address and public port number to the service 34, which analysis thus involves analysing the port setting of the service record SRVR. If the service record SRVR has the pre-defined port setting it represents a request for public IP address and public port number allocation to the service 34. The service message is thus analysed and considered to be such a request to allocate a public IP address and public port to the service 34 if the message analysing unit 50 detects that the service record SRVR comprises the pre-defined port setting in the target name TN, step 82, which pre-defined port setting according to the given example is a zero port number.

The address obtaining unit 52 then proceeds and obtains a public IP address and a public port number for the service 34 if the service message 94 is considered to be a request to allocate a public IP address and public port to the service 34. This may involve the address obtaining unit 52 sending a request REQ 96 for allocation of a public IP address and a public port number to be made by the network address translator 28, step 84, and receiving a public IP address and public port number allocated to the service 34 by the network address translator 28, step 86, which sending is thus made if the service message 94 is considered to be a request to allocate a public IP address and public port number to the service. The sent request is thus destined for the network address translator 28, which then performs the allocation and returns it as a response to the request. As described earlier the request 96 maybe sent to the resource manager 26, which may in turn send an instruction 98 to the network address translator 28 to allocate the actual public IP address and public port number and then receive the allocated public IP address and public port number in an acknowledgement message 100. The resource manager 26 may thereafter return the public IP address and public port number to the record handling unit 54 of the service record handler 24 in a response message 102.

The record handling unit 54 then makes the obtained public IP address and public port number available for use in communication involving the service 34, i.e. in communcaiton to and from the service 34, which maybe done through the creating of at least one record comprising the public IP address and the public port number, step 88.

It is for instance possible that a DNS record comprising the public IP address and a service record comprising the public port number is created. It is additionally possible that the service record handler, when creating at least one record sends an acknowledgement ACK SRV U 104 of the service update request SRV U 94.

The public IP address and public port number may then be queried by a querying entity, which querying entity may be the node implementing the container for the service or a client device desiring to access the service. 2b

Such a client device may be a user terminal of the communication network. Alternatively, the client device may be a node implementing the container for another service. The querying device may send at least one query to the service record handler and may receive the public IP address and the public port number as at least one response to the at least one query. The at least one query may comprise a service query, the response to which comprises the public port number. The at least one query may additionally or instead comprise at least one domain name query, the response to which is the public IP address.

The record handling unit 54 of the service record handler 24 may thus receive at least one query from a querying entity such as the node implementing the container for the service or the client device. The record handling unit 54 of the service record handler 24 then sends the allocated public IP address and the public port number to the querying entity, which sending may be made as at least one response to the at least one query received from the querying entity. The record handling unit thus sends the allocated public port number to the requesting entity, step 90. It also sends the allocated public IP address to the querying entity, step 92. It is additionally possible that the public port number is sent as a response SRV R 108 to a service query SRV Q 106 and the public IP address is sent as a response DNS R 112 to a DNS query no.

In case the querying entity is the node implementing the container 33 for the service 34, this node thus receives the public port number from the service record handler 24, step 72. The querying entity also receives the public IP address from the service record handler 24, step 74. The public port number maybe received as a response SRV R 108 to a service query SRV Q 106 and the public IP address maybe received as a response DNS R 112 to a DNS query 110. The querying entity may thus send a service query 106 and a DNS query 110 to the service record handler 24 in order to receive the public port number and the public IP address. It is thereafter possible for the node to register 114 the service 34 at the client 31 using the public IP address and public port number, step 76.

As the service record handler 24 may create a DNS record, it is realized that it maybe a DNS server although as will be mentioned later, it should be known that the service record handler may 24 be realized in a different way.

Put differently the operation of the second embodiment may be described in the following way with reference being made to the signalling chart in fig. 12.

1. The Service 34 makes an SRV update request SRV U 94 and sends it to the service record handler 24. The content of the SRV update request 94 is filled according to the configuration of the service 34, i.e., the service has a name, it listens to either TCP or UDP, it is part of a domain etc. However, the port field is set to a zero value and the target part has the following format: external_< service_name > . <port > . < domain > . where <service_name> is the name of the service, <port> is the port the service listens to, and < domain > the domain configured for the service.

For example: external_sip . o . example .com.

It should be noted that the standard SRV update process can be protected by requiring a key from the client in order to prevent an unauthorized client from sending updates, and the required key can be preconfigured to the service.

2. The service record handler 24 detects the SRV update SRV U 94 with a zero value in port, which initiates the process of allocating a public IP address and a public port number for the service 34. A DNS server, such as CoreDNS, can for example be extended with plugins to provide the required, additional functionality to perform this detection and initiate the process when required. The service record handler 24 requests REQ 96 a new public IP address +public port allocation from the Resource Manager 26. In the request 96, the service record handler 24 may include the source address of the initial SRV update message and the port number of the service port, encoded in the target field of the SRV update message.

3. The Resource Manager 26 is responsible for keeping track of available IP addresses and ports. It can be implemented as part of the Kubernetes network plugin or in another component that is aware of the available resources. The Resource Manager 26 reserves an IP address and port for the service. It then sends a request 98 to the network address translator 28 to allocate the reserved resources.

4. The process of requesting the allocation of a public IP address and public port number from the network address translator 28 can be done with standardized protocols such as Port Control Protocol (PCP)[rfc6887] or Universal Plug and Play (UPnP). These protocols can be used to program the network address translator 28 in order to reserve a public IP address and public port number for the service 34. The network address translator 28 needs to be configured for the IP address and port of the service 34 in order to create a required mapping between the public port and the private port. The source address of the initial SRV update message 94 specifies the private IP address of the service (as observed by the service record handler 24) whereas the private port is encoded in the target field of the SRV update message 94.

5. The Resource Manager 26 returns 102 the allocated public IP address and public port number to the service record handler 24. The service record handler 24 uses the public IP address in order to create a new DNS entry (i.e. a record) for the target host, and the target host is the value of the target field from the SRV update message 94. Next, the service record handler 24 creates an SRV record by using the values provided in the SRV update message 94 and the public port value received from the Resource Manager 26. Upon completion, the service record handler 24 acknowledges 104 the SRV update request back to the service. The service 34 makes an SRV query SRV Q 106 for its own SRV- prefix to learn the allocated public port (because this information cannot be included in the standard SRV UPDATE acknowledgment message sent in the previous step). The service record handler 24 returns the requested SRV record in the SRV response SRV R 108, which contains the target and the public port allocated for the service 34. The service 34 makes a DNS query, DNS Q no, in order to learn the public IP address allocated for it by using the value in the target field of the received SRV record (because, again, it is not possible to include this information in the earlier SRV UPDATE acknowledgement message 104). The service record handler 24 replies with the public IP address allocated for the service in the DNS response DNS R 112. The service 34 can now use the acquired information (public or external IP address and public or external port number) to publish its location (i.e. so-called self-registration 114) using some external mechanism. If the service record handler 24 described here is a DNS server that supports publishing record also externally, then the fully qualified domain name (FDQN) or some other record could be used (naturally the client connecting to the service must utilize the SRV record). The SRV registration has a lifetime value that defines when allocated information is released. In order to avoid expiration, the service 34 can refresh the allocation by sending a new SRV update message before the old registration expires. The service 34 should then fill in the port field in the SRV message, because there is no need to create a new allocation. It should also be noted that the service may be responsible for keeping the NAT state alive.

As was mentioned earlier, it is possible to instead use an SRV query to trigger an allocation of a public IP address and a public port number. How this can be done according to a third embodiment will now be discussed with reference being made to the signalling chart in fig. 13.

In this case the node implementing the service 34 uses a first SRV query SRV Qi 116 instead of an SRV update SRV U to trigger the allocation of public IP address and public port number. In this approach, the service record handler 24 investigates a service name of the SRV query 116, which service name may be provided in the payload of the service query 116.

The service name may as was mentioned earlier look like: sip.udp.myserver.mycloud.net, where udp is the service prefix.

If no SRV record for the service name having the prefix udp can be found among the service records of the service record handler 24, i.e. if no existing SRV record for the specified SRV-prefix in the first SRV query SRV Qi 116 is found among the service records of the service record handler 24, then the SRV query 116 is considered to be a trigger for the service record handler 24 to obtain a public IP address and a public port number for the service 34.

Thereafter the service record handler 24 obtains a public IP address and public port number for the service 34. This may be done in the same way as was described above through communicating 118 and 124 with the resource manager 26, which in turn communicates 120 and 122 with the network address translator 28.

It is then possible for a querying entity to obtain the public IP address and public port number from the service record handler 24. This may be done in the same way as in the second embodiment through the querying entity sending an SRV query, here a second SRV query SRV Q2 128 to the service record handler 24 and receive the public port number as a response SRV R 130. The querying entity can also send a DNS query DNS Q 132 to the service record handler 24 and receive the public IP address of the service in a response DNS R 134.

As can be seen in fig. 13, the querying entity is the client 31 in the third embodiment.

However, it should be realized that in a variation of this third embodiment, the querying entity may again be the node implementing the service 34, here exemplified by the SGW 16. SRV Qi 116 may query the public port number. The node implementing the container may thereby learn the public port number of the service through the response 126 to the service query SRV Qi 116. The node can then learn the public IP address through a DNS response to a DNS query that is directly sent to the service record handler 24. There would thus be no need for the second SRV query if the node implementing the service 34 is the querying entity. This would remove the need to send an additional request to learn the port number when the resources are allocated. Thereby the roundtrip time can be reduced compared with the second embodiment. The trade-off in this optimization is related to security; SRV queries, unlike SRV updated messages, do not require a key. Therefore, in this case, it may be desirable that only SRV queries originating from the service will trigger the process based on access control mechanisms.

In order to distinguish a query of an expired SRV record from the case of adding a new entry, the following format could, e.g., be used to explicitly trigger the creation procedure: create_external_<service_name>.<port>.<domain>. The SRV entry, however, would be created with external_< service_name > . <port > . < domain > .

There are a number of variations that can be made of the above-mentioned embodiments. It is for instance possible that the querying entity is the client device in the second embodiment. The service may additionally be provided in another network node than the SGW, such as in the PGW. The client is also not limited to being provided in a mobile terminal. The client can in fact be another service because sometimes services are connecting to other services to consume them.

Below are some examples of client device and node implementing container for the service: a) client: web service (back-end), service: database b) client: web front-end, service: web back-end c) client: microservicei, service: microservice2 d) client: (containerized/virtualized) network functioni, (containerized/virtualized) service: network function2 Consider case d) I should also note that it is possible that a "client" could also implement "service" functionality (e.g. open a port in NAT) if it is part of a service chain or Network Service Mesh, and the different parts of the service chain are located in different, NATted networks:

[a: client] — > [b: service + client] — > [c: service]

From what is stated above, it is evident that the communication network is not necessarily a mobile communication network, but may for instance be any type of computer network where communication is implemented. The communication can additionally be between a server and a database.

Above the container technology used was Kubernetes, which is Linux based, It should be realized that a container does not have to be a Linux container. It may be realized using other technologies. It may for instance be realized as a virtual machine, unikernel or perhaps even a serverless function (= Function as a Service).

The Resource manager could be realized/implemented alternatively, e.g., as an SDN controller. In such a case, the service record handler could be an OpenvSwitch, and then the protocol between the OpenvSwitch and SDN controller and NAT could be, e.g., OpenFlow, In such a case, the communication protocol between resource manager and network address translator could be, e.g., OpenFlow, P4 or NETCONF

The realization in fig, 2 is a so-called sidecar realization, where the functionality of handling the obtaining of a public IP address and public port number can be implemented as a so-called proxy sidecar, which runs in the same pod as the service itself. This has the benefit of not having to embed the required functionality in the service itself. The sidecar would also be responsible for refreshing the SRV registration to keep the allocation alive. In the sidecar approach, the service would trigger the allocation process by sending a request to a local port in the pod that the sidecar listens to. The sidecar service would then trigger the acquisition of a public address and port through the sending of a service message according to any of the above described types to the service record handler,

The "sidecar" approach could also be realized in a bit more optimized way, so that the port allocation procedures are ready when the container is started. This involves using an init container and some environment variables.

The computer program code for implementing a container for a service or a sidecar proxy may be provided in a computer program product for instance in the form of a data carrier, such as a CD ROM disc or a memory stick. In this case the data carrier carries a computer program with the computer program code, which will implement the above-mentioned container or sidecar proxy. One such data carrier 136 with the computer program code 43 is schematically shown in Fig. 14.

Also, the computer program code of the service record handler may be in the form of computer program product for instance in the form of a data carrier, such as a CD ROM disc or a memory stick. In this case the data carrier carries a computer program with the computer program code, which will implement the above-mentioned service record handler functionality. One such data carrier 138 with the computer program code 47 is schematically shown in Fig. 15.

In the service record handler • the message handling unit may be considered to comprise means for receiving a service message from a node implementing a container for a service,

• the message analysing unit may be considered to comprise means for analysing the content of the service message for assessing whether the service message is a request to allocate a public IP address and a public port number to the service,

• the address obtaining unit may be considered to comprise means for obtaining a public IP address and a public port number for the service if the service message is considered to be a request to allocate a public IP address and public port number to the service, and

• the record handling unit may be seen as comprising means for making the obtained public IP address and public port number available for use in communications involving the service.

The means for obtaining a public IP address and a public port number for the service may additionally comprise means for sending a request for allocation of a public IP address and a public port number destined for the network address translator if the service message is considered to be a request to allocate a public IP address and public port number to the service and means for receiving a public IP address and public port number allocated to the service from the network address translator as a response to the request.

The means for sending a request for allocation of a public IP address and a public port number that is destined for the network address translator may comprise means for sending the request to the resource manager, thereby triggering the resource manager to request and receive an allocated public IP address and public port number from the network address translator and forward them to the service record handler. The means for making the obtained public IP address and public port number available for use in communications involving the service may additionally comprise means for sending the allocated public IP address and the public port number to the querying entity, which means for sending the allocated public IP address and the public port number to the querying entity may additionally comprise means for sending the public IP address and the public port number as at least one response to at least one query from the querying entity. The means for sending the public IP address and the public port number as at least one response to at least one query from the querying entity may additionally comprise means for sending the public port number as a response to a service query and means for sending the public IP address as a response to a Domain Name Server Query.

While aspects of the present disclosure have been described in connection with what is presently considered to be most practical and preferred embodiments, it is to be understood that the disclosure is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various modifications and equivalent arrangements. Therefore, the disclosure is only to be limited by the following claims.

Claims

37 CLAIMS

1. A service record handler (24) of an address allocation system (22), the service record handler (24) comprising a processor (44) acting on computer instructions (47) whereby the service record handler (24) is operative to:

• receive a service message (55; 94; 116) from a node (16) implementing a container (33) for a service (34),

• analyse the content of the service message (55; 94; 116) for assessing whether the service message (55; 94; 116) is a request to allocate a public IP address and a public port number to the service (34),

• obtain a public IP address and a public port number for the service, if the service message (55; 94; 116) is considered to be a request to allocate a public IP address and public port number to the service (34), and

• make the obtained public IP address and public port number available for use in communications involving the service (34).

2. The service record handler (24) according to claim 1, the address allocation system (22) further comprising a network address translator (28), and where the obtaining of a public IP address and a public port number for the service comprises

• sending a request (96; 118) for allocation of a public IP address and a public port number destined for the network address translator (28) if the service message (55; 94; 116) is considered to be a request to allocate a public IP address and public port number to the service (34) and

• receiving a public IP address and public port number allocated to the service (34) from the network address translator (28) as a response to the request (96; 118).

3. The service record handler (24) according to claim 1 or 2, being further operative to send the allocated public IP address and the public port number to a querying entity (16; 30). 38

4. The service record handler (24) according to claim 3, wherein

• the public IP address and the public port number are sent as at least one response (108, 112; 130, 134) to at least one query (106, no; 128, 132) from the querying entity.

5. The service record handler (24) according to any previous claim, wherein the service message is a service update request (94) comprising a service record (68) with a port setting and the service message is considered to be a request to allocate a public IP address and public port number to the service if the port setting of the service record is a predefined port setting representing a request to allocate a public IP address and public port number to the service.

6. The service record handler (24) according to any of claims 1 - 4, wherein the service record handler (24) comprises a group of service records, and

• the service message is a service query (116) comprising a service name (69) with a service prefix and

• the service message is considered to be a request to allocate a public IP address and public port number to the service, if the service message is a service query for which said service prefix is missing in the service records of the group of service records.

7. The service record handler (24) according to any previous claim, wherein the service is a virtual network function.

8. A method of making a public IP address and public port number available for communications involving a service (34), the method being carried out by a service record handler (24) of an address allocation system (28) and comprising: • receiving (60; 80) a service message (55; 94; 116) from a node (16) implementing a container (33) for a service (34),

• analysing (62; 82) the content of the service message (55; 94; 116) for assessing whether the service message (55; 94; 116) is a request to allocate a public IP address and public port number to the service (34),

• obtaining (64; 84, 86) a public IP address and a public port number for the service if the service message (55; 94; 116) is considered to be a request to allocate a public IP address and public port number to the service, and

• making (66; 82) the obtained public IP address and public port number available for use in communications involving the service (34).

9. The method according to claim 8, wherein the address allocation system (22) comprises a network address translator (28) and the obtaining of a public IP address and a public port number for the service comprises

• sending (84) a request (96; 118) for allocation of a public IP address and a public port number destined for the network address translator (28) if the service message is considered to be a request to allocate a public IP address and public port number to the service and

• receiving (86) a public IP address and public port number allocated to the service as a response to the request (96; 118).

10. The method according to claim 8 or 9, further comprising sending (90, 92) the allocated public IP address and the public port number to a querying entity.

11. The method according to claim 10, wherein the querying entity is the node (16) implementing the container (33) for the service (34).

12. The method according to claim 10, wherein the querying entity is a client device (30) desiring to access the service (34).

13. The method according to any of claims 8 - 12, wherein the service message is a service update request (94) comprising a service record (68) with a port setting and the service message is considered to be a request to allocate a public IP address and public port number to the service if the port setting is a pre-defined port setting representing a request to allocate a public IP address and public port number to the service.

14. The method according to any of claims 8 - 13, wherein the service record handler comprises a group of service records, the service message is a service query (116) comprising a service name (69) with a service prefix and the service message is considered to be a request to allocate a public IP address and public port number to the service if the service message is a service query for which said service prefix is missing in the service records of the group of service records.

15. A computer program for making a public IP address and public port number available for communications involving a service, the computer program comprising computer program code (47) which when run by a processor (44) forms a service record handler (24) of an address allocation system (28), that is operative to:

• analyse the content of the service message (55; 94; 116) for assessing whether the service message (55; 94; 116) is a request to allocate a public IP address and public port number to the service,

• obtain a public IP address and a public port number for the service (34) if the service message is considered to be a request to allocate a public IP address and public port number to the service, and

16. A computer program product for making a public IP address and public port number available for communications involving a service, the computer program product comprising a data carrier (138) with computer program code (47) according to claim 15.

17. A node (16) implementing a container (33) for a service (34), the node comprising a processor (40) acting on computer instructions (43) whereby said node is operative to: send a service message (55; 94; 116) to a service record handler (24) of an address allocation system (22), said service message comprising content that identifies the message as a request for public IP address and public port number allocation to the service thereby triggering the service record handler (24) to obtain a public IP address and a public port number for the service.

18. The node (16) according to claim 17, wherein the service message is a service update request (94) comprising a service record comprising a pre-defined port setting that identifies the message as a request for public IP address and public port number allocation to the service.

19. The node according to claim 18, wherein the pre-defined port setting is zero.

20. The node (16) according to any of claims 17 - 19, being further operative to receive the public IP address and the public port number from the service record handler.

21. The node (16) according to any of claims 17 - 20, being further operative to send at least one query (106, no) to the service record handler (24) and receive the public IP address and public port number as at least one response (108, 112) to the at least one query (106, 110). 42

22. The node (16) according to claim 20 or 21, being further operative to register (114) the service at a client device (30) using the public IP address and public port number.

23. A method of triggering an allocation of a public IP address and public port number to a service, the method being carried out by a node (16) implementing a service (34) for a container (33) and comprising: sending (56; 70) a service message (55; 94; 116) to a service record handler (24) of an address allocation system (22), said service message comprising content that identifies the message as a request for public IP address and public port number allocation to the service, thereby triggering the service record handler (24) to obtain a public IP address and a public port number for the service.

24. The method according to claim 23, wherein the service message is a service update request (94) comprising a service record comprising a predefined port setting that identifies the message as a request for public IP address and public port number allocation to the service.

25. The method according to claim 24, wherein the pre-defined port setting is zero.

26. The method according to any of claims 23 - 25, further comprising receiving (72, 74) the public IP address and the public port number from the service record handler (24).

27. The method according to claim 26, further comprising registering (76) the service (34) at a client device (30) using the public IP address and public port number.

28. A computer program for triggering an allocation of a public IP address and a public port number to a service (34), the computer program 43 comprising computer program code (43) which when run by a processor (40) forms a node (16) implementing a service (34) for a container (33), which node (16) is operative to: send a service message (55; 94; 116) to a service record handler (24) of an address allocation system (22), said service message comprising content that identifies the message as a request for public IP address and public port number allocation to the service (34) thereby triggering the service record handler (24) to obtain a public IP address and a public port number for the service (34).

29. A computer program product for triggering an allocation of a public IP address and a public port number to a service, the computer program product comprising a data carrier (136) with computer program code (43) according to claim 28.

30. A service accessing system comprising a service record handler (24) of an address allocation system (22) and a node (16) implementing a container (33) for a service (34), the node (16) comprising a processor (40) acting on computer instructions (43) whereby said node is operative to; send a service message (55; 94; 116) to the service record handler (24), and the service record handler (24) comprising a processor (44) acting on computer instructions (47) whereby the service record handler (24) is operative to: receive the service message (55; 94; 116), analyse the content of the service message (55; 94; 116) for assessing whether the service message (55; 94; 116) is a request to allocate a public IP address and public port number to the service (34), obtain a public IP address and a public port number for the service if the service message (55; 94; 116) is considered to be a request to allocate a public IP address and public port number to the service (34), and 44 make the obtained public IP address and public port number available for communications involving the service (34).