WO2009084968A1

WO2009084968A1 - A device and system for selective forwarding

Info

Publication number: WO2009084968A1
Application number: PCT/NO2008/000470
Authority: WO
Inventors: Haakon Bryhni; Tarik Cicic
Original assignee: Media Network Services
Priority date: 2008-01-02
Filing date: 2008-12-29
Publication date: 2009-07-09
Also published as: GB201012136D0; NO328057B1; GB2469241B; GB2469241A; NO20080027L; GB2469241A8

Abstract

A system and method of operating equipment and services to allow enhanced global transport of IP packets is presented. A global virtual network with guaranteed capacity is used to transport said IP packets. A number of application-specific selective forwarding devices are deployed to detect and forward selected traffic types to the said virtual network. The application-specific selective forwarding devices can be implemented based on the IP packets analysis, or by deploying enhanced control protocols like SIP/H.323.

Description

A device and system for selective forwarding

Background of the Invention

In the use model that dominates the Internet today as shown in figure 1, communication equipment (1) that produces data streams is situated at the edges of the network. The data are sent from the source endpoint to the destination endpoint using the network system. The network system comprises local networks on the source and destination side (13), one or more local Internet Service Providers (ISP, 10) and one or more transport networks (H) -

Local networks (13) implement secure communication environments typically with private addresses and a firewall toward the rest of the Internet. Local Internet service provider networks (10) aggregate a number of local networks and use the transport providers (11) to reach each other.

Data packets enter the network from the end systems typically using a socket interface. In this model, the socket is identified by the pentuple of (source address, destination address, source port number, destination port number, protocol type) . The packets comprise two parts: a header and a payload. The header provides control information, while the payload contains higher-layer (e.g., application-level) data. The header identifies said pentuple.

Data packets are forwarded between the forwarding devices (20) hop-by-hop using the information in the packet header. Although additional functionality can be implemented in a network, only this hop-by-hop forwarding toward the destination is implemented universally in the Internet. Therefore, the network functionality an endpoint and its associated local network components typically implement is related to network addressing, including a) Resolving of symbolic names to network addresses b) Support for traversal of Network Address Translator (NAT) and firewall traversal.

This simple interface does not allow the endpoint to select the end-to-end network path. Only the destination can be selected, and the network itself chooses the path. Typically, the packet will have to traverse multiple administrative authorities on its path.

The Internet provides so-called best-effort service to its users. This means the packets are transported from node to node toward their destination. They can be temporarily stored in the transit nodes awaiting available network capacity to continue the journey (buffering) . The nodes are free to discard any packet; this would typically happen if a node receives more packets than it can forward in the moment and its buffering capacity is exceeded. No notification is given to the sender of the packet.

Many applications are interactive or bandwidth-demanding and have special network requirements such as low latency or low packet loss. These applications include among others gaming, business information feeds and multimedia communications. The traditional Internet model is insufficient for these applications. Advanced endpoint equipment may experience reduced quality due to congestion and packet loss. Remedies that can improve the network quality and availability include establishing private wide area networks, both physical and virtual. Large enterprises may rent or deploy network capacity to connect their locations within the enterprise, but with a significant cost. Furthermore, one can influence the packet path using overlay or peer-to-peer architectures . Overlays and peer-to-peer networks cannot improve the network quality unless the network resources are provided to them with capacity guarantees, which is typically not the case.

Recently, some Internet Service Providers (ISPs) have extended their network access and Virtual Private Networks (VPN) services by offering new network service models.

One model is to provide the infrastructure for temporary data storage (caching) to enhance large-scale one-to-many data streaming. This model conserves bandwidth, but it assumes delay-tolerance and is not suitable for interactive, real-time communications.

Another network service model is to provide infrastructure with guaranteed bandwidth to customers with geographically diverse office locations together with associated private network maintenance services. This service is different from VPNs in that there can be given bandwidth and latency guarantees to the traffic, and the customer need not have maintenance personnel employed. The model is however limited to the locations where the provider has physical infrastructure available, and cannot be extended to arbitrary communication peers .

Some providers build their business model on extensive Border Gateway Protocol (BGP) peering with locally present ISPs, enhancing the performance of their hosting services. This method improves the network service quality only locally.

Finally, some providers rent network capacity or deploy it themselves where needed and provide end-to-end guaranteed bandwidth service. This approach provides excellent network infrastructure, but is coarse and expensive and therefore reserved only to the most well-funded enterprise customers. Communication with arbitrary peers is not possible .

Quality of Service in the Internet Recognizing the shortcomings of the best effort Internet service, the research community has proposed Quality of Service (QoS) models for the Internet.

In IntServ [RFC1633] , network resources can be reserved end-to-end using a special signaling protocol called RSVP. The resources are reserved per flow, along the standard routing path. Such per-flow reservations scale poorly in the Internet where millions of flows are running concurrently, and are seldom deployed in practice. DiffServ [RFC2475] is a QoS framework for differentiation between different traffic classes. DiffServ scales well and can be used to provide a better service to a certain segments of the network traffic like VoIP. However, DiffServ provides no hard QoS guarantees, only prioritizing a given traffic type in front of another.

Both Internet QoS service frameworks have a serious shortcoming in that they need service agreements between the administrative domains. Furthermore, the local ISP would have to guarantee the service level to the user, without having full control of how the data is sent to the destination. This has been proved to be difficult in practice, and IntServ and DiffServ remain used largely in private networks .

Network Virtualization

Network virtualization has recently been proposed as a means of deploying global network services . In a recent architecture proposal called CABO ("Concurrent Architectures are Better than One" [CABO] ) , virtual network links connect virtual routers to deploy a range of concurrent internets. The virtual links are implemented using any of many available technologies including MPLS and IP tunneling. Virtual routers are running as processes on real routing equipment owned and managed by the infrastructure providers. The virtual routers have their integral resources such as output queues and schedulers. There is also a possibility to connect virtual links based on infrastructure owned by different providers using the virtual routers.

The distinction between the infrastructure providers and the network service providers is a novel concept in CABO and facilitates implementation of custom global network services. These could include secure networks, QoS networks, and networks with different addressing and routing schemes providing yet unknown services. CABO also advocates deployment of a signaling system for dynamic establishment of virtual network topologies. However, current business and security models in the Internet do not encourage deployment of CABO since the network operators do not accept third-party access to their critical infrastructure. Real-Time Conferencing

Real-time multimedia conferencing has gained substantial popularity recently, particularly in audio (telephony / Voice over IP) applications. Typically, a control system based on the Session Initiation Protocol, H.323 or a proprietary protocol (e.g. Skype) establishes a connection between the endpoints. The endpoints encode the media (audio, video, text for short messages, etc.) and send them as IP packets.

Figure 2 shows a typical state of the art deployment for VoIP and/or video conferencing using SIP or H.323. The VoIP/conferencing operator typically operates a control infrastructure (17) with at least a control server (30) and optionally media gateways (22) to facilitate audio communication from IP-based networks (11,13,14) to PSTN (18) . The communication is initiated in a terminal connected to a terminal adapter (32) . Many terminals include the terminal adapter capabilities inside the terminal, constituting a multimedia terminal, often called a ^λλsoftphone" if implemented inside a mobile phone / computer. The call is signaled from the terminal to the control server (30) using a control protocol (220) . This control server is typically a SIP or H.323 proxy, which communicate with the remote terminal and establish a connection. The terminals are instructed to use an IP/port address combination for the media communication. The media stream (250) takes the default path through the IP network (11,13,14) to the destination terminal, and voice or video communication can begin. If the called party is a terminal on the PSTN network, the control server (30) will direct the call to a suitable media gateway (22) and complete the call over regular PSTN. NAT and Firewall Traversal

Network Address Translation (NAT) devices perform translation of IP addresses between networks. For example, internal IP addresses on a user network (13) can have a mapping in the public Internet address space. In each packet leaving the local network (13) the IP header has to be modified by swapping the local addresses with the global ones. Thee are 4 basic types of NAT [STUN]:

• Full Cone (not frequently used due to security issues)

• Restricted Cone (the NAT IP mapping is only valid with outgoing traffic to the destination)

• Port Restricted Cone (same as Restricted Cone, but with IP and port mapping) • Symmetric (different mapping for different destination addresses)

Firewalls are used to enforce security in the local network. They typically close majority of network ports and discard packets addressed to these ports.

NAT and firewalls are widely used. Any device operating in the Internet today must be capable of handling them. There are many practical solutions to the NAT and firewall problem, among these:

• Universal Plug and Play (security issues by client control of firewall pinholes, and does not work with cascading NATs)

• STUN [STUN] , which is a client-server system where the server answers the clients query by embedding the perceived global address of the client in the payload of its reply. • TURN server [TURN] , which is a STUN server with additional functionality to forward data packets to a given global IP destination

• Application Level Gateway (ITU standard H.460.17/18/19) for use with the H.323 standards.

Note that the present invention does not specify any particular of the NAT and firewall traversal solutions, and is intended to work with all of the above.

Description of the Invention

The basic principle of the present invention is to redirect latency or bandwidth sensitive traffic to a dedicated network (15) in order to provide certain QoS guarantees to the user of the network service. Said dedicated network is a transport network comprising retransmission devices (20) at multiple points of presence (PoPs) , internally connected by guaranteed bandwidth channels (50), owned or rented from transport providers (12) . The network is connected to multiple ISPs (10) .

The traffic is redirected to the said dedicated transport network (15) using an application-specific selective forwarding device (31). Said device forwards selected traffic to any destination address to the address of a retransmission device (20) in the transport network. The traffic can be selected by analyzing the packet header (130) or packet content (150), or by interaction with a centralized or distributed server (30) . To forward packets to the re-transmission device, said application-specific selective forwarding device can use many mechanisms, including IP tunnels and transport-level proxy mechanisms. The packets selected for forwarding over the dedicated transport network (15) are addressed (102) to a retransmission device (20) within the dedicated network

(15) . The address of said re-transmission device (20) is determined by a mapping between an address space and the addresses of the re-transmission devices within the transport network. Said address space can be the IP address space, or the PSTN E.164 address space, or another address space that contains the network addresses of the call source and destination. Said re-transmission device

(20) can be an IP router, or a transport relay (33) operating as a SIP or H.323 media proxy.

Said mapping can be implemented in several ways. It can be based on BGP routing information collected in the transport network from the connected ISPs. It can be based on measurements such as the current network load in the transport network. It can be based on the network distance, i.e., which re-transmission device is closest to the destination address, or which re-transmission device is closest to the source address.

Embodiment 1 The first embodiment comprises a dedicated transport network (15), an application-specific forwarding device (31) and compliant re-transmission devices (20) , as shown in figure 3.

The dedicated transport network (15) comprises points of presence (PoP) that are located close to the local ISPs (10) . The PoPs are interconnected using physical or virtual links (50) with guaranteed bandwidth. This embodiment relies on an application-specific forwarding device (31) that selects relevant traffic from the local network (13) and forwards this traffic onto a dedicated transport network (15) via the standard ISP used by the customer (10) . The forwarding can be done using IP tunneling or a proxy operation using SIP or H.323. The retransmission devices (20) can be implemented as IP routers or as SIP/H.323 media proxies.

Using this configuration, all unrelated traffic such as email and file transfer will go over the default IP route (11) , while latency and bandwidth-sensitive traffic will be redirected to a dedicated transport network (15) with sufficient capacity as shown in figure 4.

The redirection can also be applied for signaling traffic, but the signaling can also use the regular IP route since it is not latency and bandwidth sensitive.

Optional control servers (30) may communicate with the application-specific forwarding device to assist in determination of the route selection. Additionally, they can be used for admission control, AAA and directory services .

In addition, each local network can have multiple endpoints as shown in figure 5. Multiple endpoints can be served by a concentrator typically located in the enterprise DMZ.

