WO2008047930A1

WO2008047930A1 - Tunneling processing apparatus and tunneling processing method

Info

Publication number: WO2008047930A1
Application number: PCT/JP2007/070499
Authority: WO
Inventors: Jun Hirano; Mohana Dhamayanthi Jeyatharan; Chan Wah Ng; Pek Yew Tan
Original assignee: Panasonic Corporation
Priority date: 2006-10-16
Filing date: 2007-10-15
Publication date: 2008-04-24

Abstract

The present invention discloses a technique, by which it is possible to grasp information relating to communication session of an encapsulated data packet (inner packet) by referring to the encapsulated packet when encapsulation of packets is performed by mobility support. According to this technique, an application 131 creates three different virtual tunnel interfaces 151, 152 and 153 with different configuration parameters to three communication sessions (flows) 231, 232 and 233. Also, an application 134 creates one virtual tunnel interface 154 for one flow 234. The packets of each flow are transmitted to each of the corresponding virtual tunnel interfaces from the application and are encapsulated. As a result, it is possible to logically differentiate the flows for the encapsulated packets to be transmitted from the same network interface 110.

Description

DESCRIPTION

TUNNELING PROCESSING APPARATUS AND TUNNELING PROCESSING

METHOD

TECHNICAL FIELD

The present invention relates to a tunneling processing apparatus for performing the processing of encapsulation and decapsulation of packets (tunneling of packets) in a packet switched data communication network.

BACKGROUND ART

In many protocols belonging to Internet Protocol suite, encapsulation of packets (or packet tunneling) is used. This packet encapsulation in IPv6 (Internet protocol version 6) is primarily defined in the Non- Patent Document 1 as given below.

For instance, in VPN (Virtual Private Network) , a large-scale private network is created by interconnecting two or more networks, which are present at different locations, by using tunneling technique. Also, in the mobility support in IPv6 (MlPvβ) , a mobile node can be reached at all times by its home address through the tunneling between the mobile node and the home agent. In the network mobility support (NEMO) in IPv6, a mobile router establishes a tunnel between the mobile router and its home agent. As a result, the entire network can roam in Internet while maintaining the ability be reached by using a mobile network prefix.

In IPv6 tunneling, encapsulation is performed to place an inner IPv6 packet (inner packet) as the payload of an outer IPv6 packet (outer packet) . The inner packet may also be called a payload packet, and the outer packet may be also called a tunnel packet.

Tunneling involves two entities, i.e. a tunnel entry node and a tunnel exit node. In the present specification, the tunnel entry node may be referred as a tunnel entry point or TEP, and the tunnel exit node may be referred as a tunnel exit point. Also, the tunnel entry node and the tunnel exit node may be comprehensively referred as tunnel end nodes or tunnel end points.

The tunnel entry node encapsulates a payload packet into a tunnel packet, which has an address of the tunnel entry node as source address and has an address of tunnel exit node as destination address. When the tunnel packet reaches the tunnel exit point, the payload packet is decapsulated and is forwarded as a normal packet. As a result, an overlay network can be effectively created on the existing routing infrastructure. Further, the payload packet may be encrypted so that an intermediate router can refer to the contents of the inner packet. Actually, such tunneling can be normally accomplished as an interface. That is, IP routing layer handles the tunnel as a network interface of a Layer 2, and the routing is determined according to the tunnel interface. In an application such as VPN, the tunnel end point is stable, while, in a tunnel established for mobility protocol, the tunnel end point is updated at all times to different status by changing care-of address . In order to conceal the complicated status caused by such change, the Patent Document 1 as given below describes a virtual interface to conceal the complicated status caused by mobility in an upper layer. Also, in the Patent Document 2 as given below, a method is described, by which a plurality of network interfaces are put together into a group by using virtual interfaces, is disclosed. Further, the Patent Document 3 as given below discloses an apparatus with a virtual interface, which can conceal the complicated status caused by the handover of sessions between a plurality of network interfaces. Also, the Patent Document 4 as given below discloses a technique, in which different protocols can coexist by using different virtual interfaces for each application. [Patent Document 1] U.S. Patent Application Publication No. 2006/0039407 [Patent Document 2] PCT International Application Publication No. WO 2002/059719

[Patent Document 3] U.S. Patent Application Publication No. 2004/0176023 [Patent Document 4] U.S. Patent Application Publication No. 2004/0095932

[Non-Patent Document 1] "Generic Packet Tunneling in IPv6 Specification"; RFC 2473; December 1998

In the tunneling, source address and destination address of the inner packet are concealed. Thus, in the existing routing infrastructure, routing is determined according to the outer packet.

