WO2011083846A1 - 通信システム、転送ノード、経路管理サーバおよび通信方法 - Google Patents
通信システム、転送ノード、経路管理サーバおよび通信方法 Download PDFInfo
- Publication number
- WO2011083846A1 WO2011083846A1 PCT/JP2011/050182 JP2011050182W WO2011083846A1 WO 2011083846 A1 WO2011083846 A1 WO 2011083846A1 JP 2011050182 W JP2011050182 W JP 2011050182W WO 2011083846 A1 WO2011083846 A1 WO 2011083846A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transfer
- route
- information
- node
- packet
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/34—Source routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/42—Centralised routing
Definitions
- the present invention is based on the priority claim of Japanese Patent Application No. 2010-002875 (filed on Jan. 08, 2010), the entire contents of which are incorporated herein by reference. Shall.
- the present invention relates to a communication system, a transfer node, a route management server, and a communication method, and more particularly, to a communication system, a transfer node, a route management server, and a communication method for realizing communication by transferring a packet by a transfer node arranged in a network. .
- FIG. 30 shows a network configuration using IP (Internet Protocol).
- a communication node 100 (communication node 100a and communication node 100b) is a communication node that performs communication using IP.
- the forwarding node 200 determines the forwarding destination of the IP packet and forwards it to the determined forwarding destination. The forwarding node repeats this and finally forwards the IP packet to the destination communication node.
- the routing table is a table indicating which network addressed packet should be sent to which forwarding node responsible for the next forwarding process via which interface.
- the destination network address, the next forwarding destination IP address, and the sending destination This table lists the correspondence of the interface as one entry.
- the entry includes information other than the information described above, but is omitted here for simplicity.
- the network address is an address obtained by extracting a part of the number of bits from the top of the IP address, and is expressed in a format such as 192.168.1.0/24, for example.
- the upper 24 bits of the address is a network address, and the network includes addresses from 192.168.1.1 to 192.168.1.255. At this time, 24 is called a prefix length.
- the forwarding node 200 uses a method called longest match when determining appropriate route information from the routing table. This is a method in which the destination address of the IP packet is compared with each entry in the routing table, and the higher-order bits of the destination address are determined to match the longer number of bits.
- the routing table is set in advance in the forwarding node 200 by a manual method or automatically by a protocol for exchanging route information called a routing protocol.
- a packet is transferred by the above transfer method.
- the packet transfer depends on the routing table of each transfer node, and there is a problem that the route cannot be completely controlled.
- the transfer destination is determined based only on the destination address, there is a problem in that precise route control cannot be performed due to differences such as the source address and communication by which application.
- the source routing is a method in which a source node (for example, the communication node 100a) explicitly enumerates the address of the forwarding node 200 to be used as a forwarding route in a transmission packet.
- the communication node 100a can transfer the packet to a destination node (for example, the communication node 100b) through a transfer path intended by an application to be used.
- MPLS Multi-Protocol Label Switching
- the labeling is performed when the packet is transferred after the packet is input to the forwarding node arranged at the boundary of the MPLS network, and the forwarding node in the MPLS network thereafter labels each time the packet is transferred. Repeat the transfer process while pasting. Then, when the data is transferred to an external network by a transfer node arranged at the boundary of the MPLS network, the label is removed by the transfer node.
- LDP Constrained Routing-Label Distribution Protocol
- LDP is a protocol for exchanging the label between forwarding nodes in an MPLS network.
- LDP intended to strictly specify a packet forwarding route is CR-LDP. It is.
- Patent Document 1 stores a plurality of relay nodes positioned in parallel in the routing header in the source routing technique, and the relay node is selected from among the plurality of relay nodes positioned in parallel based on a predetermined policy.
- a packet communication method in which one relay node is selected is disclosed.
- OpenFlow captures communication as an end-to-end flow and performs path control, failure recovery, load balancing, and optimization on a per-flow basis.
- the OpenFlow switch that functions as a forwarding node includes a secure channel for communication with the OpenFlow controller, and operates according to a flow table that is appropriately added or rewritten from the OpenFlow controller. In the flow table, for each flow, a set of a rule that collates with the packet header, an action that defines the processing content, and flow statistical information is defined.
- the OpenFlow switch when it receives the first packet (first packet), it searches the flow table for an entry having a rule (FlowKey) that matches the header information of the received packet. When an entry that matches the received packet is found as a result of the search, the OpenFlow switch performs the processing content described in the action field of the entry on the received packet. On the other hand, if no entry matching the received packet is found as a result of the search, the OpenFlow switch forwards the received packet to the OpenFlow controller via the secure channel, and the source / destination of the received packet. To request the determination of the route of the packet based on the above, receive the flow entry that realizes this, and update the flow table.
- FlowKey a rule
- Patent Document 1 and Non-Patent Documents 1 and 2 are incorporated herein by reference.
- the following analysis has been made by the present invention.
- Forwarding nodes based on IP technology that is, routing tables held by switches and routers, have been increasing, and a problem called explosion of route information has been pointed out.
- the route increase the required amount of memory for holding the routing table increases and the route determination processing takes time, so that the packet transfer processing capability deteriorates.
- MPLS can reduce the route determination time as compared with IP routing, if various forwarding policies are applied, the number of entries in the routing table also increases, leading to deterioration in processing performance.
- suppression of the number of entries in the routing table is an important issue for the forwarding node from the viewpoint of reducing memory and improving processing capacity.
- source routing since the address of the forwarding node 100 is stored in the packet, there is a problem that the net amount of data that can be included in the packet is reduced. For this reason, source routing is limited to some uses such as network testing, and is not used for packets used in communications such as applications (hereinafter referred to as “data packets”). Information other than net data is called overhead. In other words, the above-described problem can be restated as a problem that increases overhead.
- information on the forwarding node for each forwarding is included as in the source routing in the IP routing described above.
- an IPv4 address or an IPv6 address is used as forwarding node information.
- the information becomes large, so that it is used other than the control packet. Is not realistic.
- transfer information for each transfer policy needs to be set in the transfer node by the CR-LDP or the like.
- Patent Document 1 The method of Patent Document 1 is also the above-described source routing itself, and there is a problem that the net amount of data that can be included in the packet is reduced.
- each forwarding node needs to refer to the flow table, and the latency (delay time) increases as the number of entries increases. ) Or a load on the node.
- the method of adding an entry for each transfer policy to the routing table or flow table has problems that the processing load of adding / updating / deleting entries and the amount of information in the routing table increase.
- source routing or the like that explicitly designates a transfer route has a problem in that it increases overhead and is not suitable for data packet transmission.
- the present invention has been made in view of the above-described circumstances, and the object thereof can be realized by using a simplified transfer table, and moreover, it is possible to control the routing of data packets, in particular, transfer routes.
- An object of the present invention is to provide a communication system, a transfer node, a route management server, a communication method, and a program that can switch to an alternative route according to the above failure occurrence situation and traffic load situation.
- a forwarding node of a data forwarding network stores a packet in which a plurality of forwarding route information including information capable of uniquely designating a forwarding route of a packet is stored.
- a communication system that performs transfer processing using the communication interface, that is, a communication interface provided in each transfer node on the transfer path of the data transfer network or a link established between each transfer node and its adjacent nodes.
- a plurality of transfer route information for a packet to which a header storing a plurality of transfer route information and a header storing the plurality of transfer route information is added.
- a communication system is provided that includes a forwarding node that performs packet forwarding processing according to either.
- the communication interface provided in each transfer node on the transfer path of the data transfer network or the link established between the individual transfer node and its adjacent node is identified.
- the packet is connected to a route management server that configures a plurality of transfer route information configured by arranging identifiers for performing the processing, and a packet to which a header storing the plurality of transfer route information is added is stored in the plurality of transfer route information.
- a forwarding node that performs packet forwarding processing using either one is provided.
- a third aspect of the present invention when receiving a route request from the forwarding node described above, based on information included in the route request, a plurality of pieces of forwarding route information that can cause the packet to reach a communication partner.
- a responding route management server is provided.
- the route management server of the data transfer network when the route management server of the data transfer network receives the route request from the transfer node, the data on the transfer route of the data transfer network based on the information included in the route request. It responds with a plurality of forwarding path information configured by arranging an identifier for identifying a communication interface provided in each forwarding node or a link established between each forwarding node and its adjacent nodes.
- a forwarding node group on a forwarding path selected from any of the plurality of forwarding path information including the forwarding node, sequentially forwarding the packets using the selected forwarding path information;
- a communication method is provided. This method is linked to specific machines such as the forwarding node and the path management server described above.
- a program that is executed by a computer that constitutes the transfer node and the path management server described above.
- This program can be recorded on a computer-readable storage medium. That is, the present invention can be embodied as a computer program product.
- the present invention it is possible to perform path control capable of switching to an alternative path with less compression of the net data amount and less increase in load on a forwarding node on the path.
- the reason is that an identifier for identifying a communication interface provided in each transfer node on the transfer path of the data transfer network or a link established between the individual transfer node and its adjacent node is arranged.
- a configuration is adopted in which a plurality of transfer path information configured by the above is added to the header and the transfer node interprets and executes the transfer path information.
- FIG. 1 is a diagram illustrating a communication system according to a first embodiment of the present invention. It is a figure which shows the structure of the boundary forwarding node of the communication system which concerns on the 1st Embodiment of this invention. It is a figure which shows the transfer table recorded on the recording part of the boundary transfer node of the 1st Embodiment of this invention, and an internal transfer node. It is a figure which shows an example of the provision form of the route information header to a packet, an alternative route start position information header, and an alternative route information header. It is an example of the format of the path
- FIG. 5 is a sequence diagram illustrating a packet transfer flow (with one transfer failure) when a communication node according to the first exemplary embodiment of the present invention transmits a packet to an opposite communication node.
- FIG. 6 is a sequence diagram illustrating a packet transfer flow (with two transfer failures) when a communication node according to the first exemplary embodiment of the present invention transmits a packet to an opposite communication node. It is a figure which shows the structure of the boundary forwarding node of the communication system which concerns on the 2nd Embodiment of this invention.
- the transfer node of the communication system performs transfer processing by selecting one of the plurality of transfer route information when a header including a plurality of transfer route information is added to the received packet. .
- the transfer path information may be an order in which individual transfer nodes on the data transfer network can identify identifiers that can identify communication interfaces as transfer destinations in the transfer order.
- the identifier need only have a length sufficient to ensure the uniqueness of the transfer destination in each transfer node.
- the number of interfaces included in the forwarding node is much smaller than IP addresses. Unlike the source routing described at the beginning, since the identifier constituting the transfer route information of the present invention can be described by short information such as 1 byte length, the influence on the net data amount is negligible. . Accordingly, it is possible to store information describing the transfer path for each hop for all packets such as data packets as well as some control packets, and advanced transfer control is possible.
- each forwarding node only needs to hold the correspondence relationship between the identifier and the destination communication interface, and it is not necessary to hold a forwarding table such as the routing table described at the beginning, which is a huge number, The amount of memory can be reduced. Also, since the transfer destination can be determined easily and at high speed, the packet transfer delay can be reduced. Furthermore, the processing capacity of the CPU of each transfer node can be low.
- the addition and deletion of the header including the plurality of transfer route information may be executed by the transfer node (boundary transfer node) arranged at the boundary with the external network as follows.
- a boundary forwarding node that has received a packet from an external network obtains a forwarding route for the packet from a separately provided route management server or information recorded in the border forwarding node, and stores a plurality of forwarding route information. Is added to the received packet.
- the boundary forwarding node deletes the header when transmitting a packet to the external network.
- the packet can store route selection information indicating which transfer route information of the plurality of transfer route information is used, It is preferable that the forwarding node determines forwarding route information used for the packet forwarding process with reference to the route selection information.
- the plurality of transfer route information includes information for determining a transfer node that can branch from one transfer route to another transfer route, It is preferable that the transfer node at the branchable position selects one of the plurality of transfer path information.
- the packet can store forwarding result information indicating a forwarding result when the forwarding node performs forwarding processing based on forwarding route information determined by the route selection information, It is preferable that the forwarding node refers to the forwarding result information that is updated according to the result of forwarding processing and selects forwarding path information that has not failed to be forwarded.
- the packet can store branch point information indicating the number of transfer nodes that can branch from a current transfer path to a different transfer path on a transfer path to the transfer node that has received the packet,
- the forwarding node preferably reduces the branching point information when the forwarding process fails, and determines whether to discard the packet using the branching point information.
- the packet can store information that can identify transfer route information before the change when the transfer route is changed, Preferably, the forwarding node performs a return process to the forwarding path before the change using the forwarding path information before the change included in the packet, and searches for a further branch destination.
- the forwarding node further includes: A transfer result recording unit that records transfer path information in which transfer failure has occurred, When a packet is received, the transfer route information stored in the packet is compared with the recorded route information where the transfer failure has occurred, and if a transfer failure is predicted as a result, the transfer route information is switched to another transfer route. It is preferable.
- a transfer result recording unit that records transfer path information in which transfer failure has occurred, When a packet is received, the transfer route information stored in the packet is compared with the recorded route information where the transfer failure has occurred, and if a transfer failure is predicted as a result, the transfer route information is switched to another transfer route. It is preferable.
- [Form 8] As in the forwarding node according to the second aspect.
- [Form 9] As in the path management server according to the third aspect.
- [Form 9] As in the communication method according to the fourth aspect.
- [Mode 10] As described in the program according to the fifth aspect. Note that the transfer node, path management server, communication method, and
- a transfer route with the second or lower priority is referred to as an “alternate transfer route”.
- Such an alternative transfer path is used when transfer using a certain transfer path fails. For example, if transfer processing of a packet fails, the transfer route is transferred in the reverse direction based on the transfer route information inside the packet that failed to transfer, and becomes a branch node on the boundary transfer node or multiple transfer routes. And retransmission using the alternative transfer path can be performed.
- a header indicating the existence of such an alternative route (an alternative route start position header described later is an example thereof) and the presence / absence of the branch point (in a route information header described later)
- the 'Ex' field is an example thereof.
- Information indicating the transfer result (the 'F' field in the route information header described later is an example thereof), and identification information of an alternative route to be used next (described later) Increment or decrement to the value of the 'Alt' field in the route information header.)
- the configuration using the data transfer network status (failure / load increase of the destination node, traffic status, etc.) as route selection information It can be adopted.
- FIG. 1 is a diagram showing a communication system according to the first embodiment of the present invention. Referring to FIG. 1, communication nodes 100a and 100b, boundary forwarding nodes 300a and 300b, an internal forwarding node 400, and a path management server 500 are shown.
- the data transfer network 600 is a network that performs packet transfer processing by the method of the present invention
- the external network 700 is a network that performs packet transfer processing by a method different from the network 600, such as an IP network.
- the external network 700 can be used if the administrator is different.
- the external network 700 will be described as an IP network.
- the external network 700 is connected to the data transfer network 600 via boundary transfer nodes 300a and 300b.
- the communication nodes 100a and 100b are communication nodes belonging to the external network 700, and transmit and receive packets in accordance with the packet transfer method of the external network 700. That is, in this embodiment, the node transmits and receives IP packets. Since the communication nodes 100a and 100b are similar to general IP nodes, a detailed description thereof is omitted.
- the boundary transfer nodes 300a and 300b are arranged between the data transfer network 600 and the external network 700, and when receiving packets transmitted from the communication nodes 100a and 100b, transfer path information and alternative transfer path information described later. Is added, and the packet is transferred to the internal transfer node 400 in the data transfer network 600 based on the plurality of transfer path information in the header.
- the boundary transfer nodes 300a and 300b receive a packet with a header storing transfer route information and the like from the internal transfer node 400, and transfer routes from the transfer route information or the alternative transfer route information in the headers. If it is determined that the node is the last node above, the route information header is deleted from the received packet, and then the packet is transmitted to the communication nodes 100a and 100b side of the external network 700.
- the transfer route information is described as being acquired from the route management server 500. However, the transfer route information may be generated from information held in the boundary transfer node 300 regardless of this.
- FIG. 2 is a diagram showing the configuration of the boundary forwarding nodes 300a and 300b in FIG.
- the boundary forwarding node 300 includes a communication interface 310, a packet forwarding unit 320, a header operation unit 330, a local ID determination unit 340, a neighborhood information notification unit 350, a route acquisition unit 360, and an alternative.
- a path transition unit 370, a transfer result recording unit 380, and a recording unit 390 are provided.
- the communication interface 310 is an interface for transmitting and receiving packets, and is realized by, for example, a network interface card (NIC) such as a LAN card and software (driver) that operates the network interface card (NIC).
- NIC network interface card
- driver software
- NIC network interface card
- NIC network interface card
- not only a physical interface as described above but also a logical interface may be used. In this case, it is possible to operate using a single physical interface as if a plurality of interfaces are provided.
- the boundary transfer node 300 includes one or more physical interfaces or logical interfaces as described above. Each communication interface 310 is connected to the internal transfer node 400 and other boundary transfer nodes 300 in the data transfer network. Some communication interfaces 310 are also connected to the communication nodes 100 of the external network 700. Further, some communication interfaces 310 are also connected to the route management server 500. The route management server 500 may be arranged in the data transfer network 600, or may be connected via a network dedicated to the route management server 500.
- the packet transfer unit 320 When a header storing transfer route information or the like is added to the received packet, the packet transfer unit 320 first determines whether or not to move to the alternative route by the alternative route transfer unit 370 (details will be described later), and moves. In some cases, after the preparation for that is completed, the packet is transferred based on the transfer route information or the alternative transfer route information in the header and the information recorded in the recording unit 390.
- the recording unit 390 includes a local ID, a communication interface as a transfer destination, and a neighboring boundary transfer node 300 or an internal transfer node 400 connected to the communication interface 310.
- a transfer table having the identifier correspondence information as one entry is recorded.
- the packet transfer unit 320 can transfer the packet to the next node corresponding to the local ID.
- boundary transfer node 300 and the internal transfer node 400 are collectively referred to as a transfer node.
- directly connected nodes communication node 100, boundary forwarding node 300, internal forwarding node 400
- neighboring nodes are referred to as neighboring nodes.
- FIG. 3 is an example of a transfer table recorded in a recording device (corresponding to a recording unit 390 or a recording unit 470 described later) of the boundary transfer node 300 and the internal transfer node 400.
- an identifier (link ID) assigned to a physical link or a logical link between adjacent forwarding nodes or between a border forwarding node 300 and a communication node 100a (100b) is used as a local ID.
- the link ID is set in the “local ID” field.
- Information for identifying the communication interface 310 connected to the link to which the link ID is assigned is set in the “interface” field indicating the communication interface as the transfer destination.
- the identifier of the forwarding node connected to the link is set in the “next hop” field indicating information on neighboring nodes.
- the identifier of the field of “next hop” for example, the IP address of the communication node 100a (100b) Can be used.
- the boundary forwarding node 300 or the internal forwarding node 400 uniquely assigned identifiers (for example, Node_1, Node_2, etc. in FIG. 3) are used.
- the identifier of the forwarding node may be set in advance, or may be set from an external node such as the route management server 500.
- the identifier of the “next hop” field is not necessarily required for the transfer process and can be omitted.
- the information for identifying the communication interface 310 itself can be used as the local ID. Since the information for identifying the communication interface 310 is desirably information that can be described with a short amount of information (for example, about 1 to 2 bytes), when the information for identifying the communication interface 310 is long (for example, the name of the communication interface, etc.) In the case of using), another identifier that can be described with short information such as 1 byte is separately allocated and applied as a local ID. However, unless otherwise described here, it is assumed that a link ID is used as a local ID.
- link identifiers and communication An interface identifier can be sufficiently expressed by 1 byte. If the actual communication interface identifier is long information that requires several bytes, an identifier having a range that can be stored in 1 byte or 2 bytes may be created separately and associated with the communication interface identifier.
- FIG. 4 is a diagram illustrating an example of a form of adding a path information header, an alternative path start position information header, and an alternative path information header to a packet by the boundary forwarding node 300.
- the path information header is added to the head portion of the packet.
- the alternative route information is included, it is given in the order of a route information header, an alternative route start position information header (described in detail later), and an alternative route information header.
- a plurality of alternative route information headers can be provided. When a plurality of alternative route information headers are provided, the next alternative route information header is arranged after the first alternative route information header.
- the number of alternative route information headers is not limited, it is one of the objects of the present invention to avoid the above-described compression of the net data amount, and therefore an upper limit may be set for the number of alternative route information headers. desirable.
- description will be made assuming that a maximum of three alternative path information headers can be added.
- FIG. 5 shows an example of the format of the path information header used in this embodiment.
- ‘Alt’ is 0, the alternative route is not used, and transfer processing is performed with reference to the route information after ‘Local ID # n’.
- “Alt” is 1 to 3 it indicates that the transfer process is performed by referring to the alternative route described in the alternative route information header corresponding to each value.
- the alternative route information header will be described in detail later.
- the transfer node increments the “Ex” field when the packet can be transferred to the alternative path from the node. Therefore, when there is no alternative route to the transfer node that currently performs the transfer process, the value is “0”.
- the number of branch points to the existing alternative route is set.
- 'Ex' is decremented when moving to an alternative route.
- 'F' (Failure Flag) is set to '1' when the forwarding node fails to forward to the forwarding node that becomes the next hop for some reason.
- 'Rsv' (Reserved) is a reserved field and is not used in the embodiment of the present invention. Therefore, a fixed value such as 0 is set.
- offset information of local ID information to be referred to at the time of transfer is set (unit: bytes). This value is indicated by the number of offset bytes from 'LocalID # 0'.
- the value of 'Current Offset' is set to '0'.
- 'Header Length' indicates the length of the header after 'Route Length' in bytes.
- a value in units of 4 bytes is set in consideration of packet shaping (alignment). If the end of the net data does not fit the 4-byte boundary, stuffing (padding) is performed (a dummy information set with 0 is placed after).
- 'Route Length' indicates the total number of bytes of the route information indicated by enumerating local IDs that follow.
- 'Local ID # n' is set to a local ID that the n-hop boundary forwarding node 300 or the internal forwarding node 400 should refer to as a forwarding destination.
- the format shown in FIG. 5 is merely an example, and information may be stored in various modified formats.
- the amount of information in the path information header can be reduced by using a local ID that is unique within a local range such as within a forwarding node or between adjacent forwarding nodes as forwarding path information.
- each local ID is 1 byte, but there is a possibility that it cannot be expressed by 1 byte in a logical link.
- information related to an alternative route (priority order, selection condition, etc.) is set for each route information, it is considered that one byte is insufficient.
- the most significant bit of 'LocalID # n' is used as a local ID extension flag ('E' (Extension) bit) indicating whether the local ID is expressed in 1 byte or 2 bytes. You may do it.
- 'E' Extension
- the forwarding node interprets the local ID as a 1-byte identifier
- the forwarding node interprets the local ID as a 2-byte identifier.
- FIG. 6 is a diagram showing a local ID when the local ID extension flag ('E') is '0'.
- FIG. 7 is a diagram showing a local ID when the local ID extension flag (“E”) is “1”, and the path information length per hop is 2 bytes.
- 1 byte or 2 bytes can be selected as the length of the local ID, it is important to describe the route per hop with as short a bit length as possible, and exactly 1 byte, 2 bytes.
- the fixed length of less than 1 byte or any variable length delimited by an appropriate delimiter character is also possible.
- the specified value is set. Specifically, when “Alt” is 0, it indicates that there is no alternative route branched from the forwarding node that refers to the local ID. On the other hand, when “Alt” is 1 to 3, it indicates that there is an alternative route branching from the forwarding node, and its value indicates the number of the transfer information header to be referred to when branching to the alternative route.
- the forwarding node sets the bit to ‘1’ when forwarding the packet to the alternative route.
- “Local ID type 2” in FIG. 7 is a field for setting a local ID like “Local ID” in FIG. 6, but since the bit length is larger than that in FIG. 6, more link identifiers or interface identifiers. Can be described.
- FIG. 8 is an example of a format of the alternative route start position information header.
- 'Reserved' is a reserved field and is not used in this embodiment.
- Offset # n an offset from the first byte of the path information header to the nth alternative path information header is set.
- the unit is byte.
- the offset may be an offset from the first byte from the alternative path start position information header.
- FIG. 9 is an example of a format of the alternative route information header.
- 'Reserved' is a reserved field and is not used in this embodiment.
- the format of the route information header, the alternative route start position information header, the alternative route information header, and the set information exemplified above are merely examples, and different formats may be used.
- the information included in each header may be other headers. It is also possible to adopt a form in which the data is stored as a separate header.
- the packet transfer unit 320 refers to the 'Alt' field of the route information header of the received packet. If this is '0', the packet transfer unit 320 performs the transfer process using the route information header, and otherwise uses the alternative route information header. Perform the transfer process.
- the packet transfer unit 320 When ‘Alt’ is ‘0’, the packet transfer unit 320 performs transfer processing with reference to the path information header as described above. More specifically, when the 'D' field of the route information header of the received packet is '0', that is, when forwarding is indicated in the forward direction, the packet forwarding unit 320 refers to “Current Offset”. After determining the transfer destination communication interface 310 by referring to the corresponding local ID, the local ID is increased by the length of the local ID referring to the value of “Current Offset” (for example, 1 byte or 2 bytes), and the determination is made. The packet is transmitted from the communication interface 310.
- the packet transfer unit 320 refers to “Current Offset” and refers to the local ID immediately before the corresponding local ID. To determine the communication interface 310 as the transfer destination. Thereafter, the local ID referring to the value of “Current Offset” is reduced by the length, and a packet is transmitted from the determined communication interface 310.
- the packet transfer unit 320 refers to the alternative path start position information header, regards the value set in the “Alt” field as the alternative path number, and corresponds to “ Read the Offset # n 'field. For example, when ‘Alt’ is ‘1’, the value of the ‘Offset # 1’ field is read. The value read here is an offset byte from the first byte of the path information header to the alternative path information header to be referred to. Therefore, the packet transfer unit 320 refers to the alternative path information header indicated by the number of offset bytes and executes the transfer process. Even when transfer processing is performed using the alternative route information header, the 'D' field, the 'Ex' field, and the 'F' field used for transfer control are referred to the route information header.
- the number of the route that becomes the transfer source when the route is transferred to the alternative route indicated by the alternative route information header is set. Since it is also possible to move from the alternative route to the alternative route, the route as the transfer source includes not only the route indicated by the route information header but also the route indicated by the alternative route information header.
- the packet transfer unit 320 also replaces the route information header referred to for the current transfer or the “Local ID #n” field of the alternative route information header other than “0”, that is, substitutes from the relevant transfer node.
- the “Ex” field of the route information header is incremented, and the fact that a branch point to an alternative route exists on the route is recorded in the received packet.
- the packet transfer unit 320 is configured such that, when the transfer node is a branch point to the alternative route, and a packet that has been sent back due to a transfer failure occurs in the alternative route, A function of returning the packet in the reverse direction after returning to the route is provided. Specifically, in the case where a packet other than “0” is received in the “F” field and the “D” field of the route information header and the “Alt” field is other than “0”, “Current” in the alternative route information header is received. When “Offset” is 0, the packet transfer unit 320 has a function of copying the information in the “Frm” field of the alternative route information header to the “Alt” field of the route information header.
- the header operation unit 330 When receiving a packet from the external network 700, the header operation unit 330 acquires route information for each hop from the route transfer unit 300 to the boundary transfer node 300 as an exit from the route acquisition unit 360.
- FIG. The path information header shown, and an alternative path start position information header and an alternative path information header as necessary, are configured and provided to the packet. For example, when assigning a path information header, the header operation unit 330 sets “0” indicating forward transfer in the “D” field, and similarly sets “Alt”, “Ex”, “ “0” is also set in each field of F. Further, the header operation unit 330 sets “0” in “Current Offset” and sets the acquired route information for each hop in “Local ID #n”. The header operation unit 330 sets appropriate values for the other fields.
- the header operation unit 330 also has a function of deleting the route information header and, if necessary, the alternative route start position information header and the alternative route information header when transferring the packet to which the route information header has been added to the external network 700. Is provided.
- the local ID determination unit 340 has a function of exchanging information between the boundary forwarding node 300 and a neighboring node to determine a non-overlapping link ID. For example, it is possible to avoid duplicate setting of link IDs with adjacent nodes by the following method.
- the forwarding node proposes a link ID candidate by transmitting to the neighboring node a packet in which a link ID other than the link ID that has already been assigned is set.
- the neighboring node to which the link ID is proposed confirms whether or not there is a duplicate link ID in the own node, and if there is no duplicate link ID, a response packet in which the proposed link ID and identification information of the own node are set. Is transmitted to the forwarding node as the proposal source.
- a response packet in which information indicating duplication and the identifier of the own node is set is transmitted. This process is repeated until there are no duplicate link IDs.
- the link ID determined in this way and information on neighboring nodes are recorded in the recording unit 390 as a transfer table.
- the link ID may be determined by other methods.
- another node such as the route management server 500 may be determined and notified to each forwarding node.
- the negotiation with the neighboring node can be omitted.
- the interface identifier is long information that requires several bytes as described above, a process for associating the identifier with a range that can be stored in 1 byte or 2 bytes with the interface identifier is performed.
- the local ID uses information that is not known to neighboring nodes, such as an interface identifier, and if the information is not exchanged with each other, the reverse transfer cannot be performed as described above. It is preferable to use information shared with other neighboring nodes.
- the neighbor information notifying unit 350 transmits the neighbor information storing the link ID determined as the local ID by the local ID determining unit 340, the identifier of the neighbor node connected to the link, and its own identifier to the route management server 500. It has a function to do. If the communication nodes 100a and 100b of the external network 700 are connected to the link, information that can be determined as a node of the external network is also added to the information. In addition, for the route calculation in the route management server 500, the neighborhood information may include information such as the bandwidth, reliability, and congestion status of each link, failure information of neighboring nodes, and the like.
- the trigger for transmitting the neighborhood information to the route management server 500 may be the timing when the local ID determination process is completed, or may be transmitted at a predetermined time interval.
- the information when transmitting information including link information and failure information of neighboring nodes, the information may be transmitted when a change occurs in the information.
- the route acquisition unit 360 When receiving a packet from the communication nodes 100a and 100b of the external network 700, the route acquisition unit 360 transmits a route request signal storing the information of the received packet and the identifier of the boundary forwarding node 300 to the route management server 500. And a function of acquiring the transfer route of the packet.
- the information of the received packet is information that can influence the forwarding route determination, and in the simplest case, only the destination address. However, when performing more precise route control, in addition to the destination address, the source address, protocol information stored after the packet header, TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) are used. Some or all of the information such as the destination port number and the source port number can be included. Further, other information may be included.
- a route response signal is returned from the route management server 500.
- the transfer route information included in the route response signal stores information listing local IDs for each hop along the transfer route starting from the boundary transfer node 300. If there is an alternative route, information about the alternative route information is also stored.
- the route acquisition unit 360 acquires the transfer route information not from the route management server 500 but from information set inside.
- the local forwarding ID that can first identify the communication interface that is the forwarding destination of the boundary forwarding node 300 is a starting point.
- the local ID that can identify the communication interface 310 that has received the packet is the starting point. It does not matter.
- the alternative route transfer unit 370 determines to transfer to the alternative route, the alternative route transfer unit 370 performs a process of transferring to transfer using the alternative route information. Specifically, the alternative route transition unit 370 sets the 'U' field in the local ID to '1', and similarly sets the value of the 'Alt' field in the local ID to 'Alt' in the route information header. Copy to field. Further, the alternative route transition unit 370 sets both the “D” field and the “F” field of the route information header to “0”, and decrements the “Ex” field.
- the transfer result recording unit 380 fails to transfer the received packet from the appropriate communication interface 310 by the packet transfer processing unit 320 for some reason, such as a link down, the transfer by the current transfer path has failed. Information indicating this is recorded in the received packet, and further, processing for tracing back the route through which the received packet has been transferred is performed. Specifically, the transfer result recording unit 380 sets the 'F' field of the route information header or the alternative route information header currently referenced for transfer processing to '1', and further sets the 'D' field to '1'. To the packet transfer means 320. As a result, transfer processing in the reverse direction is performed.
- the recording unit 370 holds the transfer table shown in FIG. 3 and causes the packet transfer unit 320, the local ID determination unit 340, and the neighborhood information notification unit 350 to refer to it.
- the internal forwarding node 400 is arranged in the data forwarding network 600, and when receiving a packet transmitted from a neighboring node, the internal forwarding node 400 is based on the information of the route information header or the alternative route information header in the packet. A function of forwarding the packet to a neighboring node is provided.
- FIG. 10 is a diagram showing the configuration of the internal forwarding node 400 of FIG.
- the internal forwarding node 400 includes a communication interface 410, a packet forwarding unit 420, a neighborhood information notification unit 430, a local ID determination unit 440, an alternative route transition unit 450, and a forwarding result recording unit 460. And a recording unit 470.
- the communication interface 410, the packet transfer unit 420, the local ID determination unit 430, the neighborhood information notification unit 440, the alternative route transition unit 450, the transfer result recording unit 460, and the recording unit 470 of the internal transfer node 400 are respectively connected to the boundary transfer node 300.
- the communication interface 310, the packet transfer unit 320, the local ID determination unit 340, the neighborhood information notification unit 350, the alternative path transition unit 370, the transfer result recording unit 390, and the recording unit 390 are equivalent to the detailed description here. Is omitted.
- the internal forwarding node 400 can be regarded as the header forwarding unit 330 and the route acquisition unit 360 subtracted from the boundary forwarding node 300.
- the boundary forwarding node 300 can be said to be a forwarding node in which a header operation unit 330 and a route acquisition unit 360 are added to the internal forwarding node 400.
- the route management server 500 collects neighboring information notified from the boundary forwarding node 300 and the internal forwarding node 400, and provides network topology information describing the connection relation between the boundary forwarding node 300 and the internal forwarding node 400 in the data forwarding network 600. To construct.
- the network topology information includes connection information with the communication nodes 100a and 100b connected to the boundary forwarding node 300.
- the notified route information includes information (congestion status, failure status, etc.) indicating the link between the transfer nodes and the status of the transfer node, it is also managed in association with the connection information.
- the route management server 500 calculates one or a plurality of alternative routes, and the calculated alternative route information is used as the response. You may include in information to do.
- FIG. 11 is a diagram showing a configuration of the route management server 500 of FIG. As shown in FIG. 11, the route management server 500 includes a communication interface 510, a route information collection unit 520, a route request processing unit 530, a route calculation unit 531, and a route information recording unit 540. .
- the communication interface 510 is an interface for transmitting and receiving packets. As described above, it can be realized by a NIC such as a LAN card and software (driver) for operating the NIC.
- a NIC such as a LAN card and software (driver) for operating the NIC.
- the path information collection unit 520 When receiving the neighbor information sent from the boundary forwarding node 300 and the internal forwarding node 400, the path information collection unit 520 stores the identifier of the node that transmitted the neighbor information, the local ID (link ID), stored in the neighbor information, The network topology information in the data transfer network 600 is constructed in the route information recording unit 540 using the neighbor node identifier. If the neighboring information includes incidental information such as link bandwidth, reliability, congestion status, and failure information of neighboring nodes, the incidental information is recorded in association with the network topology information. Such information can be used, for example, as the cost of the link in the route calculation described later.
- FIG. 12 is an example of neighboring information received from each forwarding node.
- FIG. 13 is an example of a network topology constructed from the neighborhood information of FIG. In the example of FIG. 13, the accompanying information is omitted for simplicity. In addition, it is assumed that the external network is an IP network.
- ‘SenderID’ in FIG. 12 indicates the identifier of the forwarding node that transmitted the neighborhood information.
- ‘LinkID’ in FIG. 12 indicates a link ID assigned to the link to which the forwarding node is connected.
- 'neighborID' indicates an identifier of a neighboring node connected to the link. Since the external network is assumed to be an IP network, an IP address is used as the identifier of the communication node 100.
- the link ID is not set to be duplicated in one forwarding node, but non-adjacent forwarding nodes use the same link ID. Permissible.
- the route information collection unit 520 constructs a network topology as shown in FIG. 13 and records it in the route information recording unit 540.
- the link ID is used for the neighbor information of FIG. 12 and the network topology information of FIG. 13 constructed based on the neighbor information, the network topology information is similarly constructed even when other information such as an interface identifier is a local ID. Is possible.
- the route request processing unit 530 receives the route request signal transmitted from the boundary forwarding node 300, and notifies the route calculation unit 531 of the route calculation request together with information included therein.
- the route request processing unit 530 also stores the transfer route information when acquiring one or more transfer route information (information listing the link IDs for each hop in the order of the transfer route) from the route calculation unit 531.
- the route response signal thus transmitted is transmitted to the boundary forwarding node 300 that is the transmission source of the route request signal.
- the route calculation unit 531 When the route calculation unit 531 is notified of the route calculation request from the route request processing unit 530, the route information is input using the identifier and destination address of the route request source boundary forwarding node 300 that are input together as the start point and the end point, respectively. Using the network topology information as shown in FIG. 13 recorded in the recording unit 540, the route is calculated. For the route calculation, an algorithm called the Dijkstra method for obtaining the shortest route can be applied. However, other algorithms may be applied. At this time, in addition to the optimum route, some alternative routes may be obtained.
- the source address of the IP packet may be included in the route calculation request.
- the source address (that is, the identifier of the communication node 100a or 100b that becomes the source of the packet received by the boundary forwarding node 300) may be used as the starting point.
- route information may be calculated using other information such as TCP or UDP destination / source port number.
- information attached to the link (bandwidth, congestion, etc.) and information such as the identifier of the failed boundary / internal forwarding node may be used for route calculation.
- the network topology information as shown in FIG. 13 is recorded in the route information recording unit 540 by the route information collecting unit 520.
- the network topology information is referred to by the route calculation unit 531 for route calculation.
- the communication interfaces 310, 410, 510 described in the embodiment of the present invention can be realized by a NIC such as a LAN card and software (driver) for operating the NIC.
- a NIC such as a LAN card and software (driver) for operating the NIC.
- the recording unit 390, the recording unit 470, and the path information recording unit 540 can be realized by an apparatus capable of recording information, such as a semiconductor memory and a hard disk drive.
- Other functional blocks can be realized by a computer program (software) or hardware executed by one or a plurality of CPUs installed in each device. A part of processing to be performed by the functional block may be performed by a computer program (software), and the rest may be configured by hardware.
- FIG. 14 shows a processing flow when the boundary transfer node 300 receives a packet from the data transfer network 600 or the external network 700.
- the packet transfer unit 320 checks whether or not a route information header is attached to the packet (step S100).
- Step S101 If the route information header is added, the process proceeds to 'Y', and the transfer process is performed according to the route information header (to step S103). On the other hand, when the route information header is not added, the process proceeds to 'N', and a route acquisition process for acquiring transfer route information by transmitting a route request signal from the route acquisition unit 360 to the route management server 500 is performed. (Step S101).
- the header operation unit 330 sets the local ID in the local ID field ('LocalID # n') of the route information header of FIG. 5 according to the transfer route order of the acquired transfer route information. Set. Also, the header operation unit 330 sets the ‘D’, ‘Alt’, ‘Ex’, and ‘F’ fields to ‘0’, and sets ‘Current Offset’ to ‘0’. The header operation unit 330 sets other fields to appropriate values.
- the header operation unit 330 also assigns alternative route information headers as many as the number of alternative routes. At this time, the header operation unit 330 sets “Frm” and “Current Offset” of the alternative route information header shown in FIG. 9 to “0” and acquires the obtained alternative in the local ID field (“Local ID # n”). Set the route. Furthermore, the header operation unit 330 sets other fields to appropriate values, and, as described above, in the “Offset # n” field of the alternative route start position information header, the nth bit from the first byte of the route information header. Set the number of offset bytes to the alternative path information header.
- the header operation unit 330 adds the path information header, the alternative path start position information header, and the alternative path information header to the head of the received packet in the order shown in FIG. 4 (step S102).
- the packet transfer unit 320 performs transfer processing in accordance with either the above-described route information header or proxy route information header (step S103).
- FIG. 15 is a flowchart showing details of the transfer process in step S103 of FIG. Referring to FIG. 15, first, the alternative route transition unit 370 determines whether to perform transfer processing using an alternative route or normal route information. Details of the determination process will be described later with reference to FIG.
- the packet transfer unit 320 checks the ‘D’ field of the path information header and determines whether to transfer in the forward direction or to transfer in the reverse direction (step S ⁇ b> 201).
- step S202 it is determined whether the transfer destination of the packet is the external network 700 (step S202).
- the forward transfer whether or not the transfer is to the external network 700 can be determined by comparing ‘Current Offset’ and ‘Route Length’.
- the local ID may be a value that can be distinguished as to whether or not the transfer is to the external network 700, and information indicating the end is stored after the last local ID in the path information header. You may do it.
- other methods may be used.
- the process proceeds to 'N', and the route information header or the alternative route information header is referred to according to the value of the 'Alt' field of the route information header, and the 'Current' of the referenced header is referred to.
- the number of bytes for one hop is added to Offset '(details will be described later).
- the number of bytes for one hop is the number of bytes in the currently referenced ‘LocalID # n’ field.
- the local ID that is the reference destination is added before the value of 'Current Offset' is added.
- 'Alt' field in the local ID ('LocalID # n') is other than '0', that is, when the forwarding node is a branch point to an alternative route for the received packet, a route information header Increment the 'Ex' field.
- the packet transfer unit 320 performs a packet transfer process in the forward direction using the held local ID (step S203). Specifically, the communication interface 310 to be the transfer destination is determined from the local ID using the information in the transfer table recorded in the recording unit 370, and the packet is transferred from the communication interface 310.
- the packet transfer unit 320 refers to the 'Alt' field of the route information header, refers to the route information header if the 'Alt' field is '0', and substitutes the value if other than '0'.
- the route number is n, and the nth alternative route information header is referred to.
- the number of offset bytes up to the nth alternative route information header can be obtained by referring to the 'Offset # n' field in the alternative route start position information header.
- step S204 As a result of the forward packet transfer, if the packet transfer is successful (“Y” in step S204), the processing relating to the packet ends. On the other hand, when packet transfer has failed (“N” in step S204), the presence / absence of an alternative route is confirmed (step S205).
- packet transfer failures such as a failure of the communication interface, detection of a link not functioning, or a case where the transmission buffer overflows. To do.
- the confirmation of the presence / absence of an alternative route is performed using the “Ex” field of the route information header.
- the packet transfer unit 320 determines that there is an alternative route (“Y” in step S205), and there is a case where the branch point to the alternative route (the own transfer node is a branch point).
- the return setting for appropriately setting each field of the path information header is performed so that the received packet is sent back to the forwarding node (step S206). Specifically, both the ‘D’ field and the ‘F’ field of the route information header are set to ‘1’, and the alternative route transfer determination in step S200 is performed.
- step S205 when the “EX” field is “0”, it is determined that there is no alternative route (“N” in step S205), and the packet transfer unit 320 discards the packet (step S207) and performs processing related to the packet. finish. If the “Ex” field is “0”, it can be regarded that the alternative route information header is not attached, but instead of the above method, it is confirmed that an alternative route exists by following the route information header. Also good.
- step S208 it is determined whether the transfer destination of the packet is the external network 700 (step S208). ).
- Whether or not the transfer is to the external network 700 in the reverse transfer is determined by whether or not the “Alt” field of the route information header is “0” and the value of “Current Offset” is “0”. Yes (when it is “0”, it is determined that the transfer is to an external network).
- This is a determination method in the case where the link identifier of the link between the communication node 100a (100b) that first transmits a packet and the boundary forwarding node 300 that receives the packet is not used as the first local ID.
- the link identifier is used as the first local ID, if the value obtained by subtracting one hop from the current ‘Current Offset’ is ‘0’, it can be determined that the link identifier is transferred to an external network.
- the local ID may be a value that can be distinguished whether the transfer is to the external network 700, or before the first local ID in the path information header.
- information indicating the start may be stored. Furthermore, other methods may be used.
- the packet transfer unit 320 refers to the route information header or the alternative route information header according to the value of the “Alt” field of the route information header. Then, the number of bytes for one hop is subtracted from “Current Offset” of the referenced header (details will be described later).
- the local ID serving as a reference destination is held by the value of 'Current Offset' after subtraction.
- the packet transfer unit 320 performs packet transfer processing based on the stored local ID (step S209). Specifically, the communication interface 310 to be a transfer destination is determined from the local ID using the transfer table recorded in the recording unit 390, the packet is transferred from the communication interface 310, and the processing is completed.
- the method for determining either the route information header or the alternative route information header is the same as the forward transfer in step S203.
- step S208 when it is determined in steps S202 and S208 that the transfer is to the external network 700 (“Y” in step S208), the path information header, the alternative path start position information header, and the alternative path are determined from the header of the received packet.
- the information header is deleted (step S210).
- the packet from which the header has been deleted is transferred to the node 100a (100b) of the external network 700 (step S211).
- the alternative path transition unit 370 is a packet in which a received packet has failed to be transferred at a transfer node via the transfer node and the transfer node, and is sent back in the reverse direction. Is determined (step S300). Specifically, the ‘D’ field and the ‘F’ field in the path information header of the received packet are referred to, and it is determined whether or not both are ‘1’. Here, if the packet is neither a reverse packet nor a transfer failure packet, the alternative path transition unit 370 decides not to transfer the transfer path to the alternative path, and the process is completed (“N” in step S300). ).
- step S300 if the transfer is in the reverse direction due to the failure (both 'D' and 'F' are '1') ('Y' in step S300), the alternative path transition unit 370 determines that 'Current The local ID to be referred to by the forwarding node is checked in the Offset 'field, and the forwarding node is a branching point that can move to the alternative route, and determines whether the alternative route is unused (step S301). Specifically, it is confirmed whether the 'Alt' field in the local ID ('LocalID # n') is other than '0' and the 'U' field is '0'.
- each of the route information header and the proxy information header is used to transfer the packet to the alternative route.
- An appropriate value is set in the field (step S302).
- the settings are listed below. Set the 'D' field of the routing information header to '0' (return to forward transfer) -Set the 'F' field of the route information header to '0' (clear transfer failure information) Decrement the 'Ex' field of the route information header. Set the number of the route information that is the source of the transition to the alternative route in the 'Frm' field of the alternative route information header.
- the value of the “Alt” field of the route information header is copied to the “Frm” field of the alternative route information header.
- the 'U' field in the local ID ('LocalID # n') is set to '1'.
- the value of the 'Alt' field in the local ID ('LocalID # n') is set to 'Alt in the path information header. 'Copy to field.
- step S301 when it is determined in step S301 that there is no unused alternative route, that is, the forwarding node itself is not a branch point to the alternative route, or the branch destination alternative route is already the target.
- the packet is a route that has been transferred (“N” in step S301)
- the alternative route transition unit 370 is currently referring to the alternative route information header, and the first route information (local ID) in the alternative route information header. ) Is referenced (whether it is the starting point of the alternative route) (step S303).
- whether or not the alternative route information header is referenced can be determined by referring to the 'Alt' field of the route information header. Further, whether or not it is the first can be determined by whether or not “Current Offset” of the alternative route information header is “0”.
- step S303 when it is determined that the forwarding node itself is the starting point of the alternative route (“Y” in step S303), the alternative route transition unit 370 executes a return process to the original route (step S303). S304). This return processing to the original route is performed by copying the value of the 'Frm' field in the alternative route information header currently being referenced to the 'Alt' field of the route information header. Thereafter, the process returns to step S301 to determine whether there is an unused alternative route.
- step S303 the process is terminated without performing the return process to the original route.
- FIG. 17 shows a process when the internal forwarding node 400 receives a packet from the boundary forwarding node 300 or the internal forwarding node 400 of the data forwarding network 600.
- the packet transfer unit 420 checks whether or not a route information header is attached to the packet (step S400).
- step S401 the process proceeds to ‘Y’, and the alternative route transfer determination is executed.
- the same process as the alternative path transfer determination process in the boundary transfer node 300 shown in FIG. 16 is performed (step S401).
- the process proceeds to 'N', and the received packet is discarded (step S407).
- the packet transfer unit 420 checks the “D” field of the path information header, and determines whether to transfer in the forward direction or to transfer in the reverse direction (step S402).
- the process proceeds to “Y”, and the route information header or the alternative route information header according to the value of the “Alt” field of the route information header. And add the number of bytes for one hop to 'Current Offset' of the referenced header.
- the number of bytes for one hop is the number of bytes in the local ID ('Local ID # n') field currently being referenced.
- the local ID that is the reference destination is added before the value of 'Current Offset' is added.
- the 'Ex' field of the route information header is set. Increment.
- a communication interface 410 to be a transfer destination is determined from the local ID using a transfer table recorded in the recording unit 470, and a packet is transferred from the communication interface 410.
- route information header or the alternative route information header can be determined using the 'Alt' field of the route information header. If the ‘Alt’ field is ‘0’, the route information header is referred to. If the ‘Alt’ field is other than ‘0’, the value is set as an alternate route number n, and the nth alternate route information header is referenced. The number of offset bytes up to the nth alternative route information header can be obtained by referring to the 'Offset # n' field in the alternative route start position information header.
- step S404 When the packet transfer is successful as a result of the forward packet transfer (“Y” in step S404), the processing related to the packet is finished. On the other hand, if the packet transfer has failed (“N” in step S404), the presence / absence of an alternative route is confirmed (step S405).
- Confirmation of the presence / absence of an alternative route is performed using the 'Ex' field of the route information header.
- the packet transfer unit 420 determines that there is an alternative route (“Y” in step S405), and there is a case where the branch point to the alternative route (the own transfer node is a branch point).
- the return setting for appropriately setting each field of the path information header is performed so that the received packet is sent back to the forwarding node (step S406). Specifically, both the ‘D’ field and the ‘F’ field of the route information header are set to ‘1’, and thereafter, the alternative route transfer determination in step S ⁇ b> 401 is performed.
- step S405 when the “EX” field is “0”, it is determined that there is no alternative route (“N” in step S405), and the packet transfer unit 420 discards the packet (step S407) and performs processing related to the packet. finish. If the “Ex” field is “0”, it can be regarded that the alternative route information header is not attached, but instead of the above method, it is confirmed that an alternative route exists by following the route information header. Also good.
- the packet transfer unit 420 sets the value of the 'Alt' field of the route information header. Then, the route information header or the alternative route information header is referred to, and the value of 'Current Offset' in the referenced header is subtracted by one hop.
- the packet transfer unit 420 holds the local ID that is the reference destination in the “Current Offset” after the subtraction.
- the packet transfer unit 420 performs packet transfer processing in the reverse direction based on the stored local ID (step S408). Specifically, the communication interface 410 to be a transfer destination is determined from the local ID using the transfer table recorded in the recording unit 470, the packet is transferred from the communication interface 410, and the processing is completed.
- the determination of whether the route information to be referred to is the route information header or the alternative route information header (if there are a plurality of them) is the same as the forward transfer in step S403.
- FIG. 18 is a flowchart showing an operation in which the boundary forwarding node 300 and the internal forwarding node 400 transmit the neighborhood information notification.
- the local ID determination unit 340 determines a local ID (step S500).
- the link ID is determined by negotiating the link ID with the neighboring node.
- the said boundary forwarding node 300 or the internal forwarding node 400 uses the identifier allocated to the communication interface 310 (410) with which it is provided as a local ID.
- the link ID is determined for all physical or logical links that can be used by the boundary forwarding node 300 or the internal forwarding node 400.
- communication interface identifiers are determined for all physical or logical communication interfaces. However, some links and communication interfaces may be excluded from the management reasons.
- the local ID determination unit 340 associates the determined local ID with communication interface information (information necessary for setting the communication interface as a packet transfer destination), and records the recording unit 390 (470). It is recorded in the transfer table (see FIG. 3) (step S501).
- the forwarding table identifiers of neighboring nodes connected to the end of each link are also recorded in association with each other. Furthermore, information related to each link, failure information of neighboring nodes, and the like may be recorded as incidental information.
- the neighborhood information notifying unit 350 uses the neighborhood information (in which the local ID and the identifier of the neighboring node are set) from the information of the forwarding table recorded in the recording unit 390 (470). Is configured and transmitted to the route management server 500 (step S502).
- incidental information such as information related to each link and failure information of neighboring nodes may be stored.
- FIG. 19 is a flowchart showing the processing of the route management server 500 that has received the neighborhood information.
- the route management server 500 determines from the received neighborhood information, Information such as a local ID and an identifier of a neighboring node is acquired, network topology information is constructed using the acquired information, and is recorded in the recording unit 540 (step S601).
- FIG. 20 is a flowchart showing the processing of the route management server 500 for which route information is requested from the boundary forwarding node 300.
- the route request processing unit 530 notifies the route calculation unit 531 of information included in the route request signal (step S700).
- the route calculation unit 531 calculates an optimum transfer route based on the information included in the route request signal notified in step S700 and the network topology information recorded in the route information recording unit 540 ( Step S701). At this time, in consideration of a case where the transfer on the determined transfer route has failed, some alternative routes obtained by branching the route at any transfer node on the transfer route may be calculated.
- the route calculation unit 531 reads the local ID for each hop in the transfer order for the determined route and the alternative route, and notifies the route request processing unit 530 of the local ID.
- the route request processing unit 530 that has received the calculation result of the transfer route (including the alternative route information if there is an alternative route) sets the notified transfer route information (arrangement of local IDs) in the route information response signal. Then, the packet is transmitted to the boundary forwarding node 300 that is the transmission source of the route request signal (step S702).
- communication node 100a which is an IP node
- boundary transfer node 300a which is sequentially transferred
- communication node 100b which is an IP node.
- connection status of each node is like the network topology shown in FIG.
- step S800 When the IP packet transmitted from the communication node 100a reaches the boundary forwarding node 300a (step S800), the boundary forwarding node 300a executes processing according to the flowchart shown in FIG. Here, since no route information header is attached to the IP packet, a route information request signal is transmitted to the route management server 500 in step S101 of FIG. 14 (step S801).
- the path management server 500 that has received the path information request signal calculates path information and determines a transfer path according to the flowchart of FIG. 20, and then transmits a path information response signal to the boundary transfer node 300a (step S802).
- the transfer route is calculated as follows.
- the storage order of the local IDs included in the route information response signal is 0, 1, 2, 0.
- the storage order of local IDs is 1 and 2.
- the IP address is used as the IP node ID of the external network, it may be a network address obtained by extracting an arbitrary bit length from the top of the IP address, layer 2 information such as a MAC (Media Access Control) address, Other information may be used.
- layer 2 information such as a MAC (Media Access Control) address, Other information may be used.
- the internal transfer node 400 When the internal transfer node 400 receives the packet with the route information header (step S805), the internal transfer node 400 performs transfer processing according to the flowchart shown in FIG. 17 (step S806).
- the boundary forwarding node 300b When the boundary forwarding node 300b receives the packet to which the route information header is added (step S807), the boundary forwarding node 300b performs processing according to the flowchart shown in FIG. Further, in step S103 of FIG. 14, the transfer process shown in the flowchart of FIG. 15 is further performed.
- the communication node 100a which is an IP node, transmits a packet to the boundary forwarding node 300a, which is sequentially forwarded, but the first calculated optimal route ( A series of flows when a transmission failure occurs in the middle of the transfer on the basic route) and the transfer is successfully performed using the alternative route will be described.
- connection status of each node is like the network topology shown in FIG. 21
- Step S900 When the IP packet transmitted from the communication node 100a arrives at the boundary forwarding node 300a (step S900), the boundary forwarding node 300a acquires route information from the route management server 500 and adds a route information header to the IP header. (Step S901). Step S901 corresponds to step S802 to step S803 in FIG. 21, but here, as route information, it is assumed that two alternative routes can be acquired in addition to the basic route as follows.
- the route is 20 nodes.
- the route is a node of 0.20.
- the local IDs of the basic route, the first alternative route, and the second route are as follows.
- the received IP packet is provided with an alternative route start position information header and two alternative route information headers in which the local IDs are arranged.
- the “Ex” field of the route information header is incremented to “2”.
- the internal forwarding node 400a checks whether there is an alternative route.
- the “Ex” field of the route information header is not “0” (“2”), it is determined that an alternative route exists in the middle of the route to the forwarding node.
- the internal forwarding node 400a performs the setting to forward the packet in the reverse direction to the branch point in order to forward the packet by an alternative route instead of the route information header of the packet (" Settings for recovery ”). Specifically, “1” is set for both the “D” field and the “F” field of the path information header.
- the internal forwarding node 400a does not immediately forward the packet in the reverse direction, but performs again the alternative route forwarding determination processing in step S401 in FIG.
- the ‘D’ field and ‘F’ field of the route information header are immediately reset to ‘0’, and the ‘Ex’ field is also decremented.
- the “Ex” field becomes “1”.
- the 'U' field of the referenced local ID is set to '1', and the 'Alt' field of the local ID is also copied to the 'Alt' field of the alternative path information header.
- “1” is set in the field.
- the internal transfer node 400a and the subsequent transfer nodes execute the transfer processing using the first alternative route.
- the internal forwarding node 400a refers to the local ID of the alternative route information header in which the first alternative route information is set.
- the local ID link identifier
- the 'Current Offset' field of the alternative route header is added by the number of bytes of the local ID.
- the communication node 100a which is an IP node, transmits a packet to the boundary forwarding node 300a, which is sequentially forwarded, but the first calculated optimal route ( A series of flows when a transmission failure occurs during transfer on the basic route) and the first alternative route and transfer is successful using the second alternative route will be described.
- connection status of each node is like the network topology shown in FIG. 21
- Steps S1000 to S1004 in FIG. 23 are exactly the same as steps S900 to S904 in FIG.
- step S1005 since the internal forwarding node 400a is a branch point to the first alternative route, the internal forwarding node 400a refers to the local ID of the alternative route information header in which the first alternative route is set.
- the local ID link identifier
- the 'Current Offset' field of the alternative route header is added by the number of bytes of the local ID.
- step S905 it is the same as step S905, but here, it is assumed that the internal transfer node 400a detects a packet transfer failure ('N' in step S404 in FIG. 17).
- the internal forwarding node 400a confirms whether or not there is an alternative route (step S1006).
- the “Ex” field of the route information header is not “0” (“1”), it is determined that an alternative route exists in the middle of the route to the transfer node.
- the internal forwarding node 400a performs the setting to forward the packet in the reverse direction to the branch point in order to forward the packet by an alternative route instead of the route information header of the packet (" Settings for recovery ”). Specifically, “1” is set in both the “D” field and the “F” field of the path information header.
- the internal forwarding node 400a does not immediately forward the packet in the reverse direction, but performs again the alternative route forwarding determination processing in step S401 in FIG.
- the local ID referred to in the first alternative route has no information that becomes a branch point to the further proxy route. Transition is made to “Y” and “N” in step S301, and it is determined in step S303 in FIG. 16 whether or not the route has returned to the starting point of the alternative route.
- step S304 in FIG. 16 the return processing to the original route is executed.
- the return processing to the original route is performed by copying the value of the 'Frm' field of the first alternative route information header to the 'Alt' field of the route information header.
- the 'Alt' field is set to '0', and the forwarding node including the internal forwarding node 400a and thereafter receiving the packet will perform forwarding processing based on the basic route information (route set in the route information header). Will be performed.
- step S301 it is determined again in step S301 whether there is an unused alternative route.
- the local ID of the route information header is used for the determination here.
- the process proceeds to “N” in step S301 in FIG.
- step S303 it is determined whether or not the proxy route is the starting point. Since the internal forwarding node 400a is not the starting point of the basic route and is not an alternative route in the first place, the determination result is “N” and the alternative route forwarding determination process is completed.
- step S1008 when receiving the packet forwarded in the reverse direction, the boundary forwarding node 300a executes the forwarding process shown in FIG.
- the 'D' field and the 'F' field of the path information header are set to '0'.
- the 'Alt' field of the local ID is copied to the 'Alt' field of the path information header, and as a result, '2' is set.
- the 'U' field in the local ID is set to '1'.
- the transfer procedure refers to the 'Alt' field of the route information header, and since this is not '0' ('2'), transfer using the second alternative route information header is started. .
- the local ID to be referred to is specified by the 'Current Offset' field of the second alternative route information header.
- “Current Offset” is “C1”
- “Local ID # 1” of the second alternative route information header is referred to.
- the internal forwarding node 400b transmits the packet from the communication interface connected to the link whose link identifier is “1” (step S1011). ).
- the processing content is the same as the transfer processing in the internal transfer node 400b described in step S1010.
- the internal forwarding node 400c transmits the packet from the communication interface connected to the link whose link identifier is “3” (step S1013).
- the boundary forwarding node 300b performs processing according to the flowchart shown in FIG.
- step S103 of FIG. 14 the transfer process shown in the flowchart of FIG. 15 is further performed.
- the route information header, the alternative route start position information header, and the alternative route information header are removed in step S210 of FIG. 15, and then the packet is transmitted from the communication interface connected to the external network. Is sent out (step S1015). As a result, the packet is sent to the communication node 100b.
- the uniqueness in the local range such as within the forwarding node or between neighboring forwarding nodes is not the routing information such as the IP address that is globally unique.
- a transfer destination is designated using a guaranteed local ID. For this reason, a transfer route for one hop can be stored in an information amount of about 1 byte or 2 bytes. Even when information on the transfer route is stored in a route information header and attached to a packet, the overhead due to the attached header is reduced. It becomes possible to suppress to an extremely small size. As a result, the path information header can be stored in all packets regardless of the application.
- the number of entries in the forwarding table provided in the forwarding node can be approximately the number of communication interfaces provided in each forwarding node. Further, since the transfer table is stored / updated / used, the size of the memory required for the transfer node and the processing capacity of the CPU can be suppressed, and the transfer node can be made inexpensive.
- the net information can be transferred efficiently and at higher speed.
- the alternative transfer route information is added to the packet, and the transfer node is provided with a function for appropriately transferring to the alternative transfer route. Therefore, when a failure occurs in the transfer route or the traffic becomes excessive. The packet can be transferred to the destination without being affected by the case.
- the overall configuration of the second embodiment of the present invention is substantially the same configuration and function as the first embodiment, but changes are made to the boundary forwarding node 301 and the internal forwarding node 401. An explanation will be added focusing on the following differences.
- FIG. 24 is a diagram showing a configuration of the boundary forwarding node 301 according to the second exemplary embodiment of the present invention.
- the same functional blocks as those of the boundary forwarding node 300 of the first embodiment are denoted by the same reference numerals.
- the alternative path transition unit 371, the transfer result recording unit 381, and the recording unit 391, which are assigned different reference numerals from the boundary transfer node 300 of the first embodiment will be described.
- the alternative path transition unit 371 has substantially the same function as the alternative path transition unit 370 of the first embodiment of the present invention, but the path information header in the received packet (alternative path information header if an alternative path is used)
- the route information (arrangement of local IDs) is compared with each entry of the transfer failure route information table recorded in the recording unit 391, and if they match, the received packet is regarded as a packet via an invalid route. And a function of shifting the transfer route to an alternative route or another alternative route.
- the transfer failure route information table has a format as shown in FIG. 25, for example, and each entry includes information on the transfer failure route and the valid time.
- the transfer failure path information is information in which a local ID referred to in the transfer node to a local ID failed in transfer in the transfer node subsequent to the transfer node.
- the local ID of this embodiment is different in format only from the first embodiment as will be described later, and the transfer node that failed to transfer is connected to the identifier of the communication interface that attempted transfer or the communication interface. Is one of the link identifiers of the selected link.
- the valid time information means that if the time exceeds the valid time recorded here, the entry is deleted or invalidated. However, the effective time may not be used.
- the alternative path transition unit 371 When the alternative path transition unit 371 receives a packet that has been transferred in the reverse direction and has been transferred in the reverse direction (that is, a packet in which both the 'D' field and the 'F' field are '1'), When it is a branch point to an alternative route, the received packet is transferred to the alternative route, and an entry is added to the transfer failure route information table using the route information header of the received packet or the information of the alternative route information header. It has a function.
- FIG. 26 shows a local ID format used in the present embodiment.
- a 'B' (BrokenLink) field is added to the local ID in the first embodiment.
- the 'B' field of the local ID corresponding to the communication interface identifier or link identifier in which the transfer failure has occurred is set to '1'. Therefore, it is possible to read from the local ID referred to by the forwarding node to the local ID where the forwarding failed and record it in the forwarding failure path information table.
- the transfer result recording unit 381 has substantially the same function as the transfer result recording unit 380 of the first embodiment of the present invention, but when the transfer fails, the 'D' field and the 'F' field of the path information header In addition to setting “1” to “1”, a function is provided for setting “1” in the “B” field of the local ID referenced when the transfer is attempted.
- the transfer failure path information table illustrated in FIG. 25 is recorded in the recording unit 391.
- FIG. 27 is a diagram illustrating a configuration of the internal forwarding node 401 according to the second embodiment of this invention.
- the same functional blocks as those of the internal forwarding node 400 of the first embodiment are denoted by the same reference numerals.
- the alternative path transition unit 451, the transfer result recording unit 461, and the recording unit 471, which have different reference numerals from those of the internal transfer node 400 of the first embodiment, are the alternative path transition unit 371 and the transfer result recording of the boundary transfer node 301, respectively. Since the functions are the same as those of the unit 381 and the recording unit 391, the description thereof is omitted.
- Both the boundary transfer node 301 and the internal transfer node 401 operate in substantially the same manner as the boundary transfer node 300 and the internal transfer node 400 in the first embodiment.
- the difference is the alternative route transfer determination process shown in FIG. 16, the return setting in the boundary transfer node 300 in FIG. 15 (step S206), and the return setting in the internal transfer node 400 in FIG. 17 (step S406).
- step S206 the return setting in the boundary transfer node 300 in FIG. 15
- step S406 the return setting in the internal transfer node 400 in FIG. 17
- the forwarding node determines whether the received packet is a packet that has passed through the forwarding node and the forwarding node, a forwarding failure has occurred in the forwarding node after that, and has been sent back in the reverse direction. Is determined (step S1100). Specifically, the 'D' field and the 'F' field in the path information header of the received packet are referred to and it is determined whether or not both of them are '1'.
- the forwarding node uses the path information header of the received packet (alternative path information header if an alternative path is used).
- the currently referred local ID and the subsequent local ID are compared with each entry in the transfer failure path information table shown in FIG. 25 (step S1101). If there is a matching entry as a result of the comparison, it is determined that the received packet is transferred to an alternative route as a packet that fails to be transferred (“Y” in step S1101). On the other hand, if there is no matching entry, the process proceeds to 'N' and the process is completed ('N' in step S1101).
- step S1101 is a process newly added by the alternative path transition unit 371 and the alternative path transition unit 451 in the second embodiment of the present invention.
- the forwarding node is in the 'Current Offset' field.
- the local ID to be referred to is checked, and it is determined whether or not the forwarding node is a branch point that can move to the alternative route and whether the alternative route is unused (step S1102). Specifically, it is determined whether the 'Alt' field in the local ID ('Local ID # n') is other than '0' and the 'U' field is '0'.
- the forwarding node displays a route information header (alternative route if an alternative route is used).
- a route information header alternative route if an alternative route is used.
- step S1103 is a process newly added by the alternative path transition unit 371 and the alternative path transition unit 451 in the second embodiment of the present invention.
- the forwarding node sets appropriate values in each field of the route information header and the proxy information header in order to forward the packet to the alternative route (step S1104). Since the specific setting contents are the same as S302 in FIG. 16, they are omitted here. After the setting is completed, the alternative route transfer determination process ends.
- step S1102 the forwarding node determines whether or not the current reference is the alternative route information header and the first route information (local ID) is referred to (step S1102). S1105).
- whether or not the alternative route information header is referenced can be determined by referring to the 'Alt' field of the route information header. Whether or not it is the first time can be determined by checking whether or not “Current Offset” of the alternative route information header is “0”.
- the alternative route transfer determination process ends.
- the forwarding node returns to the original route. Execute the process.
- the return processing to the original route is performed by copying the value of the 'Frm' field in the alternative route information header currently being referenced to the 'Alt' field of the route information header.
- step S206 in FIG. 15 the process of returning the received packet to the forwarding node that becomes a branch point to the alternative route (the forwarding node may be a branch point)
- Each field of the route information header is set appropriately. Specifically, both the 'D' and 'F' fields of the path information header are set to '1'.
- the transfer result recording unit 381 uses “B” of the local ID information referred to when performing the transfer that failed as a result. Processing to set the field to “1” is performed.
- the return setting process (step S406 in FIG. 17) of the first embodiment of the present invention is a process for returning a received packet to a forwarding node that becomes a branch point to the alternative route (the forwarding node may be a branch point).
- each field of the route information header is appropriately set. Specifically, both the 'D' and 'F' fields of the path information header are set to '1'.
- the transfer result recording unit 461 uses the transfer result recording unit 461 to refer to the local ID information “B” that is referred to when the transfer ends in failure. Set the field to '1'.
- communication node 100a that is an IP node transmits a packet to boundary forwarding node 300a, is sequentially transferred, and finally reaches communication node 100b that is an IP node. The process will be described.
- a transfer failure occurs during the transfer of the first packet, and the packet is returned to the transfer node that is a branch point to the alternative route (in this example, the boundary transfer node 300a), and then transferred via the alternative route.
- the alternative route in this example, the boundary transfer node 300a
- the boundary forwarding node 300a receives a packet sent from the communication node 100a to the communication node 100b, the failure of the packet is predicted, so the boundary forwarding node 300a is not a basic route, but immediately Perform transfer on an alternative route.
- step S1200 when the IP packet transmitted from the communication node 100a arrives at the boundary forwarding node 300a (step S1200), the boundary forwarding node 300a that has received the IP packet acquires route information from the route management server 500. Then, a process of adding a route information header to the IP header is executed (step S1201).
- connection status of each node is like the network topology shown in FIG. 13, and one alternative route is added in addition to the basic route information as follows. It is assumed that it has been acquired.
- the local IDs of the basic route and the first alternative route are as follows.
- the received IP packet is provided with an alternative route start position information header and one alternative route information header in addition to the route information header.
- the boundary transfer node 300a transmits a packet from the communication interface connected to the link indicated by the local ID (link identifier) to be transferred in accordance with the assigned path information header (step S1202).
- the boundary forwarding node 300a since the boundary forwarding node 300a has a branch point to the alternative route, the “Ex” field of the route information header is incremented to “1”.
- step S1204 it is confirmed whether there is an alternative route. Since the “Ex” field of the route information header is not “0” (“1”), it is determined that an alternative route exists in the route to the forwarding node.
- a setting is made to transfer the packet in the reverse direction to the branch point (step S1204). Specifically, both the 'D' field and the 'F' field of the path information header are set to '1'.
- the 'B' field of the local ID referred when performing the failed transfer is also set to '1'.
- the 'B' field of the local ID where local ID '2' is set to '1'.
- the internal forwarding node 400a forwards the packet in the reverse direction (step S1205).
- the 'D' field and the 'F' field of the route information header are set to '0'.
- the 'Alt' field the 'Alt' field of the local ID is copied, and as a result, '1' is set.
- the 'U' field in the local ID is set to '1'.
- step S1208 when another IP packet transmitted from the communication node 100a to the communication node 100b arrives at the boundary transfer node 300a (step S1208), the boundary transfer node 300a transfers the transfer route to the route management server 500 in the same manner as in step S1201.
- the cache information is used to send information to the route management server 500. Inquiry may be omitted.
- the same route information as in step S1201 can be acquired, and a route information header, an alternative route start position information header, and an alternative route information header configured using the route information are added to the IP packet.
- the boundary transfer node 300a executes the transfer process according to the flowchart of FIG. 15, but first, an alternative path transfer determination process is performed in step S200 (step S1209).
- step S1101 the route information header of the packet is compared with the entry in the transfer failure route information table of FIG. 25, and it is checked whether there is a matching entry.
- the transfer failure route information table includes an entry whose transfer failure route is ⁇ 1, 2 ⁇ .
- the local ID sequence when starting from the local ID that the boundary transfer node 300a refers to at the time of transfer is ⁇ 1, 2, 0 ⁇ It is.
- step S1101 the process proceeds to 'Y', and step S1104 is processed. That is, the transfer route can be immediately switched to the alternative route without transferring the received packet to the internal transfer node 400a, and highly efficient transfer can be performed.
- the packet is finally sent to the communication node 100b through the alternative route (step S1210).
- the present invention is not limited to the above-described embodiments, and further modifications, replacements, and replacements may be made without departing from the basic technical idea of the present invention. Adjustments can be made.
- the link ID shared between the neighboring nodes at both ends of the link has been described.
- the identifier of the communication interface can also be used as the local ID.
- each forwarding node is provided with a local ID determination unit, and each local node is determined.
- the configuration information of each forwarding node can be obtained by the route management server.
- a configuration in which the route management server determines the local ID and stores the transfer table in each recording unit may be employed.
- the local ID determination unit of each forwarding node can be omitted.
- the path management server can also obtain the connection relationship of each forwarding node and the local ID can be set so that adjacent nodes do not overlap each other, the neighborhood information notification unit of each forwarding node is also omitted. Is possible.
- the path management server 500 of the above-described embodiment can be realized by the OpenFlow controller of Non-Patent Document 1, and in this case, the forwarding node can be realized by an OpenFlow switch.
- the route management server 500 of the above-described embodiment can be realized as a dedicated server, and as a forwarding node, in addition to the above OpenFlow switch, it is realized by a router in the IP network and an MPLS switch in the MPLS network. Can do.
- the present invention can be applied to any network where the server centrally manages the forwarding nodes in the network.
- a packet transfer path In a commercial network such as a data center, it is necessary to strictly control a packet transfer path according to various conditions such as a destination address, a source address, and a used protocol for QoS (Quality of Service) and load distribution.
- QoS Quality of Service
- the communication system of the present invention makes it possible to specify a transfer route strictly while suppressing packet overhead without increasing route information and storing it in a header even when a failure occurs in a specific link. Packets can be transferred using several alternative routes, and a network system excellent in fault tolerance and availability can be constructed.
- the present invention can be suitably applied to a commercial network such as a data center. It should be noted that the embodiments and examples can be changed and adjusted within the scope of the entire disclosure (including claims) of the present invention and based on the basic technical concept. Various combinations and selections of various disclosed elements are possible within the scope of the claims of the present invention. That is, the present invention of course includes various variations and modifications that could be made by those skilled in the art according to the entire disclosure including the claims and the technical idea.
- the transfer result recording unit uses the identifier for identifying a link established between a communication interface used by the transfer node that failed to transfer in the packet or a neighboring node, and a transfer path in which the transfer failure has occurred.
- a communication system that generates and records information.
- [Appendix 2] In the forwarding node described above, And a forwarding node that determines forwarding route information to be used for the packet forwarding processing with reference to route selection information indicating which forwarding route information to use among a plurality of forwarding route information in the packet.
- a forwarding node that determines whether to discard the packet using the branch point information.
- a transfer result recording unit that records transfer path information in which transfer failure has occurred, When a packet is received, the transfer route information stored in the packet is compared with the recorded route information where the transfer failure has occurred, and if a transfer failure is predicted as a result, the transfer route information is switched to another transfer route. Forwarding node.
- the transfer result recording unit uses the identifier for identifying a link established between a communication interface used by the transfer node that failed to transfer in the packet or a neighboring node, and a transfer path in which the transfer failure has occurred.
- a forwarding node that generates and records information [Appendix 8] In the forwarding node described above, Further, when a packet not including the transfer route information is received, a plurality of transfer route information obtained by inquiring a route management server and capable of reaching the communication partner with the packet is used. Forwarding node that stores information (boundary forwarding node).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
本発明は、日本国特許出願:特願2010-002875号(2010年01月08日出願)の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、転送ノード、経路管理サーバおよび通信方法に関し、特に、ネットワークに配置された転送ノードによりパケットを転送して通信を実現する通信システム、転送ノード、経路管理サーバおよび通信方法に関する。
以下の分析は、本発明によってなされたものである。
IP技術に基づく転送ノード、すなわちスイッチやルータが保持するルーティングテーブルは増大の一途をたどり、ルート情報の爆発と呼ばれる問題が指摘されている。ルート増大の結果、ルーティングテーブルを保持するためのメモリの必要量が増えるとともに、ルート決定処理に時間がかかるため、パケット転送処理能力が劣化する。
本発明において以下の形態が可能である。
[形態1]
前記第1の視点に記載の通信システムのとおり。
[形態2]
前記パケットは、前記複数の転送経路情報のうちのどの転送経路情報を使うかを示す経路選択情報を格納可能であり、
前記転送ノードは、前記経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定することが好ましい。
[形態3]
前記複数の転送経路情報には、1つの転送経路から、別の転送経路へと分岐可能な転送ノードを判別するための情報が含まれており、
前記分岐可能な位置の転送ノードが、前記複数の転送経路情報のいずれかを選択することが好ましい。
[形態4]
前記パケットは、転送ノードが前記経路選択情報により決定された転送経路情報に基づき転送処理を行った際の転送結果を示す転送結果情報を格納可能であり、
前記転送ノードは、転送処理の結果により更新される前記転送結果情報を参照して、転送に失敗していない転送経路情報を選択することが好ましい。
[形態5]
前記パケットは、当該パケットを受信した転送ノードまで至る転送経路上における現在の転送経路から異なる転送経路へと分岐可能な転送ノードの数を示す分岐点情報を格納可能であり、
前記転送ノードは、転送処理に失敗した場合前記分岐点情報を減らし、前記分岐点情報を用いて当該パケットを破棄するか否かを決定することが好ましい。
[形態6]
前記パケットは、転送経路を変更した際に、変更前の転送経路情報を特定可能な情報を格納可能であり、
前記転送ノードは、前記パケットに含まれる変更前の転送経路情報を用いて、変更前の転送経路への復帰処理を行い、さらなる分岐先を探索することが好ましい。
[形態7]
前記転送ノードは、さらに、
転送失敗が発生した転送経路情報を記録する転送結果記録部を備え、
パケットを受信した際に、当該パケットに格納された転送経路情報と前記記録された転送失敗が発生した経路情報とを比較し、その結果、転送失敗が予測される場合、別の転送経路に切りかえることが好ましい。
[形態8]
前記第2の視点に記載の転送ノードのとおり。
[形態9]
前記第3の視点に記載の経路管理サーバのとおり。
[形態9]
前記第4の視点に記載の通信方法のとおり。
[形態10]
前記第5の視点に記載のプログラムのとおり。
なお、上記第2~第5の視点に記載の転送ノード、経路管理サーバ、通信方法およびプログラムは、形態1の通信システムと同様に、それぞれの構成要素ないしステップについて、形態2~形態7の内容に展開することが可能である。
続いて、本発明の第1の実施形態について図面を参照して詳細に説明する。図1は、本発明の第1の実施形態に係る通信システムを示す図である。図1を参照すると、通信ノード100a、100bと、境界転送ノード300a、300bと、内部転送ノード400と、経路管理サーバ500とが示されている。
・経路情報ヘッダの‘D’フィールドを‘0’に設定(順方向の転送に戻す)
・経路情報ヘッダの‘F’フィールドを‘0’に設定(転送失敗情報をクリア)
・経路情報ヘッダの‘Ex’フィールドをデクリメント
・代替経路情報ヘッダの‘Frm’フィールドに代替経路への移行元となる、経路情報の番号を設定する。つまり、経路情報ヘッダの‘Alt’フィールドの値を、代替経路情報ヘッダの‘Frm’フィールドにコピーする。
・前記ローカルID(‘LocalID#n’)中の‘U’フィールドを‘1’に設定
・前記ローカルID(‘LocalID#n’)中の‘Alt’フィールドの値を、経路情報ヘッダの‘Alt’フィールドにコピーする。
基本経路:1(第2の代替経路への分岐有り),2(第1の代替経路への分岐有り),0
第1の代替経路:3,1,3,0
第2の代替経路:2,1,3,0
続いて、本発明の第1の実施形態に変更を加え、転送失敗経路を記憶保持するようにした本発明の第2の実施形態について図面を参照して詳細に説明する。
基本の経路情報(代替経路ではない経路):
ID=1のノード -> ID=10のノード -> ID=8のノード -> 192.168.0.20のノードという経路。
第1の代替経路情報:
基本経路のID=1のノードを分岐点として、ID=1のノード -> ID=10のノード -> ID=5 -> ID=6 -> ID=8のノード -> 192.168.0.20のノード という経路。
基本経路 :1(第1の代替経路への分岐有り),2,0
第1の代替経路:2,1,3,0
したがって、本発明はデータセンタなどの商用ネットワークへ好適に適用可能である。
なお、本発明の全開示(請求の範囲を含む)の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
上記した通信システムにおいて、
前記転送結果記録部は、パケット内の前記転送失敗した転送ノードが使用した通信インタフェースまたは隣接ノードとの間に張られたリンクを識別するための識別子を用いて、前記転送失敗が発生した転送経路情報を生成し、記録する通信システム。
[付記2]
上記した転送ノードにおいて、
さらに、パケット内の複数の転送経路情報のうちのどの転送経路情報を使うかを示す経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定する転送ノード。
[付記3]
上記した転送ノードにおいて、
パケットに含まれる、1つの転送経路から、別の転送経路へと分岐可能な転送ノードを判別するための情報を用いて、転送経路を異なる転送経路に切り替える転送ノード。
[付記4]
上記した転送ノードにおいて、
パケットに含まれる、転送処理の結果により更新される前記転送結果情報を参照して、転送に失敗していない転送経路情報を選択する転送ノード。
[付記5]
上記した転送ノードにおいて、
転送処理に失敗した場合、当該パケットに含まれる、当該パケットを受信した転送ノードまで至る転送経路上における現在の転送経路から異なる転送経路へと分岐可能な転送ノードの数を示す分岐点情報を減らし、前記分岐点情報を用いて当該パケットを破棄するか否かを決定する転送ノード。
[付記6]
上記した転送ノードにおいて、
転送失敗が発生した転送経路情報を記録する転送結果記録部を備え、
パケットを受信した際に、当該パケットに格納された転送経路情報と前記記録された転送失敗が発生した経路情報とを比較し、その結果、転送失敗が予測される場合、別の転送経路に切りかえる転送ノード。
[付記7]
上記した転送ノードにおいて、
前記転送結果記録部は、パケット内の前記転送失敗した転送ノードが使用した通信インタフェースまたは隣接ノードとの間に張られたリンクを識別するための識別子を用いて、前記転送失敗が発生した転送経路情報を生成し、記録する転送ノード。
[付記8]
上記した転送ノードにおいて、
さらに、前記転送経路情報を含まないパケットを受信した場合、経路管理サーバに問い合わせることで取得した、前記パケットを通信相手まで到達させ得る複数の転送経路情報を用い、前記パケットに前記複数の転送経路情報を格納する転送ノード(境界転送ノード)。
200 転送ノード
300、300a、300b、301、301a、301b 境界転送ノード
310 通信インタフェース
320 パケット転送部
330 ヘッダ操作部
340 ローカルID決定部
350 近隣情報通知部
360 経路取得部
370、371 代替経路移行部
380、381 転送結果記録部
390、391 記録部
400 内部転送ノード
410 通信インタフェース
420 パケット転送部
430 ローカルID決定部
440 近隣情報通知部
450、451 代替経路移行部
460、461 転送結果記録部
470、471 記録部
500 経路管理サーバ
510 通信インタフェース
520 経路情報収集部
530 経路要求処理部
531 経路計算部
540 経路情報記録部
600 データ転送ネットワーク
700 外部ネットワーク
Claims (10)
- データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を構成する経路管理サーバと、
前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報のいずれかに従ってパケット転送処理を実行する転送ノードを含むことを特徴とする通信システム。 - 前記パケットは、前記複数の転送経路情報のうちのどの転送経路情報を使うかを示す経路選択情報を格納可能であり、
前記転送ノードは、前記経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定する請求項1の通信システム。 - 前記複数の転送経路情報には、1つの転送経路から、別の転送経路へと分岐可能な転送ノードを判別するための情報が含まれており、
前記分岐可能な位置の転送ノードが、前記複数の転送経路情報のいずれかを選択する請求項1または2の通信システム。 - 前記パケットは、転送ノードが前記経路選択情報により決定された転送経路情報に基づき転送処理を行った際の転送結果を示す転送結果情報を格納可能であり、
前記転送ノードは、転送処理の結果により更新される前記転送結果情報を参照して、転送に失敗していない転送経路情報を選択する請求項1から3いずれか一の通信システム。 - 前記パケットは、当該パケットを受信した転送ノードまで至る転送経路上における現在の転送経路から異なる転送経路へと分岐可能な転送ノードの数を示す分岐点情報を格納可能であり、
前記転送ノードは、転送処理に失敗した場合前記分岐点情報を減らし、前記分岐点情報を用いて当該パケットを破棄するか否かを決定する請求項1から4いずれか一の通信システム。 - 前記パケットは、転送経路を変更した際に、変更前の転送経路情報を特定可能な情報を格納可能であり、
前記転送ノードは、前記パケットに含まれる変更前の転送経路情報を用いて、変更前の転送経路への復帰処理を行い、さらなる分岐先を探索する請求項1または5いずれか一の通信システム。 - 前記転送ノードは、さらに、
転送失敗が発生した転送経路情報を記録する転送結果記録部を備え、
パケットを受信した際に、当該パケットに格納された転送経路情報と前記記録された転送失敗が発生した経路情報とを比較し、その結果、転送失敗が予測される場合、別の転送経路に切りかえる請求項1から6いずれか一の通信システム。 - データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を構成する経路管理サーバと接続され、
前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報のいずれかを使ってパケット転送処理を実行する転送ノード。 - 請求項8の転送ノードからの経路要求を受信した際に、前記経路要求に含まれる情報に基づき、前記パケットを通信相手まで到達させ得る複数の転送経路情報を応答する経路管理サーバ。
- データ転送ネットワークの経路管理サーバが、転送ノードからの経路要求を受信した際に、前記経路要求に含まれる情報に基づき、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を応答するステップと、
前記転送ノードを含む前記複数の転送経路情報の中からいずれかから選択された転送経路上の転送ノード群が、前記選択された転送経路情報を使って順次前記パケットを転送するステップと、を含む通信方法。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201180005856.2A CN102714629B (zh) | 2010-01-08 | 2011-01-07 | 通信系统、转发节点、路径管理服务器以及通信方法 |
EP11731844.4A EP2523405A4 (en) | 2010-01-08 | 2011-01-07 | COMMUNICATION SYSTEM, TRANSMISSION NUDS, ROUTING MANAGEMENT SERVER AND COMMUNICATION METHOD |
JP2011549034A JP5699939B2 (ja) | 2010-01-08 | 2011-01-07 | 通信システム、転送ノード、経路管理サーバおよび通信方法 |
US13/137,237 US20110286326A1 (en) | 2010-01-08 | 2011-07-29 | Communication system, forwarding node, path management server, and communication method |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010-002875 | 2010-01-08 | ||
JP2010002875 | 2010-01-08 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/137,237 Continuation US20110286326A1 (en) | 2010-01-08 | 2011-07-29 | Communication system, forwarding node, path management server, and communication method |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2011083846A1 true WO2011083846A1 (ja) | 2011-07-14 |
Family
ID=44305582
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2011/050182 WO2011083846A1 (ja) | 2010-01-08 | 2011-01-07 | 通信システム、転送ノード、経路管理サーバおよび通信方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US20110286326A1 (ja) |
EP (1) | EP2523405A4 (ja) |
JP (3) | JP5699939B2 (ja) |
CN (2) | CN102714629B (ja) |
WO (1) | WO2011083846A1 (ja) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014129624A1 (ja) * | 2013-02-25 | 2014-08-28 | 日本電気株式会社 | 制御装置、通信システム、経路切替方法及びプログラム |
WO2014132967A1 (ja) * | 2013-02-26 | 2014-09-04 | 日本電気株式会社 | 通信システム、スイッチ、制御装置、制御用チャネルの構築方法及びプログラム |
JP2014236481A (ja) * | 2013-06-05 | 2014-12-15 | 富士通株式会社 | 通信システム、通信制御方法、及び、伝送装置 |
JP2015115643A (ja) * | 2013-12-09 | 2015-06-22 | パナソニックIpマネジメント株式会社 | 通信システム及び通信方法 |
CN104871500A (zh) * | 2012-12-19 | 2015-08-26 | 日本电气株式会社 | 通信节点、控制装置、通信系统、分组处理方法、通信节点控制方法及程序 |
JP2016025400A (ja) * | 2014-07-16 | 2016-02-08 | 富士電機株式会社 | 無線通信システム、無線機、中継ルート決定方法、および、プログラム |
JP2016220202A (ja) * | 2015-05-15 | 2016-12-22 | 華為技術有限公司Huawei Technologies Co.,Ltd. | データ交換システム、データトラヒックを送出する方法及び交換装置 |
WO2017022833A1 (ja) * | 2015-08-06 | 2017-02-09 | 日本電気株式会社 | Vnf提供システム、vnf id管理装置、vnfのid管理方法及びプログラム |
JP2017506846A (ja) * | 2014-02-11 | 2017-03-09 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | 公開鍵を基礎とするデジタル署名を使用してソースルーティングを保全するためのシステムおよび方法 |
JP2022548152A (ja) * | 2020-01-13 | 2022-11-16 | テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド | ルーティング制御方法、装置、プログラム及びコンピュータ装置 |
JP2022550343A (ja) * | 2019-09-27 | 2022-12-01 | 華為技術有限公司 | Srネットワークでパケットを転送する方法、デバイス、及びシステム |
Families Citing this family (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9001645B2 (en) * | 2006-05-17 | 2015-04-07 | Rajant Corporation | System and method for packet delivery backtracking |
USRE48951E1 (en) | 2015-08-05 | 2022-03-01 | Ecolab Usa Inc. | Hand hygiene compliance monitoring |
US9300491B2 (en) | 2011-02-11 | 2016-03-29 | Qualcomm Incorporated | Frame delivery path selection in hybrid communication networks |
US8897169B2 (en) | 2011-03-02 | 2014-11-25 | Qualcomm Incorporated | Discovery of conventional devices and bridges in hybrid communication networks |
US9025603B2 (en) * | 2011-03-08 | 2015-05-05 | Qualcomm Incorporated | Addressing scheme for hybrid communication networks |
US9461777B2 (en) | 2011-11-21 | 2016-10-04 | Qualcomm Incorporated | Hybrid networking system with seamless path switching of streams |
KR101887581B1 (ko) * | 2011-12-26 | 2018-08-14 | 한국전자통신연구원 | 플로우 기반의 패킷 전송 장치 및 그것의 패킷 처리 방법 |
US9185166B2 (en) | 2012-02-28 | 2015-11-10 | International Business Machines Corporation | Disjoint multi-pathing for a data center network |
JP5817078B2 (ja) * | 2012-04-17 | 2015-11-18 | 株式会社日立製作所 | 伝送システム、集中制御計算機、及び伝送方法 |
JP2014003408A (ja) * | 2012-06-18 | 2014-01-09 | Hitachi Ltd | 中継転送システム、経路制御装置およびエッジ装置 |
US9722943B2 (en) * | 2012-12-17 | 2017-08-01 | Qualcomm Incorporated | Seamless switching for multihop hybrid networks |
US10904144B2 (en) | 2012-12-27 | 2021-01-26 | Sitting Man, Llc | Methods, systems, and computer program products for associating a name with a network path |
US10397100B1 (en) | 2012-12-27 | 2019-08-27 | Sitting Man, Llc | Routing methods, systems, and computer program products using a region scoped outside-scope identifier |
US10447575B1 (en) | 2012-12-27 | 2019-10-15 | Sitting Man, Llc | Routing methods, systems, and computer program products |
US10397101B1 (en) | 2012-12-27 | 2019-08-27 | Sitting Man, Llc | Routing methods, systems, and computer program products for mapping identifiers |
US10419334B1 (en) | 2012-12-27 | 2019-09-17 | Sitting Man, Llc | Internet protocol routing methods, systems, and computer program products |
US10212076B1 (en) | 2012-12-27 | 2019-02-19 | Sitting Man, Llc | Routing methods, systems, and computer program products for mapping a node-scope specific identifier |
US10419335B1 (en) | 2012-12-27 | 2019-09-17 | Sitting Man, Llc | Region scope-specific outside-scope indentifier-equipped routing methods, systems, and computer program products |
US10404583B1 (en) | 2012-12-27 | 2019-09-03 | Sitting Man, Llc | Routing methods, systems, and computer program products using multiple outside-scope identifiers |
US10411997B1 (en) | 2012-12-27 | 2019-09-10 | Sitting Man, Llc | Routing methods, systems, and computer program products for using a region scoped node identifier |
US10587505B1 (en) | 2012-12-27 | 2020-03-10 | Sitting Man, Llc | Routing methods, systems, and computer program products |
US10411998B1 (en) | 2012-12-27 | 2019-09-10 | Sitting Man, Llc | Node scope-specific outside-scope identifier-equipped routing methods, systems, and computer program products |
US10374938B1 (en) | 2012-12-27 | 2019-08-06 | Sitting Man, Llc | Routing methods, systems, and computer program products |
US10404582B1 (en) | 2012-12-27 | 2019-09-03 | Sitting Man, Llc | Routing methods, systems, and computer program products using an outside-scope indentifier |
US10476787B1 (en) | 2012-12-27 | 2019-11-12 | Sitting Man, Llc | Routing methods, systems, and computer program products |
US9282034B2 (en) | 2013-02-20 | 2016-03-08 | International Business Machines Corporation | Directed route load/store packets for distributed switch initialization |
US9252965B2 (en) | 2013-03-15 | 2016-02-02 | International Business Machines Corporation | Directed route load/store packets for distributed switch initialization |
US9444748B2 (en) * | 2013-03-15 | 2016-09-13 | International Business Machines Corporation | Scalable flow and congestion control with OpenFlow |
CN103248536B (zh) * | 2013-04-28 | 2017-12-29 | 新华三技术有限公司 | 一种虚链路pw检测方法及设备 |
EP2992643B1 (en) * | 2013-04-30 | 2017-03-15 | Telefonaktiebolaget LM Ericsson (publ) | Technique of operating a network node for load balancing |
CN104426815B (zh) * | 2013-08-27 | 2019-07-09 | 中兴通讯股份有限公司 | 一种sdn中流表下发的方法和系统、of控制器和of交换机 |
US20150100560A1 (en) | 2013-10-04 | 2015-04-09 | Nicira, Inc. | Network Controller for Managing Software and Hardware Forwarding Elements |
US9444677B2 (en) | 2013-10-18 | 2016-09-13 | Cisco Technology, Inc. | Scalable edge node protection using IPv6 segment routing extension header |
US9912577B2 (en) * | 2014-04-17 | 2018-03-06 | Cisco Technology, Inc. | Segment routing—egress peer engineering (SP-EPE) |
US9923799B2 (en) * | 2014-04-25 | 2018-03-20 | Metaswitch Networks Ltd. | Data processing |
US20160099859A1 (en) * | 2014-10-06 | 2016-04-07 | Futurewei Technologies, Inc. | Reverse Path Validation for Source Routed Networks |
CN105634942B (zh) * | 2014-10-31 | 2020-01-03 | 华为技术有限公司 | 转发报文的方法和交换机 |
CN104378380A (zh) * | 2014-11-26 | 2015-02-25 | 南京晓庄学院 | 一种基于SDN架构的识别与防护DDoS攻击的系统及方法 |
CN105991435B (zh) * | 2015-02-05 | 2019-08-27 | 华为技术有限公司 | 用于获取端口路径的方法及装置 |
US9942058B2 (en) | 2015-04-17 | 2018-04-10 | Nicira, Inc. | Managing tunnel endpoints for facilitating creation of logical networks |
US10554484B2 (en) | 2015-06-26 | 2020-02-04 | Nicira, Inc. | Control plane integration with hardware switches |
US9967182B2 (en) | 2015-07-31 | 2018-05-08 | Nicira, Inc. | Enabling hardware switches to perform logical routing functionalities |
US9847938B2 (en) | 2015-07-31 | 2017-12-19 | Nicira, Inc. | Configuring logical routers on hardware switches |
US9819581B2 (en) | 2015-07-31 | 2017-11-14 | Nicira, Inc. | Configuring a hardware switch as an edge node for a logical router |
US10313186B2 (en) | 2015-08-31 | 2019-06-04 | Nicira, Inc. | Scalable controller for hardware VTEPS |
US10230576B2 (en) | 2015-09-30 | 2019-03-12 | Nicira, Inc. | Managing administrative statuses of hardware VTEPs |
US9948577B2 (en) | 2015-09-30 | 2018-04-17 | Nicira, Inc. | IP aliases in logical networks with hardware switches |
US10263828B2 (en) | 2015-09-30 | 2019-04-16 | Nicira, Inc. | Preventing concurrent distribution of network data to a hardware switch by multiple controllers |
US9998324B2 (en) | 2015-09-30 | 2018-06-12 | Nicira, Inc. | Logical L3 processing for L2 hardware switches |
US10250553B2 (en) | 2015-11-03 | 2019-04-02 | Nicira, Inc. | ARP offloading for managed hardware forwarding elements |
US9998375B2 (en) | 2015-12-15 | 2018-06-12 | Nicira, Inc. | Transactional controls for supplying control plane data to managed hardware forwarding elements |
US9992112B2 (en) | 2015-12-15 | 2018-06-05 | Nicira, Inc. | Transactional controls for supplying control plane data to managed hardware forwarding elements |
US9917799B2 (en) | 2015-12-15 | 2018-03-13 | Nicira, Inc. | Transactional controls for supplying control plane data to managed hardware forwarding elements |
US10182035B2 (en) | 2016-06-29 | 2019-01-15 | Nicira, Inc. | Implementing logical network security on a hardware switch |
CN106603415A (zh) * | 2016-12-16 | 2017-04-26 | 成都西加云杉科技有限公司 | 数据处理方法及装置 |
US11272815B2 (en) | 2017-03-07 | 2022-03-15 | Ecolab Usa Inc. | Monitoring modules for hand hygiene dispensers |
CN107689921B (zh) * | 2017-09-15 | 2020-11-13 | 深圳市盛路物联通讯技术有限公司 | 一种转发节点的选择方法及系统 |
US10574561B2 (en) * | 2017-10-04 | 2020-02-25 | Cisco Technology, Inc. | Centralized error telemetry using segment routing header tunneling |
JP6773088B2 (ja) * | 2018-08-09 | 2020-10-21 | 沖電気工業株式会社 | 無線中継装置、無線中継プログラム、及び無線通信システム |
US11310201B2 (en) * | 2018-10-23 | 2022-04-19 | Akamai Technologies, Inc. | Network security system with enhanced traffic analysis based on feedback loop |
CA3123862A1 (en) * | 2018-12-20 | 2020-06-25 | Ecolab Usa Inc. | Adaptive route, bi-directional network communication |
US11102121B2 (en) | 2019-10-23 | 2021-08-24 | Cisco Technology, Inc. | Path signatures for data flows |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001251343A (ja) * | 2000-03-06 | 2001-09-14 | Fujitsu Ltd | ラベルスイッチネットワークシステム |
JP2004153318A (ja) * | 2002-10-28 | 2004-05-27 | Ntt Docomo Inc | パケット通信方法、パケット通信システム、送信元ノード、中継ノード及び中継器 |
JP2006165952A (ja) * | 2004-12-07 | 2006-06-22 | Hitachi Ltd | パケット中継装置およびパケット通信ネットワーク |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH03195235A (ja) * | 1989-12-25 | 1991-08-26 | Mitsubishi Electric Corp | パケット交換網のルーチング制御方式 |
JP2570963B2 (ja) * | 1993-05-31 | 1997-01-16 | 日本電気株式会社 | パケット網における中継経路情報を用いたシグナリング方式 |
US6788689B1 (en) * | 2000-03-07 | 2004-09-07 | Cisco Technology, Inc. | Route scheduling of packet streams to achieve bounded delay in a packet switching system |
JP2002185513A (ja) * | 2000-12-18 | 2002-06-28 | Hitachi Ltd | パケット通信ネットワークおよびパケット転送制御方法 |
JP2002198989A (ja) * | 2000-12-25 | 2002-07-12 | Yaskawa Electric Corp | 制御システムにおけるネットワーク中継方法および制御システム |
JP2002314586A (ja) * | 2001-02-09 | 2002-10-25 | Mitsubishi Electric Corp | 送信装置及び多重通信方式及び多重通信方法及び多重通信プログラム及び多重通信プログラムを記録した計算機で読み取り可能な記録媒体 |
IL141855A0 (en) * | 2001-03-07 | 2002-03-10 | Onetiercommunications Inc | A method and apparatus for providing an improved quality of service for data transfer over the internet |
DE60131551T2 (de) * | 2001-12-12 | 2008-10-23 | Alcatel Lucent | Telekommunikationsnetzwerk und entsprechenden Paketkopf |
US7047315B1 (en) * | 2002-03-19 | 2006-05-16 | Cisco Technology, Inc. | Method providing server affinity and client stickiness in a server load balancing device without TCP termination and without keeping flow states |
JP2004356883A (ja) * | 2003-05-28 | 2004-12-16 | Nippon Telegr & Teleph Corp <Ntt> | データ通信システム、および方法 |
JP2005045681A (ja) * | 2003-07-24 | 2005-02-17 | Nec Engineering Ltd | スイッチネットワーク装置及びその転送制御方法 |
US8081566B1 (en) * | 2004-04-19 | 2011-12-20 | Rockstar BIDCO, LLP | Method and apparatus for indicating congestion in a source routed network |
JP2005333454A (ja) * | 2004-05-20 | 2005-12-02 | Nippon Telegr & Teleph Corp <Ntt> | パス設定用サーバ装置、パス設定方法およびパス設定用プログラム |
US7471669B1 (en) * | 2004-09-30 | 2008-12-30 | Nortel Networks Limited | Routing of protocol data units within a communication network |
JP4549961B2 (ja) * | 2004-11-01 | 2010-09-22 | 株式会社日立製作所 | 通信路監視システム及び通信ネットワークシステム |
JP4726498B2 (ja) * | 2005-01-14 | 2011-07-20 | 富士通株式会社 | 情報処理方法及びルータ |
US7522603B2 (en) * | 2006-03-14 | 2009-04-21 | Cisco Technology, Inc. | Technique for efficiently routing IP traffic on CE-CE paths across a provider network |
CN101047614B (zh) * | 2006-05-01 | 2010-08-25 | 华为技术有限公司 | 一种IPv6网络环境中流传输路径建立方法和数据传输系统 |
US8982887B2 (en) * | 2007-05-18 | 2015-03-17 | International Business Machines Corporation | System, method and program for making routing decisions |
US7911944B2 (en) * | 2007-12-26 | 2011-03-22 | Nortel Networks Limited | Tie-breaking in shortest path determination |
JP5062845B2 (ja) * | 2008-06-30 | 2012-10-31 | 日本電信電話株式会社 | 経路切替方法、サーバ装置、境界ノード装置、経路切替システム及び経路切替プログラム |
CN101436998A (zh) * | 2008-12-16 | 2009-05-20 | 华为技术有限公司 | 报文转发路径获取方法和报文转发装置 |
EP2479938A4 (en) * | 2009-09-14 | 2016-09-07 | Nec Corp | COMMUNICATION SYSTEM, FORWARDING NOTIFICATION, PATH MANAGEMENT SERVER, COMMUNICATION PROCESS AND PROGRAM |
CN102687465B (zh) * | 2009-12-28 | 2015-04-08 | 日本电气株式会社 | 通信系统和收集端口信息的方法 |
-
2011
- 2011-01-07 CN CN201180005856.2A patent/CN102714629B/zh active Active
- 2011-01-07 JP JP2011549034A patent/JP5699939B2/ja active Active
- 2011-01-07 WO PCT/JP2011/050182 patent/WO2011083846A1/ja active Application Filing
- 2011-01-07 CN CN201510368390.2A patent/CN105141516A/zh active Pending
- 2011-01-07 EP EP11731844.4A patent/EP2523405A4/en not_active Withdrawn
- 2011-07-29 US US13/137,237 patent/US20110286326A1/en not_active Abandoned
-
2015
- 2015-02-19 JP JP2015030198A patent/JP5935913B2/ja active Active
-
2016
- 2016-05-12 JP JP2016095970A patent/JP6137384B2/ja active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001251343A (ja) * | 2000-03-06 | 2001-09-14 | Fujitsu Ltd | ラベルスイッチネットワークシステム |
JP2004153318A (ja) * | 2002-10-28 | 2004-05-27 | Ntt Docomo Inc | パケット通信方法、パケット通信システム、送信元ノード、中継ノード及び中継器 |
JP2006165952A (ja) * | 2004-12-07 | 2006-06-22 | Hitachi Ltd | パケット中継装置およびパケット通信ネットワーク |
Non-Patent Citations (3)
Title |
---|
"OpenFlow Switch Specification Version 1.0.0", WIRE PROTOCOL OX01, 31 December 2009 (2009-12-31), XP008166937, Retrieved from the Internet <URL:http://www. openflow.org/documents/openflow-spec-v1.0.0.pdf> * |
See also references of EP2523405A4 * |
YOSHITAKE TAJIMA ET AL.: "A Traffic Engineering Scheme in a Global Networking Service Platform", IEICE TECHNICAL REPORT SSE2000-268, vol. 100, no. 670, 2 March 2001 (2001-03-02), pages 241 - 248, XP002996836 * |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9906438B2 (en) | 2012-12-19 | 2018-02-27 | Nec Corporation | Communication node, control apparatus, communication system, packet processing method, communication node controlling method and program |
CN104871500A (zh) * | 2012-12-19 | 2015-08-26 | 日本电气株式会社 | 通信节点、控制装置、通信系统、分组处理方法、通信节点控制方法及程序 |
WO2014129624A1 (ja) * | 2013-02-25 | 2014-08-28 | 日本電気株式会社 | 制御装置、通信システム、経路切替方法及びプログラム |
JPWO2014129624A1 (ja) * | 2013-02-25 | 2017-02-02 | 日本電気株式会社 | 制御装置、通信システム、経路切替方法及びプログラム |
WO2014132967A1 (ja) * | 2013-02-26 | 2014-09-04 | 日本電気株式会社 | 通信システム、スイッチ、制御装置、制御用チャネルの構築方法及びプログラム |
US9628376B2 (en) | 2013-02-26 | 2017-04-18 | Nec Corporation | Communication system, switch, controller, method for constructing a control channel and program |
JP2014236481A (ja) * | 2013-06-05 | 2014-12-15 | 富士通株式会社 | 通信システム、通信制御方法、及び、伝送装置 |
JP2015115643A (ja) * | 2013-12-09 | 2015-06-22 | パナソニックIpマネジメント株式会社 | 通信システム及び通信方法 |
JP2017506846A (ja) * | 2014-02-11 | 2017-03-09 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | 公開鍵を基礎とするデジタル署名を使用してソースルーティングを保全するためのシステムおよび方法 |
JP2016025400A (ja) * | 2014-07-16 | 2016-02-08 | 富士電機株式会社 | 無線通信システム、無線機、中継ルート決定方法、および、プログラム |
JP2016220202A (ja) * | 2015-05-15 | 2016-12-22 | 華為技術有限公司Huawei Technologies Co.,Ltd. | データ交換システム、データトラヒックを送出する方法及び交換装置 |
US9883261B2 (en) | 2015-05-15 | 2018-01-30 | Huawei Technologies Co., Ltd. | Data switching system, method for sending data traffic, and switching apparatus |
WO2017022833A1 (ja) * | 2015-08-06 | 2017-02-09 | 日本電気株式会社 | Vnf提供システム、vnf id管理装置、vnfのid管理方法及びプログラム |
JP2022550343A (ja) * | 2019-09-27 | 2022-12-01 | 華為技術有限公司 | Srネットワークでパケットを転送する方法、デバイス、及びシステム |
JP7481436B2 (ja) | 2019-09-27 | 2024-05-10 | 華為技術有限公司 | Srネットワークでパケットを転送する方法、デバイス、及びシステム |
JP2022548152A (ja) * | 2020-01-13 | 2022-11-16 | テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド | ルーティング制御方法、装置、プログラム及びコンピュータ装置 |
JP7345059B2 (ja) | 2020-01-13 | 2023-09-14 | テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド | ルーティング制御方法、装置、プログラム及びコンピュータ装置 |
Also Published As
Publication number | Publication date |
---|---|
US20110286326A1 (en) | 2011-11-24 |
CN102714629B (zh) | 2015-07-29 |
JP5699939B2 (ja) | 2015-04-15 |
EP2523405A1 (en) | 2012-11-14 |
JPWO2011083846A1 (ja) | 2013-05-16 |
JP5935913B2 (ja) | 2016-06-15 |
JP2016165150A (ja) | 2016-09-08 |
CN105141516A (zh) | 2015-12-09 |
EP2523405A4 (en) | 2016-09-07 |
JP6137384B2 (ja) | 2017-05-31 |
JP2015128304A (ja) | 2015-07-09 |
CN102714629A (zh) | 2012-10-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6137384B2 (ja) | 通信システム、転送ノード、経路管理サーバおよび通信方法 | |
JP5790850B2 (ja) | 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム | |
US8065434B2 (en) | Method and device for maintaining routes | |
EP1411678B1 (en) | Method and system for content-oriented routing of packets in a storage-embedded network | |
JP5672235B2 (ja) | 通信システム、フロー制御装置、フローテーブルの更新方法およびプログラム | |
JP4491397B2 (ja) | トラフィック迂回機能を備えるパケット転送装置。 | |
JP4541745B2 (ja) | ホームエージェント管理装置及び管理方法 | |
JP5483149B2 (ja) | 通信システム、管理計算機、スタックドスイッチ、フロー経路決定方法 | |
WO2021169258A1 (zh) | 转发报文的方法、发布路由信息的方法、装置及系统 | |
JP5800019B2 (ja) | 通信経路制御システム、経路制御装置、通信経路制御方法および経路制御プログラム | |
US20130058345A1 (en) | Apparatus and Method for Establishing Tunnels Between Nodes in a Communication Network | |
JPWO2002087175A1 (ja) | リストレーション・プロテクション方法及び装置 | |
JP2013541235A (ja) | 制御装置、通信システム、通信方法、および通信プログラムを記録する記録媒体 | |
JP5001966B2 (ja) | 経路情報管理方法およびその管理システム | |
US11431632B1 (en) | ID/location hybrid forwarding method based on source routing | |
JP6724427B2 (ja) | コントローラ、通信スイッチ、通信システム、通信制御方法、及びプログラム | |
JP2017204785A (ja) | 通信装置、通信システム、及び通信装置のパケット転送方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 201180005856.2 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11731844 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2011549034 Country of ref document: JP |
|
REEP | Request for entry into the european phase |
Ref document number: 2011731844 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2011731844 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |