WO2012056010A1

WO2012056010A1 - Method and system for controlling ip traffic in a service provider network

Info

Publication number: WO2012056010A1
Application number: PCT/EP2011/069015
Authority: WO
Inventors: Rolf Winter; Joerg Wagner; Andreas Ripke; Armin Jahanpanah
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2010-10-29
Filing date: 2011-10-28
Publication date: 2012-05-03
Anticipated expiration: 2013-04-29

Abstract

A method and a system for controlling IP traffic in a service provider network, wherein said service provider network (2) includes one or more switches (4a, 4b) for connecting service provider's customers (3) to the global Internet (5), and a Carrier Grade Network Address Translation (CGN NAT) device (1), which is configured to translate between private and public IP addresses, wherein the private side faces said service provider's customers (3), are characterized in that said service provider's customers (3) and/or said CGN NAT device (1) are enabled to select IP traffic according to configurable criteria, wherein selected IP traffic is routed such that it bypasses said CGN NAT device (1).

Description

METHOD AND SYSTEM FOR CONTROLLING IP TRAFFIC IN A SERVICE PROVIDER NETWORK

The present invention relates to a method and a system for controlling IP traffic in a service provider network, wherein said service provider network includes one or more switches for connecting service provider's customers to the global Internet, and a Carrier Grade Network Address Translation (CGN NAT) device, which is configured to translate between private and public IP addresses, wherein the private side faces said service provider's customers.

Internet Service Providers (ISPs) face a significant operational problem once IPv4 addresses run out. With IPv6 not being universally available in the foreseeable future, there seems no way out other extending the lifetime of IPv4 for a little longer until all Internet stakeholders have migrated to IPv6. One approach to extend IPv4's lifetime are NATs, however this time, they are not installed at the customer-end of the network (e.g. enterprises, broadband home customers etc.) to connect customers to a service provider, but they are installed within the operator network with the private side of the NAT facing the service provider's customers. Hereinafter, these NATs are referred to as carrier-grade NATs, briefly CGN NAT, although sometimes in the literature one can also find the denotation "large-scale NAT".

Although on the one hand CGN NATs are an efficient mechanism for economizing the deployment of scarce public, globally unique IPv4 addresses, since they enable service providers to assign to their customers private IP addresses instead, there are on the other hand numerous problems with these devices. For instance, there is no control over which ports are being used and how they are used, which makes it difficult to e.g. host services at the customer-end or troubleshoot network connectivity problems. For home customers this might often not be a problem but many other customer groups and technology-sawy users might not be satisfied with such a solution. Furthermore, some applications make use of IP addresses in the payload and NAT complicates the operation of these protocols or even breaks them. The easy answer to the above problems would be to give a public IP address to these customers, but with the current rate of IPv4 address depletion this answer will soon not be viable any more.

Another problem is user diversity. Some heavy users consume a huge amount of ports whereas others only consume very little. Some cause a huge amount of traffic and others don't. An operator might want to restrict the usable port range, charge on excessive port consumption or distinguish between different tariffs. However, with today's way of using CGN NAT, no individual handling of different users is possible.

A more general problem is of performance. In contrast to an individual NAT implemented in customer premise equipment, a carrier-grade NAT serving many customers at once needs to store a huge amount of mapping state and needs to operate on much higher bandwidth scales. These requirements will render the device slow, expensive or both. Some delay in packet delivery might be acceptable for home users but if a service is hosted at an enterprise there should be no such delay.

It is therefore an object of the present invention to improve and further develop a method and a system for controlling IP traffic in a service provider network of the initially described type in such a way that the aforementioned problems are eliminated or at least significantly ameliorated and that a flexible and individual control over diverse IP traffic flows is achieved.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method is characterized in that said service provider's customers and/or said CGN NAT device are enabled to select IP traffic according to configurable criteria, wherein selected IP traffic is routed such that it bypasses said CGN NAT device.