The architecture supports multicast. Multi-party conferences can be arranged by unicast-multicast reflectors [REFLECT] deployed in (20) and native multicast deployed in (15) . Embodiment 2

In this embodiment shown in figure 6, the control server (30) is located in the public IP network, typically close to the dedicated transport network. One or more transport relays (33) are placed centrally in the dedicated transport network and can serve many users.

In this embodiment, the SIP/H.323 endpoint control system (32) in the terminals (1) must be configured to always contact the control server (30) as outbound signaling proxy. Signaling path is indicated between the terminals and the proxy (220) . The control server maintains a mapping in the transport relay (33) using a control protocol (200) .

After initial signaling between the endpoint control system (32) and the control server (30), the terminal is instructed to send the media stream (250) over the dedicated transport network (15) using the transport relay (33) as outbound media proxy.

The control server rewrites source and destination IP addresses/ports as part of the media redirection, to ensure that a packet redirected to the media proxy will be forwarded on to the original destination.

Embodiment 3

Embodiment 3 as shown in figure 7 is similar to embodiment 2, the difference being that the control server (30) does not control the transport relay (33) directly. Instead, a modified Interactive Connectivity Establishment [ICE] procedure is used to instruct the transport relay (33) where to send the packets. In this embodiment, the functionality of the transport relay (33) is similar to that of a TURN server [TURN] . The caller endpoint control system (32) is configured to use the transport relay (33) as the outbound media proxy. Thus, it always directs media to the dedicated network. The modified Interactive Connectivity Establishment [ICE] procedure is used to avoid sending data between collocated endpoint via the dedicated transport network (15) . This procedure includes two steps:

a) The caller endpoint verifies whether the called endpoint has an IP address in the same network segment and that the called endpoint can be contacted. If confirmative, no dedicated network

(15) is used. b) Otherwise, the transport relay (33) is used.

When the transport relay (33) is used to transfer the data over the dedicated network (15) , the NAT traversal is implicitly solved using the TURN technology.

Embodiment 4

In this embodiment the selective forwarding device (31) selects the packets that shall be forwarded over the dedicated transport network (15) by packet inspection as shown in figure 8.

The packet selector (60) chooses the packets that are forwarded to the dedicated transport network (15) by analyzing the incoming packets. In Fig. 8, the packets that match the given header field specification (120) are sent over (15) . All other packets are sent using the standard Internet path (11) . Packets sent over (15) are encapsulated to a given address (102) within the dedicated network (15) . There, they are de-capsulated and forwarded to their destination (101) .

The selective forwarding device (31) learns the mapping between the global addresses (101) and the local addresses (102) from the control servers (30) using a query-reply protocol (200) . The device (31) can ask which address in the dedicated transport network (15) should be used to send data to destination (101) using message (210) . The answer is provided in the message (211).

Alternatively, the mapping can be provided by the endpoint control system (32) as shown in figure 9.

References

[CABO] Nick Feamster, Lixin Gao and Jennifer Rexford: "How to lease Internet in your spare time", ACM SIGCOMM Computer Communications Review journal, pages 61-64, Jan. 2007.

[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE) : A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", IETF draft-ietf-mmusic-ice-16 (work in progress) , June 2007.

[REFLECT] Tarik Cicic, Haakon Bryhni, Steinar Sørlie: "Multicast-Unicast Reflector", In proceedings of Protocols for Multimedia Communications (PROMS) conference, pages 60-69, Krakow, Poland, 2000.

[RFC1633] R. Braden, D. Clark, S. Shenker: "Integrated Services in the Internet Architecture: an Overview", IETF, June 1994.

