Abstract:
In a method and system for supporting resource reservation protocol (RSVP) in an Internet protocol version 4 (IPv4)/Internet protocol version 6 (IPv6) hybrid network, the method includes the steps of: transmitting, from a dual stack host in an IPv6 network, an end-to-end quality of service (QoS) session establishment request message to an IPv4 server through a dual stack transition mechanism tunnel end point (DSTM TEP); transmitting, from the IPv4 server, an end-to-end path message to the dual stack host through the DSTM TEP; transmitting, from the DSTM TEP to the dual stack host, a path message for reserving resources in the IPv6 network; transmitting, from the dual stack host, an end-to-end resource reservation request message to the IPv4 server through the DSTM TEP, and making a resource reservation in an IPv4 network; and transmitting, from the dual stack host to the DSTM TEP, a resource reservation request message, and making a resource reservation in the IPv6 network.

Description:
CLAIM OF PRIORITY 
       [0001]    This application makes reference to, incorporates the same herein, and claims all benefits accruing under 35 U.S.C. §119 from an application for RESOURCE RESERVATION PROTOCOL SUPPORTING SYSTEMAND METHOD ININTEGRATED IPv4/IPv6 NETWORK earlier filed in the Korean Intellectual Property Office on the 17 th  of Feb. 2006 and there duly assigned Serial No. 10-2006-0015844. 
       BACKGROUND OF THE INVENTION 
       [0002]    1. Technical Field 
         [0003]    The present invention relates to a method and system for supporting resource reservation protocol (RSVP) in an Internet protocol version 4 (IPv4)/Internet protocol version 6 (IPv6) hybrid network. 
         [0004]    2. Related Art 
         [0005]    The Internet has become the core infrastructure of the twenty-first century information oriented society. Traffic transmitted through the Internet has changed from text traffic of the past into multimedia traffic including sound, image and video, and high quality multimedia traffic requiring real-time processing, such as voice over Internet protocol (VoIP) service and Internet television service, is explosively increasing. 
         [0006]    Multimedia traffic carries a tremendous amount of data compared to conventional text traffic, and is sensitive to delay and jitter. Therefore, efforts have been made to provide quality of service (QoS) required for traffic, such as voice, video and data, of triple play service (TPS) having different characteristics in the current Internet. 
         [0007]    With the increase in such multimedia traffic and generalization of Internet use, the amount of traffic transmitted through the Internet is doubling every six months, and this tendency is predicted to continue in the future. Thus, it is necessary to build Internet infrastructure capable of efficiently accepting the rapid increase in Internet traffic. 
         [0008]    The current Internet is based on IPv4. According to IPv4, a source records a source address and a destination address in a packet and transmits the packet through the Internet in order to transmit traffic to the destination. Roughly, the Internet may be regarded as a router-based network in which, when a router receives the packet, it determines an interface to transmit the packet using its own routing table. 
         [0009]    The router compares the length of the packet with a maximum transmission unit (MTU) of the interface, and when the packet length is larger than the MTU, the router fragments the packet. The router determines whether the packet has an option and performs a proper action. However, the fragmentation, option checking and processing deteriorate performance of the router, and thus overall performance of the Internet. 
         [0010]    Furthermore, an IPv4 address has 32 bits, enabling a maximum of approximately four billion hosts to have access to the Internet. A very small number of hosts, however, are actually allowed to access the Internet due to the use of special addresses, subnetting, and inefficient address allocation caused by network address allocation. 
         [0011]    Meanwhile, with the generalization of the Internet and the increase in multimedia traffic, efforts have been continuously made to connect mobile communication terminals, electronic information appliances and the like, as well as computers, to the current Internet, unlike in the past. There are a great number of electronic information appliances, such as mobile communication terminals, televisions and refrigerators, and IPv4 addresses are extremely insufficient to connect such appliances to the Internet. 
         [0012]    Therefore, IPv6 technology has been suggested because it allows a substantially unlimited number of terminals to connect to the Internet and improves the overall performance of the Internet by addressing the inefficiency of IPv4. 
         [0013]    IPv6 is a protocol capable of preventing performance deterioration of the Internet caused by drawbacks of IPv4, and capable of efficiently accepting multimedia traffic needing real-time transmission, the drawbacks of IPv4 being caused because all transit routers between a source and a destination should check all options and perform fragmentation. 
         [0014]    In addition, IPv6 uses a 128-bit address system, and thus it can accommodate a substantially unlimited number of terminals. When an address system is changed from 32 bits to 128 bits, the content of a routing table required for a router to determine a path may increase. Since the address system of IPv6 has a structure of more layers than that of IPv4, it does not take a long time to find a proper path from the routing table. 
         [0015]    That is, the improved functions of IPv6 can resolve the performance problem of the current Internet caused by the rapid increase in Internet traffic and generalization of multimedia traffic. 
         [0016]    While IPv6 has considerably improved functions over IPv4, the current Internet is based on IPv4, and IPv4 and IPv6 are not directly compatible with each other. In addition, it is impossible to quickly change IP functions of all routers and hosts constituting the current Internet. 
         [0017]    Therefore, a shift from IPv4 to IPv6 will be gradually realized over a considerably long time. The Internet will be based upon IPv4 at the time when IPv6 is initially introduced, and then an IPv6 network will expand in size from utilization at specific enterprises or research institutes while the IPv4 network will reduce, achieving a natural shift to IPv6. Thus, it will be a main factor of the success of IPv6 to provide a mechanism capable of transmitting information between an IPv6 network connected host and an IPv4 network connected host. 
         [0018]    Accordingly, a transition mechanism is necessary to provide mutual compatibility, allowing hosts located in an IPv6 network and an IPv4 network to transmit and receive traffic between each other. 
         [0019]    For such a transition mechanism, the Internet Engineering Task Force (IETF) suggested a translation mechanism such as network address translation-protocol translation (NAT-PT) and a tunneling mechanism such as dual stack transition mechanism (DSTM). NAT-PT combines stateless IP/Internet control message protocol translator (SIIT) protocol translation and proper dynamic address translation of application level gateway (ALG), such as NAT and a domain name system (DNS) ALG, thereby allowing mutual communication between an IPv6-only node and an IPv4-only node. 
         [0020]    In other words, NAT-PT allows an IPv4 address to be dynamically allocated using an IPv4 address pool at a boundary between an IPv6 network and an IPv4 network. The NAT-PT binds an IPv6 network address to an IPv4 network address, and provides datagrams transmitted and received between address areas with transparent routing. 
         [0021]    In other words, nothing is changed at a terminal node using the NAT-PT mechanism, and IP packet routing becomes completely transparent to the terminal node. However, there is a restriction on the application of the NAT-PT transition mechanism. All responses and requests for one session should be routed through the same NAT-PT router. 
         [0022]    Furthermore, there is a difference in meanings between IPv4 fields and IPv6 fields, not allowing direct translation from IPv4 to IPv6. In addition, since the NAT-PT performs address translation in an IP layer, an application using an IP address in an upper layer does not normally work. An ALG is used to solve the problem. It is, however, essentially impossible to make an ALG in consideration of all of currently used applications and newly developed applications. Therefore, the address translation related problems cannot be resolved. 
         [0023]    Furthermore, the most important problem associated with NAT-PT is that security of an end-to-end network layer is impossible. When an IP address is used in the application layer, security of transport and application layers is also impossible. This is a limitation of the NAT function itself. Meanwhile, since IP security protocol (IPSec) security is impossible between different address areas, end nodes that want IPSec network level security should both support IPv4 or IPv6. In addition, IPSec security has a drawback in that domain name system (DNS)-security (SEC) cannot be applied. 
         [0024]    On the other hand, terminals located in an IPv6 network implement two protocol stacks of IPv4 and IPv6, and DSTM enables each terminal to communicate using the IPv6 stack when it connects to an IPv6 node, and enables the terminal to communicate using the IPv4 stack according to an IPv4-in-IPv6 tunneling mechanism when it connects to an IPv4 node. 
         [0025]    The DSTM provides a method for providing a temporary global IPv4 address to an IPv6 node, and for transmitting an IPv4 packet using a dynamic tunnel in an IPv6 network. The DSTM also provides a series of processes and architecture defining essential support infrastructure for this transition mechanism. 
         [0026]    When necessary, the DSTM designates an IPv4 address to a dual IP layer host. Then, an IPv6 host can communicate with an IPv4-only host, or an IPv4-only application can be executed without being modified at the IPv6 host. 
         [0027]    In other words, the DSTM is composed of a DSTM server, a tunnel end point (TEP), and a DSTM client, and when the DSTM client attempts to connect to an IPv4 node in an IPv4 network, it is allocated a temporary global IPv4 address by the DSTM server. 
         [0028]    When the DSTM client generates an IPv4 packet using the information in order to communicate with the IPv4 node, the node encapsulates the IPv4 packet using its own IPv6 address and IPv6 address information of the TEP, and then transmits the packet. The packet is an IPv6 packet. Thus, in a network including a DSTM node, the packet is transmitted to the TEP by means of an internal routing algorithm. 
         [0029]    When receiving the packet, the TEP builds a mapping table using the address included in an IPv6 header and the source IPv4 address of the IPv4 packet included in a payload of the IPv6 packet, removes the IPv6 header, and then transmits the IPv4 packet to the IPv4 node. The IPv4 node then transmits a reply packet in response to the received traffic, and the TEP receives the packet and sends it to the IPv6 node using tunneling. 
         [0030]    Meanwhile, RSVP is defined, RSVP being a resource reservation scheme to accommodate traffic requiring different QoS in an IP layer. According to the RSVP method, network resources are previously reserved for connection based on QoS, and when the reservation is not possible, resource reservation is rejected. 
         [0031]    The RSVP method is a technique which reserves required resources of all routers between a source and a destination in order to establish a flow, which is a type of virtual line, from the source to the destination, thereby ensuring QoS. The RSVP method may be called a flow-based model. 
         [0032]    In other words, RSVP may be defined as a signaling protocol for ensuring QoS based on a flow, and routers between a source node and a destination node reserve their resources using the signaling protocol. 
         [0033]    When a network to which the source node belongs is an IPv6 network, and a network to which the destination node belongs is an IPv4 network, interworking is essential between an RSVP operating in the IPv6 network and an RSVP operating in the IPv4 network in order to ensure QoS between the IPv6 network and the IPv4 network. However, only resource reservation in a single network, such as an IPv4-based network or an IPv6-based network, is defined in current RSVP. 
         [0034]    As described above, a conventional RSVP supporting mechanism allows establishment of a session for providing QoS in only a single network, such as an IPv4 network or an IPv6 network, but it cannot allow a session for providing QoS to be established in an IPv6-IPv4 hybrid network environment in which an IPv6 network and an IPv4 network are combined. 
         [0035]    In addition, because the current Internet is based on IPv4, servers such as a streaming server storing and transmitting traffic requiring real-time processing are generally located in an IPv4 network. Therefore, there is no series of processes for a dual stack host in an IPv6 network to establish a QoS session with a server located in the IPv4 network. 
       SUMMARY OF THE INVENTION 
       [0036]    It is an object of the present invention to provide a method and system for supporting resource reservation protocol (RSVP) in an Internet protocol version 4 (IPv4)/IPv6 hybrid network in which IPv4 and IPv6 networks coexist, wherein when a server for multimedia traffic is located in an IPv4 network, an end-to-end RSVP connection is established so that traffic transmitted from the server to a dual stack host located in an IPv6 network can be assured quality of service (QoS). 
         [0037]    According to an aspect of the present invention, a method for supporting RSVP in an IPv4/IPv6 hybrid network comprises the steps of: transmitting, from a dual stack host in an IPv6 network, an end-to-end QoS session establishment request message to an IPv4 server through a dual stack transition mechanism tunnel end point (DSTM TEP); transmitting, from the IPv4 server, an end-to-end path message to the dual stack host through the DSTM TEP; transmitting, from the DSTM TEP, a path message for reserving resources in the IPv6 network to the dual stack host; transmitting, from the dual stack host, an end-to-end resource reservation request message to the IPv4 server through the DSTM TEP, and making a resource reservation in an IPv4 network; and transmitting, from the dual stack host, a resource reservation request message to the DSTM TEP, and making a resource reservation in the IPv6 network. 
         [0038]    In the step of transmitting, from a dual stack host in an IPv6 network, an end-to-end QoS session establishment request message to an IPv4 server through a DSTM TEP, the QOS session establishment request message may have an IPv4 header, and may be encapsulated in an IPv6 packet and transmitted to the DSTM TEP by IPv4-in-IPv6 tunneling. 
         [0039]    The DSTM TEP stores, in a table, mapping information between a source IPv6 address included in the message transmitted from the dual stack host and an internal source IPv4 address, and then transmits an IPv4 packet from which an IPv6 header is removed to the IPv4 server. 
         [0040]    In the step of transmitting, from the IPv4 server, an end-to-end path message to the dual stack host through the DSTM TEP, the path message transmitted to the DSTM TEP may have a structure which includes path data, an RSVP header, and an IPv4 header. 
         [0041]    A destination address of an IPv4 packet, including the end-to-end path message, is an IPv4 address of the dual stack host. 
         [0042]    The DSTM TEP extracts an IPv6 address, mapped to an IPv4 address corresponding to the destination address of the IPv4 packet, from a mapping table, encapsulates the IPv6 address in an IPv6 packet, and then transmits the IPv6 packet to the dual stack host using IPv4-in-IPv6 tunneling. 
         [0043]    The path message transmitted by IPv4-in-IPv6 tunneling may have a structure including path data, an RSVP header, an IPv4 header, and an IPv6 header. 
         [0044]    In the step of transmitting, from the DSTM TEP, a path message for reserving resources in the IPv6 network to the dual stack host, the path message may have a structure including path data, an RSVP header, and an IPv6 header. 
         [0045]    In the step of transmitting, from the dual stack host, an end-to-end resource reservation request message to the IPv4 server through the DSTM TEP and making a resource reservation in an IPv4 network, the end-to-end resource reservation request message may have an IPv4 header, and may be encapsulated in an IPv6 packet and transmitted to the DSTM TEP by IPv4-in-IPv6 tunneling. 
         [0046]    The resource reservation request message transmitted to the DSTM TEP may have a structure including resource reservation request data, an RSVP header, an IPv4 header, and an IPv6 header. 
         [0047]    The DSTM TEP may transmit, to the IPv4 server, an IPv4 packet which is the resource reservation request message from which an IPv6 header is removed, the resource reservation request message being transmitted from a dual stack host. 
         [0048]    The IPv4 packet transmitted to the IPv4 server may make a resource reservation in each router while being transmitted in a hop-by-hop manner. 
         [0049]    In the step of transmitting, from the dual stack host, a resource reservation request message to the DSTM TEP and making a resource reservation in the IPv6 network, the resource reservation request message may have a structure including path data, an RSVP header, and an IPv6 header. 
         [0050]    The resource reservation request message transmitted to the DSTM TEP may make a resource reservation in each router while being transmitted in the hop-by-hop manner. 
         [0051]    According to another aspect of the present invention, a system for supporting RSVP in an IPv4/IPv6 hybrid network comprises a dual stack host which, when receiving an end-to-end path message transmitted from an IPv4 server through a DSTM TEP, transmits an end-to-end resource reservation request message to the IPv4 server through the DSTM TEP making a resource reservation in the IPv4 network, and transmits a resource reservation request message to the DSTM TEP making a resource reservation in the IPv6 network. 
         [0052]    The end-to-end path message transmitted to the DSTM TEP may have a structure including path data, an RSVP header, and an IPv4 header. 
         [0053]    A destination address of an IPv4 packet, including the end-to-end path message, may be an IPv4 address of the dual stack host. 
         [0054]    The DSTM TEP extracts an IPv6 address mapped to an IPv4 address corresponding to the destination address of the IPv4 packet from a mapping table, encapsulates the IPv6 address in an IPv6 packet, and then transmits the IPv6 packet to the dual stack host using IPv4-in-IPv6 tunneling. 
         [0055]    The path message transmitted by IPv4-in-IPv6 tunneling may have a structure including path data, an RSVP header, an IPv4 header, and an IPv6 header. 
         [0056]    The DSTM TEP transmits a path message for reserving resources in the IPv6 network to the dual stack host. 
         [0057]    The path message for reserving resources in the IPv6 network may have a structure including path data, an RSVP header, and an IPv6 header. 
         [0058]    The end-to-end resource reservation request message transmitted to the DSTM TEP may have an IPv4 header, and may be encapsulated in an IPv6 packet and transmitted to the DSTM TEP by IPv4-in-IPv6 tunneling. 
         [0059]    The end-to-end resource reservation request message transmitted to the DSTM TEP may have a structure including resource reservation request data, an RSVP header, an IPv4 header, and an IPv6 header. 
         [0060]    The DSTM TEP transmits, to the IPv4 server, an IPv4 packet which is the resource reservation request message from which an IPv6 header is removed, the resource reservation request message being transmitted from the dual stack host. 
         [0061]    The IPv4 packet transmitted to the IPv4 server makes a resource reservation in each router while being transmitted in a hop-by-hop manner. 
         [0062]    The resource reservation request message transmitted to the DSTM TEP may have a structure including path data, an RSVP header, and an IPv6 header. 
         [0063]    The resource reservation request message transmitted to the DSTM TEP makes a resource reservation in each router while being transmitted in the hop-by-hop manner. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0064]    A more complete appreciation of the invention, and many of the attendant advantages thereof, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein: 
           [0065]      FIG. 1  is a diagram illustrating a “SESSION_ASSOC” object of a typical resource reservation protocol (RSVP); 
           [0066]      FIG. 2  is a diagram illustrating a “NODE_CHAR” object of a typical RSVP; 
           [0067]      FIG. 3  is a diagram illustrating the flow of a path message of RSVP in a typical IPv4/IPv6 hybrid network; 
           [0068]      FIG. 4  is a diagram illustrating the flow of a reservation message of RSVP in a typical IPv4/IPv6 hybrid network; 
           [0069]      FIG. 5  is a diagram illustrating the flow of a tunnel path message of RSVP in a typical IPv4/IPv6 hybrid network; 
           [0070]      FIG. 6  is a diagram illustrating the flow of a tunnel reservation message of RSVP in a typical IPv4/IPv6 hybrid network; 
           [0071]      FIG. 7  is a diagram illustrating packet transmission through a plurality of tunnels in a typical IPv4/IPv6 hybrid network; 
           [0072]      FIG. 8  is a diagram illustrating the configuration of a system for supporting RSVP in an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention; 
           [0073]      FIG. 9  is a diagram illustrating a method for supporting RSVP in an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention; 
           [0074]      FIG. 10  is a diagram illustrating a process of transmitting an end-to-end path message in an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention; 
           [0075]      FIG. 11  is a diagram illustrating a process of transmitting a message for reserving resources in an IPv6 network of an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention; 
           [0076]      FIG. 12  is a diagram illustrating a process of reserving resources in an IPv4 network of an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention; and 
           [0077]      FIG. 13  is a diagram illustrating a process of reserving resources in an IPv6 network of an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0078]    Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. Like elements are denoted by like reference numerals throughout the drawings. In the following description, a detailed description of known functions and configurations incorporated herein has been omitted for conciseness. 
         [0079]      FIG. 1  is a diagram illustrating a “SESSION_ASSOC” object of a typical resource reservation protocol (RSVP). 
         [0080]    As illustrated in  FIG. 1 , the “SESSION_ASSOC” object includes a “Length” field having length information, a “Class” field having class information, a “Type” field having type information, a “SESSION Object” field having end-to-end session information, and a “FILTER_SPEC information” field having tunnel session information. 
         [0081]    The “SESSION_ASSOC” object is included in a path message transmitted from a transmitting end to a receiving end. 
         [0082]      FIG. 2  is a diagram illustrating a “NODE_CHAR” object of a typical RSVP. 
         [0083]    A “NODE_CHAR” object is used to enable a final node in a tunnel section so as to deliver, to an initial node in the tunnel section, information as to whether the final node can support a tunnel RSVP mechanism defined by “Request For Comments (RFC) 2746.” 
         [0084]    As illustrated in  FIG. 2 , when a final node in a tunnel section can support the tunnel RSVP mechanism, a “T” bit indicating whether the final node can support the RSVP is set in a “NODE_CHAR” object of a Resv message, which is transmitted from a receiving end to a transmitting end. 
         [0085]      FIG. 3  is a diagram illustrating the flow of a path message of RSVP in a typical IPv4/IPv6 hybrid network. 
         [0086]    In  FIG. 3 , a transmitting end (S 1 )  10  and a receiving end (D 1 )  20  are in an IPv4 network while a tunnel established between an initial node Rentry  31  and a final node Rexit  32  are in an IPv6 network. 
         [0087]    It is assumed that routers and nodes on the paths between the transmitting end  10  and the initial node  31 , between the initial node  31  and the final node  32 , and between the final node and the receiving end  20  are omitted. 
         [0088]    For example, when the transmitting end  10  wants to transmit traffic to the receiving end  20  at 10 Mbps, the transmitting end  10  transmits an end-to-end path message according to RSVP to the receiving end  20  in order to reserve a bandwidth of 10 Mbps between the two ends. 
         [0089]    The transmitting end  10  sets source address information of an IP header to its own IP address information “S_IP” and destination address information to IP address information “D_IP” of the receiving end  20 . 
         [0090]    The transmitting end  10  also sets the destination address information “D_IP” and destination port information “D_Port” in a “SESSION” object of the end-to-end path message, and sets source address information of a “SENDER_TEMPLATE” object to its own address information “S_IP” and source port information to its own port information “S_Port.” 
         [0091]    The end-to-end path message is transmitted with a “Router Alert IP option,” and thus is processed by all routers supporting RSVP between the transmitting end  10  and the receiving end  20 . 
         [0092]    When receiving the path message, the initial node Rentry  31  of the tunnel cannot recognize whether the final node Rexit  32  of the tunnel can support the RSVP mechanism, and thus stores a path status of an end-to-end session, and encapsulates and transmits the path message to Rexit  32 . 
         [0093]    Rexit  32  decapsulates the received encapsulated path message, sets up a path for the end-to-end session, and then transmits the path message to the receiving end  20 . 
         [0094]    When receiving the path message, the receiving end  20  transmits a Resv message to the transmitting end  10  in a hop-by-hop manner. 
         [0095]      FIG. 4  is a diagram illustrating the flow of a reservation message of RSVP in a typical IPv4/IPv6 hybrid network. 
         [0096]    Referring to  FIG. 4 , the receiving end  20  sets source address information of an IP header (Hdr) to “D_IP” and destination address information to IP address information of Rexit  32 , which is an upstream node (Next_Hop) supporting the RSVP mechanism, and transmits to Rexit  32  an RSVP message having a “SESSION” object including the same information as in the path message and a “FILTER SPEC” object including the same information as in a “SENDER_TEMPLATE” object of the path message. 
         [0097]    When receiving the Resv message from the receiving end  20 , Rexit  32  reserves a resource for an end-to-end session. Since there is no tunnel session mapped to the end-to-end session, Rexit  32  adds to the Resv message a “NODE_CHAR” object having a “T” bit set to inform Rentry  31  that a tunnel RSVP can be supported, and then encapsulates and transmits the Resv message to Rentry  31 . 
         [0098]    Rentry  31  decapsulates the received Resv message, removes the “NODE_CHAR” object, and then reserves resources for the end-to-end session. In addition, Rentry  31  transmits the Resv message from which the “NODE_CHAR” object is removed to the transmitting end  10 . 
         [0099]    In this regard, when Rentry  31  can support the tunnel RSVP mechanism, Rentry  31  transmits a tunnel path message to Rexit  32  while transmitting the Resv message to the transmitting end  10  through an uplink. 
         [0100]      FIG. 5  is a diagram illustrating the flow of a tunnel path message of RSVP in a typical IPv4/IPv6 hybrid network. 
         [0101]    Referring to  FIG. 5 , when receiving a Resv message, Rentry  31  which is an initial node of a tunnel establishes a tunnel session mapped to an end-to-end session, and transmits a tunnel path message and an end-to-end path message for indicating changed information on a path to Rexit  32  in order to reserve resources in the tunnel. 
         [0102]    Since the transmitting node of the tunnel path message is Rentry  31  and the receiving node is Rexit  32 , source address information of an IP header is set to “Entry_IP” which is address information of Rentry  31 , destination address information is set to “Exit_IP,” destination address information of a “SESSION” object is set to “Exit_IP”, and destination port information is set to, for example, “363.” 
         [0103]    Additionally, in a “SENDER_TEMPLATE” object of the tunnel path message, source address information becomes “Entry_IP,” and source port information becomes a specific value allocated by Rentry  31  in order to identify each flow in the tunnel. 
         [0104]    Such a tunnel path message allows nodes which exist in the tunnel established between Rentry  31  and Rexit  32 , and which support RSVP, to set up a path for the tunnel session. 
         [0105]    In addition, the end-to-end path message, including a “SESSION_ASSOC” object indicating mapping information between the end-to-end session and the tunnel session, allows Rexit  32  to map the tunnel session and the end-to-end session. 
         [0106]    When receiving the end-to-end path message, Rexit  32  sets up mapping information corresponding to the “SESSION_ASSOC” object of the end-to-end path message, removes the “SESSION_ASSOC” object, and then transmits a tunnel Resv message to Rentry  31 , in order to request resources of the tunnel session mapped in the end-to-end session, along the path set toward the receiving end in the tunnel. 
         [0107]      FIG. 6  is a diagram illustrating the flow of a tunnel reservation message of RSVP in a typical IPv4/IPv6 hybrid network. 
         [0108]    Referring to  FIG. 6 , source address information included in an IP header of a tunnel Resv message is set to “Exit_IP,” and destination address information is set to address information of an upstream node (Next_Hop) of Rexit  32  supporting RSVP. 
         [0109]    In addition, in a “SESSION” object of the tunnel Resv message, destination address information is set to “Exit_IP” and destination port information is set to “363.” In a “FILTER SPEC” object, source address information is set to “Entry_IP” and source port information is set to a value (e.g., 200) allocated for a tunnel session corresponding to an end-to-end session by Rentry  31 . 
         [0110]    The tunnel Resv message is transmitted to RSVP-supportable nodes in the tunnel which is established between Rexit  32  and Rentry  31  in the hop-by-hop manner, allowing each node to reserve tunnel resources. 
         [0111]      FIG. 7  is a diagram illustrating packet transmission through a plurality of tunnels in a typical IPv4/IPv6 hybrid network. 
         [0112]    Referring to  FIG. 7 , a case wherein a first transmitting end  10  has reserved resources for transmitting a packet to a first receiving end  20  at 10 Mbps, and wherein a second receiving end  10 ′ has reserved resources for transmitting a packet to a second receiving end  20 ′ at 20 Mbps, will be described below. 
         [0113]    Rentry  31  sets source port information for identifying sessions in a tunnel established for the first transmitting end  10  and the second transmitting end  10 ′ to “200” and “201,” respectively. 
         [0114]    When receiving a packet from the first transmitting end  10 , Rentry  31  encapsulates an IP header and a user datagram protocol (UDP) header of the packet for transmission to Rexit  32 . 
         [0115]    In the latter regard, destination port information of the encapsulated IP header and the UDP header of the packet are the same for all sessions, and source port information of the UDP header is set to a different value according to a session established between a transmitting end and a receiving end, and is then transmitted so that the RSVP-supportable node in the tunnel can identify each session based on the source port information of the received packet and can provide quality of service (QoS) required for each session. 
         [0116]    Rexit  32  decapsulates the IP header and UDP header of the received packet for transmission to the receiving end  20 . 
         [0117]      FIG. 8  is a diagram illustrating the configuration of a system for supporting RSVP in an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention. 
         [0118]    Referring to  FIG. 8 , the RSVP supporting system of the present invention comprises a dual stack host  100 , a DSTM server  200 , a DSTM terminal end point (TEP)  300 , a domain name server (DNS)  400 , and an IPv4-only server  500 . 
         [0119]    The dual stack host  100  is located in an IPv6 network. When the dual stack host  100  wants to receive multimedia traffic from the IPv4-only server  500  located in an IPv4 network and wants to ensure QoS for the traffic, the dual stack host  100  transmits a query message to the DNS  400  in order to obtain an IP address corresponding to the domain name of the server  500 . 
         [0120]    When receiving a response message including the IP address corresponding to the domain name of the IPv4-only server  500 , the dual stack host  100  confirms that the IPv4-only server  500  is located in the IPv4 network. 
         [0121]    Then, the dual stack host  100  transmits to the DSTM server  200  an address request message to obtain a temporary IPv4 address so as to connect to the IPv4-only server  500  using IPv4. 
         [0122]    After transmitting the address request message, the dual stack host  100  is allocated one temporary global IPv4 address from the DSTM server  200 , and is provided with IPv6 address information of the DSTM TEP  300 . 
         [0123]    The dual stack host  100  then transmits to the DSTM TEP  300  a message requesting to receive multimedia traffic based on QoS from the IPv4-only server  500 . 
         [0124]    In this regard, the message is transmitted to the DSTM TEP  300  by means of IPv4-in-IPv6 tunneling. More specifically, the message has an IPv4 header and is encapsulated again in an IPv6 packet. 
         [0125]    When the dual stack host  100  receives a path message from the DSTM TEP  300  after transmitting the message requesting to receive multimedia traffic, the dual stack host  100  generates and transmits a Resv message using Ipv4-in-IPv6 tunneling in order to reserve resources in the IPv4 network. 
         [0126]    In this regard, the Resv message transmitted to the DSTM TEP  300  has a structure which includes resource reservation request data (Resv data), an RSVP header (RSVP Hdr), an IPv4 header (IPv4 Hdr), and an IPv6 header (IPv6 Hdr). 
         [0127]    In addition, the dual stack host  100  generates another Resv message, adds an IPv6 header to the message, sets a destination address to the DSTM TEP  300 , and transmits the message using an IPv6 stack. 
         [0128]    More specifically, the Resv message transmitted to the DSTM TEP  300  has a structure which includes path data, an RSVP header (RSVP Hdr), and an IPv6 header (IPv6 Hdr). 
         [0129]    In this regard, the message is transmitted to the DSTM TEP  300  in the hop-by-hop manner, and reserves resources in each router existing in the IPv6 network during the transmission. When the packet arrives at the DSTM TEP  300 , a QoS connection is established between the dual stack host  100  and the DSTM TEP  300 . 
         [0130]    When receiving the address request message transmitted from the dual stack host  100 , the DSTM server  200  allocates the one temporary global IPv4 address to the dual stack host  100  and also provides the dual stack host  100  with the IPv6 address information of the DSTM TEP  300 . 
         [0131]    When the multimedia traffic reception request message is received from the dual stack host  100  by IPv4-in-IPv6 tunneling, the DSTM TEP  300  stores, in a table, mapping information between a source IPv6 address included in the received packet and an internal source IPv4 address, and then removes an IPv6 header and transmits an IPv4 packet having no IPv6 header to the IPv4-only server  500 . 
         [0132]    After transmitting the IPv4 packet having no IPv6 header to the IPv4-only server  500 , the DSTM TEP  300  receives a path message defined in RSVP from the IPv4-only server  500 . 
         [0133]    The DSTM TEP  300  then extracts an IPv6 address from its own mapping table, the IPv6 address corresponding to an IPv4 address which is a destination address of the packet received from the IPv4-only server  500 . 
         [0134]    In other words, the DSTM TEP  300  encapsulates the path message into an IPv6 packet using the IPv6 address information extracted from the mapping table, and then transmits the IPv6 packet to the dual stack host using IPv4-in-IPv6 tunneling. 
         [0135]    In this respect, the path message transmitted from the DSTM TEP  300  to the dual stack host  100  has a structure which includes path data, an RSVP header (RSVP Hdr), an IPv4 header (IPv4 Hdr), and an IPv6 header (IPv6 Hdr). 
         [0136]    In order to reserve resources in the IPv6 network, the DSTM TEP  300  generates a path message of RSVP, adds an IPv6 header to the path message, and then transmits the path message to the dual stack host  100 . 
         [0137]    In this regard, the path message transmitted to the dual stack host  100  has a structure which includes path data, an RSVP header (RSVP Hdr), and an IPv6 header (IPv6 Hdr). 
         [0138]    In addition, when receiving the Resv message through IPv4-in-IPv6 tunneling from the dual stack host  100 , the DSTM TEP  300  removes the IPv6 header of the transmitted packet, and then transmits the IPv4 packet, including the Resv message, to the IPv4-only server  500 . In this regard, the packet is transmitted in the hop-by-hop manner. 
         [0139]    In other words, the packet transmitted to the IPv4-only server  500  has a structure which includes resource reservation request data (Resv data), an RSVP header (RSVP Hdr), and an IPv4 header (IPv4 Hdr). 
         [0140]    In message transmission, resources are reserved in each router, and when the packet arrives at the IPv4-only server  500 , a QoS connection is established between the DSTM TEP  300  and the IPv4-only server  500 . 
         [0141]    The DNS  400  confirms that the address corresponding to the domain name of the IPv4-only server  500  is an IPv4 address in response to the query message from the dual stack host  100 , sets a type to “A,” and then transmits a response message, including the IPv4 address corresponding to the domain name of the IPv4-only server  500 , to the dual stack host  100 . 
         [0142]    The IPv4-only server  500  is located in the IPv4 network for providing the dual stack host  100  with multimedia traffic. When a decapsulated QoS session request message is received from the DSTM TEP  300 , the IPv4-only server  500  transmits the path message defined in RSVP to the dual stack host  100 . 
         [0143]    In other words, the path message transmitted by the IPv4-only server  500  is first transmitted to the DSTM TEP  300 , and the path message has a structure which includes path data, an RSVP header (RSVP Hdr), and an IPv4 header (IPv4 Hdr). 
         [0144]    In this respect, the destination address of an IPv4 packet included in the path message is an IPv4 address of the dual stack host  100 , and the packet is transmitted to the DSTM TEP  300 . 
         [0145]      FIG. 9  is a diagram illustrating a method for supporting RSVP in an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention,  FIG. 10  is a diagram illustrating a process of transmitting an end-to-end path message in an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention,  FIG. 11  is a diagram illustrating a process of transmitting a message for reserving resources in an IPv6 network of an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention,  FIG. 12  is a diagram illustrating a process of reserving resources in an IPv4 network of an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention, and  FIG. 13  is a diagram illustrating a process of reserving resources in an IPv6 network of an IPv4/IPv6 hybrid network according to an exemplary embodiment of the present invention. 
         [0146]    As illustrated in  FIG. 9 , when a dual stack host  100  located in the IPv6 network wants to receive multimedia traffic from an IPv4-only server  500  located in the IPv4 network and to ensure QoS for the traffic, the dual stack host  100  transmits a query message (Asks DNS for A RR for “H2”) to a DNS  400  in order to obtain an IP address corresponding to the domain name of the IPv4-only server  500  (S 10 ). 
         [0147]    In step S 20 , the DNS  400  confirms that the address corresponding to the domain name of the IPv4-only server  500  is an IPv4 address, sets a type to “A,” and then transmits a response message (Answer is 192.5.5.1) to the dual stack host  100 . 
         [0148]    In step S 30 , the dual stack host  100  receiving the response message from the DNS  400  confirms that the IPv4-only server  500  is located in the IPv4 network, and transmits an address request message (Request DSTM Server for an IPv4 address) to a DSTM server  200  in order to obtain one temporary IPv4 address to connect to the IPv4-only server  500  using an IPv4 protocol. 
         [0149]    In step S 40 , the DSTM server  200  receiving the address request message from the dual stack host  100  allocates (Provides a temporary IPv4 global address (H1_IPv4), TEP&#39;s IPv6 address (TEP_IPv6)) one temporary global IPv4 address to the dual stack host  100 . 
         [0150]    In step S 50 , the dual stack host  100  transmits to the IPv4-only server  500  a message requesting to receive multimedia traffic based on QoS (To request end-to-end QoS session). The message is transmitted by means of IPv4-in-IPv6 tunneling. More specifically, the message has an IPv4 header and is again encapsulated into an IPv6 packet. 
         [0151]    When the packet arrives at the DSTM TEP  300 , the DSTM TEP  300  stores, in a table, mapping information between a source IPv6 address included in the packet and an internal source IPv4 address (cache association Hi_IPv6-H1_IPv4), removes an IPv6 header, and then transmits an IPv4 packet to the IPv4-only server  500  (S 60 ). 
         [0152]    In step S 70 , the IPv4-only server  500  sends a path message defined in RSVP to the dual stack host  100  (Send E to E Path message). In this regard, the destination address of an IPv4 packet including the message is an IPv4 address of the dual stack host  100 , and the packet is transmitted to the DSTM TEP  300 . 
         [0153]    In other words, as illustrated in  FIG. 10 , the path message transmitted from the IPv4-only server  500  is transmitted to the DSTM TEP  300  first. In this regard, the path message has a structure which includes path data (Path data), an RSVP header (RSVP Hdr), and an IPv4 header (IPv4 Hdr). 
         [0154]    Furthermore, the destination address of the IPv4 packet included in the path message is the IPv4 address of the dual stack host  100 , and the packet is transmitted to the DSTM TEP  300 . 
         [0155]    In step S 80 , the DSTM TEP  300  extracts an IPv6 address corresponding to the IPv4 address, which is the destination address of the packet, from its own mapping table, encapsulates the IPv4 packet in an IPv6 packet using the information, and then sends the IPv6 packet to the dual stack host  100  using IPv4-in-IPv6 tunneling (Send E to E Path message (IPv4-in-IPv6)). 
         [0156]    More specifically, as illustrated in  FIG. 10 , the DSTM TEP  300  extracts the corresponding IPv6 address from its own mapping table using the IPv4 address which is the destination address of the packet received from the IPv4-only server  500 . 
         [0157]    After encapsulating the IPv4 packet in the IPv6 packet using the IPv6 address information extracted from the mapping table, the DSTM TEP  300  transmits the IPv6 packet to the dual stack host  100  using IPv4-in-IPv6 tunneling. 
         [0158]    In this regard, the path message transmitted from the DSTM TEP  300  to the dual stack host  100  has a structure which includes path data (Path data), an RSVP header (RSVP Hdr), an IPv4 header (IPv4 Hdr), and an IPv6 header (IPv6 Hdr). 
         [0159]    In step S 90 , in order to reserve resources in the IPv6 network, the DSTM TEP  300  generates a path message defined in RSVP, adds an IPv6 header to the path message, and transmits the path message to the dual stack host  100  (Send Path message (IPv6)). 
         [0160]    In other words, as illustrated in  FIG. 1 , in order to reserve resources in the IPv6 network, the DSTM TEP  300  generates the path message defined in RSVP, adds an IPv6 header to the path message, and transmits the path message to the dual stack host  100 . 
         [0161]    In this regard, the path message transmitted to the dual stack host  100  has a structure which includes path data (Path data), an RSVP header (RSVP Hdr), and an IPv6 header (IPv6 Hdr). 
         [0162]    In step S 100 , in order to reserve resources in the IPv4 network, the dual stack host  100  receiving the path message generates and transmits (Send EtoE Resv message (IPv4 in IPv6)) a Resv message using IPv4-in-IPv6 tunneling. 
         [0163]    In other words, as illustrated in  FIG. 12 , when the dual stack host  100  receives the path message from the DSTM TEP  300  after transmitting the message requesting to receive multimedia traffic, the dual stack host  100  generates and transmits the Resv message using IPv4-in-IPv6 tunneling in order to reserve resources in the IPv4 network. 
         [0164]    In this regard, the Resv message transmitted to the DSTM TEP  300  has a structure which includes resource reservation request data (Resv data), an RSVP header (RESVP Hdr), an IPv4 header (IPv4 Hdr), and an IPv6 header (IPv6 Hdr). 
         [0165]    When the packet is transmitted to the DSTM TEP  300 , the DSTM TEP  300  removes the IPv6 header and then transmits an IPv4 packet including the Resv message to the IPv4-only server  500  (Decapsulate IPv6 and Send E to E Resv message), in step S 110 . Here, the packet is transmitted to the server in the hop-by-hop manner. 
         [0166]    As illustrated in  FIG. 12 , the packet transmitted to the IPv4-only server  500  has a structure which includes resource reservation request data (Resv data), an RSVP header (RSVP Hdr), and an IPv4 header (IPv4 Hdr). 
         [0167]    In message transmission, resources are reserved in each router. When the packet arrives at the IPv4-only server  500 , a QoS connection is established between the DSTM TEP  300  and the IPv4-only server  500 . With this alone, however, an end-to-end QoS connection is not established. 
         [0168]    In order to establish an end-to-end QoS connection, resource reservation must be made in the IPv6 network. To this end, in step S 120 , the dual stack host  100  generates another Resv message, adds an IPv6 header to the message, sets a destination address to the DSTM TEP  300 , and then transmits the message using an IPv6 stack (Sends Resv message (IPv6)). 
         [0169]    As illustrated in  FIG. 13 , the Resv message transmitted to the DSTM TEP  300  has a structure which includes path data (Path data), an RSVP header (RSVP Hdr), and an IPv6 header (IPv6 Hdr). 
         [0170]    In this latter regard, the message is transmitted to the DSTM TEP  300  in the hop-by-hop manner, and resources are reserved in each router in message transmission. When the packet arrives at the DSTM TEP  300 , a QoS connection is established between the dual stack host  100  and the DSTM TEP  300 . 
         [0171]    As a result, when the QoS connections are established between the dual stack host  100  and the DSTM TEP  300 , and between the DSTM TEP  300  and the IPv4-only server  500 , the end-to-end QoS connection is established. 
         [0172]    According to the present invention, when a server for multimedia traffic is located in an IPv4 network of an IPv4/IPv6 hybrid network in which IPv4 and IPv6 networks coexist, traffic transmitted from the server to a dual stack host located in the IPv6 network can be assured QoS. Therefore, it is possible to ensure QoS through an end-to-end RSVP connection. 
         [0173]    While the present invention has been described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the present invention as defined by the following claims