On the other hand, in the IETF (Internet Engineering Task Force) , discussions are made particularly on NSIS (Next Step in Signaling) , which can perform signaling between intermediate routers to provide the quality of service (QoS) . For the purpose of offering different QoS for each communication session in the protocol, which handles such QoS, it is necessary to carry out the method, by which an intermediate router to offer QoS can differentiate the packets of different communication sessions. This differentiation of packets can be accomplished according to various fields of the packet header such as a source address, a destination address, a flow label, a security payload index (SPI) of IP security (IPSec) protocol, and a special extension field inserted into the packet as a hop-by-hop option.

However, in the IPv6 tunneling as described above, actual data packet (inner packet) , by which actual data packet (inner packet) carries information to differentiate the packet by the intermediate router for each flow, is encapsulated in the tunnel packet, and the intermediate router cannot use such information.

In the signaling protocol such as NSIS, the tunnel entry point must add a mark to the tunnel packet so that the intermediate routers, which are present along transmission path of the tunnel packet, can differentiate the tunnel packet for each flow according to the inner packet. This means that the tunnel entry point itself must have a mechanism to differentiate the inner packets.

However, the information relating to the flow parameter is normally information which can be used in a layer above a layer where the tunnel is created, or it is information which is derived from a layer above a layer where the tunnel is created. For instance, when offering QoS, the flows are identified in NSIS layer operated above the IP layer. On the other hand, the tunnel of mobile IPv6 or NEMO is generally created on the IP layer. Here, to facilitate the explanation, a layer where such flow parameters can be originally used is called "a flow layer", and a layer where the tunnel is created is called "a tunnel layer".

The flow layer and the tunnel layer are independent from each other. Different flows where different services or parameters are set up at the flow layer are tunneled according to the necessity of packet routing in the tunnel layer. In this case, the flow layer expects that individual processing is performed to match the setting of the flow with respect to the packet that makes up each flow, while the tunnel layer performs the tunneling. As a result, the packets relating to different flows are encapsulated by the same tunnel header.

In this respect, when the intermediate node for managing the flow performs flow processing according to the information of the packet header (source address, destination address or information added as option) , the processing is performed - not as a processing for each flow as expected by the flow layer - but as a processing in the unit of the same tunnel packet group. As a result, problems may occur such as the impossibility to meet the requirements as set up on the flow, insufficient communication resources, and further, the use of excessive resources needed to overcome the insufficiency of resources. In order to strengthen the cooperation between the layers independent from each other, the flow identification information must be delivered from a certain layer to the other layer, i.e. the information must be delivered from a flow layer to a tunnel layer. Therefore, API (Application Programming Interface) must be prepared in more complicated design. Further, the tunnels often have the same source address and the same destination address, and additional .means must be provided and maintained to differentiate the tunnel packets on the flow layer (i.e. the mapping of the flow identification information before the tunneling and the flow identification information after the tunneling must be maintained on the flow layer) . However, when such additional means is introduced, the situations may become more complicated.

DISCLOSURE OF THE INVENTION

To solve the above problems, it is an object of the present invention to provide a tunneling processing apparatus, by which it is possible to differentiate the tunnel packets for each of communication sessions on the encapsulated data packets (inner packets) when the packets of different communication sessions are transmitted via the same tunnel.

To attain the above object, the present invention provides a tunneling processing apparatus to be provided in a packet transfer apparatus fulfilling the function as a tunnel entry point to perform encapsulation of packets, said apparatus comprising: network connecting means for transmitting and receiving said packet; packet transfer means for performing transfer processing of said packet by referring to a routing table including a matching relation between identification pattern of said packet and transfer route of said packet; session management means for managing logical session of packet flow between two communication nodes; and tunnel management means for creating a virtual tunnel interface to encapsulate a packet of a specific session in response to a request from said session management means and for setting a matching relation between the identification pattern of the packet of said specific session and said virtual tunnel interface, wherein: encapsulation of said packets is performed in different virtual tunnel interfaces for each session.

With the arrangement as described above, it is possible to perform packet processing for each of communication sessions on the encapsulated data packets (inner packets) when the packets for different communication sessions are transmitted via the same tunnel and to generate an encapsulated packet (tunnel packet) , which can be differentiated for each communication session.

Further, the present invention provides the tunneling processing apparatus as described above, wherein a source address of encapsulated packet generated by different virtual tunnel interfaces is the same as a destination address.

With the arrangement as described above, it is possible to differentiate the encapsulated packets passing through the same tunnel for each of the communication sessions on the encapsulated data packets.

Also, the present invention provides the tunneling processing apparatus as described above, wherein identification information to identify said session is inserted in a packet header of the encapsulated packet generated at said virtual tunnel interface.