[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss "An Architecture for Differentiated Services", IETF, Dec. 1998.

[RFC4364] E. Rosen and Y. Rekhter: "BGP/MPLS IP Virtual Private Networks (VPNs)", IETF, Feb. 2006.

[STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Many, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [TURN] J. Rosenborg, R. Mahy, C. Huitema: "Traversal Using Relays around NAT (TURN) : Relay Extensions to Session Traversal Utilities for NAT (STUN)", IETF draft-ietf- behave-turn-06 (work in progress), 2007.

Claims

C l a i m s

1. End-to-end application-specific selective transport network (ASSTN), comprising local networks (13), a transport network (15), with re-transmission devices (20) at multiple points of presence, internally connected by guaranteed bandwidth channels, connected to multiple ISPs, characterized by said transport network having guaranteed capacity dedicated to authorized users, and where admission control to the transport network is provided by control servers (30), and an application-specific selective forwarding device (31), redirecting selected latency and bandwidth- sensitive traffic, addressed to any destination to the address of a re-transmission device (20) in the transport network, where said re-transmission device address is determined by a mapping between an address space and the addresses of the re-transmission devices within the transport network.

2. End-to-end application-specific selective transport network according to claim 1, where at least one local network (13) comprises said application-specific selective forwarding device (31) .

3. End-to-end application-specific selective transport network according to claim 1, where said application- specific selective forwarding device (31) is located in a terminal (1) with an endpoint control system (32) .

4. End-to-end application-specific selective transport network according to any of the preceding claims, where said application-specific selective forwarding device (31), forwarding selected traffic to any destination address to the address of a re-transmission device (20) in the transport network, characterized in that the said re- transmission device address is determined by a mapping between the packet header (130) or packet content (150) and the addresses of the re-transmission device within the transport network.

5. End-to-end application-specific selective transport network according to any of the preceding claims where said mapping is controlled by a centralized or distributed server (30), implementing a mapping function between an address space and the addresses of re-transmission device (20) within the transport network (15) .

6. End-to-end application-specific selective transport network according to any of the preceding claims where said the address of the re-transmission device (20) is an IP address.

7. End-to-end application-specific selective transport network according to any of the preceding claims, the said mapping is based on BGP routing information from the transport network.

8. End-to-end application-specific selective transport network according to any of the preceding claims, where the mapping is based on the current network load in transport network.

9. End-to-end application-specific selective transport network according to any of the preceding claims, where the selected re-transmission device in the transport network selected in the mapping function is the retransmission device closest to the destination address.

10. End-to-end application-specific selective transport network according to any of the preceding claims, where the selected re-transmission device in the transport network selected in the mapping is the re-transmission device closest to the source address.

11. End-to-end application-specific selective transport network according to any of the preceding claims, where the control server manages the routing configuration in the dedicated transport network.

12. End-to-end application-specific selective transport network according to any of the preceding claims, where the communication between the control server and the application-specific selective forwarding device is encrypted.

13. End-to-end application-specific selective transport network according to any of the preceding claims, where the forwarding device uses tunnels to forward packets to the re-transmission device.

14. End-to-end application-specific selective transport network according to any of the preceding claims, where the forwarding device uses proxy mechanism to forward packets to the re-transmission device.

15. End-to-end application-specific selective transport network according to any of the preceding claims, where the endpoint control system (32) uses TURN to forward packets to the re-transmission device.

16. An application-specific selective forwarding device (31) , characterized by being adapted to

- redirection of selected latency and bandwidth-sensitive traffic addressed to any destination to the address of a re-transmission device (20) in a transport network (15) ,

- determine the re-transmission device IP address by a mapping between an address space and the addresses of the re-transmission devices within the transport network (15) , - communicate with control servers (30) providing admission control to the transport network (15) , the transport network (15) having guaranteed capacity dedicated to authorized users.

17. An application-specific selective forwarding device according to claim 16, where the said mapping is determined by a SIP proxy which informs the calling terminal to use said re-transmission device (20) for communication with the called terminal, and inform the called terminal to use the said re-transmission device (20) for communication with the caller.

18. An application-specific selective forwarding device according to claim 16 or 17, where the said mapping is determined by a control server (30) .

19. An application-specific selective forwarding device according to one of the claims 16 to 18, where the retransmission device is a TURN server.

20. An application-specific selective forwarding device according to one of the claims 16 to 19, where the said forwarding device is located in the enterprise network.

21. An application-specific selective forwarding device according to one of the claims 16 to 19, where the said forwarding device is located on the Internet.