NO328057B1 - A system for media network services - Google Patents

Abstract

A system and method for equipment and services to provide improved global transport of IP packets. A global virtual network with guaranteed capacity is used to transport the said IP packets. A number of application-specific, selective Forwarding Devices are used to detect and forward selected traffic types to the aforementioned virtual networks. The application-specific, selective forwarding devices can be implemented based on IP packet analysis or by control protocols such as SIP / H.323

Description

A system for media network services

Background for the invention

In the usage model that dominates the Internet today as shown in Figure 1, communication equipment (1) that produces data streams is located at the edge of the network. Data is sent from the sender endpoint to the receiver endpoint using the network. The network comprises local networks at the sender and at the receiver (13), one or more Internet service providers (ISP, 10) and one or more transport networks (11).

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

Data packets enter the network from the end systems, typically via a socket interface. In this model, the socket is identified by the pentuple combination of sender address, receiver address, sender port number, receiver port number and protocol type. The packets consist of two parts: a packet header and a payload. The packet header contains control information, while the payload contains higher level (eg application level) data. The packet header identifies the previously mentioned 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 to the receiver is universally implemented in the Internet. Therefore, the network functionality implemented in an endpoint and the associated local network components are related to addressing, which include:

a) Translation of symbolic names into network addresses

b) Support for Network Address Translator (NAT) traversal and traversal of

firewalls.

This simple interface does not allow the endpoint to choose the end-to-end network path. Only the recipient can be selected, and the network itself chooses the path for the packet. Typically, the package must traverse multiple administrative authorities along the way.

The Internet implements so-called best-effort service to its users. This means that packets are transported from node to node towards the recipient. They can be temporarily stored in the transit nodes and await available network capacity to continue their journey (intermediate storage/buffering). The nodes can discard a packet, which typically happens if a node receives more packets than it can currently forward and the buffer capacity is exceeded. No notification is given to the sender of the package.

Many applications are interactive or bandwidth-intensive, and have special network requirements such as low delay or low packet loss. These applications include games, business information streams, and multimedia communications, among others. The traditional Internet model is insufficient for these applications. Advanced endpoint equipment may experience reduced quality due to queuing and packet loss.

Measures that can improve network quality and availability include the establishment of physical or virtual private networks. Large companies can rent or establish network capacity to connect their locations within the company, at a significant cost.

Furthermore, one can influence the packet path by using superimposed or peer-to-peer architectures. Overlaid networks and peer-to-peer networks cannot improve network quality unless the network resources can offer capacity guarantees, which is typically not the case.

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

One model is to provide infrastructure for temporary data storage (caching) to improve large-scale one-to-many data transfer. This model saves on transmission capacity, but it requires tolerance for the delay and is not suitable for interactive, real-time communication.

Another network service model is to offer infrastructure with guaranteed transmission capacity to customers who are geographically dispersed, together with associated private network maintenance services. Such services differ from VPN in that no guarantee can be given for transmission capacity and delay in the network, and the customer does not need to employ operational personnel. However, the model is limited to where the service provider has physical infrastructure available, and cannot be extended to connections with arbitrary recipients.

Some providers build their business model on extensive "Border Gateway Protocol" (BGP) peering agreements with local Internet Service Providers (ISPs), extending the performance of their hosting services. This method improves network quality of service only locally.

Finally, some providers rent network capacity, or establish it themselves where needed, and offer a service with end-to-end guaranteed transmission capacity. This option provides very good network infrastructure, but is fragmented and expensive and is therefore only available to the most solvent business customers. Communication with arbitrary recipients is not possible.

In WO 2006/043139 "Address Modification in Application Servers" address modification is presented in

application servers by placing an Internet Protocol multimedia subsystem on top of a packet-switched network for third-generation multimedia services. The document describes the procedure, server and control equipment for private number plan changes, service carrier access code changes, call forwarding, service number changes and number portability. This solution is limited to signaling functionality, and does not include a data plan or network quality.

"A Practical Transit Mapping Service" (Draft-jen-apt-00.txt) Version 01 released 2007.11.18 from the Routing Research Group (RRG) is a draft submitted to the IETF (Internet Engineering Task Force) that describes address space mapping for transit networks. This architecture does not include local area networks, and treats all traffic equally.

In US 2003/0118036 "Routing Traffic in a Communications Network" routing of packets in a system of autonomous, i.e. independent network systems based on BGP (Border Gateway Protocol) is presented.

In WO 2007/011927 "Dynamic Enforcement of MPLS-TE Inter-Domain Policy and QOS" dynamic routing based on LSP is described

(Label Switched Path) for routing between domains. Policy is triggered at a PDP (Policy Decision Point). Issues in delivering quality of service (QoS) in terms of bandwidth are addressed. A solution for MPLS switching is presented in that each router has a forwarding section where one determines from a "label" in the incoming packet a reference to a table with this information so that the network egress can make a forwarding decision.

In EP 1 708 408 "A System and Method of Ensuring Quality of Service in Virtual Private Network" a system and method for ensuring the required quality of service (QoS) is presented. Here, centralized resource controllers are described for handling resources for private networks that are placed so that topographical information is exchanged.

Quality of service in the Internet

Recognizing the weaknesses of "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 by using a special signaling protocol called RSVP. The resources are reserved per flow, along the standard routing path. This per flow reservation scales poorly in the Internet where millions of such flows flow simultaneously, and the method is rarely used in practice. DiffServ [RFC2475] is a quality of service framework for differentiating between different service classes. DiffServ scales well and can be used to offer a better service to specific segments of network traffic, such as VoIP. However, DiffServ does not offer hard quality of service guarantees, only prioritizing one given traffic type over another.

Both of the Internet-based quality of service frameworks have a significant problem in that they need service agreements between the administrative domains. Furthermore, a local Internet service provider will have to guarantee the level of service to the user, without having full control over how data is sent to the recipient. This has proven difficult in practice, and IntServ and DiffServ are currently primarily used in private networks.

Network virtualization

Network virtualization has recently been proposed as a method to establish global network services. In an architecture proposal called CABO ("Concurrent Architectures are Better than One" [CABO]), virtual network links connect virtual routers to establish a spectrum of concurrent Internets. The virtual links are implemented using one of many available technologies such as MPLS and IP tunnelling. Virtual routers run as processes on physical routers owned and managed by the infrastructure provider. The virtual routers have their integrated resources such as egress queues and schedulers. It is also possible to connect virtual links based on infrastructure owned by different providers using virtual routers.

The distinction between infrastructure providers and network service providers is a new concept in CABO and makes it possible to implement tailored global network services. These can include secure networks, networks with quality of service, and networks with different addressing and routing solutions that enable hitherto unknown services. CABO also recommends using a signaling system for the dynamic creation of virtual network topologies. However, with current business and security models in the Internet, it is difficult to establish CABO-based networks since the network operators do not accept third-party access to their critical infrastructure.

Real-time conferencing services

Real-time multimedia conferencing services have gained significantly increased popularity in recent times, especially in audio (telephony / voice over IP) applications. Typically, a control system based on "Session Initiation Protocol", H.323 or a proprietary protocol, such as Skype, is used to establish a connection between the endpoints. The endpoints encode media (audio, video, text for short messages, etc.) and send them as IP packets.

Figure 2 shows a typical installation for VoIP and/or video conference SIP or H.323. The VoIP/conference operator typically operates a control infrastructure (17) with a control server (30) and alternatively also media gateways (22) to carry out audio communication over IP-based networks (11,13,14) to the PSTN [Public Switched Telephone Network]. (18). The communication is initiated in a terminal connected to an endpoint control system (32). Many terminals include endpoint control features inside the terminal, which together constitute a multimedia terminal, often called a "softphone" if implemented in a mobile phone / computer. The call is signaled from the terminal to the control server (30) using the control protocol (220). The control server is typically a SIP or H.323 proxy, which communicates with the receiver and establishes a connection. The terminals are instructed to use an IP port address combination for the media communication. The media stream (250) takes the standard route through the IP network (11,13,14) to the receiver's terminal, and voice or video communication can start. If the recipient is a terminal in the normal telephone network (PSTN), the control server (30) must redirect the call to a suitable media gateway (22) and carry out the call through the normal telephone network.

Traversing network address translators and firewalls Network Address Translation (NAT) translates IP addresses between networks. For example, internal IP addresses in a user network (13) can be mapped to the public Internet address space. In each packet leaving the local network (13), the IP header must be changed by replacing the local addresses with the global ones. There are 4 basic types of NAT [STUN]: • Full Cone, which is rarely used because security issues. • Restricted cone (Restricted Cone), where the NAT-IP mapping is valid only with outgoing traffic towards the destination. • Port Restricted Cone (Port Restricted Cone), like restricted cone, but with IP address and port mapping. • Symmetrical, with different mapping for different destination addresses.

