WO2003034670A1

WO2003034670A1 - A method and apparatus for transferring data packets in ip routers

Info

Publication number: WO2003034670A1
Application number: PCT/SE2002/001889
Authority: WO
Inventors: Jan Berglund; Stefan Gabrielsson; Johan Gerhardsson; Ingela NÖTEBERG; Dusan Stevanovic; Johan Svedberg
Original assignee: Operax Ab
Priority date: 2001-10-19
Filing date: 2002-10-16
Publication date: 2003-04-24
Also published as: EP1444812A1; SE0201346L; SE0201346D0; SE523862C2

Abstract

A method and apparatus for transferring data packets over a router (100) comprising interface units (106) and a switchingunit (108). It is determined whether a received data packetbelongs to an existing session context by comparing extractedheader information with any session contexts stored in the router. In that case, a header translation is applied for thepacket according to the existing session context duringtransfer through the router from an ingress unit to an egress unit. Otherwise, a new session context is createdincluding selecting a header translation scheme to be used for further packets of the new session. The new session context is stored in the router together with a context IDassigned to the new session context. In this way, processingwork and delays are reduced in the router when transferring data packets, thereby enabling a high data throughput.

Description

A METHOD AND APPARATUS FOR TRANSFERRING DATA PACKETS IN IP ROUTERS

TECHNICAL FIELD The present invention relates generally to a method and apparatus for packet-based data transfer between two different communication networks. In particular, the invention is concerned with reducing the processing work in an IP router for enabling a high data throughput and functionality.

BACKGROUND OF THE INVENTION AND PRIOR ART

Recently, systems and solutions have been developed for providing packet-based transmission of digitally encoded information for a variety of services, such as voice telephony, video telephony, television and video distribution, in addition to Internet surfing and messaging. These services are delay sensitive to a varying extent, and are often classified accordingly for selecting suitable transmission mechanisms and protocols. The most delay sensitive applications, such as voice and video, are sometimes referred to as real-time services. Less delay sensitive applications, such as downloading of data, e.g., homepages from the Internet, are sometimes referred to as best effort services. Thus when transmission resources are shared, real-time data is typically given priority over best effort data.

The information to be transmitted, e.g., audio, video, text or images, is digitally encoded at the sending side and arranged into data packets of a specific format according to a selected coding scheme . A communication session is then established during which the data packets are transmitted. In packet switched sessions, communicated data packets are individually handled along the transmission path, which may comprise various networks, switches, gateways, routers and interfaces. Therefore, individual data packets of a communication session may be transmitted with different delays and even over different routes. When received at their destination, the packets are arranged in the correct sequence order, and the encoded information in the data packets may be decoded, e.g. in order to be presented or played to a user at the receiving end. The sending and receiving parties may each comprise any type of end station, such as fixed or mobile phones, computers, servers, game stations, TV sets, etc.

As mentioned above, data packets are typically transmitted over a plurality of different networks. Routers are transmission nodes, either within networks or interconnecting different networks for handling traffic therebetween. The Internet Protocol (IP) is extensively used today as a transmission standard for communication within and between networks. Thus, data packets are typically transferred over one or more IP routers in a transmission path during a communication session.

In addition to simply receiving and forwarding . data packets, an IP router also performs other activities, such as security control, packet scheduling, and address and protocol translations. By way of example, the IP router may decide whether to forward an incoming packet or not, based on predetermined rules and security policies. For example, it may be checked at so-called domain edge routers that a data flow entering a predefined domain does not violate any agreement or reservation. It may also be necessary to employ scheduling mechanisms for multiplexing plural incoming packets of different communication sessions over shared transmission resources, e.g., based on Quality of Service (QoS) policies and priority classifications. Different sessions may thus have different requirements regarding delays and/or data rate, and are classified accordingly. End-user subscriptions may also have differentiated QoS classes.

Further, address and protocol translations of the packets may be necessary to perform when different protocols or address spaces are used by two interconnected networks . For example, translation may be required between private and public address spaces according to IP version 4, or between IP version 4 and IP version 6 domains . However, all these activities within the IP router require considerable processing resources and may also limit the data throughput rate. In particular, if many or all of the functions outlined above are performed for each single incoming data packet of plural sessions, the processing resources available in the IP router may not be sufficient . If so-called "broadband" access is extensively implemented, practically all transferred packets will require these functions .

Hence, there is a great need for a simple and more effective solution that reduces transmission load, processing work and delays in the router, yet basically fulfilling requirements for, e.g., accessibility, security and QoS .