With the arrangement as described above, it is possible to grasp the communication session of the encapsulated data packet (inner packet) by referring to the encapsulated packet header (outer packet) and to perform packet processing for each communication session.

Further, the present invention provides the tunneling processing apparatus as described above, wherein, in case said tunnel management means stores configuration parameters of said abandoned virtual tunnel interface when said tunnel management means abandons said virtual tunnel interface and said abandoned virtual tunnel interface is re-configured, it is so arranged that said virtual tunnel interface is re-configured by using said configuration parameters stored in said predetermined information storage means.

With the arrangement as described above, it is possible to maintain the configuration parameters of virtual tunnel interface used previously and to use the maintained configuration parameters when the same virtual interface is to be reconstructed.

Also, the present invention provides the tunneling processing apparatus as described above, wherein said logical session is a single flow or a plurality of flows being put together to give QoS guarantee.

With the arrangement as described above, it is possible to differentiate the encapsulated packet for each logical session by regarding a single flow or a plurality of flow, which are put together and redefined, as a logical session to give QoS guarantee in the packet communication between different communication apparatuses.

Further, to attain the above object, the present invention provides a tunneling processing method to be executed when packets are encapsulated, said method comprising: a step where the tunnel managing apparatus prepares a virtual tunnel interface for encapsulating a packet of a specific session in response to a, request from a session managing apparatus for managing logical session of packet flows between two communication nodes; a step where said tunnel management apparatus sets up a matching relation between the identification pattern of a packet of said specific session and said virtual tunnel interface to a routing table, said routing table including a matching relation between identification pattern of said packet and a transfer route of said packet; a step where said session management apparatus transmits said packet with identification information to identify said specific session placed in a packet header to said tunnel management apparatus; and a step where said tunnel management apparatus delivers said packet to said matching virtual tunnel interface according to said identification information, wherein: encapsulation of said different packets is performed for each of said sessions by said virtual tunnel interface . With the arrangement as described above, it is possible to perform packet processing for each of communication sessions on the encapsulated data packets (inner packets) when the packets for different communication sessions are transmitted via the same tunnel and to generate an encapsulated packet (tunnel packet), which can be differentiated for each communication session.

Also, the present invention provides the tunneling processing method as described above, wherein said session management apparatus and said tunnel management apparatus are provided in the same apparatus or in different apparatuses.

With the arrangement as described above, an apparatus to transmit the data packet and an apparatus to encapsulate the packet by creating virtual tunnel interface can be realized by the same apparatus or these apparatuses can be different apparatuses .

The tunneling processing apparatus of the present invention has the arrangement as described above. When the packets of different communication sessions are transmitted via the same tunnel, it is possible to differentiate the tunnel packets for each of the communication sessions on the encapsulated data packets (inner packets). In particular, when the tunneling (encapsulation) of the packets is performed by mobility support, the router to transfer the inner packet can grasp the information relating to the communication session of the inner packet by referring to the tunnel packet.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram to show an example of functional architecture of a tunnel entry point in an embodiment of the present invention;

Fig. 2 is a schematical drawing to show an example of the relation between application, virtual tunnel interface and network interface in the mode of implementation of the invention;

Fig. 3 is a schematical drawing to show an example of network arrangement in the mode of implementation of the invention; Fig. 4A is a schematical drawing to show an aspect of communication in the mode of implementation of the invention;

Fig. 4B is a schematical drawing to show an aspect of communication in the prior art; Fig. 5A is a sequence chart to show another preferred embodiment in the mode of implementation of the present invention; and

Fig. 5B is a schematical drawing to show an example of arrangement to realize the sequence chart shown in Fig. 5A. BEST MODE FOR CARRYING OUT THE INVENTION

Description will be given below on the mode of implementation of the present invention referring to the attached drawings. According to the present invention, a routing unit is installed for providing a virtual tunnel at a tunnel entry point. This virtual tunnel is provided from the routing unit to a transport protocol or to an application, which is present at upper position above the routing unit so that the transport protocol or the application can differentiate the flow by using these virtual tunnels.

To facilitate the explanation, the term "application" is used hereinafter as a term to indicate the means to maintain logical communication session between two of the entities such as an arbitrary transport protocol, a session management utility or a user program. For instance, a single flow or a plurality of flows to give QoS guarantee are put together and re- defined, and this corresponds to a logical communication session. Also, as to be described later, these two entities may be nodes which are physically independent, and the "application" may not be executed by these two entities. An example of such application is a session management program started by an intermediate router. Fig. 1 is a schematical block diagram to show a functional architecture of the tunnel entry point as described above. The tunnel entry point 100 as shown in Fig. 1 comprises a network interface 110, a routing decision unit 120, one or more applications 130, and a tunnel manager 140.

The network interface 110 is a functional block including all types of hardware and software needed for communication, by which a mobile node performs communication with another node via an arbitrary communication medium. If the terminology well-known in the related technical field is used, the network interface 110 represents communication components of a Layer 1 (physical layer) and a Layer 2 (data link layer) , firmware, driver and protocol. Those skilled in the art would easily understand that the functional architecture of the tunnel entry point 100 can have one or more network interfaces 110.

The routing decision unit 120 has a function to perform the processing to decide a method for transmitting the packets. If the terminology well-known in the related technical field is used, the routing decision unit 120 is mounted with a Layer 3 (network layer) protocol such as IPv4 or IPv6 (Internet Protocol version 4 or 6), for instance. In order to support the processing on the decision to be made at the routing decision unit 120, a routing table 125 is provided where the rules to prescribe the routing of the packets are included. Preferably, a list of routing entries is included in the routing table 125. In each of the routing entries, address of the next hop node,- to which the packet is to be delivered, and/or the network interface 110 or the virtual tunnel interface are prescribed in relation to the destination address and the source address or other information obtained from the packet to be transmitted. The routing decision unit 120 can update the entries in the routing table 125 via a signal/data path 175 or can extract the entries from the routing table 125. Also, the routing decision unit 120 can transmit or receive a packet at an adequate network interface 110 via a signal/data path 171. Further, the routing decision unit 120 can transmit or receive the packets at an adequate virtual tunnel interface 150 via a signal/data path 172. The application 130 has the functions of a transport protocol, a session management entity or a user program to maintain logical communication session between two entities. If the terminology well-known in the related technical field is used, the application 130 represents a software program or a communication protocol in a Layer 4 (transport layer), a Layer 5 (session layer), a Layer 6 (presentation layer) or a Layer 7 (application layer) . Also, the routing decision unit 120 can transmit or receive the packets at the application 130 via a signal/data path 173.

According to the present invention, a tunnel manager 140 is introduced. The application 130 can request the establishment of a new virtual tunnel interface 150 to this tunnel manager 140. In order to accomplish this, the tunnel manager 140 provides an application programming interface (API) to the application 130 via a signal/data path 184. Also, the tunnel manager 140 can carry out the management (such as creation, maintenance and revocation, etc.) of the virtual tunnel interface 150 via a signal/data path 185.

When the virtual tunnel interface 150 is created, the tunnel manager 140 must insert a new routing entry into the routing table 125. When the routing entry of the virtual tunnel interface is inserted into the routing table 125, the routing decision unit 120 can transmit the packet to the virtual tunnel interface 172. Similarly, when the virtual tunnel interface 150 is abandoned or revoked, the tunnel manager 140 must remove the corresponding routing entry from the routing table 125. When the routing entry of the virtual tunnel interface is removed from the routing table 125, the routing decision unit 120 does not transmit the packet any more to the revoked virtual tunnel interface 172. To accomplish the insertion or the deletion of the entry to the routing table 125 by the tunnel manager 140 as described above, it is so arranged that the tunnel manager 140 can change the contents of the routing table 125 via a signal/data path 182. Also, as described above, when the application 130 needs a new virtual tunnel interface 150 for its session, the creation of the virtual tunnel interface 150 can be requested to the tunnel manager 140 through API offered via the signal/data path 184. Preferably, API is accomplished by using a special interface offered according to the existing network programming interface such as Microsoft Winsock or BSD (Berkeley Software Distribution) socket interfaces, while it is not limited to these. For instance, it is preferable that the application 130 can describe an option to request the creation of a new virtual tunnel interface 150 to the tunnel manager 140 in the socket () API during the course of implementation of BSD socket. Also, as one of the preferred modes of implementation of the tunnel manger 140, it may be so arranged that the application 130 can offer a special tag to be executed to a tunnel packet relating to the virtual tunnel interface 150 via API provided through the signal/data path 184. For instance, the application 130 can preferably describe an option with such a tag by using API of setsockopt () function under the condition that BSD socket is implemented. Such tagging is preferably- accomplished by the setting a specific flow label to a flow label field of IPv6 header of the tunnel packet or by the addition of a specific Router Alert Option to the hop-by-hop option of the tunnel packet, while it is not limited to these.