Firewalls are used to secure local networks. They typically close the majority of network ports and drop IP packets addressed to those ports.

NAT and firewalls are in widespread use. All the devices used in the Internet today must be able to handle them. There are several practical solutions to solve the NAT and firewall problems, including: • "Universal Plug and Play" (security problems with client control of firewall openings, does not work with multiple NAT levels) • STUN [STUN], which is a client- server system where the server responds to the client's requests by attaching the client's observed global address to the response packet • TURN server [TURN] which is a STUN server with additional functionality to forward data packets to a given

global IP receiver

Application level gateway (ITU standard H.460.17/18/19) for use with the H.323 standard

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

Description of the invention

The basic principle of this invention is to redirect delay- or bandwidth-sensitive traffic to a dedicated network (15) in order to provide certain service quality guarantees to the user of the network service. This dedicated network is a transport network consisting of forwarding devices (20) in several points of presence (Points of Presence, PoP), internally interconnected with channels with guaranteed bandwidth, owned or leased by transport network providers (12). The network is connected to several Internet service providers (10).

The traffic is redirected to this dedicated transport network (15) using an application-specific selective redirection unit (31). This unit redirects selected traffic destined for an arbitrary address to the address of a forwarding device (20) in the transport network. The traffic can be selected by analyzing the packet header (130) or packet content (150), or by interacting with a centralized or distributed server (30). To redirect the packets to the forwarding device, this application-specific selective redirection device may use many mechanisms, including IP tunnels and proxy mechanisms at the transport layer.

The packets selected for redirection to the dedicated transport network (15) are addressed (102) to a forwarding device (20) within the dedicated network (15). The address of this forwarding device (20) is determined from a mapping between an address space and the addresses of the forwarding devices within the transport network. This address space can be IP address space, or PSTN E.164 address space, or another address space that contains the network addresses of sender and receiver. This forwarding device (20) can be an IP router, or a transport relay (33) operating as a SIP or H.323 media proxy.

This mapping can be implemented in different ways. It can be based on BGP route information collected in the transport network from connected ISPs. It can be based on measurements of, for example, the current traffic load in the transport network. It can be based on network distance, for example which forwarding device is closest to the destination address, or which forwarding device is closest to the source address.

Embodiment 1

The first embodiment comprises a dedicated transport network (15), an application-specific redirection unit (31), and associated forwarding devices (20), as shown in Figure 3.

The dedicated transport network (15) comprises points of presence (PoP) which are located near the local Internet service providers (10). The PoPs are interconnected by physical or virtual links (50) with guaranteed bandwidth.

This embodiment relies on an application-specific redirection unit (31) that selects relevant traffic from the local area network (13) and forwards this traffic to the 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 forwarding device (20) can be implemented as IP routers or SIP/H.323 media proxies.

In this setup, all unrelated traffic, such as e-mail and file transfer, will follow the normal IP route (11), while delay- and bandwidth-sensitive traffic is redirected to a dedicated transport network (15), with sufficient capacity, as shown in Figure 4 .

The redirection can also be used on signaling traffic, but the signaling can also use normal IP routes since it is not delay- and bandwidth-sensitive.

Optional control servers (30) may communicate with application-specific redirection devices to help determine route selection. In addition, they can be used for access control, AAA and directory services. In addition, each local network can have several endpoints as shown in Figure 5. Several endpoints can be served by a concentrator typically located in the company's DMZ.

The architecture supports multicasting. Multiparty conferences can be arranged with unicast-multicast reflectors [REFLECT] implemented in (20) and own-multicast implemented in (15).

Embodiment 2

In this embodiment shown in figure 6, the control server (30) is located in the public IP network, typically in the vicinity of the dedicated transport network. One or more transport relays (33) are centrally located 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 outgoing signaling proxy. The signaling path is indicated between the terminals and the proxy (220). The control server maintains an image 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 the outgoing media proxy. The control server rewrites source and destination IP addresses/ports as part of media redirection to ensure that a packet redirected to the media proxy will be forwarded to its original destination.

Embodiment 3

As shown in figure 7, embodiment 3 is similar to embodiment 2, with the difference that the control server (30) does not control the transport relay (33) directly. Instead, a modified "Interactive Connectivity Establishment" is used

[ICE] procedure, which is used to instruct the transport relay (33) where to send the packets.

