JP2004140869A - Router apparatus and packet transfer method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reserve resources even when requested resources can not be reserved only by IP scheduling, and to rightly notify another node of whether or not the resources are reserved in a present node. <P>SOLUTION: In the timing that a resource reservation message is received from the downstream side, when virtual transfer paths each available for transferring a packet while omitting one part of or all transfer processing of a network layer level is present on the upstream side and the downstream side of a node which receives the message and when a requested service quality indicated in the message for resource reservation can be satisfied for the first time by storing a corresponding relation of the virtual transfer paths and performing packet transfer according to the stored relation, the resource reservation message is transmitted to the upstream side after the presence of both the virtual transfer paths is confirmed. <P>COPYRIGHT: (C)2004,JPO

Description

The present invention relates to a method for forming a virtual transfer path for performing multicast packet transfer via a router device capable of connecting virtual connection networks.

The {router device} is used when connecting between LANs (Local Area Network) and plays a role of transferring a packet from one LAN to another LAN. In the packet, in addition to the communication information data to be transferred, the network layer address of the transmission source and the final destination are described. The router device uses the address information to output the packet output interface and the next transfer node. Is determined.

This router device can perform not only unicast communication that transfers packets from one source to one final destination, but also multicast communication that transmits packets from one source to many final destinations.

By the way, in recent years, attempts have been made to transfer voices and images using packets. At present, audio data and other data are transmitted in the same way by the router, so if the audio is interrupted, the video is disturbed. Therefore, by making a resource reservation in the router, the audio image is transferred preferentially, so that the sound becomes easy to hear and the image is easy to see. Here, an audio image is taken as an example. However, in the case of data to be preferentially transmitted, there is an advantage by reserving resources.

{In order to make a resource reservation in a router device in this way, it is necessary to exchange resource reservation information between router devices. As a protocol for the resource reservation, RSVP (Resource Reservation Protocol) has been developed. This protocol supports both unicast and multicast.

In RSVP, resource reservation is performed from a downstream node receiving data to an upstream node that is a source of information. Specifically, a PATH message is sent from the source of the information to the same destination as the destination of the data, and the route on which the information passes is stored in a router on the route. The PATH message describes an identifier for specifying data to be reserved for the resource, and an IP address of a node transmitting the PATH message. (4) Upon receiving the PATH message, the data receiving node sends a RESV message to the upstream node that transmitted the PATH message, thereby indicating the intention of resource reservation. The RESV message describes an identifier for specifying data to be reserved for resources, and a QOS # (quality of service) requested by the receiving node.

(4) If the router that receives this RESV message has the ability to reserve resources in the network layer (IP) processing unit, it performs network layer scheduling and transfers the RESV upstream. If the resource cannot be reserved, RESV @ Error is transmitted to the downstream node. By repeating this, resource reservation can be made up to the upstream node.

One of the aspects of the present invention is that a router having a relatively low capacity of the network layer processing unit cannot satisfy a required quality of service indicated in a message for resource reservation only by network layer scheduling. It is an object of the present invention to provide a mechanism that makes it possible to reserve a reserved resource and correctly informs another node whether or not a resource reservation has been made in its own node.

The present invention also provides a method for efficiently performing a connection for the communication and setting in the router when the router performs a multicast communication using a virtual connection switching function in a layer lower than the network layer. The purpose is to do.

According to the present invention, when performing multicast communication in a system having a switch between routers, a connection for this communication is uniquely identified by routers at both ends, and necessary connections and settings in the router are efficiently performed. The aim is to provide a method.

According to a first aspect of the present invention, there is provided a router device having a physical interface with a virtual connection type network and connecting at least two logical networks, wherein a virtual transfer path used for reception from one of the logical networks is provided. Storage means for storing a correspondence with a virtual transfer path used for transmission to the other logical network; transfer means for transferring a packet in accordance with the stored correspondence; a message for resource reservation Receiving means for receiving from the logical network on the receiver side, and a virtual for packet transmission capable of being transmitted via the transferring means to the logical network on the receiver side based on the received message for resource reservation. The existence of a transfer path and the packet that can be transmitted from the logical network on the sender side via the transfer means. Depending on the presence or absence of virtual connection for bets received, characterized in that a message for resource reservation and transmitting means for transmitting to the sender of the logical network.

A second invention of the present invention is directed to a router device having a physical interface with a virtual connection type network and connecting at least two logical networks, wherein a virtual transfer path used for reception from one of the logical networks is provided. Storage means for storing a correspondence with a virtual transfer path used for transmission to the other logical network; transfer means for transferring a packet in accordance with the stored correspondence; a message for resource reservation Receiving means for receiving a message for resource reservation based on the received message for resource reservation, and transmitting means for transmitting a message for resource reservation to the logical network on the sender side. Of a virtual transfer path for transmitting packets to the logical network through the transfer means And canceling a message for resource reservation transmitted by the transmitting means according to the presence or absence of a virtual transfer path for receiving a packet from the logical network on the sender side via the transferring means. And a notifying means for notifying the user.

A third invention of the present invention is realized by using, for example, the router device according to the first invention, and transfers a packet transmitted from a first node to a logical network different from the first node. In the packet transfer method for transferring to a second node to which the packet belongs, a message for resource reservation is received from the second node, and a part of a transfer processing at a network layer level from the first node to the second node. Or a virtual transfer path that can receive packets from the first node and that can transmit packets to the second node, set to enable packet transfer without performing all When there is a virtual transfer path, the correspondence between these virtual transfer paths is stored and a message for resource reservation is sent to the first node. And Shin, when receiving a packet, if the correspondence between the virtual connection used for this reception is stored, and wherein the transfer of said packets according to the corresponding relationship.

The fourth invention of the present invention is realized by using, for example, the router device according to the second invention, and transfers a packet transmitted from the first node to a logical network different from the first node. In the packet transfer method for transferring to a second node to which the packet belongs, a message for resource reservation is received from the second node, and in response to the reception, a message for resource reservation is transmitted to the first node. From the first node, configured to enable packet transfer from the first node to the second node without performing part or all of a network layer level transfer process. If at least one of a virtual transfer path capable of receiving a packet and a virtual transfer path capable of transmitting a packet to the second node does not exist (confirmed), transmission is performed. The first node notifies the first node of the cancellation of the message for the resource reservation, and stores the correspondence relationship between these virtual transfer paths when the two virtual transfer paths exist, and If the correspondence relation for the virtual transfer path used for the reception is stored, the packet is transferred according to the correspondence relation.

Here, transferring the packet in accordance with the stored correspondence means that the packet is transferred while omitting some or all of the transfer processing at the network layer level. The at least omitted processing is to determine a node to which the packet is to be transferred next from the destination address of the packet, and to specify a virtual transfer path used for transmitting the packet to the determined node (network layer level analysis). ). In addition, a virtual transfer path set to enable packet transfer without performing part or all of the transfer processing at the network layer level is performed at the network layer level between nodes belonging to different logical networks. It is desirable that the virtual transfer path is different from the virtual transfer path already set to perform the processing and transfer the packet.