When the virtual tunnel interface 150 is created, the application 130 has no need to specify the source address or the destination address of the tunnel. The present invention can be applied to the tunnel entry points where the tunnel must be present (home agent or mobile router in NEMO basic support, home agent or mobile host of mobile IPv6, or security gateway of the virtual private network) . Each of the virtual tunnel interfaces 150 is a duplication of an existing tunnel, and the source address and the destination address can be obtained form the existing tunnel instead of specifying by the application 130. When the virtual tunnel interface 150 is created and adequately set up, the tunnel manager 140 can insert a route into the routing table 125, and the packet received by the routing decision unit 120 can be transmitted to an adequate virtual tunnel interface 150 (e.g. a packet, which has specific concurrent parameters such as source address, destination address, port number, flow label or the presence of a value in the hop-by-hop header) . This can also be applied to the packet which the routing decision unit 120 receives from the network interface 110 or the application 130. In another mode for carrying out the invention, it may be so arranged that, when the virtual interface 150 is created, the data path 195 to directly transmit and receive the packet to and from the virtual tunnel interface 150 is provided to the application 130. Those skilled in the art would easily understand that a first mode of operation (in which the packet is transmitted from the application 130 to the routing decision unit 120 and is sent to the virtual tunnel interface 150) is more adequate for an entity of small scale management, and a second mode of operation (in which the application 130 directly transmits the data to the virtual tunnel interface 150) is more adequate for a socket-oriented communication program.

Further, those skilled in the art would obviously understand that there is no substantial difference between these two modes of operation. In both modes of the operation, the packet transmitted from the application 130 is delivered to the virtual tunnel interface 150 and is processed. Each of the created virtual tunnel interfaces 150 has the function to perform encapsulation on the outgoing packet and decapsulation of the incoming packet. When the outgoing packet is encapsulated, the virtual tunnel interface 150 inserts an adequate tag specified by the application 130 to a tunnel packet header. Then, the tunnel packet is delivered to the routing decision unit 120 and is transmitted.

In an apparatus described in the present invention, a simple and effective mechanism can be provided, by which it is possible to differentiate the logic flow passing through the tunnel to the application 130. With regard to this, description will be given below by referring to Fig. 2.

In Fig. 2, two different applications 131 and 134 are shown. The application 131 performs management on three different communication sessions (flows) 231, 232 and 233. The application 134 maintains one communication session (flow) 234. Regarding the three flows 231, 232 and 233, the application 131 requests the creation of three virtual tunnel interfaces 151, 152 and 153 to the tunnel manager 140. Also, regarding the flow 234, the application 234 requests the creation of one virtual tunnel interface 154 to the tunnel manager 140.

As shown in Fig. 2, the flows 231, 232, 233 and 234 are transmitted to the different virtual tunnel interfaces 151, 152, 153 and 154 respectively. As a result, even when the virtual tunnel interfaces 151, 152, 153, and 154 transmit the encapsulated packets ultimately to the same network interface 110 via flow paths 251, 252, 253 and 254 respectively, the applications 131 and 134 can logically differentiate the flows 231, 232, 233 and 234. From the network interface 110, these flows are integrated into a single outgoing stream 210.

Even in case of the packets of different flows, these can be ultimately integrated to a single outgoing stream. According to the present invention, when the applications 131 and 134 configure the virtual tunnel interfaces 151, 152, 153 and 154 differently from each other, each tunnel packet can include different parameters such as IPv6 flow label or different router alert options. These parameters are useful in case a router existing along the path of the tunnel differentiates the tunnel packet for each flow.

With regard to this usefulness, description will be given now by referring to the examples shown in Fig. 3, Fig. 4A and Fig. 4B. Fig. 3 shows an example of a scenario, according to which the effects of the present invention can be preferably realized. MR 310 is a mobile router, which controls (manages) a mobile network 305, and it is roaming in Internet 300. In a mobile network 305, two mobile nodes MN 330 and MN 332 are present. A home agent of the mobile router MR 310 is HA 320. The mobile nodes MN 330 and 332 have communication sessions to and from a correspondent node CN 340. In the network mobility support, the packets transmitted from MN 330 or MN 332 are encapsulated by MN 310 and are tunneled to HA 320. HA 320 decapsulates the packet and transfers it to CN 340. Similarly, the packet transmitted from CN 340 to MN 330 or MN 332 is intercepted by HA 320. In this case, HA 320 encapsulates the intercepted packet and tunnels it to MR 310. MR 310 decapsulates the packet and transfers it to MN 330 or to MN 332.

Here, it is assumed that QoS support is needed in the communication session between MN 330 or MN 332 and CN 240. This is present along the communication path, for instance, and it is provided by special routers to perform communication by using NSIS (Next Step in Signaling) protocol. These special routers are known in the related technical field as NSIS entities (or NEs) .

In Fig. 3, NEs (i.e. three NEs 350, 352 and 354) are shown. NE 350 and NE 352 are present along the tunnel from MR 310 to HA 320. NE 354 is present along the path from HA 320 to CN 340.

According to the prior art, different sessions of MN 330 and MN 332 are encapsulated by the same tunnel between MR 310 and HA 320. Therefore, unless MR 310 places the complicated flow mapping under management, NE 350 and NE 352 cannot differentiate these sessions. According to the present invention, such mapping can be easily accomplished.

