Operating method for communication network

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to data communication and computer networking.

【0002】

[Conventional technology]

In the field of data communications, how devices talk to each other is a major concern. For example, in the case of humans, people use and understand each other for devices that talk to each other. These languages correspond to so-called communication protocols. This protocol is agreed with a standard that is usually based on a layered model that allows devices from different vendors to communicate (internetwork). An example of a hierarchical model protocol can be found in Andrew S. Tannenbaum, Computer Networks, 2nd Edition, Prentice Hall, 1989.

【0003】

One of the new protocols that has emerged is the Asynchronous Transfer Mode (ATM) protocol. ATM is incorporated into one of the most popular computer protocols, namely the Transmission Control Protocol / Internet Protocol (TCP / IP). Figure 1 is a conceptual block diagram of the IP on the ATM host protocol stack. The physical layer 10 of the ATM network consists of a regenerator section level 15 that reproduces weak signals, a digital section level 20 that disassembles and assembles a continuous byte stream, and a transmission path level 25 that assembles and disassembles the payload of the system.

【0004】

The ATM layer 30 is set on the physical layer 10. The ATM layer consists of virtual path level 35 and virtual channel level 40. This virtual path level 35 consists of a bundle of virtual channels with the same endpoint. This virtual channel level 40 concerns issues such as quality of service (QoS), switched semi-permanent virtual channel connectivity, cell sequence integrity, traffic parameter negotiation, and utilization monitoring. This QoS parameter allows ATMs to provide network resources based on the various types of applications in use.

【0005】

For example, an application sends short bursts of information, so it does not require a long connection (eg, logging on to a remote computer). Other applications, on the other hand, require large amounts of information, but not necessarily reliable data transfer (eg, video conferencing). By using QoS parameters in ATM networks, file transfer is processed differently than video conferencing. AAL5 layer 50 is a segmentation and reassembly sublayer that packages (packs) information into cells for transmission and unpackages (unpacks) that information at the other end.

【0006】

The LLC / SNAP layer 60 provides a mechanism for encapsulating other protocols (eg, IP, Novell IPX) via ATMAAL5. The IP layer (70) provides a common packet format at the network layer of the IP protocol suite and an address scheme that transfers data over multiple subnetworks technologies (eg Ethernet, ATM). The TCP layer (80) and the UDP (User Datagram Protocol) layer (80) provide various types of transport services over IP. The application / API (90) in the end system accesses the TCP service and UDP service via the application API (Application Programming Interface).

【0007】

Communication between devices in the network is performed digitally. The information to be communicated is usually represented by 1 or 0. Information or data (0 and 1) to be communicated is grouped into units called packets. The hierarchical modeling protocol described above is executed within a packet by defining the meaning of the bits in the packet, defining different types of packets, and arranging the different types of packets in order.

【0008】

When data or information is subdivided into packets, the packets are sent within the network, where they take the same path or different paths. The packet is finally reconstructed on the destination device. In ATM, the communication path between two devices is established via a virtual circuit. This circuit is called a virtual circuit because a path is set and then removed and resources along the path are shared by multiple virtual circuits. When a packet is sent through a network switch that establishes a virtual circuit through an automated call-setup procedure, this path is called a switched virtual circuits (SVC).

【0009】

In an IP packet network, packets are sent from the transmitting device over the local network and then to a device called a router. This router forwards packets into the network. Traditional modems for IP over ATMs have a way of communicating directly between two end devices (possibly on different subnetworks) once the path between the two devices is established. providing. A recently emerging protocol (Next Hop Resolution Protocol (NHRP)) and NHRP Server (NHS) are used to map IP addresses from endpoints on different IP networks to their corresponding ATM addresses.

【0010】

Once the destination ATM address is obtained, a direct ATM path between the source and destination is set. If this source (source) and destination are members of different subnetworks (eg ATMs), the SVC is referred to as a cut-through or shortcut SVC. Using this approach, all packets take the same path (virtual circuit) between the two end devices. However, in another model, when a communication connection between two end devices is set up, all packets are processed through the router.

【0011】