SUMMARY OF THE INVENTION

It is an object of the present invention to overcome the drawbacks outlined above, and to achieve a high data throughput and reduced processing load, as well as ensured quality and security of packet data transmissions in IP routers. These and other objects are achieved by a simple solution for transferring data packets over a router between a sending end station and a receiving end station. Packets from the sending end station are received in an ingress unit at a first interface unit in the router, and packets are sent from an egress unit at a second interface unit to the receiving end station. The router further comprises a switching unit for transferring packets between the first and second interface units.

When a data packet is received from the sending end station at the ingress unit, information is extracted from a header of the packet . Extracting the header information may include calculating a hash key from data in the header fields, such as^' a check sum. The extracted header information may also comprise actual data in the header fields .

It is determined whether the received data packet belongs to an existing session context by comparing the extracted header information with any existing session contexts stored in the router. For example, a calculated hash key may be compared with a corresponding hash key of any stored session contexts. If the packet belongs to an existing session context, a header translation is applied for the packet during transfer through the router from the ingress unit to the egress unit, according to a selected translation scheme of the existing session context. In the header translation, the header is replaced with a modified and substantially reduced header including a context ID assigned to the existing session context . The modified header may further include dynamic header fields and a TTL (Time To Live) field. After transfer through the router, the header can be re-created at the egress unit by using the selected translation scheme and by retrieving the stored session context matching the packet based on the assigned context ID, before sending out the packet towards the receiving end station.

If the received data packet does not belong to an existing session context, a new session context is created including selecting a translation scheme to be used for applying a header translation for further packets of the new session. Session characteristics may then be determined from the received packet, based on information extracted from the packet header and on predetermined rules or policies . The session characteristics may comprise any of: a source IP address, a destination IP address, a communication protocol, a required QoS, a source port number and a destination port number. The new session context may further include taken decisions regarding forwarding, access control, QoS and address or protocol translations. The created session context is then stored together with a context ID assigned to the session as a key.

Creating the new session context includes taking a forwarding decision by checking if the packet is allowed to be transferred, based on predefined policies, and if any route to its destination exists from the router.

Creating the new session context includes defining context descriptors describing the characteristics of the data session. The context descriptors comprises the selected header translation scheme and any of: header templates, a forwarding decision and identifications of ingress and egress units in the router to be used during the session. The context descriptors may be defined separately for originating and terminating interface units of the router, and may further be defined separately for ingress and egress units in each of the originating and terminating interface units, respectively. The invention embraces a method and a router having means for performing the method. The inventive method may further be executed by means of a computer program product comprising a software code being adapted to perform the method in a router. The computer program product may be directly loadable into the internal memory of a computer in the router, or may be stored on a computer usable medium, comprising readable program which can be executed in a computer in the router.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail and with reference to the accompanying drawings, in which:

Fig. 1 is a schematic view of an exemplary communication scenario for transferring data.

Fig. 2 is a more detailed view of a router.

Fig. 3 is a schematic illustration of an exemplary data packet .

Fig. 4 is a flow chart of a procedure for receiving data packets in a router.

Fig. 5 is a flow chart of the first part of a procedure for creating a new session context when receiving a first packet .

Fig. 6 is a flow chart of the second part of a procedure for creating the new session context .

Fig. 7 is a schematic illustration of the originating and terminating sides of a router. DESCRIPTION OF PREFERRED EMBODIMENTS

Fig. 1 is an overview of an exemplary communication scenario in which the inventive method and apparatus for transferring data packets can be implemented. A router 100 interconnects a plurality of different networks 102 for enabling communication between end stations 104 connected thereto. The router 100 is capable of communicating data packets in different formats between a multitude of different end stations or terminals, such as fixed or mobile phones, computers, game stations, servers, etc. Further, the networks 102 may comprise any type of communication networks, such as mobile or fixed networks, private or public networks, backbone IP (Internet Protocol) networks, the Internet etc.

A first end station 104A is connected to a first network 102A, and a second end station 104B is connected to a second network 102B. The router comprises a number of network interface units 106, of which interface unit 106A is connected to the first network 102A, and interface unit 106B is connected to the second network 102B. The interface units 106A, 106B are also interconnected within the router 100 by means of a switching unit 108. This is a simplified router structure, and in reality, further switches and/or links may be involved, which are not shown here for simplicity. In Fig. 1, only four interface units 106 and networks 102 are shown, but the router 100 may of course comprise any number of interface units connected to any number of networks. Each interface unit 106 may also be connected to one or more networks 102 and may work either as an originating packet processing unit or as a terminating packet processing unit, depending on which networks the originating and terminating end stations are connected to, respectively, i.e., from which side a communication session is initiated.