Furthermore, the above mentioned object is accomplished by a system comprising the features of claim 16. According to this claim such a system is characterized in that said service provider's customers and/or said CGN NAT device are enabled to select IP traffic according to configurable criteria, wherein selected IP traffic is routed such that it bypasses said CGN NAT device.

According to the invention it has been recognized that the above mentioned problems mainly result from the fact that the entire IP traffic within the service provider network is treated equally. Therefore, the present invention proposes a selection mechanism that allows service provider's customers and/or the CGM NAT device itself to select certain traffic according to configurable criteria. Typically, in case of customers this will be some kind of "premium" traffic the customer considers to be of high priority, for instance because it pertains to a service hosted by the customer's enterprise, e.g. the traffic of a Web server operated by the customer. According to the invention such selected traffic is routed such that it bypasses the CGN NAT device. In other words, the customers are given native IP connectivity by bypassing the CGN NAT device for a particular selected service. By isolating the associated traffic in such a way the above mentioned known limitations of NAT are widely avoided. Furthermore, operation and control of a carrier-grade NAT in accordance with the present invention allows to separate low and high-priority traffic by bypassing the NAT device, resulting in higher performance, isolation of traffic and improvement of the troubleshooting situation.

With respect to the present invention it is important to note that, typically, the switches process packets much faster than the CGN NAT device. Because of the pass-through no packet re-writing will be performed, which will eliminate the problems associated with NAT and will make connectivity troubleshooting easier. The memory limitation of current switches will be no problem as there should be far less services that need pass-through entries compared to the NAT states. Handling traffic to the NAT device is handled on the switches by a single entry (default). Together this idea will decrease the delay and isolates the specific traffic from problems on the NAT.

To summarize, the present invention provides a new method and system that allows to separate different kinds of traffic, e.g. low and high-priority traffic, for performance and isolation reasons by selectively and dynamically bypassing a CGN NAT device using appropriate switches to obtain native IP connectivity for services to customers that are otherwise behind the CGN NAT device. With this innovation, it is easy to provide customers an interface to offer services which are automatically provisioned in the NAT system, with the added benefit that the traffic belonging to their service is treated in a special way that ensures native IP, isolated traffic, and high performance.

According to a preferred embodiment it may be provided that the service provider network includes a switch that connects the service provider's customers with the network. Hereinafter, this switch will be denoted "customer facing switch", corresponding to its location within the service provider network and corresponding to its functions. In addition, it may be provided that the service provider network includes a further switch that connects service provider's customers to the global Internet. Correspondingly, hereinafter this switch will be denoted "Internet facing switch".

As will be appreciated by a person skilled in the art, the customer facing switch and the Internet facing switch could, in principle, even be the same switch being configured in a loop-back connection, depending on the switch design. Moreover, it would even be possible to deploy a high-power switch that is logically partitioned into two independent ones.

In any case, in a preferred embodiment it may be provided that the CGN NAT device is located between the customer facing switch and the Internet facing switch. Based on this architectural design it is possible that all traffic that traverses the switches is directed to the CGN NAT device. For instance, this could be realized by setting the default switching entries of the switches accordingly, such that they pass - by default - all incoming IP traffic to the CGN NAT device.

With respect to an efficient and flexible possibility of controlling switching entries of the switches it may be provided that the switches of the service provider network are programmable flow-based switches. For instance, OpenFlow switches could be deployed. Advantageously, the controller may be provided within the service provider network, which on the one hand is logically connected to the involved switches of the service provider network in which on the other hand it is logically connected to the CGN NAT device. By exchanging appropriate control traffic with the switches and with the CGN NAT device, as will be explained in detail below, the controller may effectuate CGN NAT device bypassing for specific traffic.

In a first embodiment, CGN NAT device traffic bypassing may be realized in situations in which selected IP traffic belongs to a specific customer side service. For instance, such situations may occur when a service provider's customer wishes to isolate certain "premium" traffic, which e.g. pertains to services hosted on the customer side, from other less vital traffic. To this end it proves to be advantageous that the controller includes a web interface for customer login. However, in other embodiments alternative means may be provided that allow a customer to login to the controller. After successful login, in a next step, it may be provided that the customer is enabled to request at the controller a public IP address and a port for the selected traffic.