When a packet is processed through a router, it will all take the same path. Processing packets through a router is advantageous if the running application is a small application (small in time or low bandwidth). However, this method of processing is difficult if the application has larger requirements (longer time requirements or wider bandwidth). Therefore, if the application has greater requirements, it is advantageous to use a switching virtual circuit between the two communication terminal devices.

【0012】

One important issue when ATM is used in a TCP / IP environment is SVC connection management. At one end of the spectrum, an SVC is established between all communication entities. And at the other end of the spectrum, all communication entities are forced to move through routers. Given different applications, there is no solution for each. Therefore, SVC management is preferably controlled by the requirements of the application, especially the QoS requirements of the application.

【0013】

In traditional TCP / IP applications, the decision to use an SVC or a router depends on the sending address and the destination IP address. Transmission protocols such as TCP and UDP use port numbers to identify applications associated with IP addresses. A port number (1-255) is known and represents a service such as host function, file transfer, network news. Other port numbers (1024-65535) are known and are used to identify QoS requirements within a communication session.

【0014】

Another mechanism for communicating the QoS requirements of an application is through the currently deployed Resource Reservation Protocol (RSVP). This RSVP makes it possible to reserve resources in IP networks and negotiate QoS. RSVP operates within the context of the IP protocol and therefore does not take into account the specific subnetworks technology (eg, ATM) on which IP operates.

【0015】

Therefore, resource reservation and QoS negotiation occur between the end system in communication and the network router. In RSVP protocol technology, the source sends a path message to the destination address to identify the communication route. This destination then requests a reservation of resources for the "flow" along the route. Finally, when the destination reservation request is accepted, the flow receives the requested network resources and QoS from the path.

【0016】

This RSVP method is supported by several components of the RSVP protocol. The first component is the characteristics of the packet stream sent by the source in the flow specification (for example, packets with short intermittent frequencies for terminal communication and long packets that occur at more normal intervals for video conferencing). Describe. This flow specification defines the desired QoS and uses it to set packet scheduler parameters.

【0017】

The routing protocol then gives the communication path. The setup protocol allows the generation and maintenance of reserved resources. The admission control algorithm keeps the network load at the right level by denying resource requirements that would overload the level. Finally, a packet scheduler is deployed within the router in the path between the source and destination to ensure correct QoS.

【0018】

[Problems to be Solved by the Invention]

Figure 2 shows the flow model when the RSVP model is realized on an IP network. During RSVP execution, packets are categorized based on "session" and "filter spec" parameters (especially source and destination addresses), and IP protocol services are referred to as flow specifications (hereinafter abbreviated as "flow"). Is based on). The flow model in Figure 2 represents packet processing within a router.

【0019】

The classifier 810 separates communication packets based on the "session" and "filter spec" parameters indicated by the flow spec 820. This packet is then input into the scheduler 830, further processed by the output driver 840, and output data at the output point 850. The output driver 840 then handles the interface leading to the "next hop" router in the path to the destination (ie, in this case, the destination itself if the next hop is the destination).

【0020】

[Means for solving problems]

The present invention is as described in the claims. An embodiment of the present invention provides a method and architecture for executing a Resource Reservation Protocol (RSVP) via an Internet Protocol / Asynchronous Transfer Mode (IP / ATM). In the architecture of the invention, the resources required for the communication path between the two devices are defined by the application resource requirements. This application requirement is mapped to RSVP parameters via an IP-capable application programming interface (API) with RSVP in the host computer.

【0021】

When ATM is used in a network, the direct method is to translate the RSVP flow specification parameters into the corresponding ATM QoS parameters (mapping RSVP parameters to ATM parameters is exactly what it is. It does not match). Thus, if X represents a set of RSVP parameters and Y represents a set of ATMQoS parameters, then Y = F (X), where F is a function that maps X to Y.

【0022】

In the examples of the present invention, the database (d) is used as an interface between RSVP parameters and ATM parameters to enhance the RSVP to ATM mapping. This database (d) contains user endpoint (also referred to as customer) data, which is used to characterize the customer's network requirements.

【0023】

Therefore, the mapping from RSVP parameters to ATMQoS parameters takes the form of Y = F (X, d). Here, X, Y, and F have the same meaning as above, and d represents a policy mapping database (PMD). This database is referenced whenever an X-to-Y mapping is performed. This database allows for decisions and choices that were not possible when a direct X-to-Y mapping was adopted.

【0024】

Advantageously, this Policy Mapping Database (PMD) allows users to shortcut SVC with or without mapping QoS, making it impossible to establish shortcut SVC, and hop-by-hop QoS. Gives the ability to support mapping. This database should allow the user to perform a Next Hop Resolution Protocol (NHRP), whether an SVC backup should be established, or a date and time override. It will be possible to decide whether or not to use another ATM path if the main ATM path fails.

【0025】

Also, the X to Y mapping depends, for example, on various levels of customer provisions, such as security, priority, performance, information availability date, information about network status, and so on. In summary, the RSVP flow specification is mapped to an ATM exchange virtual circuit with specified QoS using PMD. As a result of mapping RSVP flow specifications to ATM QoS requirements, the methods and architectures of the present invention allow RSVP to be performed on IPs on ATMs.

【0026】

BEST MODE FOR CARRYING OUT THE INVENTION

The present invention provides a method and architecture for allocating network resources (eg, bandwidth, priority) according to the type of application used in the communication end terminal. The Asynchronous Transfer Mode (ATM) architecture and the Resource reSerVation Protocol (RSVP) together have the necessary components that allow an application to allocate network resources. At ATMs, protocol traffic descriptors and quality of service (QoS) futures are used to set different network requirements for different applications.

【0027】

For example, a telnet session uses a small, rarely occurring packet that is forwarded through a router, so a set of traffic descriptors and a quality of service parameter that defines this type of connection are set. However, when video conferencing is set up, large delay-sensitive packets are often generated. Therefore, a dedicated exchange virtual circuit with low delay sensitivity characteristics is more effective for transporting in a video conferencing session.

【0028】

This RSVP protocol is based on QoS and is executed with components that meet the requirements required to generate bandwidth allocation. This RSVP protocol has a class fire that classifies packets and a flow specification that defines and details the relevant characteristics of the packet. The RSVP parameters and flow specifications are mapped to ATM switched virtual circuits (SVC) with the corresponding traffic descriptors and QoS parameters using the policy mapping database PMD. This PMD associates the RSVP flow specification with the ATM QoS parameters of the SVC.

【0029】

FIG. 3 shows a flow model of the RSVP protocol according to an embodiment of the present invention. The RSVP flow model on ATM associates the flow specification with the QoS exchange virtual circuit to establish the ATMSVC. In FIG. 3, class fire 810 classifies packets based on their session parameters and filter spec parameters. The classification of each packet is associated with Flow Spec 820. The output of this flow spec 820 is fed to the policy mapping database 210. This policy mapping database 210 maps packets based on the flow spec 820.

【0031】

The policy mapping database 210 allows mapping between the parameters of RSVP flow spec 820 and ATMQoS parameter 940. The mapping of FlowSpec 820 to ATMSVC is based on the resources required by the application (eg, best effort traffic is mapped to routers and video conferencing has appropriate traffic descriptors and QoS parameters. Mapped to a separate SVC). Once the Policy Mapping Database (PMD) user interface is established, users can manage mappings for their own traffic.

【0032】

Figure 4-8 shows the end-to-end flow flow of a sequence of steps in a unicast case (transmission of a packet from one endpoint to another). In the method disclosed herein, the customer first enters various service options (0) in the PMD230, along with a list of IP end terminals to which the option applies (although one customer has multiple entries in the database). That is, one subnet of a customer's end terminal can have different options than another).

【0033】

When the source (S) attempts to communicate with the destination (D), the source (S) sends a path message (1) to the destination (D) via 110. This path message (1) is then forwarded to the destination (D) hop-by-hop by steps (2), (3), (4). When the destination (D) receives this pass message, the destination (D) sends the reservation request to the source (S) by the path message of steps (5), (6), (7), (8). Use the route taken to hop-by-hop back in the opposite direction.