In this example, the first end station 104A initiates a packet data session by sending a first data packet addressed to the second end station 104B. The first data packet will be followed by further packets during the session. The first data packet may comprise a service request to a server, a first block or frame of speech data from a telephone, a first data block for video streaming from a server, just to name a few examples.

By definition, the first end station 104A is then the originating end station, and hence, the interface unit 106A receiving the first data packet will work as an originating packet processing unit. Consequently, the second end station 104B is the terminating end station, and the interface unit 106B will work as a terminating packet processing unit. Later, a new session may be initiated in the opposite direction, reversing the roles described above. For each ongoing data session communicated over the router 100, a session context is created and stored in the router 100, defining parameters valid for the session. When receiving the first data packet from the first end station 104A, the interface unit 106A extracts information from a header in the packet and recognises that the packet does not belong to any existing session, by comparing the extracted header information with any stored session contexts. A new session context is therefore created and stored in the router 100, based on the information in the header and on predefined rules or policies .

Creating a new session context involves a number of decisions which are taken based on the first received packet, wherein the taken decisions are included in the stored session context . These decisions are taken with respect to predefined rules or policies which may be stored in the originating ingress unit and the terminating egress unit, respectively. Alternatively, rules may be received from a separate and common controlling unit, sometimes referred to as an Application Layer Gateway ALG, which monitors control signals transmitted between the end- stations 104A, 104B before the session is started. The ALG injects relevant rules to the concerned interface units, which then can take necessary decisions according to the injected rules.

Decisions to be taken may include any of :

- forwarding decisions which may be based on routing tables, - access control decisions which may be based on predefined security policies,

- QoS decisions with respect to, e.g., priority classifications and packet scheduling, and

- address or protocol translation decisions . As further packets of the initiated session are received after the first packet, such decisions need not be taken or be retrieved for each received packet, since the decisions stored in the context are made valid by just detecting that a packet belongs to the stored session context . This will save considerable processing work and reduce delays in the router 100. A similar procedure is described in Applicant's earlier Swedish Patent application 0100708-7, where a data stream is initiated based on stream characteristics determined from a first received data packet .

In order to further facilitate the transfer of data packets within the router, a header translation is applied for each packet during transfer through the router, which will be described below. By using header translation, the header size can be substantially reduced, thereby reducing bandwidth and processing requirements internally in the router, such that the throughput rate can be increased and delays can be reduced.

Fig. 2 illustrates components in the router 100 of Fig. 1 being involved in the communication of data packets between the end stations 104A and 104B. Each of the interface units 106A and 106B comprises an ingress unit

200Ai, 200Bi, an egress unit 200Ae, 200Be and a control unit 202A, 202B,- respectively. It should be noted that Fig. 2 is merely a logical illustration, and the functional components 200Ai,Bi, 200Ae,Be and 202A,B may be physically implemented as separate or combined processing elements. For example, the control units 202A,B may be implemented in separate processors or one common processor, either located in any of the interface units 106A,B or elsewhere. Further, the ingress and egress units of each interface unit 106A and 106B may be one and the same unit taking different roles depending on the direction of communicated packets.

In an exemplary procedure, data packets are received from the first end station 104A at the ingress unit 200Ai of the interface unit 106A. The received packets are destined to the second end station 104B. Fig. 3 illustrates schematically an exemplary incoming data packet 300 comprising a header 302 with various header fields 304-314 containing information on the data session. In this example, the header fields include, among other things, a source IP address field 304, a destination IP address field 306, a communication protocol field 308, a required QoS field 310. Depending on the protocol, the header further includes, in this case, a source port number field 312 and a destination port number field 314. The data packets also contain a payload data field 316 in addition to the header 302. The above-described header fields are typically included in each packet of a session.