In this embodiment, the functionality of transport relay (33) corresponds to a TURN server [TURN]. Sender's endpoint control system (32) is configured to use transport relay (33) as an outbound media proxy. The media is thus routed to the dedicated network. The modified "Interactive Connectivity Establishment" [ICE] procedure is used to avoid sending data between adjacent endpoints via the dedicated transport network (15). This procedure includes two steps: a) The sending endpoint verifies whether the endpoint to receive data has an IP address in the same network segment and that this endpoint can be reached. If this is true, the dedicated network (15) will not be used.

b) Otherwise transport relay (33) will be used.

When the transport relay (33) is used to transfer data over a

dedicated network (15), NAT traversal is solved implicitly using TURN.

Embodiment 4

In this embodiment, the application-specific selective redirection unit (31) selects the packets to be forwarded over the dedicated transport network (15) by packet inspection as shown in Figure 8.

The packet lector (60) selects which packets to forward to the dedicated transport network (15) by analyzing the incoming packets. Figure 8 shows how the packets that match a given header field specification

(120) is sent over (15). All other packets are sent via the standard Internet path (11).

Packages sent above (15) are wrapped to a given address

(102) in the dedicated network (15). There, the packages are unpacked and forwarded to their destination (101).

The application-specific selective redirection unit (31) learns the mapping between the global address (101) and the local address (102) from control servers (30) using a "request-response" protocol (200). The redirection unit (31) can ask which address in the dedicated transport network (15) should be used to send data to the destination (101) using message (210). The answer is

delivered in the message (211).

Alternatively, the mapping can be done in the endpoint control system (32) as shown in Figure 9.

References

[CABO] Nick Fefamster, 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. Mahy, "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 (15)

1. End-to-end application-specific, selective transport system, comprising of local area networks (13), a transport network (15), with forwarding device (20) at multiple installations, internally interconnected by communication channels with guaranteed capacity, connected to multiple Internet service providers (ISPs ), characterized by that said transport network with guaranteed capacity dedicated to authorized users, and where access control to the transport network is performed by control servers (30), and an application-specific selective redirection unit (31) redirects (forwards) selected traffic sensitive to delay and transmission capacity, addressed to a destination address of the address of a forwarding device (20) in the transport network, where the address of said forwarding device is determined by a mapping between an address space and the addresses of the forwarding devices in the transport network. 2. End-to-end application-specific, selective transport system according to claim 1, where at least one local network (13) comprises said application-specific, selective redirection unit (31). 3. End-to-end application-specific, selective transport system according to claim 1, where said application-specific, selective redirection unit (31) is located in a terminal (1) with an endpoint control system (32). 4. End-to-end application-specific, selective transport system according to one of the preceding claims, where said application-specific, selective redirection unit (31) redirects selected traffic to a destination address to the address of a forwarding device (20) in the transport network, where the address of said forwarding device is determined by a mapping between information in the packet header (130) or the contents of the package (150) and the address of the forwarding device in the transport network. 5. End-to-end application-specific, selective transport system according to one of the preceding claims, where said mapping is controlled by a centralized or distributed control server (30), which implements a mapping function between an address space and the addresses of forwarding devices (20) in the transport network (15). 6. End-to-end application-specific, selective transport system according to one of the preceding claims, where the address of the forwarding device (20) is an IP address. 7. End-to-end application-specific, selective transport system according to one of the preceding claims, where the mapping is based on BGP routing information from the transport network. 8. End-to-end application-specific, selective transport system according to one of the preceding claims, where the mapping is based on the current network load in the transport network. 9. End-to-end application-specific, selective transport system according to one of the preceding claims, where the selected forwarding unit in the transport network that is selected in the mapping function is the forwarding device that is closest to the destination address. 10. End-to-end application-specific, selective transport system according to one of the preceding claims, where the selected forwarding device in the transport network selected in the mapping function is the forwarding device closest to the source address. 11. End-to-end application-specific, selective transport system according to one of the preceding claims, where the control server manages routing configuration in the transport network. 12. End-to-end application-specific, selective transport system according to one of the preceding claims, wherein the communication between the control server and the application-specific, selective redirection unit is encrypted. 13. End-to-end application-specific, selective transport system according to one of the preceding claims, wherein the redirection unit uses tunnels to redirect packets to the forwarding device. 14. An end-to-end application-specific selective transport system according to any one of the preceding claims, wherein the redirection device uses a proxy mechanism to redirect packets to the forwarding device. 15. An end-to-end application-specific, selective transport system according to one of the preceding claims, wherein the control system (32) uses TURN to redirect packets to the forwarding device.