In a second embodiment, CGN NAT device traffic bypassing may be realized in situations in which IP traffic is selected by the CGN NAT device itself with the objective to offload the selected IP traffic from the CGN NAT device, for instance because it is currently operating under high load. In this case it may be provided that the CGN NAT device sends a respective notification to the controller.

In both cases, it may be further provided that the controller, upon receiving such notification/request, installs suitable flow entries within the involved switches. More specifically, the controller may prompt the Internet facing switch to install a respective flow entry for IP traffic belonging to the selected customer side service, such that all such traffic from the Internet is directed directly through the customer facing switch, thus bypassing the CGN NAT device. On the other end, the controller may prompt the customer facing switch to install a flow entry that directs the selected traffic directly through the Internet facing switch, thus also bypassing the CGN NAT device. Advantageously, in case of service provider's customer requests the controller, before performing any flow entry installations, may check with an AAA server whether the requesting customer is authorized to do so. For instance, in this context it could be checked whether the customer's actual tariff includes the authorization to execute such actions or, if not, whether the customer is willing/potential to pay more for a premium traffic isolation as described above.

According to a still further embodiment it may be provided that the service provider offers value-added managed services with respect to the traffic of a selected customer side service that circumnavigates the CGN NAT device. For instance, with respect to a service a customer wishes to host at his premises, the service provider could program the switches, in particular the customer facing switch and the Internet facing switch, in such a way that they first redirect traffic/flows of the selected service through a firewall and/or intrusion detection system. As a result, such a firewall and/or intrusion detection system would then not need to be hosted by the customer himself. Instead, the customer could therefore easily outsource the services to the service provider.

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 claims 1 and 16 on the one hand, and to the following explanation of a preferred example of an embodiment of the invention illustrated by the drawing on the other hand. In connection with the explanation of the preferred example of an embodiment of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawings the only

Fig. schematically illustrates a carrier-grade NAT architecture in accordance with an embodiment of the present invention.

Carrier-grade NAT technology is currently being standardized within the IETF. At the moment the NAT "flavor" is the main focus. "Flavor" here refers to aspects such as address ranges used in certain parts of the network and related issues. Today carrier-grad NAT is already in use in countries or areas where a high mis- ratio between a provider's public IP range and the number of (potential) customers is faced, e.g. India, China but also some ISPs in highly developed countries start offering Internet connectivity behind NAT devices.