With reference to the flow chart of Fig. 4, the ingress unit 200Ai operates according to the following procedure when receiving data packets. In a first step 400, the ingress unit 200Ai receives a data packet from the end station 104A and extracts information from a header therein for matching the packet with any existing and stored session contexts, in a next step 402. Extracting information preferably comprises calculating a hash key or the like from data in the header fields, such as a check sum, which is compared with a corresponding hash key of any stored session contexts, e.g., in a stored hash look-up table. Alternatively, actual data may be extracted from the header fields for comparison. A combination of hash key and actual data may also be used. If recognised in step 402 that the packet does not belong to any existing session, the packet is sent to the control unit 202A for creating and storing a new session context in a step 404, which will be described later. On the other hand, if the packet is matched with a stored session context in step 402, the procedure moves to a step 406. In step 406, a TTL (Time To Live) field and dynamic header fields, such as a TCP (Transmission Control Protocol) field comprising a segment number, are read. It is then determined, in a step 408, whether the packet is valid, e.g., based on the read TTL field. If expired, the packet is discarded in a step 410. If the packet is still valid, a header translation is applied to the packet in a step 412, according to a translation scheme selected for the session, which is maintained during transfer through the router.

The header translation performed in step 412 includes replacing the header of the incoming packet with a modified and substantially reduced header according to the selected translation scheme which has been stored in the session context of the recognised session. The modified header preferably only comprises a context ID and the dynamic header fields . The context ID may be extracted from the stored hash look-up table checked in step 402. The packet, comprising the modified and reduced header and payload data, is finally forwarded from the ingress unit 200Ai to the egress unit 200Be over the switching unit 108, in a step 414. The egress unit 200Be receiving the packet then re-creates a proper header, including the received dynamic fields, by retrieving the stored session context matching the packet based on the received context ID. The egress unit 200Be then finally sends out the packet over the second network 102B towards the end station 104B. Since the header is modified and substantially reduced in size during transfer between the ingress and egress units 200Ai, 200Be, the packet transmission requires less resources within the router, e.g., in the switching unit 108, thereby enabling a higher data throughput and reducing delays .

It will now be described, with reference to Fig's 5 and 6, how a new session context is created. Fig. 5 is a flow chart illustrating the procedure executed at the originating interface unit 106A. As mentioned above, a first data packet not belonging to any existing session was sent to the control unit 202A for creating and storing a new session context in step 404 of Fig. 4. The new packet is thus received at the control unit 202A in a first step 500, and various header fields, such as those illustrated in Fig. 3 , are read in order to create the new session context . In a next step 502, it is checked whether it is possible to forward the packet to its destination and a forwarding decision is taken. It may then be checked if the packet is allowed to be transferred, based on predefined ingress policies, and if any route to its destination exists from the router. If it is not possible to forward the packet, it is discarded in a step 504.

If the packet is accepted in step 502, it is checked in a step 506 whether any translations of, e.g., protocols and addresses are necessary. If so, the translations are performed accordingly in a step 508 before proceeding to a next step 510. If no translations are necessary, the procedure moves directly from step 506 to step 510.

In the next step 510, a session context is created based on the header fields of the packet . Creating a new session context includes extracting session characteristics from the received packet, comprising any of: a source IP address, a destination IP address, a communication protocol, a required QoS, a source port number and a destination port number. The session context is created by defining context descriptors describing the session characteristics, which are valid at the originating and terminating sides. In particular, a header translation scheme is selected for the session context . The context descriptors may further include header templates, a forwarding decision and identifications of the ingress and egress units 200Ai, 200Be to be used during the session. Further, a context ID is assigned to the session in step 510 for identifying the session. The header translation scheme selected in the context shall be applied on further packets of the session during transfer in the router 100.

The first packet is then sent, along with the defined context descriptors and assigned context ID, to the control unit 202B at the terminating interface unit 106B in a step 512.

With reference to the flow chart of Fig. 6, the terminating interface unit 106B operates according to the following procedure when receiving the first data packet from the originating interface unit 106A. In a first step 600, the control unit 202B at the terminating interface unit 106B receives the first data packet which was forwarded from the originating interface unit 106A over the switching unit 108, in step 512 of Fig. 5.

The received first packet comprises the context descriptors defined at the control unit 202A and the assigned context ID. At the control unit 202B, it is then checked if it is possible to send out the packet, in a step 602. It may then be checked whether the packet is allowed to be sent according to egress policies, and whether an egress unit exists to the destined end station. If it is not possible to send the packet, the packet is discarded in a step 604. If the packet is allowed, it is checked whether the session context needs to be updated, in a step 606. It is thus checked if the received context descriptors are correct and valid, or if they must be updated.

If the received context descriptors must be updated, this is done in a step 608. Further forwarding decisions may then be taken and the received context descriptors may be modified, if necessary. Updating the context descriptors may be based on egress policies, security and QoS requirements for sending packets from the terminating interface unit 106B. Context descriptors may also be defined separately for the originating and terminating sides, which will be described later. The updated session context, including the defined and finalised context descriptors, is finally stored in the router together with the assigned context ID as a key, in a step 610.