【0034】

The route information required for these steps is stored as PATH status information in 110,120,130. When Source (S) receives the reservation, Source (S) sends an inquiry (9) to PMD230. This PMD does not have to be in the same location as the source (S). This PMD is reachable via an ATM address known to the source (S). Inquiry (9) contains all the information from the originally received booking message. The query (9) is processed by the PMD230 and a response (10) containing the ATM traffic descriptor and information related to the QoS parameters and various PMD specification options is returned to the source (S).

【0035】

The details of the inquiry message and the response message from the source (S) to the PMD230 will be described below. Assuming that the source (S) has the result of the response (10) and allows service options and network conditions, for example cut-through, the source (S) defaults to the NHRP query (11). Send to NHS140 and receive a response (12) containing the ATM address of the destination (D). The source (S) then sets the ATMSVC (13) directly to the destination (D) using the ATMQoS information from the response (10).

【0036】

Modify the methods and architecture disclosed in Figure 4 to improve performance and perform processing for end-system clients. In the architecture of FIG. 5, its operation is the same as that of FIG. 4 until the inquiry message (9) is included. Upon receiving the inquiry (9), the PMD initiates (ships) an NHRP request (10) to the NHS for the source. This NHRP request (10) is signaled by the NHRP lookup option in the PMD inquiry message (9), which contains the IP address of the destination (D).

【0037】

When the PMD230 receives an NHRP response (11) for the NHS, the PMD230 responds with a response (12) to the source (S). This response includes the ATM address corresponding to the destination (D) IP address. This source (S) can set up a direct call (13) to the destination (D), which can be done without the step of querying the NHRP server. The reason is that the NHRP server is accessed by or located within the PMD230.

【0038】

Higher efficiency can be achieved when the NHRP lookup option is implemented. As shown in FIG. 6, the third party ATM call setting is performed by PMD230 via proxy signaling (that is, when a terminal other than the communication end terminal sends a signal to the terminal to set up communication). It will be started. The surrogate signaling is signaled by the source (S) to the PMD230 with the surrogate signaling call configuration option in the third party / PMD inquiry message (9) (this PMD is both the source (S) and the destination (D)). It is equipped to perform surrogate signaling for, which requires a signaling virtual circuit configured between the PMD230 and the communicating terminal).

【0039】

In FIG. 6, the operation is the same as that in FIG. 5 until the response (11) is included. The PMD230 then executes a third party ATM call setup request (12) via proxy signaling to the ATM network 300 for both the source (S) and destination (D). An ATM connection (13) is then set up between the source (S) and the destination (D). When this connection setup is complete, a surrogate signaling confirmation message (14) is received from the ATM network 300. The PMD230 then issues a surrogate signaling confirmation message (15) to the source (S) and a surrogate signaling confirmation message (16) to the destination (D).

【0040】

This confirmation message includes a virtual path / virtual channel identifier (VPI / VCI), address information, and other information received within the QoS and proxy signaling confirmation message (14). The confirmation message (15) to the source (S) is piggybacked (backed) in the PMD response (17), so there is no need to send a separate message. Thus, the source (S) uses the VPI / VCI information received in the message (15) to convert the IP address to the ATM address, or without issuing an ATM call setting request to the destination (D). Can be sent to.

【0041】

By further modifying the above method, the overall performance of the system can be greatly improved. Such improvements allow cut-through and intermediate routers (110,120,130) between the source (S) and the destination (D) when an SVC is established between the source (S) and the destination (D). This is because there is no storage of resources inside. To explain this point, in the above case, the RSVP reservation request message returned from the destination (D) to the source (S) is sent to each router along the path from the destination (D) to the source (S). Resources at (110,120,130) will be reserved.

【0042】

Two problems arise when the final result is to allow cut-through and establish an ATMSVC (13) between the source (S) and the destination (D). The first problem is that we must use a mechanism to free reserved resources along the path defined to go through routers 120,130,140. This can be easily achieved either by simply using a timeout mechanism or by having the source (S) send an RSVP Reservation Teardown message. The second and more important issue is that new reservations that actually require resources in the intermediate router (eg, because cut-throughs are not allowed for these reservations) will run out of resources within 110,120,130. Or, it is blocked due to lack of related links in the network.