In Fig. 4A, an example of the effects of the present invention is shown. Fig. 4B shows an example according to the prior art. In Fig. 4A and Fig. 4B, MN 332 has two different communications between CN 340 and itself. MN 330 has a communication session between CN 340 and itself. These communication sessions are differentiated by application processes App 431 and App 432 at MN 332 and by an application process App 433 at MN 330. Also, the corresponding application processes at CN 340 are App 435, App 436 and App 437. Three communication sessions are present between App 431 and App 435, between App 432 and App 436, and between App 433 and App 437.

With regard to Fig. 4A, the NSIS management program on MR 310 creates three different virtual tunnel interfaces for the communication flows to and from MN 330, MN 332 and CN 340 by using the apparatus offered by the present invention. When these virtual tunnel interfaces are created, the NSIS management program can prescribe each flow label for the tagging with respect to the packet encapsulated by the virtual tunnel interfaces.

Also, the NSIS management program can differentiate the packets by each flow label to the packets encapsulated by three virtual tunnel interfaces by using NSIS signaling to NE 350 and NE 352 respectively and can also request so that the quality of service can be offered according to QoS needed by MN 330, MN 332 and CN 350. Therefore, according to the present invention, the NSIS management program can create three different logical tunnels between MR 310, passing through NE 350 and NE 352, and HA 320, even when the tunnel packet has the same source address and the same destination address.

Fig. 4A shows an example of the creation of different logical tunnels as described above. A packet transmitted from App 431 to CN 340 is sent along a path 441 and is intercepted by MR 310. The NSIS management program sends the packet via a first virtual tunnel interface, which is shown as a virtual tunnel 451 in Fig. 4A. The virtual tunnel 451 reaches HA 320 via NE 350 and NE 352. HA 320 decapsulates the packet, and the packet is transferred to CN 350 along a path 461. In the initial NSIS setup between MN 332 and CN 340, the path 461 passes through NE 354.

Similarly, the packet transmitted from App 432 to CN 340 is sent along a path 442 and is intercepted by MR 310. The NSIS management program sends the packet via a second virtual tunnel interface, which is shown as a virtual tunnel 452 in Fig. 4A. The virtual tunnel 452 reaches HA 320 via NE 350 and NE 352. HA 320 decapsulates the packet, and the packet is transferred to CN 340 along a path 462. In the first NSIS setup between MN 332 and CN 350, the path 462 passes through NE 354.

Similar to the two flows as described above, the packet transmitted from App 433 to CN 340 is sent along a path 443 and is intercepted by MR 310. The NSIS management program sends the packet via a third virtual tunnel interface, which is shown as a virtual tunnel 453 in Fig. 4A. The virtual tunnel 453 reaches HA 320 via NE 350 and NE 352. HA 320 decapsulates the packet, and the packet is transferred to CN 340 along a path 463. In the initial NSIS setup between MN 332 and CN 350, the path 463 passes through NE 354.

Fig. 4B shows an example of a packet flow (a packet flow according to the prior art) is shown in case where the present invention is not applied. When the present invention is not applied, there is only one logical tunnel between MR 310 and HA 320. Therefore, the packets transmitted from App 431, App 432 and App 433 are all converged to a single tunnel 450. In order to continuously provide the requested QoS level, the NSIS management program of MR 310 must request an aggregated QoS level to the tunnel 450 so that all of the three flows from App 431, App 432 and App 433 can be supported.

For instance, it is assumed here that the session between App 431 and App 435 is a file transfer requiring high bandwidth, that a session between App 432 and App 436 is real-time voice communication, which requires the reduction of delay, and that a session between App 433 and App 437 is a video-on-demand streaming, which requires lower jitter.

In Fig. 4B, all flows pass through the same tunnel. Thus, although it is only necessary that high bandwidth is required for a certain packet, and even when only lower jitter is required for other packets, according to a prior art, the NSIS management program of MR 310 must request the quality of service of high bandwidth, low delay and low jitter to NE 350 and NE 352. Even for those packets which have no need to receive QoS support as such, the quality of service is offered when the packet passes through the tunnel 450 from MR 310 to HA 320. This is apparently wasteful use of the network resources.

On the other hand, according to the present invention, NE 350 and NE 352 comprehend that the communication sessions are logically different tunnels as shown in Fig. 4A. Therefore, based on the requirements of qualities of service, it is possible to perform different processings on the packets, which pass through the tunnels.

In the preferred mode for carrying out the invention as described above, the application 130 to create the virtual tunnel interfaces 150 is present on the same machine as that of the tunnel manager 140 as shown in Fig. 1. Accordingly, it would be obvious to those skilled in the art that the present invention is not limited to the mode of implementation as described above. For instance, the application 130 has no need to be present on the same machine as the tunnel manager 140.