The finalised context descriptors are then added to the packet in a step 612, after which the first packet can be forwarded to the selected egress unit 200Be in a step 614. The finalised context descriptors are stored at the egress unit 200Be with the context ID as a key. The packet is then restored based on the finalised context descriptors as being valid for the terminating egress context, and is finally sent out to its destined end station 104B, in a step 616. If no updating is needed in step 606, the process can move directly to the packet sending step 616.

After step 612, the finalised context descriptors are also sent back to the originating interface unit 106A in a step 618, and the updated and finalised context descriptors are stored there as well .

After the process of establishing the session context described in Fig's 5 and 6, the session context, including relevant context descriptors, have been stored in both the originating and terminating interface units 106A,B. Further packets of the session can then be smoothly transferred through the router 100, as described above in connection with Fig. 4, using the header translation according to the translation scheme defined for the session. The session context may be stored either in a common database or in separate databases at the originating and terminating interface units 106A, 106B, respectively. Also, a hash value, such as a check sum, may be calculated and stored in a hash look-up table, such that following packets can be identified as belonging to the same session context by checking the hash look-up table, as described above in step 402 of Fig. 4. Thereby, further packets can easily be recognised as belonging to the established session.

In one embodiment, context descriptors may be defined separately for the originating and terminating interface units 106A, 106B. Thus, when a first new packet is received at the control unit 202A of the originating interface unit 106A, originating context descriptors are defined based on ingress policies, security and QoS requirements for receiving packets at the originating interface unit 106A. Likewise, when the new packet is received at the control unit 202B of the terminating interface unit 106B, terminating context descriptors are defined based on egress policies, security and QoS requirements for sending packets from the terminating interface unit 106A.

Further, preliminary terminating context descriptors may be defined at the originating interface unit 106A, which may be modified when the first packet arrives at the terminating interface unit 106B. When the originating and terminating context descriptors are finalised, these are stored in the router together with an assigned context ID as a key, as described above.

In another embodiment, reverse context descriptors may be defined for packets to be transmitted in the opposite direction within the same session, based on the first received packet. Thus in total, the following four different context descriptors may be defined, with reference to Fig. 6:

1. An originating ingress descriptor 700Ai valid for packets from the originating side A when arriving at the ingress unit 200Ai of the originating interface unit 106A.

2. A terminating egress descriptor 700Be valid for packets from the originating side A when arriving at the egress unit 200Be of the terminating interface unit 106B.

3. A terminating ingress descriptor 700Bi valid for packets from the terminating side B when arriving at the ingress unit 200Bi of the terminating interface unit 106B.

4. An originating egress descriptor 700Ae valid for packets from the terminating side B when arriving at the egress unit 200Ae of the originating interface unit 106A.

In this way, a context descriptor is defined for packets in either direction and at either side of the router. Each of these context descriptors may comprise a header template, a forwarding decision and a selected translation scheme, as mentioned above. When all four context descriptors have been defined, these are stored as a session context together with an assigned context ID. Thereby, following packets in either direction can be recognised as belonging to the stored session context, and the packet header can be translated and substantially reduced in size at the ingress unit and re-created at the egress unit accordingly, as described above, for efficient transfer through the router.

By using the described invention, processing work and delays are reduced in the router when transferring data packets, thereby enabling a high data throughput and releasing functionality resources . The inventive method may be implemented in a software code running in a computer in the router 100. While the invention has been described with reference to specific exemplary embodiments, the description is only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention. Various alternatives, modifications and equivalents may be used without departing from the spirit of the invention, which is defined by the appended claims.

Claims

1. A method of transferring data packets over a router between a sending end station and a receiving end station, comprising the steps of:

A) receiving a data packet from the sending end station at an ingress ^"unit,

B) extracting information from a header in the packet,

C) determining whether the received data packet belongs to an existing session context by comparing the header information extracted in step B) with any existing session contexts stored in the router, characterised by the further steps of :

D) applying a header translation for the packet during transfer through the router from the ingress unit to an egress unit, according to a selected translation scheme, if the packet was recognised in step C) as belonging to an existing session context, wherein the header is replaced with a modified and substantially reduced header including a context ID assigned to the existing session context, or

E) creating a new session context if the packet was recognised in step C) as not belonging to any existing session context, including selecting a translation scheme to be used for applying a header translation for further packets of the new session, and