【0043】

This issue is resolved by allowing the PMD230 to be queried. If cut-through is allowed, the destination (D) establishes an SVC to the source (S) and sends its RSVP Reservation Request message to the source (S) via this SVC. In other words, the RSVP reservation request message is not returned hop-by-hop in the reverse direction along the route obtained by the RSVP path message, and the resource is not reserved on this intermediate router. It is still necessary to clear the path state information (generated when processing the path message) in the intermediate router. This is not considered a problem because a significant amount of memory is needed to store the path state information.

【0044】

There are still two issues that must be resolved at the source (S) in order to configure the SVC with the destination (D). The first issue is how to associate the received RSVP reservation request message with the previously sent path message. If the destination (D) has a PMD230 queried and cut-through is allowed, the RSVP reservation request message is received by the source S via a virtual circuit. And this virtual circuit is separate from the virtual circuit to which the RSVP path message was sent.

【0045】

The RSVP protocol uses the message ID field in these messages to associate the RSVPPATH with the reserved RSVP reserved message. Furthermore, the use of only one message ID is required through one interface. This identical message ID must not be used through a supported virtual circuit on the interface to identify individual reservations.

【0046】

The second problem arises when the source (S) receives the RSVP reservation request message via the same virtual circuit used to send the RSVP path message. The problem facing this source (S) is how to distinguish between the following two cases. The first case is when the inquiry to the PMD is executed by the destination (D) and cut-through is not allowed. In this case, the second query to PMD should be avoided.

【0047】

The second case is when the query to the PMD is not made by the destination (D) and the query to the PMD from the source (S) must be made. This problem can be solved by defining an end-to-end user signaling mechanism between the source (S) and the destination (D). The method according to the invention is for an RSVP object with an unassigned Class-Num (eg 64 <Class-Num <128 is not assigned) to signal whether a query to the PMD has been executed. Related to the specification.

【0048】

Depending on the RSVP specification, systems that do not recognize objects will ignore the RSVP specification altogether. However, the system that implements the method of the invention disclosed herein recognizes an object and operates on that information. In other words, the method of the invention disclosed herein uses unused bits in the packet structure of the RSVP protocol as a signaling mechanism to communicate information between the source (S) and the destination (D). There is.

【0049】

Examples of the above method are shown in FIGS. 7 and 8. In FIG. 8, the operation is the same as that in FIG. 4 until the path message (4) is included. From this path message (4), the destination (D) sends an inquiry (5) to the PMD230. This inquiry (5) includes information from the pass message and the requested reservation information for the destination (D). The query (5) is processed by the PMD230 and the response (6) containing the requested ATM traffic descriptor and QoS parameters and various options is returned to the destination (D).

【0050】

When the destination (D) gets the result of the response (6), cut-through is allowed (if cut-through is not allowed, it will be explained below), and the destination (D) sources the NHRP query (7) to the default NHS. Receive a response (8) containing the ATM address of (S). The destination (D) then sets the ATMSVC (9) directly to the source (S) using the ATMQoS information from the response (6). The destination (D) then sends the RSVP reservation request message (10) to the source (S) via the established ATMSVC (9). This source (S) associates the RSVP reservation request message (11) with the RSVP path message (1) by using the message ID fields in messages (1) and (11).

【0051】

In FIG. 8, the operation is the same as that in FIG. 7 until the inquiry response (6) returned to the destination (D) by PMD230 is included. Cut-through is not allowed when destination (D) obtains the result of response (6), and destination (D) sends an RSVP reservation request message via response (7), (8), (9), (10). It is sent to the source (S) using the accumulated path status information in 120, 130, 110 arranged along the path from the destination (D) to the source (S).

【0052】