There are protocols currently being specified on how to control the port allocation on a CGN NAT device (http://tools.ietf.org/html/draft-wing-softwire-port-control- protocol-02) to e.g. enable to host services on the customer side. However, according to the present invention it has been recognized that hosting services through the same device where other, less vital traffic, passes through is not optimal for two main reasons: The traffic from services (such as web servers, mail servers etc.) is not well isolated on the CGN NAT device. That means that performance problems on a complex device such as a CGN NAT will impact these important services as well and thus provide an additional attack vector for hostile Internet users. Instead of attacking the server behind the CGN NAT device (e.g. via DOS) just overloading the NAT device would be sufficient and far more difficult to detect from the server-side. Secondly, a CGN NAT device introduces delay as it is difficult to implement efficiently everything needed in HW as huge amounts of state information must be kept if many customers are to be put behind the same CGN NAT device. With carrier-grade NAT such a scenario is the norm rather than the exception. In addition to these two important reasons there are also well known problems with carrier-grade NAT that might cause connectivity problems.

The present invention avoids these problems by allowing certain selected traffic to bypass the CGN NAT device. Basically, the present invention relates to a technology and connection design as depicted in the Fig., which allows traffic bypassing and/or traffic offloading from a CGN NAT device 1 in a service provider network 2. As mentioned already above, in order to avoid the problematic issues arising from NAT'ing, it is beneficial to bypass the CGN NAT device 1 for selected services, e.g. services that are hosted by customers 3 (for instance a web server), and have other traffic from customers 3 still passing the CGN NAT device 1 (e.g. from desktop computers). According to the present invention these issues can be handled in a configurable and dynamic way, as will be explained in detail below. ln the specific embodiment illustrated in the Fig., customers 3 are connected to a programmable flow-based switch (such as an OpenFlow switch), which hereinafter is denoted customer facing switch 4a. The default switching entry in the customer facing switch 4a is to pass all traffic to the CGN NAT device 1 . This means that, e.g., home customers' traffic or the traffic of desktop computers in enterprises will all go through the CGN NAT device 1 . Behind the CGN NAT device 1 is another flow-based switch, Internet facing switch 4b, which connects the customers 3 to the global Internet 5. In principle this could even be the same switch as switch 4a in a loop-back connection, depending on the switch design. Alternatively, it would be possible to deploy a single big switch, which is logically partitioned into two independent ones. In any event, the Internet facing switch 4b will also per default direct all traffic coming in from the Internet 5 to the CGN NAT device 1 , thereby establishing connectivity for all customers 3.

Now assume a customer 3 wanted to add a web server. The traffic for this server should not go through the CGN NAT device 1 for reasons mentioned above. It is noted at this point that this is very different for example from the technology described in http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol-02. In order to realize CGN NAT device 1 bypassing, the service provider network 2 includes a controller 6 that is logically connected to both the CGN NAT device 1 and the customer and Internet facing switches 4a, 4b, respectively.

Although not explicitly shown in the Fig., the customer 3 can login to the controller 6 (e.g. through a web interface) and request an IP and port for this. If the customer's 3 tariff allows or if he is willing to pay more, which can be checked, for instance, with an AAA (Authentication, Authorization, Accounting) server 7, the respective flow entries are set inside the flow-based switch(es) 4a and 4b. The Internet-facing switch side 4b will install an entry to direct all traffic from the Internet 5 to the new server (identified by IP, Port and protocol number) directly through the customer-facing switch 4a, thus bypassing the CGN NAT device 1 . The customer-facing switch 4a will install an entry that directs all traffic from the new server directly through to the Internet-facing switch 4b, thus also bypassing the CGN NAT device 1 . As a result, having control over the way traffic flows and on which port services are hosted by end customers, significantly helps to mitigate various problems traditionally associated with carrier-grade NAT'ing. This also includes visibility of the NAT state and potentially setting permanent NAT table entries if the respective customer's tariff allows. For instance, if a business customer wanted to add a new server to his network, which should be reachable over the Internet, a fixed NAT table entry usually needs to be added.

So far, circumvention of the CGN NAT device 1 has been described only from a customer's point of view. However, there might be situations in which it is the CGN NAT device 1 itself that wishes to get rid of certain traffic. Therefore, the present invention not only envisions customer initiated bypassing, but also CGN NAT device 1 initiated traffic off-loading. Referring again to the Fig., for a limited amount of selected traffic off-loading can be performed directly within the switches 4a, 4b. Specific NAT functionality like IP and/or port rewriting can be executed on the assigned switches 4a, 4b, as long as their memory is not exhausted. Therefore, within the illustrated configuration dynamic traffic off-loading, e.g. whenever a CGN NAT device 1 is under high load, is made possible. To this end the CGN NAT device 1 could signal having high load to the controller 6 which installs respective entries in the flow-based switches 4a, 4b to off-load the CGN NAT device 1 for selected and specific flows. Care needs to be taken of course in case of DoS attacks, but this could be a configuration issue. The flow switches 4a, 4b need to provide packet re-writing capabilities for this, which is available for example in OpenFlow based switches. In any event, relieving the CGN NAT device 1 from traffic in cases of high load conditions makes it more stable.

Another nice feature about the above depicted design is the ability for the operator to sell value-added managed services 8 to customers 3 that want to host services at their premises. E.g. the flow based switches 4a, 4b could first redirect flows through a firewall or intrusion detection system, which then does not need to be hosted by the customer. A customer 3 could therefore easily outsource these services to the operator. 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.

Claims

C l a i m s

1 . Method for controlling IP traffic in a service provider network, wherein said service provider network (2) includes one or more switches (4a, 4b) for connecting service provider's customers (3) to the global Internet (5), and a Carrier Grade Network Address Translation (CGN NAT) device (1 ), which is configured to translate between private and public IP addresses, wherein the private side faces said service provider's customers (3),

c h a r a c t e r i z e d i n that said service provider's customers (3) and/or said CGN NAT device (1 ) are enabled to select IP traffic according to configurable criteria, wherein selected IP traffic is routed such that it bypasses said CGN NAT device (1 ).

2. Method according to claim 1 , wherein said one or more switches include a switch - customer facing switch (4a) - for connecting service provider's customers (3) to said service provider network (2).

3. Method according to claim 1 or 2, wherein said one or more switches include a switch - Internet facing switch (4b) - for connecting service provider's customers (3) to the global Internet (5).

4. Method according to claim 3, wherein said CGN NAT device (1 ) is located between said customer facing switch (4a) and said Internet facing switch (4b).

5. Method according to any of claims 1 to 4, wherein the default switching entries of said one or more switches (4a, 4b) is to pass all incoming IP traffic to said CGN NAT device (1 ).

6. Method according to any of claims 1 to 5, wherein said one or more switches (4a, 4b) are programmable flow-based switches.

7. Method according to any of claims 1 to 6, wherein CGN NAT device (1 ) bypassing is realized via a controller (6) that is logically connected to said one or more switches (4a, 4b) and to said CGN NAT device (1 ).

8. Method according to any of claims 1 to 7, wherein selected IP traffic belongs to a specific customer side service.

9. Method according to claim 7 or 8, wherein said controller (6) includes a web interface for customer login.

10. Method according to any of claims 7 to 9, wherein said controller (6) is configured to receive a notification from a service provider's customer (3) requesting the assignment of a public IP address and port for a selected customer side service.

1 1 . Method according to any of claims 7 to 10, wherein said controller (6) is configured to receive a notification from said CGN NAT device (1 ) requesting to off-load selected IP traffic from said CGN NAT device (1 ).

12. Method according to 10 or 1 1 , wherein said controller (6), upon receiving such notification, installs flow entries within said customer facing switch (4a) and said Internet facing switch (4b) for said selected IP traffic to bypass said CGN NAT device (1 ).

13. Method according to claim 12, wherein said controller (6), before performing flow entry installations, checks the authorization of the requesting customer with an AAA server (7).

14. Method according to any of claims 1 to 13, wherein said service provider offers value-added managed services (8) with respect to the traffic of a selected customer side service that circumnavigates said CGN NAT device (1 ).

15. Method according to any of claims 1 to 14, wherein said one or more switches (4a, 4b), in particular said customer facing switch (4a) and said Internet facing switch (4b), redirect traffic of a selected customer side service that circumnavigates said CGN NAT device (1 ) through a firewall and/or intrusion detection system.

16. System for controlling IP traffic in a service provider network, in particular for executing a method according to any of claims 1 to 15, wherein said service provider network (2) includes one or more switches for connecting service provider's customers to the global Internet, and a Carrier Grade Network Address Translation (CGN NAT) device (1 ), which is configured to translate between private and public IP addresses, wherein the private side faces said service provider's customers,

c h a r a c t e r i z e d i n that said service provider's customers and/or said CGN NAT device (1 ) are enabled to select IP traffic according to configurable criteria, wherein selected IP traffic is routed such that it bypasses said CGN NAT device (1 ).

17. System according to claim 16, further including a controller (6) that is logically connected to said one or more switches (4a, 4b) and to said CGN NAT device (1 ).

18. System according to claim 17, wherein said controller (6) is configured to install flow entries within said one or more switches (4a, 4b) for said selected customer side service to bypass said CGN NAT device (1 ).

19. System according to any of claims 16 to 18, including an AAA server (7) that is logically connected to said CGN NAT device (1 ) in order to enable said CGN NAT device (1 ) to check the authorization of a service provider's customer (3) who requests assignment of a public IP address.