Fig. 5A shows another preferred arrangement example in the mode of carrying out the present invention. In Fig. 5A, when an entity 510 is going to start the communication session, it is checked first whether the tunnel entry point is present along the path or not. To carry out this processing, a TEP-Discovery message 530 is sent from the entity 510. The tunnel entry point 520 gives a response to this message. In Fig. 5A, the tunnel entry point 520 is present along the path, and a TEP-Response message 540 is sent back from the tunnel entry point 520 to the entity 510. In this case, the entity 510 remotely creates the virtual tunnel interface to the tunnel entry point 520 by using a Virtual Tunnel Create Req message 550. Preferably, configuration parameters to make up the virtual tunnel interfaces such as flow label to be used in the tunnel packet are included in the Virtual Tunnel Create Req 550 message.

When the virtual tunnel interfaces are created normally, the tunnel entry point 520 gives a response by sending a Virtual Tunnel Status message 560 and indicates that the virtual tunnel interfaces are created in normal manner. The virtual tunnel status message 560 preferably contains virtual tunnel interface identification information to identify the created virtual tunnel interfaces so that the entity 510 can identify. When a data packet 570 is transmitted via the created virtual tunnel interfaces, the entity 510 must include tunnel identification information 574 in the data packet in addition to the normal IPv6 header 572 and a data payload 576.

The tunnel identification information 574 has a function to notify the tunnel entry point 520 as to which of the virtual tunnel interfaces should be used. In this case, the tunnel entry point 520 can encapsulate the data packet 570 into a tunnel packet 580 according to the configuration parameters of the virtual tunnel interface.

An outer IPv6 header 582, the original IPv6 header 572, and a data payload (data) 576 are included in the tunnel packet 580. The tunnel identification information 574 is information not required for other nodes, and the tunnel identification information 574 is preferably removed from the packet before the packet is encapsulated by the tunnel entry point 520. The IPv6 header 582 of the tunnel packet 580 contains, for instance, a value described in the virtual tunnel create req message 550 (i.e. a value configured by the entity 510) such as a specific flow label value or a special hop-by-hop option. As described above, by using an apparatus disclosed by the present invention, it is possible to accomplish the preferred mode for carrying out the invention to remotely create the virtual tunnel interfaces. Fig. 5B shows an example of remote creation of the virtual tunnel interfaces in the mode for carrying out the present invention. In Fig. 5B, the application 130 implemented at the tunnel entry point 520 may be a daemon to supervise the virtual tunnel create req message 550 from a remote entity such as the entity 510 In Fig. 5B, when the virtual tunnel create req message 550 is received. The application 130 requests the tunnel manager 140 via the signal path 184 to create the virtual tunnel interfaces 150. The application 130 sends back the virtual tunnel status message 560 to the entity 510. When the entity 510 transmits the data, the application 130 sends the data from the virtual tunnel interface 150 via the data path 195.

Also, the application 130 can perform the setup of the routing entry of the routing table (not shown in Fig. 5B) . In so doing, the data containing specific tunnel identification information transmitted from the entity 510 is sent via the virtual tunnel interface 150 from the routing decision unit (not shown in Fig. 5B) . In the description as given above, assumption is made on a case where the tunnel entry point is stable

(i.e. a case where the tunnel entry point must maintain a tunnel to another node at all times) . However, in a protocol, which requires the use of a tunnel including a mobility protocol such as mobile IPv6, no tunnel is needed when the mobile node goes back home. In such case, the tunnel manager 140 transmits a signal to indicate the deletion of the tunnel to the application 130, which created the virtual tunnel interface 150. In this case, a mechanism to selectively store the parameters of the virtual tunnel interfaces created at memory location in the tunnel manager 140 is preferably offered to the application 130 from the tunnel manager 140. In so doing, if the tunnel is needed again (e.g. when the mobile node moves away from home) , it can be so arranged that the virtual tunnel interface created earlier is automatically re-created by using the parameters previously configured. Here, the virtual tunnel interface can remain while there is actually no packet encapsulation taking place.

In the above, description has been given only on the tunnel in a single direction, while data flow is normally bi-directional in the tunnel. Therefore, a tunnel entry point in a certain direction is a tunnel exit point in reverse direction. On the contrary, a tunnel exit point in a certain direction is a tunnel entry point in reverse direction. It would be obvious to those skilled in the art that the present invention does not exert influence on the receiving of the tunnel packet (i.e. on the operation at the tunnel exit point) Also, it would be obvious to those skilled in the art that two tunnel end points of bi-directional tunnel can constitute a system to provide a mirror image (symmetrical) virtual tunnel interfaces with respect to bi-directional data flow, which passes through two tunnel end points. Also, there is possibility that some message signaling is required between the applications 130 of the tunnel end point. Those skilled in the art would easily understand that such message signaling depends on the quality of the application. Such message signaling includes: an option inserted in the binding update when two tunnel end points are a mobile IPv6 host or a mobile router and its home agent, a message inserted in NSIS signaling, a specific message option to be used in dedicated secure shell session, or a specific message option of other signaling protocol, but it is not limited to these.

In the present specification, description and drawings have been described and shown by giving due consideration that the most practical and the preferred embodiment of the invention is presented. However, it would be obvious to those skilled in the art that various changes and modifications can be made in the details of design and parameters without departing from the scope and the spirit of the invention.

For instance, it would be obvious that the present invention can be applied to any type of tunnel end point such as a mobile node, a mobile router, a home agent in mobile IP, a home agent in network mobility, virtual private network gateway, or IPv6/IPv4 transition gateway. Each of the functional blocks used in the description of the mode for carrying out the invention can be realized as LSI (Large Scale Integration) typically represented by an integrated circuit. These may be produced individually in one chip or may be designed as one chip including a part or all. Here, it is referred as LSI, while it may be called IC (Integrated Circuit) , system LSI, super LSI or ultra LSI, depending on the difference in the degree of integration.

Also, the method to produce the integrated circuit is not limited to LSI, and it may be realized by a dedicated circuit or a general-purpose processor. After the manufacture of LSI, FPGA (Field Programmable Gate Array) , which can be programmed after the manufacture of LSI, or a reconfigurable processor, which can reconfigure the connection and the setting of circuit cells inside LSI, may be used.

Further, with the progress of semiconductor technique or other technique derived from it, if a new technique of circuit integration to replace LSI may emerge, the functional blocks may be integrated by using such technique. For instance, the adaptation of biotechnology is one of such possibilities.

INDUSTRIAL APPLICABILITY The present invention has such effects that tunnel packets can be differentiated for each communication session of inner packet when packets of different communication sessions are transmitted via the same tunnel, and the invention can be applied to the technical field where the processing relating to encapsulation or decapsulation (packet tunneling) of the packet is performed.

Claims

1. A tunneling processing apparatus to be provided in a packet transfer apparatus fulfilling the function as a tunnel entry point to perform encapsulation of packets _r said apparatus comprising: network connecting means for transmitting and receiving said packet; packet transfer means for performing transfer processing of said packet by referring to a routing table including a matching relation between identification pattern of said packet and transfer route of said packet; session management means for managing logical session of packet flow between two communication nodes; and tunnel management means for creating a virtual tunnel interface to encapsulate a packet of a specific session in response to a request from said session management means and for setting a matching relation between the identification pattern of the packet of said specific session and said virtual tunnel interface, wherein: encapsulation of said packets is performed in different virtual tunnel interfaces for each session.

2. The tunneling processing apparatus according to claim 1, wherein a source address of encapsulated packet generated by different virtual tunnel interfaces is the same as a destination address.

3. The tunneling processing apparatus according to claim 1, wherein identification information to identify said session is inserted in a packet header of the encapsulated packet generated at said virtual tunnel interface.

4. The tunneling processing apparatus according to claim 1, wherein, in case said tunnel management means stores configuration parameters of said abandoned virtual tunnel interface when said tunnel management means abandons said virtual tunnel interface and said abandoned virtual tunnel interface is re-configured, it is so arranged that said virtual tunnel interface is reconfigured by using said configuration parameters stored in said predetermined information storage means.

5. The tunneling processing apparatus according to claim 1, wherein said logical session is a single flow or a plurality of flows being put together to give QoS guarantee.

6. A tunneling processing method to be executed when packets are encapsulated, said method comprising: a step where the tunnel managing apparatus prepares a virtual tunnel interface for encapsulating a packet of a specific session in response to a request from a session managing apparatus for managing logical session of packet flows between two communication nodes; a step where said tunnel management apparatus sets up a matching relation between the identification pattern of a packet of said specific session and said virtual tunnel interface to a routing table, said routing table including a matching relation between identification pattern of said packet and a transfer route of said packet; a step where said session management apparatus transmits said packet with identification information to identify said specific session placed in a packet header to said tunnel management apparatus; and a step where said tunnel management apparatus delivers said packet to said matching virtual tunnel interface according to said identification information, wherein: encapsulation of said different packets is performed for each of said sessions by said virtual tunnel interface.

7. The tunneling processing method according to claim 6, wherein said session management apparatus and said tunnel management apparatus are provided in the same apparatus or in different apparatuses.