When the source (S) receives the reservation (10), the source (S) queries the PMD230 (communicate via an object with a mechanism of 64 <Class-Num <128 or less above) and the source for the PMD230. Determine that the inquiry by (S) is not necessary. If the source (S) determines that the query to the PMD230 will not be executed at the destination (D), the source (S) sends the query to the PMD230. This is the case shown in FIG.

【0053】

The method disclosed in Figure 4-8 can be applied to the IP unicast case (ie, the case where one transmitter sends an IP packet to one receiver). Also suitable for the methods disclosed in Figures 7 and 8 (in this case the destination queries the PMD instead of the source) and the IP multicast case (one transmitter sends an IP packet to a group of receivers). Is. In the case of a multicast case, the receiver decides whether to join a particular multicast group. The transmitter does not know which receiver receives the transmission information.

【0054】

Therefore, the receiver drive characteristics of IP multicast are acceptable by having a receiver / destination that queries the PMD shown in Figures 7 and 8. If cut-through is allowed, it is performed by an ATM-level leaf-initiated join operation on either the source or the intermediate multicast server. As in the unicast case, in this multicast case, the PMD determines the IP address for the ATM address and performs the third party multipoint call setup function for the query entity. Furthermore, when the PMD performs such a function, the PMD also performs address screening, thereby providing appropriate security features for multicast (and unicast) communications.

【0055】

FIG. 9 shows the contents of a policy mapping database (PMD) according to an embodiment of the present invention. For each set of IP endpoints, the customer enters whether or not to perform the following actions. (i) Enable cut-through with QoS mapping. When possible, ATM cut-through to the destination is always attempted. This is to map to the ATMQoS parameter and traffic descriptor of the RSVP flow specification parameter. RSVP mapping based on RSVP reservation style flows to ATM, VC is one-to-one or many-to-one.

【0056】

(ii) To enable cut-through without QoS mapping. When possible, ATM cut-through to the destination is always attempted. ATMSVC always makes the utmost effort without QoS parameters or traffic descriptors being set. This mapping is usually many-to-one.

【0057】

(iii) To disable cut-through and support hop-by-hop QoS mapping. If possible, ATM cut-through will not be attempted. Packets are forwarded hop-by-hop based on a classical IP router-based packet forwarding model. Mapping RSVP flow specification parameters to ATMQoS parameters and traffic descriptors is hop-by-hop based. Depending on the RSVP reservation style, RSVP mapping flows to ATMSVC. VC mapping is one-to-one or many-to-one.

【0058】

(iv) NHRP lookup option If NO, it is ignored. If YES, PMD utilizes the NHRP server (NHS) for the source and returns the query result (ie, the destination ATM address) to the source in the PMD response message. Set by a third party with a surrogate signaling option. If NO, it is ignored. If YES, PMD utilizes the NHRP server (NHS) for the source and establishes an ATM connection between the source and destination using proxy signaling. When implemented, this suboption assumes that the PMD has both a source and a destination so that it can act as a surrogate signaling agent for each.

【0059】

(v) Limit cut-through options. If NO, it is ignored. If YES, the customer lists the name of the destination area and the IP address for which the cutthrough is allowed for the set of IP end terminals. Address prefixes and region name suffixes are allowed. Cut-through will not be attempted for destinations not on this list.

【0060】

(vi) Overwrite day / date and time If NO, it is ignored. If YES, the customer enters the month, day, and time when the cutthrough should not be attempted.

【0061】

(vii) Multicast cutthrough is allowed. If NO, no cutthrough is attempted on the multicast destination (ie, if the destination address is a class D destination address). If YES, cut-through is allowed. The customer enumerates a set of Class D addresses that are allowed to cut through and displays a list of ATM endpoints that join a particular multicast group.

【0062】

(viii) Backup options If YES, (a) If the current option requires cut-through and the cut-through fails, try to set hop-by-hop. (b) If the current option requires hop-by-hop and RSVP configuration fails, try cut-through.

【0063】

(ix) Use another ATM path when the main ATM path fails. If NO, it is ignored. If YES, the source is two or more ATMs for a given IP destination, assuming the destination is reachable from the resource by two or more ATM networks and PNNI routing between these networks is not adopted. Have an address. If the call setup for the 1st ATM address fails, the 2nd, 3rd, ... attempts are made for the 2nd, 3rd ATM address, and it is until or after the attempt is successful. This is done until another address no longer exists.