F) storing the new session context created in step E) in the router together with a context ID assigned to the new session context as a key.

2. A method according to claim 1, characterised in that the modified header applied in step D) further includes dynamic header fields and a TTL (Time To Live) field.

3. A method according to claim 1 or 2, characterised by the further step of re-creating the header at the egress unit after step D) by using the selected translation scheme and by retrieving the stored session context matching the packet based on the assigned context ID, before sending out the packet towards the receiving end station.

4. A method according to any of claims 1 - 3 , characterised in that step E) of creating a new session context includes determining session characteristics from the received packet, based on information extracted from the packet header and on predetermined rules or policies, comprising any of: a source IP address, a destination IP address, a communication protocol, a required QoS, a source port number and a destination port number.

5. A method according to any of claims 1 - 4, characterised in that step E) of creating a new session context includes taking a forwarding decision by checking if the packet is allowed to be transferred, based on predefined policies, and if any route to its destination exists from the router.

6. A method according to any of claims 1 - 5, characterised in that the new session context is created in step E) by defining context descriptors describing the characteristics of the data session.

7. A method according to claim 6, characterised in that the context descriptors comprises the selected header translation scheme and any of: header templates, a forwarding decision and identifications of ingress and egress units in the router to be used during the session.

8. A method according to claim 6 or 7, characterised in that the context descriptors are defined separately for originating and terminating interface units of the router.

9. A method according to claim 8, characterised in that the context descriptors are defined separately for ingress and egress units in each of the originating and terminating interface units, respectively.

10. A method according to any of claims 1 - 9, characterised in that step B) of extracting header information includes calculating a hash key from data in the header fields, such as a check sum, which is compared with a corresponding hash key of any stored session contexts.

11. A method according to any of claims 1 - 10, characterised in that the header information extracted in step B) comprises actual data in the header fields.

12. A router for transferring data packets between a sending end station and a receiving end station, comprising: - a first interface unit comprising an ingress unit for receiving data packets from the sending end station,

- a second interface unit comprising an egress unit for sending data packets to the receiving end station,

- a switching unit for transferring packets between the first and second interface units,

- means for extracting information from a header in a received data packet, - means for determining whether the received packet belongs to an existing session context by comparing extracted header information with any existing session contexts stored in the router, characterised by:

- means in the ingress unit for applying a header translation for the received packet during transfer through the router from the ingress unit to the egress unit, according to a selected translation scheme, if the packet belongs to an existing session context, including means for replacing the header with a modified and substantially reduced header including a context ID assigned to the existing session context,

- means for creating a new session context if the received packet does not belong to any existing session context, including means for selecting a translation scheme to be used for applying a header translation for further packets of the new session, and

- means for storing the created new session context in the router together with a context ID assigned to the new session context as a key.

13. A router according to claim 12, characterised in means in the egress unit for re-creating a header by using the selected translation scheme and by retrieving the stored session context matching the packet based on the assigned context ID, before sending out the packet towards the receiving end station.

14. A router according to claims 12 or 13 , characterised in that the means for creating a new session context includes means for determining session characteristics from the received packet, comprising any of: a source IP address, a destination IP address, a communication protocol, a required QoS, a source port number and a destination port number.

15. A router according to any of claims 12 - 14, characterised in that the means for creating a new session context includes means for taking a forwarding decision by checking if the packet is allowed to be transferred, based on predefined policies, and if any route to its destination exists from the router.

16. A router according to any of claims 12 - 15, characterised in that the means for creating a new session context includes means for defining context descriptors describing the characteristics of the data session.

17. A router according to claim 16, characterised in that the means for defining context descriptors includes means for selecting header translation scheme and any of : header templates, a forwarding decision and identifications of ingress and egress units in the router to be used during the session.

18. A router according to claim 16 or 17, characterised by means for defining context descriptors separately for originating and terminating interface units of the router.

19. A router according to claim 18, characterised by means for defining context descriptors separately for ingress and egress units in each of the originating and terminating interface units, respectively.

20. A router according to any of claims 12 - 19, characterised in that the means for extracting information from a header includes means for calculating a hash key from data in the header fields, such as a check sum, which is compared with a corresponding hash key of any stored session contexts .

21. A computer program product directly loadable into the internal memory of a computer in a router, comprising software code means for performing the method of any of the claims 1-11.

22. A computer program product stored on a computer usable medium, comprising readable program for causing a computer in a router to perform the method of any of the claims 1-11.