As described above, in the first to fourth inventions, the router device partially uses the switching function of the virtual transfer path in a layer lower than the network layer (the correspondence between these virtual transfer paths is stored. By performing packet transfer (according to leverage correspondence), resources can be reserved more often than in a conventional router device.

Further, according to the first or third invention, when a message for resource reservation (for example, a RSVP Resv message) is received from the downstream, the network is provided upstream and downstream of the node (router device) receiving the message. There is a virtual transfer path (for example, a dedicated VC) that can be used to transfer a packet by omitting a part or all of the layer-level transfer processing, and stores a correspondence relationship between these virtual transfer paths. If the required service quality indicated in the resource reservation message can be satisfied only by performing packet transfer (for example, direct connection) according to this, the existence of both virtual transfer paths is confirmed and then the resource is transferred to the upstream. Since the upstream node receives the message for reservation, the upstream node understands that it was able to reserve resources from the next node to the downstream. It is possible to operate.

Further, in the above case, if it is confirmed that at least one of the virtual transfer paths does not exist, a message indicating that the resource reservation has failed (for example, RESV @ Error) is transmitted to the downstream, thereby receiving the message. Can operate upon knowing that the resource reservation requested by itself has been rejected.

When the present invention is applied, for example, to a case where a node that has received a message for resource reservation requests that a dedicated VC be set upstream of its own node, a request is first made by the receiving side by directly connecting the dedicated VC. If resource reservation can be performed, first, if there is no dedicated VC downstream of the own node, a message for resource reservation is not transmitted to the upstream (notifying the resource reservation failure to the downstream). If a dedicated VC exists downstream of the node, a request is made to set the dedicated VC upstream, and then a message for resource reservation is transmitted upstream.

In order to reduce the case where a dedicated VC does not exist downstream of the own node, even when the requested resource reservation can be performed without directly connecting the dedicated VC, a request may be made to set a dedicated VC upstream. If dedicated VCs exist on both sides, the required resource reservation may be performed without directly connecting the dedicated VCs, so that the resources of the network layer can be used for other purposes, or may be directly connected.

On the other hand, according to the second or fourth invention, when a message for resource reservation is received from the downstream, virtual transfer paths (for example, a dedicated VC) upstream and downstream of the node (router device) receiving the message. Even if the required service quality indicated in the message for resource reservation cannot be satisfied unless the packet transfer (for example, direct connection) is performed in accordance with the stored relationship, Is transmitted, and if at least one of the virtual transfer paths is confirmed to be non-existent, the upstream node transmits a message (for example, sends RESV {Tear}) to the cancellation of the virtual transfer path from the next node. The operation can be performed by reliably knowing whether or not the resource reservation has been made for the downstream.

Further, in the above case, if it is confirmed that at least one of the virtual transfer paths does not exist, a message indicating that the resource reservation has failed (for example, RESV @ Error) is transmitted to the downstream, thereby receiving the message. Can operate upon knowing that the resource reservation requested by itself has been rejected.

When the present invention is applied, for example, to a case where a node that has received a message for resource reservation sets a dedicated VC downstream of its own node, the resource reservation requested by the receiving side cannot be performed until the dedicated VC is directly connected. If it can be performed, first, a dedicated VC is set downstream of the own node, and it waits for an upstream node to set the dedicated VC triggered by a message for resource reservation transmitted by the own node. Then, if the dedicated VC is not set upstream, a message for canceling resource reservation is transmitted to the upstream (notifying the resource reservation failure to the downstream).

Here, the timing for transmitting the message for resource reservation upstream may be before or after setting the dedicated VC downstream, but if it is before, when the dedicated VC cannot be set downstream, Sends a message to cancel the resource reservation.

In order to reduce the case where the dedicated VC is not set upstream of the own node, the dedicated VC may be set downstream even if the requested resource can be reserved without directly connecting the dedicated VC. If dedicated VCs exist on both sides, the required resource reservation may be performed without directly connecting the dedicated VCs, so that the resources of the network layer can be used for other purposes, or may be directly connected.

A fifth invention of the present invention provides a virtual machine for transferring a packet transmitted from a first node to a plurality of second nodes belonging to a logical network different from the first node via a router device. In the method of forming a static transfer path, a normal connection (eg, default VC) that can be a point-multipoint from the first node to the router device and from the router device to the second node is set. The router device analyzes a packet transmitted on the normal connection set with the first node at a network layer level and sets the packet with the second node. Out of the plurality of second nodes from the first node to the router device and from the router device. A dedicated connection (e.g., dedicated VC) that can be a point-multipoint is set to a router that satisfies a predetermined condition, and the router apparatus transmits the dedicated connection to the first node. Without using a network layer level analysis, on the dedicated connection established between the second node and the first node and the router device where the dedicated connection is established. A point-to-point normal connection is set between the router device and the second node where the dedicated connection is set, and the dedicated connection is held using the normal connection. And

Here, not performing the analysis at the network layer level means that a part or all of the transfer processing at the network layer level is omitted and the packet is transferred. The at least omitted process is a process of determining a node to which the packet is to be transferred next from the destination address of the packet, and specifying a virtual transfer path to be used for transmitting the packet to the determined node. The packet is transferred according to the correspondence stored in a layer lower than the network layer.

According to the present invention, a normal connection in which transfer is performed with normal quality for multicast, a dedicated connection in which transfer is performed with high quality for multicast, and a point-to-point normal connection are set. In the multicast communication, the router device is connected to a virtual transfer path in a layer lower than the network layer because the connection is performed using a point-to-point normal connection (for example, a message for holding is periodically sent from a downstream node). It is possible to efficiently realize the packet transfer utilizing a part of the switching function.

For example, as a trigger for setting a dedicated connection, it is assumed that a message for resource reservation is received from downstream or a data packet is received from upstream, but in the former case, a message for resource reservation is received. In this case, a point-to-point normal connection may be used. In the latter case, a normal connection for multicast may be used for data packet reception.

In addition, for example, it is assumed that the setting of the dedicated connection is requested upstream of the own node and set, or the case where the dedicated connection is set downstream of the own node.However, in the former case, it is necessary to transmit a message requesting the setting. In the latter case, a point-to-point normal connection may be used to transmit a message notifying that the setting has been made.

か ら Because the dedicated connection is for multicast, setting of the dedicated connection to the node corresponding to the same multicast group is performed by adding a leaf to the already existing dedicated connection. What is held using the point-to-point normal connection is the leaf corresponding to the dedicated connection.

A sixth invention of the present invention provides a virtual machine for transferring a packet transmitted from a first node to a plurality of second nodes belonging to a logical network different from the first node via a router device. In the method of forming a static transfer path, from the router device to the plurality of second nodes, a dedicated connection that can be a point-multipoint is set, between the router device and the second node, A point-to-point normal connection is set, unique identification information in the logical network representing the dedicated connection is transmitted from the router device using the dedicated connection, and the second node uses the normal connection. Transmitting a message for confirming the identification information.

According to the present invention, a dedicated connection for multicast and a point-to-point normal connection are set, and information for uniquely identifying the dedicated connection by the nodes at both ends is proposed by the dedicated connection from the upstream node, Thus, each time a receiver joins the multicast group, it is possible to efficiently identify a dedicated connection uniquely at each corresponding node.

According to the first to fourth aspects of the present invention, even when the required service quality indicated in the message for resource reservation cannot be satisfied only by the scheduling of the network layer, a layer lower than the network layer can be used. The use of the virtual connection switching function makes it possible to reserve the requested resource, and it is possible to correctly inform other nodes whether or not the resource reservation has been made in the own node.

According to the fifth aspect of the present invention, when a router performs multicast communication using a virtual connection switching function in a layer lower than a network layer, a connection for the communication and a setting in the router are set. Can be performed efficiently.

According to the sixth aspect of the present invention, when performing multicast communication in a system in which a switch exists between routers, a connection for this communication is uniquely identified by routers at both ends, and necessary connections and routers are identified. Can be set efficiently.

(Embodiment 1)
In the present embodiment, a method for realizing a resource reservation protocol, RSVP (resource ReSeVation Protocol), on an ATM (Asynchronous Transfer Mode) by using a CSR (Cell Switch Router) technique will be described.

The {RSVP} guarantees the QOS (service quality) of packet transfer belonging to a flow identified by a combination of a source address / port and a destination address / port (only the destination address / port may be used) at a router. Here, the identifier for identifying this flow is referred to as Flow {ID}. This QOS @ guarantee is realized by performing packet transfer scheduling inside the router, so that packets whose resources are reserved are transferred earlier.

{CSR} is a router that can perform higher-speed transfer in ATM cells by having an ATM switch function inside the router in addition to performing the operation of transferring in the same IP packet unit as a normal router.

A simple operation of the CSR will be described with reference to FIG. X. Y. from CSR through CSR Consider a case where a packet is transferred to 1 #. To perform the same IP packet transfer operation as usual, X. The packet is transmitted through the ATM connection which is set to transfer packets of various destinations from 1 # to CSR #. Here, this ATM @ connection is referred to as a default VC (Virtual @ Connection). In CSR #, the destination of the next packet is determined by looking at the destination of the IP packet. Here, the next node is Y. 1}, the packet is transmitted to the default VC, so that Y. 1} is transferred.

Next, the operation of the ATM cell transfer will be described. Y. X. 1 dedicated to packet transfer to X.1 1 from the ATM connection to the CSR and from the CSR to the Y. It is assumed that an ATM connection to No. 1 has been set. Here, this ATM connection is called a dedicated VC. Furthermore, it is set so that these two dedicated VCs can be transferred in ATM cell units by the ATM switch function in the CSR. That is, X. Dedicated VC CS from 1 to CSR
R from the VPI / VCI at the receiving port and from CSR to Y. Dedicated VC CSR to 1
Is stored as an ATM-level routing table. By performing such a setting, a bypass pipe directly connecting dedicated VCs belonging to two logical networks (IP Subnet) is formed.

X. 1 to Y. X.1 to perform packet transfer. 1 to Y. By transmitting the packet to the dedicated VC for X.1. 1 sent to the CSR and the ATM
By referring to the routing table of the level, the ATM cell is changed from CSR to Y. 1 is forwarded to the dedicated VC, and Y. Sent to 1

Here, the transfer of the packet transmitted by the dedicated VC in the unit of ATM {cell} has been described as the direct connection of the dedicated VC. However, the packet transmitted in the dedicated VC is transferred in the unit of AAL (ATM Adaptation Layer) frame. By transferring, the dedicated VC may be directly connected. Also in this case, the AAL # frame transfer can be performed by referring to the above-mentioned routing table at the ATM # level. In any of the above cases, the packet is transferred without performing the analysis processing at the network layer (for example, IP) level.

Also, for a packet transmitted by the dedicated VC, the network layer level routing table reference processing for determining the VC to be the output destination from the final destination address of the packet is not performed, and the other network layer level processing (IP In such a case, the transfer to the dedicated VC to the next-stage node by performing TTL (Time {To} Live) reducing processing or checksum calculation, etc. may be directly connected to the dedicated VC. Also in this case, by referring to the above-mentioned ATM $ level routing table, the VC to be the output destination can be determined, and the packet transfer can be performed. In this case, only part of the processing at the network layer level is performed, and the packet is transferred.

The present invention is applicable regardless of the operation of CSR described above.

When resource reservation is performed by RSVP, it is necessary to schedule IP transfer in the router. However, if CSR is used in the router, packet transfer can be transferred in ATM cell units by the ATM switch function. Scheduling can be performed by the ATM switch function. That is, for a packet that reserves resources, the ATM
By using a switch function (ATM cell transfer, AAL frame transfer, or packet transfer in which a part of IP processing is omitted), transfer can be performed at high speed. In the following, a procedure for setting a dedicated VC when RSVP is used will be described.

(Specific example 1)
In this example, a case will be described in which the ATM connection is SVC (Switched Virtual Connection) and unicast is assumed.

The procedure for setting a dedicated VC will be described taking a network topology as shown in FIG. 2 as an example. H1, H2} indicate a host, and R1, R2, and R3 indicate routers. It is assumed that a default VC is preset between all these nodes.

で は In the following procedure, R1, R2, and R3 are taken out and the procedure performed between them is described. The procedure between the host and the router between H1 and R1 or between R3 and H2 (both the host and the router are both nodes) is the same as the procedure between routers if they are connected by a virtual connection type network. Here, the description is omitted.

(Specific Example 1-1)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is transmitted is transmitted out-of-band.

A method of resource reservation in the router 2 when the routers 1, 2, 3 (R1, R2, R3) exist as shown in FIG. 3 will be described. As an initial state, consider a situation where a default VC from router 1 # to router 2 #, a default VC from router 2 # to router 3 #, and a dedicated VC from router 2 # to router 3 # are set. In the following, a diagram showing the state of message exchange (FIG. 3), an operation diagram inside the downstream router (R2 in FIG. 3) (FIG. 4, FIG. 5), and an inside of the upstream router (R1 in FIG. 3) The operation will be described with reference to FIG.

{First, it is assumed that an RSVP reservation (RESV) message arrives at the router 2 # from the router 3 # as shown in FIG. The RESV message describes Flow {ID} for indicating which packet should be reserved and QOS to be reserved. In the Flow {ID}, a source IP address / port, a destination IP address / port pair, or a Flow {ID} of IPv6 is written. In QOS #, band information and delay information are written.

The router 2 that has received the {RESV message} checks whether there is a downstream dedicated VC for Flow {ID} in the RSVP message according to the flowcharts in FIGS. 4A and 5B (S1). In this example, since a dedicated VC exists, a dedicated VC request message is sent to the upstream node (R1) (S2). This message has the same Flow {ID} and QOS} information as the contents of the RESV message. Alternatively, the quality of the ATM level may be obtained from the QOS # of the RESV, and may be written in the dedicated VC request message as the information of the QOS #.

If there is no dedicated VC on the downstream side, the IP processing unit determines whether or not the requested resource can be secured (S3). If the resource can be reserved, the resource is reserved by performing IP transfer scheduling and upstream. (S5), and sends a dedicated VC request message upstream (S2). If resources cannot be reserved, RESV @ ERROR is sent to the downstream node (S4).

Even if the own router can reserve resources even if there is no dedicated VC on the downstream side, the dedicated VC request message is sent upstream because the dedicated VC is directly connected to the nodes upstream of the own router. This is to deal with the possibility that there may be a node that cannot secure the requested resource unless it is performed. In particular, the destination node (host H2) or a router located at the boundary between the non-virtual connection type network and the virtual connection type network when the destination node is connected to the non-virtual connection type network is directly connected to the dedicated VC. However, the dedicated VC request message is sent upstream.

The router 1 # that has received the dedicated VC request message sets up an ATM connection (dedicated VC) that satisfies the request QOS # with the node (router 2 #) that transmitted the dedicated VC request message using ATM signaling according to the flowchart of FIG. (S21).

When the setting of the ATM connection is completed, an identifier called VCID is attached so that this connection can be uniquely identified at both ends. This is a unique identifier within the logical network to which the routers 1 and 2 belong. This VCID can be assigned, for example, by attaching the ID of a globally unique host and the sequence number of the VCID issued by the host, thereby giving a unique VCID. The VCID created in this way is carried to the downstream node by flowing a VCID proposal message to the newly created ATM connection (dedicated VC) (S22).

{This message includes the VCID proposed by the sender (router 1 #) and the target IP address (IP address of router 2 #). The target IP address is written to deal with the point-to-multipoint conversion of the dedicated VC as described later.

The node (router 2 #) receiving this VCID proposal message checks whether or not the target IP address included in this message is the IP address of its own node (S11), and if so, permits this VCID. If so, VCID @ ACK is transmitted to the upstream node (router 1 #) using the default VC (S12). VCID @ ACK contains at least the VCID proposed by the sender side and allowed by the own node. With this procedure, the VCID exchange ends.

{In order to inform the downstream node (router 2 #) that the VCID exchange is completed and the dedicated VC is available, a dedicated VC notification message is transmitted from router 1 # to router 2 # (S23). This message is transmitted on the default VC (that is, a VC different from the dedicated VC used for packet transmission). This message includes Flow {ID} and VCID.

The node (router 2 #) that has received the dedicated VC notification message knows that the dedicated VC specified by the VCID can be used exclusively for the flow specified by the Flow {ID}, so that the downstream dedicated node having the same Flow {ID} If there is a VC (S13 exists), the dedicated VC on the upstream side and the dedicated VC on the downstream side are directly connected (S14). That is, the correspondence between the dedicated VCs is stored in the routing table at the ATM level. When the dedicated VC becomes usable in this way, a redirect message is sent to the upstream side (S15). The redirect message includes Flow {ID} and VCID, and is transmitted by the default VC.

When the upstream node (router 1) receives the redirect message, the Flow ID has been transmitted by the default VC until now (S24 Yes), and if there is no upstream dedicated VC having the same Flow ID (no S26). If the IP processing unit
The packet related to the ID is sent to the dedicated VC (S25). That is, the routing information used in the IP processing unit is rewritten so that the packet transmitted from the further upstream node (H1) on the default VC is transferred to the dedicated VC for the router 2.

{If a dedicated VC having the same Flow {ID} exists upstream of the router 1} (S26), the dedicated VC on the upstream side and the dedicated VC to the router 2 # are directly connected (S27).

The node (router 2) that has received the dedicated VC notification message sends a Flow ID to the downstream side.
If there is no dedicated VC for use (No in S13), a setting is made to pass the packet received from the dedicated VC on the upstream side to the IP processing unit (S16). This step corresponds to a case where a resource can be reserved without being directly connected, but a dedicated VC request message is sent upstream, and thereby a dedicated VC is set on the upstream side.

Finally, since the router 2 can satisfy the RSVP QOS request, the router 2
RESV is transmitted from the router to the router 1 using the default VC (S17). Note that the order of the redirect of S15 and the transmission of the RESV of S17 may be reversed.

{As a result, the resource reservation of the router 2} is completed. The redirect message is periodically transmitted at an appropriate timing from the router 2 # to the router 1 #, so that the corresponding dedicated VC is held. The message for this holding may be substituted by the RESV message. The dedicated VC for the router to which the redirect message (or the RESV message in case of substitution) is no longer transmitted is released.

(Specific Example 1-2)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is to be transmitted is transmitted in-band.

In the procedure described in the specific example 1-1, after transmitting a dedicated VC request message and performing ATM @ signaling, three messages are transmitted: a VCID proposal, a VCID @ ACK, and a dedicated VC notification. Is passed to the newly created ATM @ connection (dedicated VC), so that the VCID proposal message and VCID @ ACK can be omitted.

{Specific sequence diagram is shown in FIG. 7}, the flowchart for the downstream node is shown in FIGS. 4 and 8, and the flowchart for the upstream node is shown in FIG.

Explaining the points changed from the specific example 1-1, in FIG. 7A, the VCID proposal message and the VCID @ ACK message disappear, and the dedicated VC notification message is transferred through the newly created ATM connection (dedicated VC). different. In addition, the dedicated VC notification message in this example includes the target IP address included in the VCID proposal message in the specific example 1-1, in addition to the Flow {ID} and the VCID.

With the elimination of two messages, the upstream node (FIG. 9)
The operation when the ACK message is received (S23) is eliminated, and the dedicated VC notification described above is transmitted to the newly created ATM connection instead of the VCID proposal (S31). The operation of the downstream node when receiving the RESV is as shown in FIG. 4, and the operation when the VCID ACK proposal is received (S12) is eliminated. When the dedicated VC notification message is received, the operation shown in FIG. After checking whether the target IP address included in this message is its own address, the same operation as in FIG. 5B is performed.

(Specific example 2)
In this example, a case where the ATM connection is a VP (Virtual Path) connection and unicast is assumed will be described.

A method of resource reservation in router 2 when routers 1, 2, and 3 (R1, R2, R3) exist as shown in FIG. 10 will be described. As an initial state, consider a situation where a default VC from router 1 # to router 2 #, a default VC from router 2 # to router 3 #, and a dedicated VC from router 2 # to router 3 # are set. In the following, description will be made with reference to a diagram showing the state of message exchange (FIG. 10), an operation diagram inside the downstream router (FIGS. 11 and 12), and an operation inside the upstream router (FIG. 13).

{First, it is assumed that an RSVP reservation (RESV) message arrives at the router 2 # from the router 3 # as shown in FIG. The RESV message describes Flow {ID} for indicating which packet should be reserved and QOS to be reserved.

The router 2 that has received the RESV message checks whether there is a dedicated VC on the downstream side for the Flow ID in the RSVP message according to the flowchart of FIG. 11 (S41).
. In this example, since there is a dedicated VC, an appropriate one is selected from unused VCs (from R1 to R2) from the upstream router, and it is determined to use this as a dedicated VC (S42). The determined upstream dedicated VC and the downstream dedicated VC are directly connected (the correspondence is stored in an ATM level routing table) (S43), and a redirect message is sent to the upstream node (R1) as the default VC. (S44).

{This message has the same Flow {ID} and VCID information as the contents of the RESV message. As the VCID, an unused VCI # in the VP (VCI # of the dedicated VC selected as described above) is used, and a set of VPI / VCI # is used as the VCID value. If there is no dedicated VC on the downstream side, the IP processing unit determines whether or not the requested resource can be secured (S45). If the resource can be reserved, the resource is reserved by performing IP transfer scheduling and upstream. (S46), and selects an appropriate VC among unused VCs with the router on the upstream side and decides to use this as a dedicated VC (S47), and receives with this dedicated VC. The packet is set to be passed to the IP processing unit (S48), and a redirect message is sent upstream (S44). If the resource cannot be reserved, RESV @ ERROR is sent to the downstream node (R3) (S49).

The router 1 that has received the redirect message switches the packet transfer related to Flow {ID} from the transfer using the default VC to the transfer using the dedicated VC in the same manner as in FIG. Alternatively, the dedicated VC notification message is transmitted by the dedicated VC (S51). This message includes information of {Flow} ID (and VCID).

When the downstream node (router 2) receives the dedicated VC notification message, it operates according to the flowchart of FIG. That is, it is understood that the dedicated VC specified by {VCID} can be used exclusively for Flow {ID}, and the router 2 # can satisfy the RSVP QOS request. Therefore, the RESV is transmitted from the router 2 # to the router 1 # by the default VC. (S52).

{As a result, the resource reservation of the router 2} is completed. The redirect message is periodically transmitted at an appropriate timing from the router 2 # to the router 1 #, so that the corresponding dedicated VC is held. The message for this holding may be substituted by the RESV message. The dedicated VC is released to the router where the redirect message (the RESV message in the case of substitution) is no longer transmitted.

(Specific example 3)
In this example, a case will be described in which the ATM connection is SVC and multicast is assumed.

A method of reserving resources in the router 4 when the routers 1, 2, 3, 4 (R1, R2, R3, R4) exist as shown in FIG. Since the hosts H2 and H3 participate in the multicast group G, a default VC of point-multipoint (hereinafter referred to as p-mp) is set from the router 2 to the router 3 and the router 4. Also, the default VC set to flow data packets and the like from the upstream router to the downstream router is for multicast (which can be p-mp). Point-to-point (
(Hereinafter referred to as pp) is set as needed.

(Specific example 3-1)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is transmitted is transmitted out-of-band.

As an initial state, as shown in FIG. 15, a default VC for multicast (which can be p-mp ({it has already been given here})) is set from the router 2 # to the router 3 # and the router 4, and from the router 2 # to the router 3 Consider a situation in which a dedicated VC (not yet here) that can be a p-mp to a host 3 # is set, and a default VC (pp- #) is set between the host 3 # and the router 4 #. The dedicated VC from the router 2 # to the router 3 # is a dedicated VC of the multicast group G #.

{Here, the dedicated VC from the router 1 # to the router 2} and the dedicated VC from the router 2 # to the router 3 # are set by the procedure described in the specific example 1-1. However, the RESV, VCID @ ACK, dedicated VC notification, and redirect messages described in the specific example 1-1 are transmitted using the default VC of pp @.

In the following, a diagram showing the state of message exchange (FIG. 15), an operation diagram inside the downstream router (R4 in FIG. 15) (FIGS. 4 and 5), and an inside of the upstream router (R2 in FIG. 15) The procedure for the router 4 # to make resource reservation for the packet of the multicast group G # will be described with reference to the operation diagram of FIG.

{First, it is assumed that an RSVP reservation (RESV) message arrives at the router 4 from the host 3 at the default VC as shown in FIG. Note that this is transmitted by the host 3 # in response to the RSVP Path message transferred from upstream to downstream using the default VC for multicast.

The {RESV message} describes Flow {ID} for indicating which packet should be reserved and QOS to be reserved. In the Flow {ID}, a source IP address / port, a destination IP address / port pair, or a Flow {ID} of IPv6 is written. In QOS #, band information and delay information are written.

The router 4 that has received the {RESV message} checks whether there is a downstream dedicated VC for Flow {ID} in the RSVP message according to the flowcharts in FIGS. 4A and 5B (S1). In this example, since there is no dedicated VC on the downstream side, the IP processing unit determines whether the requested resource can be secured (S3). If the resource can be reserved, a dedicated VC request message is sent upstream (S2). If the resource cannot be reserved, RESV @ ERROR is sent to the downstream node (S4). Here, it is assumed that a resource reservation has been made.

The router 2 that has received the dedicated VC request message sets up an ATM connection (dedicated VC) that satisfies the required QoS to the node (router 2 #) that transmitted the dedicated VC request message using ATM signaling according to the flowchart in FIG. (S21). The signaling in this case is ADD {PARTY}, and a new link that branches off from any of the switches through which the dedicated VC from router 2 to router 3 reaches router 4 is added to the existing dedicated VC. .

When the setting of the ATM connection is completed, the VCID defined when the dedicated VC from the router 2 to the router 3 is set, the VCID proposal message is added to the ATM connection with the newly added leaf so that this connection can be uniquely identified at both ends. (Dedicated VC) to carry to the downstream node (S22). This message contains the VCID proposed by the sender (router 2) and the target IP address (IP address of router 4).

The node (router 3, router 4) that has received this VCID proposal message checks whether the target IP address included in this message is the IP address of its own node (S11), and if so, this VCID Is permitted, the VCID ACK is transmitted to the upstream node (router 2) with the default VC of pp (S12). The VCID ACK contains at least the VCID proposed by the sender side and allowed by the own node. With this procedure, the VCID exchange ends. Here, since the router 4 is the target, only the router 4 transmits the VCID ACK to the upstream node.

{In order to inform the downstream node (router 4) that the {VCID exchange is completed and the dedicated VC is available}, a dedicated VC notification message is transmitted from router 2} to router 4 # (S23). This message is transmitted on the default VC of pp (that is, a VC different from the dedicated VC used for packet transmission). This message includes Flow {ID} and VCID.

{The node (router 4) that has received the dedicated VC notification message knows that the dedicated VC specified by the VCID can be used exclusively for the flow specified by the Flow {ID}. It is checked that there is no dedicated VC for Flow {ID} on the downstream side, and it is found that there is no dedicated VC (No in S13), so that a setting is made to pass the packet received by the dedicated VC on the upstream side to the IP processing unit ( S16). If there is a dedicated VC, it is directly connected.

Note that the router 4 sends a packet from the time when a leaf to itself is added to the dedicated VC by ADD {PARTY}. However, until the dedicated VC notification message is received, the handling of this packet is not known. Until it is ignored and the necessary setting is made after receiving the dedicated VC notification, the packet transmitted by the multicast default VC is transferred to the IP processing unit and transferred to the host 3.

(4) When the dedicated VC becomes available, a redirect message is sent to the upstream side (S15). The redirect message includes Flow {ID} and VCID, and is transmitted by the default VC of pp}.

Upon receiving the redirect message, the upstream node (router 2) receives the redirect message.
Since the ID has been transmitted by the dedicated VC until now (S24 No), nothing is performed.

Note that among the operations of the nodes on the upstream side in the case of the multicast, S25 in FIG. 6C is performed when the packet related to the Flow {ID} that has been sent to the multicast default VC is sent to the dedicated VC. The same packet is kept flowing to the multicast default VC. This is because in the case of multicast, there is a possibility that a different QOS is required for each receiver, and there is a case where there is a node that does not set a dedicated VC and receives a packet on the default VC for multicast. It is.

{Lastly, since the router 4 can satisfy the RSVP QOS request, the router 4 sends the RESV to the router 2 with the default VC of pp} (S17). Note that the order of S15 and S17 may be reversed.

(4) With the above, the resource reservation of the router 4 is completed. Note that the redirect message is periodically transmitted from the router 4 to the router 2 at an appropriate timing to retain the leaf of the corresponding dedicated VC. The message for this holding may be substituted by the RESV message. The leaf to the router to which the redirect message (the RESV message in the case of substitution) is no longer transmitted is deleted.

(Specific example 3-2)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is to be transmitted is transmitted in-band.

状況 As an initial state, a situation similar to that in FIG. 15 is considered. Here, the dedicated VC from the router 1 # to the router 2 # and the dedicated VC from the router 2 # to the router 3 # are set according to the procedure described in the specific example 1-2. However, the RESV and redirect messages described in the specific example 1-2 are transmitted using the default VC of pp @.

Diagram showing message exchange (FIG. 16), operation diagram inside the downstream router (R4 in FIG. 16) (FIGS. 4 and 8), and operation diagram inside the upstream router (R2 in FIG. 16) (FIG. 9
), A procedure in which the router 4 reserves resources for packets of the multicast group G 1 will be described.

Explaining the points changed from the specific example 3-1, in FIG. 16, the VCID proposal message and the VCID @ ACK message have disappeared, and the dedicated VC notification message is transferred through the ATM @ connection (dedicated VC) to which a leaf is newly added. That is different. In addition, the dedicated VC notification message in this example includes the target IP address included in the VCID proposal message in the specific example 3-1 in addition to the Flow {ID} and the VCID. Thus, the router 3 # that has received the dedicated VC notification to the router 4 # can ignore this.

With the elimination of two messages, the upstream node (FIG. 9)
The operation when the ACK message is received (S23) is eliminated, and the dedicated VC notification described above is transmitted to the ATM connection with the newly added leaf instead of the VCID proposal (S31). The operation of the downstream node when receiving the RESV is as shown in FIG. 4. The operation when the VCID ACK proposal is received (S12) is eliminated, and when the dedicated VC notification message is received, the operation proceeds to FIG. As shown, after checking whether or not the target IP address included in this message is its own address, the same operation as in FIG. 5B is performed.

In the above description, the method of performing resource reservation utilizing the technology of CSR # triggered by RSVP has been described. However, instead of setting a dedicated VC using the RSVP RESV message as a trigger as described above, a data packet is used as a trigger. Setting a dedicated VC can be realized in a similar manner.

異 な る The following two points are different from the case where RSVP is triggered. One is that when there is an RSVP, a dedicated VC request message is sent out when a RESV message is received, but when there is no RSVP, a dedicated VC request message is sent out when a data packet comes. Thereafter, an operation of setting a dedicated VC and making it available for data packet transfer (directly connecting or transferring by performing IP processing) is performed in the same manner. Another difference is that when the dedicated VC notification message is received, the RESV message is not transmitted upstream.

Specifically, for example, when the router 2 of FIG. 2 receives a data packet on the default VC, the router 2 transfers the data packet to the next node (router 3) on the default VC (or dedicated VC), and A dedicated VC request message is sent to the upstream (router 1) so as to set a dedicated VC having Flow {ID} related to. At this time, a set of the source address / port and the destination address / port (or only the destination address / port) written in the data packet is set as Flow {ID}, and the Flow {ID} is included in the dedicated VC request message.

When a dedicated VC notification message indicates that a dedicated VC has been set with the router 1, if there is a dedicated VC on the downstream side (to the router 3) having a Flow {ID} related to the packet, it is directly connected. If not, the packet transferred from the router 1 by the dedicated VC is transferred to the router 3 by the default VC. When the router 1 knows from the redirect message that the router 2 can use the dedicated VC, the router 1 transfers the data packet which has been transferred by the default VC until now by the dedicated VC.

Also, for example, the router 4 of FIG. 14 receives a data packet on the multicast default VC (the router 1 determines at this point that the transfer by the dedicated VC for the router 3 and the transfer by the default VC for the router 4 are performed). The data packet is transferred to the next node (host 3) by default VC (or dedicated VC), and Flow {ID} (the address in this case is a multicast address) obtained from the data packet is transferred to the next node (host 3). A dedicated VC request message is sent to the upstream (router 2) by the default VC of pp # so that the dedicated VC possessed is set on the upstream side.

Then, when it is known from the dedicated VC notification message that a leaf to the router 4 has been added to the dedicated VC from the router 2 to the router 3, if there is a downstream dedicated VC having Flow {ID} related to the packet, If there is no direct connection, the packet transferred from the router 1 by the dedicated VC is transferred to the host 3 by the default VC. Note that the router 1 maintains the leaf corresponding to each of the p-mp dedicated VCs while the redirect messages are periodically transmitted from the routers 3 and 4 at the respective pp @ default VCs (redirect message). (Leaves to routers that are no longer sent are deleted).

In the case where the data packet is used as a trigger, a data packet (a flow to which the above-mentioned procedure belongs) may be selected based on information included in the data packet.

(Embodiment 2)
In the present embodiment, another method for realizing RSVP, which is a resource reservation protocol, on an ATM using the technology of CSR will be described.

In the first embodiment, the procedure for setting the dedicated VC on the upstream side from the node where the RSVP RESV message has arrived has been described. Here, the procedure for setting the dedicated VC on the downstream side when the RESV message has arrived will be described. .

(Specific example 1)
In this example, a case will be described in which the ATM connection is SVC (Switched Virtual Connection) and unicast is assumed.

(Specific example 1-1)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is transmitted is transmitted out-of-band.

A method of reserving resources in router 2 when routers 1, 2, and 3 (R1, R2, R3) exist as shown in FIG. 17 will be described. Consider a situation in which a default VC is set from router 1 # to router 2 # and from router 2 # to router 3 # as an initial state. In the following, a diagram showing the state of message exchange (FIG. 17), an operation diagram inside the downstream router (R2 in FIG. 17) (FIGS. 22 and 23), and an inside of the upstream router (R1 in FIG. 17) The operation will be described with reference to FIGS. 18, 19, 20, and 21.

First, it is assumed that the RSVP RESV message arrives at the router 2 from the router 3 as shown in FIG. In the RESV message, Flow {ID} and QOS to be reserved are written.

The router 2 # determines whether or not resource reservation for realizing the QOS # to be reserved described in the RESV message can be performed by the IP scheduler (S61). If possible, the router 2 # reserves resources by the IP scheduler (S62). The message is transferred to the upstream side (to the router 1 #) by the default VC (S63). In the case where it is not possible, the router 2 # has not made a resource reservation now, but in anticipation that resource reservation can be made by setting up a dedicated VC on both the upstream side and the downstream side and making a direct connection later, the RESV message is sent. The data is sent to the upstream side (S63).

When the RESV is transmitted, an operation for setting a dedicated VC on the downstream side (to the router 3) is performed. Note that the RESV message may be sent to the upstream side after the downstream dedicated VC is set (redirect message is returned from the router 3 #).

Here, even when a resource can be reserved by the IP scheduler, the operation for setting the dedicated VC on the downstream side is performed because dedicated VCs are set on both the upstream side and the downstream side later to perform direct connection. When this is possible, the resource reservation for this flow is performed not by the IP scheduler but by the ATM switch function, so that the IP scheduler resource is given a margin and the other flows can use the IP scheduler resource. It is to keep.

The operation procedure of the router 2 that has received the RESV message, as shown in FIG. 18, after transmitting the RESV message upstream (S63), sets the ATM connection (dedicated VC) to the next node (router 3 #) by ATM signaling. After that, a VCID proposal message is transmitted through this dedicated VC (S65).

The downstream node (router 3) receiving the VCID proposal message checks whether the target IP is its own address according to FIG. 22 (S71), and if it is its own address, transmits VCID @ ACK on the default VC (step S71). S72).

The upstream node (router 2) that has received the {VCID} ACK transmits a dedicated VC notification to the downstream side using the default VC according to FIG. 19 (S66).

The downstream node (router 3) that has received the dedicated VC notification checks whether there is a dedicated VC on the downstream side (to the host 2) having the same Flow {ID} according to FIG. 23 (S73). It is set to pass the packet received by the dedicated VC (from the router 2 #) to the IP processing unit (S74). If there is, the dedicated VC on the upstream side and the dedicated VC on the downstream side are directly connected (S75). Finally, in order to notify the upstream that the own node can use the dedicated VC, a redirect message is transmitted to the upstream node using the default VC (S76).

The upstream node (router 2) that has received the redirect message does not perform the default transfer according to FIGS. 20 and 21 (if the packet has already been transferred to the dedicated VC like multicast described later) (S81 No). ),finish.

When the default transfer is performed, the upstream router (Router 1) having the same Flow ID is used.
It is checked whether there is a dedicated VC (S82), and if there is a dedicated VC, the dedicated VC on the upstream side and the dedicated VC on the downstream side (to the router 3) are directly connected (S83). If there is no dedicated VC, the IP processing unit transfers the packet which has been transferred by the default VC until now to the dedicated VC (S84).

Regarding this Flow {ID}, if the own node is the transmitting node instead of transferring the packet received by the own node (S85 Yes), the process ends here.

In other cases, the process waits for a predetermined time (S86), and a dedicated VC having the same Flow {ID} is not set on the upstream side and the dedicated VC on the upstream side and the dedicated VC on the downstream side are not directly connected (No in S87). In order to cancel the RESV message transmitted in S63, it is checked whether or not the resource reservation (S62) has been performed by the IP scheduler (S88). Is transmitted, and a RESV @ Err message indicating that the resource reservation has failed is transmitted to the downstream side (router 3 #). In step S88, it may be checked again whether the resource reservation of the IP scheduler can be made.

If a dedicated VC having the same Flow {ID} is set on the upstream side within the predetermined time and the dedicated VC on the upstream side and the dedicated VC on the downstream side are directly connected (Yes at S87), resource reservation by the IP scheduler is performed. It is checked whether or not (S62) has been performed (S90). If it has not been performed, it is left as it is. If it has been performed, the resource reservation is canceled because it is unnecessary due to the direct connection of the dedicated VC (S91).

In the above description, the resource reservation of the IP scheduler is made first, and then the dedicated VC is canceled if it can be directly connected. However, if there is a high possibility that the dedicated VC can be directly connected, the IP scheduler is A dedicated VC is set on the downstream side without performing resource reservation, and a direct connection is established when a dedicated VC is formed on the upstream side. If the direct connection is not possible (No in S87), resource reservation of the IP scheduler is attempted. Alternatively, if the resource can be reserved, it may be left as it is, otherwise, RESV {Tear} may be returned upstream and RESV @ Err may be returned downstream.

{As a result, the resource reservation of the router 2} is completed. It should be noted that the redirect message is periodically transmitted from the router 3 to the router 2 at an appropriate timing to retain a corresponding dedicated VC. The message for this holding may be replaced by a RESV message. The dedicated VC for the router to which the redirect message (or the RESV message in case of substitution) is no longer transmitted is released.

(Specific Example 1-2)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is to be transmitted is transmitted in-band.

In the procedure described in the specific example 1-1, after performing ATM signaling, three messages are transmitted: a VCID proposal, a VCID @ ACK, and a dedicated VC notification. By flowing to the dedicated VC), the VCID proposal message and VCID @ ACK can be omitted.

FIG. 24 shows a specific sequence diagram. FIGS. 20, 21, and 25 show flowcharts of the downstream node, and FIG. 26 shows a flowchart of the upstream node.

Explaining the points changed from the specific example 1-1, in FIG. 24, the VCID proposal message and the VCID ACK message are eliminated, and the dedicated VC notification message is transferred through the newly created ATM connection (dedicated VC). different. In addition, in the dedicated VC notification message in this example, in addition to the Flow ID and the VCID, the target IP address included in the VCID proposal message in the specific example 1-1 is included.

With the elimination of two messages, the upstream node no longer has the operation when receiving the VCID @ ACK message (FIG. 19), and the newly created ATM @ connection is not described as a VCID proposal but as described above. A dedicated VC notification is transmitted (S105 in FIG. 25).

The downstream node loses the operation (FIG. 22) when receiving the VCID @ ACK proposal, and when receiving the dedicated VC notification message, as shown in FIG. 26, the target IP address included in this message is After the address is checked (S111), the same operation as in FIG. 23 is performed.

(Specific example 2)
In this example, a case where the ATM connection is a VP (Virtual Path) connection and unicast is assumed will be described.

A method of reserving resources in router 2 when routers 1, 2, and 3 (R1, R2, R3) exist as shown in FIG. 27 will be described. Consider a situation in which a default VC is set from router 1 # to router 2 # and from router 2 # to router 3 # as an initial state. In the following, a specific example 1 will be described using a diagram showing the state of message exchange (FIG. 27), an operation diagram inside the downstream router (FIG. 23), and an operation inside the upstream router (FIGS. 20, 21, and 28). Explain the changes.

In FIG. 17, when the reservation (RESV) message is received, ATM @ signaling, VCID proposal, and VCID @ ACK are performed. However, in the case of VP, there is an ATM @ connection in advance, and VPI / VCI} can be used as VCID. These messages are not shown in FIG.

Since there is no transfer of these three messages, the upstream node transmits the dedicated VC notification message of S125 of FIG. 28 instead of the transmission of the VCID proposal message of S65 of FIG. Also, there is no operation for VCID @ ACK reception in FIG. The downstream node does not operate when the VCID proposal of FIG. 22 is received.

(Specific example 3)
In this example, a case will be described in which the ATM connection is SVC and multicast is assumed.

(Specific example 3-1)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is transmitted is transmitted out-of-band.

As an initial state, as shown in FIG. 29, a default VC for multicast (a VC which can be p-mp ({it is already here})) is set from router 2 # to router 3 # and router 4, and from router 2 to router 3 Consider a situation in which a dedicated VC (not yet here) that can be a p-mp to a router is set, and a default VC (pp-) is set between the router 1 and the router 2. The dedicated VC from the router 2 # to the router 3 # is a dedicated VC of the multicast group G #.

Here, the dedicated VC from the router 1 to the router 2 and the dedicated VC from the router 2 to the router 3 are described in Specific Example 1
This is set according to the procedure described in 1. However, the RESV, VCID ACK, dedicated VC notification, and redirect messages described in the specific example 1-1 are transmitted using the pp default VC.

In the following, a diagram showing the state of message exchange (FIG. 29), an operation diagram inside the downstream router (R4 in FIG. 29) (FIGS. 22 and 23), and an inside of the upstream router (R2 in FIG. 29) The procedure for the router 2 to make a resource reservation for the packet of the multicast group G # will be described with reference to the operation diagrams (FIGS. 18, 19, 20, 21) of FIG. First, it is assumed that an RSVP reservation (RESV) message arrives at the router 2 from the router 4 with the default VC as shown in FIG. Note that this is transmitted by the router 4 in response to the RSVP Path message transferred from upstream to downstream using the default VC for multicast.

The {RESV message} describes Flow {ID} for indicating which packet should be reserved and QOS to be reserved.

The router 2 receiving the RESV message checks whether the IP scheduler can reserve resources according to the flowchart of FIG. 18 (S # 61). If the resource can be reserved, the resource is reserved (S $ 62), and then a reservation (RESV) message is transmitted upstream (S $ 63). If the resource reservation cannot be made, the reservation message is transmitted upstream without making the resource reservation (S # 63).

{Next, after setting the ATM connection to the downstream node by ATM signaling (S64), the VCID proposal message is transmitted by the set ATM connection (S65). In this VCID proposal message, the target IP address and {VCID} are written. Here, the target IP address includes the address of the router 4 #.

The router 3 and the router 4 receive the @VCID proposal message. The node receiving this checks whether the target IP address is its own address according to the flowchart of FIG. The target IP address of the VCID proposal message is the router 4 #, and the router 3 # is different from its own IP address (S # 71No). Since the router 4 has the same IP address (S @ 71 yes), the router 4 transmits the VCID @ ACK upstream (S @ 72).

(4) In order to inform the downstream node (router 4) that the VCID exchange has been completed and the dedicated VC is available, a dedicated VC notification message is transmitted from router 2 to router 4 (S # 66 in FIG. 19). This message is transmitted on the default VC of pp @. This message includes Flow {ID} and VCID.

{The node (router 4) that has received the dedicated VC notification message knows that the dedicated VC specified by the VCID can be used exclusively for the flow specified by the Flow {ID}. According to FIG. 23, it is checked that there is a dedicated VC for Flow {ID} on the downstream side, and it is found that there is no dedicated VC (no S73), so that the packet received by the dedicated VC on the upstream side is passed to the IP processing unit. Is set (S74). If there is a dedicated VC, it is directly connected.

Note that the router 4 sends a packet from the time when a leaf to itself is added to the dedicated VC by ADD {PARTY}. However, until the dedicated VC notification message is received, the handling of this packet is not known. The packet transmitted by the default VC for multicast is transferred to the IP processing unit and is transferred until the necessary setting is made after receiving the dedicated VC notification.

(4) When the dedicated VC becomes available, a redirect message is sent to the upstream side (S76). The redirect message includes Flow {ID} and VCID, and is transmitted by the default VC of pp}.

Upon receiving the redirect message, the upstream node (router 2) receives the redirect message.
Since the ID has been transmitted by the dedicated VC (S81 No), nothing is performed.

In the operation of the node on the upstream side in the case of the multicast, S84 in FIG. 20 is performed when the packet related to the Flow {ID} which has been sent to the multicast default VC is sent to the dedicated VC. To keep the same packet flowing. This is because in the case of multicast, there is a possibility that a different QOS is required for each receiver, and there is a case where there is a node that does not set a dedicated VC and receives a packet on the default VC for multicast. It is.

The processing after the end of {S} 84 is the same as that of the specific example 1-1.

(4) With the above, the resource reservation of the router 2 with respect to the router 4 is completed. Note that the redirect message is periodically transmitted from the router 4 to the router 2 at an appropriate timing to retain the leaf of the corresponding dedicated VC. The message for this holding may be replaced by a RESV message. The leaf to the router to which the redirect message (the RESV message in the case of substitution) is no longer transmitted is deleted.

(Specific example 3-2)
In this example, a case will be described in which a message for notifying which dedicated VC a packet belonging to a certain flow is to be transmitted is transmitted in-band.

As an initial state, as shown in FIG. 30, a default VC for multicast (which can be a p-mp ({VC already existing})) is set from the router 2 # to the router 3 # and the router 4. Consider a situation in which a dedicated VC (not yet here) that can be a p-mp to a router is set, and a default VC (pp-) is set between the router 1 and the router 2. The dedicated VC from the router 2 # to the router 3 # is a dedicated VC of the multicast group G #.

In the procedure described in the specific example 3-1, after the ATM signaling is performed, the VCID proposal, the VCID @ ACK, and the dedicated VC notification are transmitted, but the ATM @ connection that newly created the dedicated VC notification message is transmitted. By flowing to the dedicated VC), the VCID proposal message and VCID @ ACK can be omitted.

A specific sequence diagram is shown in FIG. 30, a flowchart of the downstream node (R4 in FIG. 30) is shown in FIGS. 20, 21, and 25, and a flowchart of the upstream node ({R2 in FIG. 30)} is shown in FIG.

Explaining the points changed from the specific example 3-1, the difference is that instead of sending out the VCID proposal message, the dedicated VC notification message is transferred through the newly created ATM connection (dedicated VC). In addition, the dedicated VC notification message in this example includes the target IP address included in the VCID proposal message in the specific example 1-1, in addition to the Flow {ID} and the VCID.

With the elimination of the two messages, the upstream node no longer has the operation (FIG. 19) when receiving the VCID ACK message, and the newly created ATM connection is not described as a VCID proposal but as described above. A dedicated VC notification is transmitted (S105 in FIG. 25).

The downstream node loses the operation (FIG. 22) when receiving the VCID @ ACK proposal, and when receiving the dedicated VC notification message, as shown in FIG. 26, the target IP address included in this message is After the address is checked (S111), the same operation as in FIG. 23 is performed.

In the above description, the method of performing resource reservation utilizing the technology of CSR # triggered by RSVP has been described. However, instead of setting a dedicated VC using the RSVP RESV message as a trigger as described above, a data packet is used as a trigger. Setting a dedicated VC can be realized in a similar manner.

異 な る The following two points are different from the case where RSVP is triggered. One is that when RSVP is present, when a RESV message is received, ATM # signaling is performed and a dedicated VC is set downstream. However, when RSVP is not present, this is performed when a data packet comes. Thereafter, the operation of making the set dedicated VC available for data packet transfer (directly connecting or performing IP processing and transferring) is the same. Another difference is that the RESV message, RESV {Tear}, is not sent upstream.

Specifically, for example, when the router 2 of FIG. 2 receives a data packet on the default VC or the dedicated VC, the router 2 transfers the data packet to the next node (router 3) on the default VC, and ATM signaling is performed to set a dedicated VC to the next node having a certain Flow {ID}. Then, a set of the source address / port and the destination address / port (only the destination address / port may be written) written in the data packet is set as Flow {ID}, and the dedicated VC notification message in which the Flow {ID} is written is transmitted downstream. I do.

When the router 2 # knows from the redirect message that the router 3 # can use the dedicated VC, if there is an upstream-side dedicated VC (from the router 1 #) having the Flow {ID} related to the packet, If it is not directly connected, the packet transferred from the router 1 by the default VC is transferred to the router 3 by the dedicated VC.

Further, for example, when the router 2 of FIG. 14 recognizes that the router 4 # has joined the multicast group G by a protocol for IP multicast (for example, IGMP (Internet Group Management Protocol)), the related Flow {ID} (in this case, ADD {PARTY} is performed so that a dedicated VC having an address (a multicast address) is set on the downstream side. Then, a leaf to the router 4 is added to the dedicated VC from the router 2 to the router 3. Note that while the redirect message is periodically transmitted from the routers 3 and 4 in the respective pp @ default VCs, the router 2 # maintains the leaf corresponding to each of the p-mp dedicated VCs (the redirect message). (Leaves to routers that are no longer sent are deleted).

In the case where the data packet is used as a trigger, a data packet (a flow to which the above-mentioned procedure belongs) may be selected based on information included in the data packet.

Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying constituent elements in an implementation stage without departing from the scope of the invention. Various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Further, components of different embodiments may be appropriately combined.

The figure for demonstrating operation | movement of CSR #. The figure which shows the example of the network topology in the case of a unicast. FIG. 4 is a diagram illustrating a state of message exchange in a specific example 1-1 of the first embodiment. FIG. 5 is a diagram illustrating an operation example of a downstream node according to the first embodiment. FIG. 5 is a diagram illustrating an operation example of a downstream node according to the first embodiment. FIG. 5 is a diagram illustrating an operation example of an upstream node according to the first embodiment. FIG. 4 is a diagram showing a state of message exchange in a specific example 1-2 of the first embodiment. FIG. 9 is a diagram illustrating another operation example of the downstream node according to the first embodiment. FIG. 9 is a diagram showing another operation example of the upstream node of the first embodiment. FIG. 4 is a diagram illustrating a state of message exchange in a specific example 2 of the first embodiment. FIG. 11 is a diagram showing still another operation example of the downstream node of the first embodiment. FIG. 11 is a diagram showing still another operation example of the downstream node of the first embodiment. FIG. 10 is a diagram showing still another operation example of the upstream node of the first embodiment. The figure which shows the example of the network topology in the case of a multicast. FIG. 3 is a diagram illustrating a state of message exchange in a specific example 3-1 of the first embodiment. FIG. 3 is a diagram showing a state of message exchange in a specific example 3-2 of the first embodiment. The figure which shows the mode of the message exchange of the specific example 1-1 of Embodiment 2. FIG. 14 is a diagram illustrating an operation example of an upstream node according to the second embodiment. FIG. 14 is a diagram illustrating an operation example of an upstream node according to the second embodiment. FIG. 14 is a diagram illustrating an operation example of an upstream node according to the second embodiment. FIG. 14 is a diagram illustrating an operation example of an upstream node according to the second embodiment. FIG. 13 is a diagram illustrating an operation example of a downstream node according to the second embodiment. FIG. 13 is a diagram illustrating an operation example of a downstream node according to the second embodiment. FIG. 14 is a diagram showing a state of message exchange in a specific example 1-2 of the second embodiment. FIG. 14 is a diagram illustrating another operation example of the upstream node according to the second embodiment. FIG. 14 is a diagram illustrating another operation example of the downstream node according to the second embodiment. FIG. 14 is a diagram showing a state of message exchange in a specific example 2 of the second embodiment. FIG. 14 is a diagram showing still another operation example of the upstream node of the second embodiment. FIG. 13 is a diagram illustrating a state of message exchange in a specific example 3-1 of the second embodiment. The figure which shows the mode of the message exchange of the specific example 3-2 of Embodiment 2.

Claims (8)

A correspondence relationship between a first virtual connection set in a first logical network serving as a packet receiving source and a second virtual connection set in a second logical network serving as a destination of the packet is described. Storage means for storing;
Receiving means for receiving a first message for resource reservation from the second logical network;
The presence or absence of the first and second virtual connections when it is determined that the first and second virtual connections exist or that the resource reservation that can satisfy the service quality indicated by the first message cannot be made; Transmission means for determining whether to transmit a second message for resource reservation based on the first message to the first logical network, and transmitting the message based on the result. ,
A router for transmitting, via the second virtual connection, a packet received via the first virtual connection in accordance with the correspondence stored in the storage unit. A correspondence relationship between a first virtual connection set in a first logical network serving as a packet receiving source and a second virtual connection set in a second logical network serving as a destination of the packet is described. Storage means for storing;
Receiving means for receiving a first message for resource reservation from the second logical network;
Transmitting means for transmitting a second message for resource reservation based on the first message received by the receiving means to the first network;
When it is determined that at least one of the first and second virtual connections does not exist and the quality of service based on the first message cannot be satisfied, and depending on the presence or absence of the first and second virtual connections, Means for determining whether or not to cancel the resource reservation by the second message, and canceling the resource reservation based on the result;
A router for transmitting a packet received via the first virtual connection via the second virtual connection in accordance with the correspondence stored in the storage unit. 3. The router device according to claim 1, wherein the transmitting unit further transmits a third message indicating that the resource reservation indicated by the first message cannot be performed. 4. A packet transfer method of a router device capable of transferring a packet from a first node connected to a first logical network to a second node connected to a second logical network,
Receiving a first message for resource reservation from the second node;
Storing a correspondence relationship between a first virtual connection for receiving a packet from the first node and a second virtual connection for transmitting the packet to the second node;
If the correspondence is stored or if it is determined that a resource reservation for satisfying the service quality indicated by the first message is possible, a communication with the first node based on the received first message is performed. Send a second message for the resource reservation of
The first node requests the first logical network to set up the first virtual connection in response to a resource reservation request based on the first message;
If it is determined that the second virtual connection does not exist and that it is not possible to reserve resources enough to transfer a packet so as to satisfy the quality of service indicated by the first message, a request is made based on the first message. Sending a third message to the second node that the resource reservation has failed,
A packet transfer method, wherein a packet received from the first virtual connection is transferred to the second virtual connection according to the stored correspondence. A packet transfer method of a router device capable of transferring a packet from a first node connected to a first logical network to a second node connected to a second logical network,
Receiving a first message for resource reservation from the second node;
Storing a correspondence relationship between a first virtual connection for receiving a packet from the first node and a second virtual connection for transmitting the packet to the second node;
When the correspondence is stored or when a resource reservation for satisfying the service quality indicated by the first message is possible, or when the service quality indicated by the first message is transferred via a network layer level transfer. If it can be secured, transmitting a second message for resource reservation with the first node based on the received first message;
When the correspondence is stored, a packet received via the second virtual connection is transferred to the second virtual connection in accordance with the correspondence, or a packet received from the first logical network is transferred. A packet transfer method at a network layer level to the second logical network. A packet transfer method of a router device capable of transferring a packet from a first node connected to a first logical network to a second node connected to a second logical network,
Receiving a first message for resource reservation from the second node;
Sending a second message for resource reservation with the first node based on the first message;
When there is a first virtual connection for receiving a packet from the first node and a second virtual connection for transmitting the packet to the second node, the correspondence between the two virtual connections is described. Remember,
When the resource reservation cannot be made based on the first message when the correspondence relationship is not stored, and when the resource reservation that satisfies the service quality indicated by the first message cannot be made even at the network layer level. When determining, transmitting a cancellation message to the effect of canceling the second message to the first node;
When the correspondence is stored, a packet received via the first virtual connection is transferred to the second virtual connection according to the correspondence, or a packet received from the first logical network is transferred. A packet transfer method at a network layer level to the second logical network. 7. The method according to claim 5, wherein, when transferring the packet, when the correspondence is stored, the packet is transferred using the stored correspondence rather than the transfer at a network layer level. Packet transfer method. A packet transfer method of a router device capable of transferring a packet from a first node connected to a first logical network to a second node connected to a second logical network,
Receiving a first message for resource reservation from the second node;
Sending a second message for resource reservation based on the first message to the first node;
When there is a first virtual connection for receiving a packet from the first node and a second virtual connection for transmitting the packet to the second node, the correspondence between the two virtual connections is described. Remember,
When it is determined that a resource reservation that satisfies the service quality indicated by the first message when the correspondence is not stored cannot be made, a cancellation message to cancel the second message is sent to the first node. Send,
Requesting the second logical network to set up the second virtual connection in response to a resource reservation request based on the first message;
Forwarding the packet received from the first virtual connection to the second virtual connection according to the stored correspondence;
The packet transmitting the cancellation message to the first node when the setting of the first virtual connection is not completed even after a predetermined time has elapsed after transmitting the second message. Transfer method.

Images