【0064】

The above options are grouped together to provide different levels / categories of service to customers. For example, one (high) level service consists of possible options (i), (vii), (viii), while another level of service consists of possible (ii), (iv), (v). Consists of options. Further, the details of each option are changed, and the load-bearing option is added to the database without changing the overall operation of the present invention.

【0065】

Typical database queries and response messages include the following parameters: Inquiry: 1. RSVP including traffic specifications (amount and characteristics of bandwidth required) and service specific parameters (eg packet delay, packet jitter, packet loss) and filter specifications that identify and characterize the packet stream in the packet flow. Flow specifications.

【0066】

response: 1. Contents of the above inquiry 2. ATM related parameters -Cut through or not -ATM traffic descriptor -ATMQoS parameter -Available backup (Yes / No) -Another ATM (Yes / No) -ATM address corresponding to the destination or IP address of the inquiry message if NHRP lookup is possible -ATM virtual path / virtual channel identifier (VPI / VCI) is used to reach the IP destination if third party configuration is possible [0067]

The content of query and response messages can be extended on a call-by-call basis to allow the override of some of the included entities within the PMD. For example, it requires an NHRP lookup for one connection but not for another connection through. Inquiry messages increase with the addition of various options. It can work successfully even if the content of the inquiry message contains a subset of the information (eg port number and destination address). For example, if information related only to the filter specifications is obtained, mapping from the destination address and port number to the ATMQoS parameter is possible. As a result, the system of the present invention can be used even when RSVP is not adopted.

【0068】

[Effect of the invention]

As described above, the present invention provides a method and an architecture for allocating network resources (eg, bandwidth, priority) according to the type of application used in the communication end terminal. The RSVP flow specification of the present invention is mapped to an ATM exchange virtual circuit with specified QoS using PMD. As a result of mapping RSVP flow specifications to ATM QoS requirements, the methods and architectures of the present invention allow RSVP to be performed on IPs on ATMs.

[Simple explanation of drawings]

[Figure 1]

Diagram representing the TCP / IP protocol stack on an Asynchronous Transfer Mode (ATM) protocol stack [Figure 2]

Diagram showing RSVP operation on a non-QoS cablepable subnet [Fig. 3]

A diagram representing the flow model of RSVP protocols on IPs on ATMs with a policy mapping database (PMD) used to manage protocol translations. [Fig. 4]

A detailed diagram of communication between a source (S), a destination (D), a PMD, and an address determination / next hop server (NHS) according to the method of one embodiment of the present invention, showing a state in which the source queries the NHS. [Fig. 5]

A detailed diagram of communication between a source (S), a destination (D), a PMD, and an address determination / next hop server (NHS) according to the method of one embodiment of the present invention, showing a state in which the PMD queries the NHS. [Fig. 6]

In the detailed diagram of the communication between the source (S), the destination (D), the PMD, and the address determination / next hop server (NHS) by the method of one embodiment of the present invention, the PMD queries the NHS and sets the third party call. Diagram showing the state of setting the connection between the source (S) and the destination (D) using the mechanism. [Fig. 7]

Diagram showing a scenario according to an embodiment of the present invention in which the station of the destination (D) queries the PMD and sets the SVC. [Fig. 8]

A diagram showing a scenario according to an embodiment of the present invention, in which the station at the destination (D) queries the PMD and an uncut-through SVC is obtained. [Fig. 9]

The figure which shows the content of PMD by the Example of this invention. [Explanation of symbols]

10 physical layer 15 Player section level 20 digital section level 25 Transmission path level 30 ATM layer 35 virtual path level 40 virtual channel level 50 AAL 5 layers 60 LLC / SNAP layer 70 IP layer 80 TCP layer UDP layer 90 Application / API 810 Classfire (classifier) 820 Flow spec (flow spec) 830 scheduler 840 output driver 850 output point 210 Policy mapping database 940 ATM QoS parameters