WO2011030889A1 - 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム - Google Patents

通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム Download PDF

Info

Publication number
WO2011030889A1
WO2011030889A1 PCT/JP2010/065712 JP2010065712W WO2011030889A1 WO 2011030889 A1 WO2011030889 A1 WO 2011030889A1 JP 2010065712 W JP2010065712 W JP 2010065712W WO 2011030889 A1 WO2011030889 A1 WO 2011030889A1
Authority
WO
WIPO (PCT)
Prior art keywords
transfer
node
information
forwarding
packet
Prior art date
Application number
PCT/JP2010/065712
Other languages
English (en)
French (fr)
Inventor
潤 粟野
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to CN2010800408171A priority Critical patent/CN102498694A/zh
Priority to EP10815479.0A priority patent/EP2479938A4/en
Priority to JP2011530901A priority patent/JP5640982B2/ja
Publication of WO2011030889A1 publication Critical patent/WO2011030889A1/ja
Priority to US13/176,610 priority patent/US8750163B2/en
Priority to US14/244,701 priority patent/US9900249B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/745Address table lookup; Address filtering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/34Source routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing

Definitions

  • the present invention is based on the priority claim of Japanese Patent Application No. 2009-212221 (filed on Sep. 14, 2009), 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, a communication method, and a program, and in particular, a communication system, a transfer node, a route management server, and a communication that realize communication by transferring packets by a transfer node arranged in a network. It relates to a method and a program.
  • FIG. 20 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 only by the destination address, there is a problem that precise route control cannot be performed due to differences in the source address and the 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.
  • the transfer process is repeated while changing. 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 in an ad hoc network, not all mobile terminal apparatuses transmit link information between adjacent mobile terminal apparatuses, but only the mobile terminal apparatus that has become the cluster head transmits link information. Thus, a method capable of reducing the total amount of control packets is disclosed.
  • Non-Patent Document 1 proposes a technique called OpenFlow, which performs path control.
  • 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 The entire disclosures of Patent Document 1 and Non-Patent Document 1 are incorporated herein by reference.
  • the following is an analysis of the related art according to 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 relates to an ad hoc network that includes only a plurality of mobile terminal devices without requiring facilities that serve as the basis of a mobile communication network. Since the configuration of the network can be constantly changed, it is not possible to realize route control in which a source can specify a route such as the above-described source routing.
  • each forwarding node needs to refer to the flow table as in the method of referring to the routing table described at the beginning, and the latency (delay time) increases as the number of entries increases. Occurrence and load on the node can be considered.
  • 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 of the present invention is communication that can be realized by using a simplified transfer table and can also be applied to route control of data packets.
  • a system, a transfer node, a route management server, a communication method, and a program are provided.
  • a communication interface provided in an individual transfer node on a transfer path of a data transfer network or a link established between the individual transfer node and its adjacent node is identified.
  • a path management server that configures transfer path information by arranging identifiers for performing, and a transfer node that executes packet transfer processing according to the transfer path information for a packet to which a header storing the transfer path information is added.
  • a communication system is provided.
  • 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.
  • a route management server that creates and provides transfer route information included in a header to be added to a packet transmitted from a transmission source communication node.
  • each transfer node on the transfer path of the data transfer network identifies a communication interface included in each transfer node or a link established between adjacent transfer nodes of the own device.
  • a communication method comprising: receiving a packet to which a header storing transfer path information configured by arranging the identifiers of the packets is added; and executing packet transfer processing on the packet according to the transfer path information Provided. The method is tied to a specific machine, the forwarding node that makes up the data transfer network.
  • 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.
  • packet routing can be performed without using a transfer table having a huge volume and without reducing the net data amount.
  • the forwarding node is configured to execute the packet forwarding process according to the forwarding route information included in the packet header, and the forwarding route information is configured by arranging communication interface or link identifiers.
  • 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 a boundary transfer node and an internal transfer node. It is an example of the format of the path
  • FIG. 10 is a flowchart showing details of the transfer process of FIG. 9. It is a flowchart which shows the operation
  • the transfer node of the communication system performs a transfer process based on the path information in the header when the received packet has a header including the transfer path information.
  • the transfer path may be configured by arranging, in the transfer order, identifiers that can identify the communication interfaces to be transferred by each transfer node arranged on the transfer path.
  • the identifier need only have a length sufficient to ensure the uniqueness of the transfer destination in each transfer node.
  • 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. . Therefore, it is possible to store information describing the transfer path for each hop, not only for some control packets but also for all packets such as data packets, thereby enabling advanced transfer control.
  • 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 transfer route information may be executed by the transfer node (boundary transfer node) arranged at the boundary with the external network among the transfer nodes as follows.
  • the boundary forwarding node that has received the packet from the external network obtains the forwarding route of the packet from a separately provided route management server or information recorded in the border forwarding node, and stores the forwarding route information. Is added to the received packet.
  • the boundary forwarding node deletes the header when transmitting a packet to the external network.
  • 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.
  • the boundary transfer nodes 300a and 300b include a header (hereinafter referred to as “header” including transfer path information described later).
  • the packet is transferred to the internal transfer node 400 in the data transfer network 600 based on the transfer path information in the header.
  • the boundary transfer nodes 300a and 300b are determined to be the last transfer route in the data transfer network 600 when the packet sent from the internal transfer node 400 is received and the transfer route information in the header is received. In this case, the 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, a recording Part 370.
  • 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 has a function of transferring a packet based on the route information header and information recorded in the recording unit 370 when a route information header is added to the received packet.
  • the correspondence information of the local ID, the communication interface as the transfer destination, and the identifier of the neighboring boundary transfer node 300 or the internal transfer node 400 connected to the communication interface 310. Is stored as a single entry.
  • 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 a diagram showing a transfer table recorded in the recording devices 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 shows an example of the format of the path information header used in this embodiment.
  • 'Direction' indicates a transfer direction. For example, “1” indicates forward transfer, and “2” indicates reverse transfer.
  • Current Offset 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'.
  • 'Header Length' indicates the length of the header after 'Route Length' in bytes. Considering packet shaping, the value is in units of 4 bytes.
  • '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 transfer node 300 or the internal transfer node 400 should refer to as a transfer destination.
  • the format shown in FIG. 4 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.
  • the most significant bit of 'LocalID # n' may be used as a local ID extension flag indicating whether the local ID is expressed in 1 byte or 2 bytes. That is, in this case, when the most significant bit is 0, the local ID is interpreted as a 1-byte identifier, and when the most significant bit is 1, the local ID is interpreted as a 2-byte identifier.
  • the packet transfer unit 320 refers to the “Current Offset” in the path information header when the “Direction” field of the path information header of the received packet is “1”, that is, indicates forwarding in the forward direction. After determining the transfer destination communication interface 310 with reference 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 determined communication is performed. A packet is transmitted from the interface 310.
  • 'Direction' is '2', that is, if it indicates a transfer in the reverse direction, refer to 'Current Offset' in the route information header and refer to the local ID one before the corresponding local ID Then, the communication interface 310 as the transfer destination is determined. Thereafter, the local ID is reduced by the length of the local ID referring to the value of “Current Offset” in the path information header, and the determined communication interface 310 transmits the packet.
  • this embodiment demonstrates as what performs bi-directional transfer, you may be a communication system which implements only one-way transfer. In this case, the 'Direction' field may always be set to '1', or the field may be omitted.
  • 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 boundary transfer node 300 to the boundary transfer node 300 as an exit from the route acquisition unit 360, which is shown in FIG. A path information header, and a function for giving to the packet. For example, when assigning a path information header, the header operating unit 330 sets “Direction” to “1” indicating forward transfer, “CurrentOffset” to “0”, and “LocalID # n”. In ', the acquired route information (local ID) for each hop is set. Further, the header operation unit 330 sets appropriate values in the other fields in accordance with the rules described above.
  • the header operation unit 330 also has a function of deleting the route information header when transferring the packet to which the route information header has been added to the external network 700.
  • 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 370 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 transfer in the reverse direction is necessary, even when the interface identifier is used as the local ID, by negotiating with the neighboring node, which communication interface of the neighboring forwarding node becomes its own communication interface.
  • the interface can be selected according to the transfer direction by Direction.
  • 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.
  • 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 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 When the internal forwarding node 400 is arranged in the data forwarding network 600 and receives a packet transmitted from a neighboring node, the internal forwarding node 400 sends the packet to the neighboring node in the data forwarding network 600 based on the information of the path information header in the packet. It has a function to transfer.
  • FIG. 5 is a diagram showing a 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 local ID determination unit 430, a neighborhood information notification unit 440, and a recording unit 450.
  • the communication interface 410, the packet transfer unit 420, the local ID determination unit 430, the neighborhood information notification unit 440, and the recording unit 450 are the communication interface 310, the packet transfer unit 320, the local ID determination unit 340, and the neighborhood of the boundary transfer node 300, respectively. Since it is equivalent to the information notification unit 350 and the recording unit 370, detailed description thereof is omitted here.
  • 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 transfer route information is requested from the boundary transfer node 300, a calculation for obtaining an appropriate transfer route is performed using the information included in the route request and the network topology information built therein, and the route request From the boundary transfer node 300 that has performed the process, the transfer path to the boundary transfer node 300 serving as an exit to the external network 700 is responded as information in which local IDs (link IDs) for each hop are listed in order.
  • FIG. 6 is a diagram showing a configuration of the route management server 500 of FIG. As shown in FIG. 6, the route management server 500 further 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. Yes.
  • 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. 7 is an example of neighbor information received from each forwarding node.
  • FIG. 8 is an example of a network topology constructed from the neighborhood information of FIG. In the example of FIG. 8, the accompanying information is omitted for simplicity. In addition, it is assumed that the external network is an IP network.
  • 'SenderID' in FIG. 7 indicates the identifier of the forwarding node that transmitted the neighborhood information.
  • 'LinkID' in FIG. 7 indicates the link ID assigned to the link to which the forwarding node is connected.
  • ‘NeighborID’ in FIG. 7 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. In addition, since the negotiation is performed between adjacent forwarding nodes as described above, 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. 8 and records it in the route information recording unit 540.
  • the link ID is used for the neighbor information of FIG. 7 and the network topology information of FIG. 8 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 When the route request processing unit 530 acquires transfer route information (information listing link IDs for each hop in order of transfer route) from the route calculation unit 531, the route request processing unit 530 sends a route response signal storing the transfer route information to the route The request signal is transmitted to the boundary forwarding node 300 that is the transmission source.
  • transfer route information information listing link IDs for each hop in order of transfer route
  • 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. 8 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.
  • 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 route information recording unit 540 records network topology information as shown in FIG. 8 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 370, the recording unit 450, 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 software, and the rest may be performed by hardware.
  • FIG. 9 shows a process 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. 4 according to the transfer route order of the acquired transfer route information. Set. In addition, the header operation unit 330 sets “Direction” to “1” and sets “Current Offset” to “0”. The header operation unit 330 sets other fields to appropriate values, and adds a path information header to the head of the received packet (step S102).
  • the packet transfer unit 320 performs transfer processing according to the above-described path information header (step S103).
  • FIG. 10 is a flowchart showing details of the transfer process in step S103 of FIG. Referring to FIG. 10, first, the packet transfer unit 320 checks the “Direction” field of the path information header and determines whether to perform forward transfer or reverse transfer (step S200).
  • the process proceeds to 'Y', and it is determined whether the transfer destination of the packet is the external network 700 (step S201).
  • 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 number of bytes for 1 hop is added to 'Current Offset' of the route information header (step S202).
  • the number of bytes for 1 hop is the number of bytes in the currently referenced 'LocalID # n' field.
  • the local ID that is the reference destination is held before the value of 'Current Offset' is added.
  • the packet transfer unit 320 performs forward packet transfer processing using the stored local ID (step S206). 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.
  • Step S200 determines whether the transfer destination of the packet is the external network 700.
  • Step S203 determines whether the transfer is to the external network 700 in the reverse transfer.
  • Whether the transfer is to the external network 700 in the reverse transfer can be determined by whether the value of “Current Offset” is “0” (transfer to the external network when “0”). This is a determination method in the case where the link ID of the link between the communication nodes 100a and 100b that transmits the packet first and the boundary forwarding node 300 that receives the packet is not used as the first local ID.
  • the link ID When the link ID is used as the first local ID, when the current value of “Current Offset” is subtracted by one hop is “0”, it can be determined that the transfer is to the 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.
  • step S204 the process proceeds to 'N', and the value of 'Current Offset' in the path information header is subtracted by 1 hop (step S204).
  • the local ID to be referred to is retained in the 'Current Offset' after subtraction.
  • the packet transfer unit 320 performs a packet transfer process in the reverse direction using the stored local ID (step S206). 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.
  • step S201 If it is determined in step S201 or S203 that the data is transferred to the external network 700, the process proceeds to 'Y', and the header operation unit 330 performs a path information header removal process (step S205).
  • the header operation unit 330 performs a path information header removal process (step S205).
  • the local ID as the transfer destination is held.
  • the packet transfer unit 320 performs a packet transfer process to the external network 700 using the stored local ID (step S206). 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.
  • step S200 determines whether or not the transfer is to the external network in step S201. do it.
  • FIG. 11 shows a process when the internal transfer node 400 receives a packet from the boundary transfer node 300 or the internal transfer node 400 of the data transfer network 600.
  • the packet transfer unit 420 checks whether or not a route information header is attached to the packet (step S300).
  • step S302 If the route information header has been assigned, the process proceeds to 'Y', and the 'Direction' field of the route information header is checked to determine whether to forward or reverse (step S302). ). On the other hand, if the route information header is not added, the process proceeds to 'N', and the received packet is discarded (step S301).
  • step S302 If the value of the “Direction” field checked in step S302 indicates forward transfer (“1”), the process proceeds to “Y”, and the number of bytes for 1 hop is added to “Current Offset” of the route information header. (Step S303). Here, the local ID that is the reference destination is held before the value of 'Current Offset' is added.
  • Step S302 if the value of the “Direction” field checked in step S302 indicates reverse transfer (“2”), the process proceeds to “N”, and the number of bytes for 1 hop is subtracted from “Current Offset” of the route information header. (Step S304).
  • the local ID to be referred to is retained in the “Current Offset” after subtraction.
  • packet transfer processing is performed based on the local ID held in step S303 or step S304. Specifically, the communication interface 410 to be the transfer destination is determined from the local ID using the information in the transfer table recorded in the recording unit 450, and the packet is transferred from the communication interface 410 (step S305).
  • step S302 If the forward direction is always used without using the 'Direction' field, it is not necessary to determine the transfer direction in step S302, and the 'Current Offset' addition process in step S303 is always performed.
  • FIG. 12 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 S400).
  • 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 370 (450). It is recorded in the transfer table (see FIG. 3) (step S401).
  • 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 notification 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 370 (450). Is configured and transmitted to the route management server 500 (step S402).
  • incidental information such as information related to each link and failure information of neighboring nodes may be stored.
  • FIG. 13 is a flowchart showing 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 S501).
  • FIG. 14 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 first, when a route request signal is received 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 S600).
  • the route calculation unit 531 calculates an optimum transfer route based on the information included in the route request signal notified in step S600 and the network topology information recorded in the route information recording unit 540 (Ste S601).
  • the route calculation unit 531 reads the local ID for each hop in the determined route transfer order, 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 sets the notified transfer route information (arrangement of local IDs) in the route information response signal, and is a boundary transfer node that is the source of the route request signal It transmits to 300 (step S602).
  • 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 S700 When the IP packet transmitted from the communication node 100a reaches the boundary forwarding node 300a (step S700), 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. 9 (step S701).
  • the route management server 500 that has received the route information request signal calculates route information and determines a transfer route according to the flowchart of FIG. 14, and then transmits a route information response signal to the boundary transfer node 300a (step S702).
  • 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 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 S705), the internal transfer node 400 performs the transfer process according to the flowchart shown in FIG. 11 (step S706).
  • the boundary forwarding node 300b When the boundary forwarding node 300b receives the packet to which the path information header is added (step S707), the boundary forwarding node 300b performs processing according to the flowchart shown in FIG. Further, in step S103 of FIG. 9, the transfer process shown in the flowchart of FIG. 10 is further performed.
  • 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 path for 1 hop can be stored in an information amount of about 1 byte or 2 bytes, and even when the information of the transfer path is stored in the path information header and added to the packet, the overhead due to the added header is extremely small. It becomes possible to suppress to a 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.
  • FIG. 16 is a diagram showing a configuration of the boundary forwarding node 301 according to the second exemplary embodiment of the present invention.
  • the boundary forwarding node 301 of this embodiment has a configuration in which a cache management unit 380 is added to the configuration of the boundary forwarding node 300 of the first embodiment. Further, the operation of the route acquisition unit 360A and the information recorded by the recording unit 370A are also different from those in the first embodiment.
  • the route acquisition unit 360A has substantially the same function as the route acquisition unit 360 according to the first embodiment of the present invention, but searches a route information cache (to be described later) before requesting the transfer route information to the route management server 500. It further has a function.
  • a route information cache corresponding to the received packet is found as a result of searching the route information cache, the route management server 500 is not requested for the route information, and the transfer route information is acquired from the found route information cache.
  • the route acquisition unit 360A transmits the transfer route information acquired from the route management server 500 and the information of the received packet to the cache management unit 380 so as to be recorded as the route information cache.
  • the cache management unit 380 sets the received packet information and the route information header. A function of associating the recorded information with each other and recording the information as a path information cache in the recording unit 370A is provided.
  • a destination address and a transmission source address are recorded as information of the received packet.
  • other information may be used in addition to the destination address and the source address.
  • the route information cache may be deleted from the old route information cache when a certain amount of time elapses or a certain amount of route information cache is accumulated. Further, an arbitrary route information cache may be deleted for management reasons.
  • the recording unit 370A further records a path information cache in addition to the information recorded by the recording unit 370 in the first embodiment.
  • the route information cache is managed by the cache management unit 380 such as addition, update, and deletion.
  • FIG. 17 shows processing when the boundary transfer node 301 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 S800).
  • the process proceeds to 'Y', and the transfer process is performed according to the route information header (to step S809).
  • the route acquisition unit 360A performs a forward route information cache search process (step S801).
  • the forward path information cache search can be performed by comparing the destination address of the received packet with the destination address in the path information cache.
  • route information cache is found as a result of the search of the forward route information cache (“Y” in step S802), a route information header addition process using the route information cache is performed (to step S808).
  • the route acquisition unit 360A performs a route information cache search process in the backward direction (step S802). S804).
  • the reverse path information cache search can be performed by comparing the destination address of the received packet with the source address in the path information cache.
  • step S805 If the path information cache is found as a result of searching the path information cache in the reverse direction (“Y” in step S805), a path information header addition process using the path information cache is performed (to step S808).
  • the path acquisition unit 360A transmits a path request signal to the path management server 500 and transfers the transfer path.
  • a route acquisition process for acquiring information is performed (step S806).
  • the cache management unit 380 associates the destination address and the transmission source address included in the received packet with the transfer path information acquired in step S806 and records it in the recording unit 370A as a path information cache. (Step S807).
  • the header operation unit 330 constructs a route information header in accordance with the route information cache or the transfer route order of the acquired transfer route information, and adds it to the head of the received packet (step S808).
  • the values set in each field of the route information header are as follows.
  • the route information is set in the local ID field ('LocalID # n') of the route information header shown in FIG. 4 according to the transfer order. Also, 'Direction' is set to '1', and 'Current Offset' is set to '0'.
  • 'Direction' is set to '1' and 'Current Offset' is set to '0'.
  • the value recorded in the path information cache is set to 'LocalID # n' while maintaining the order.
  • 'Direction' is set to '2'
  • 'Current Offset' is set to the value recorded in the route information cache.
  • the value recorded in the path information cache is set to 'LocalID # n' while maintaining the order.
  • the values recorded in the route information cache can be set to 'LocalID # n' in the reverse order.
  • “Direction” is set to “1”
  • “Current Offset” is set to the number of offset bytes indicating the local ID #n as the first transfer destination.
  • the packet transfer unit 320 performs transfer processing according to the path information header configured as described above (step S809). Details of the processing in step S809 are substantially the same as the forwarding processing of the boundary forwarding node 300 in the first embodiment shown in FIG. However, in this embodiment, when the route information header is deleted in step S205 of FIG. 10, the cache management unit 380 associates the information of the received packet with the information set in the route information header. The information is recorded in the recording unit 370A as an information cache.
  • the transfer procedure of the first (outbound route) packet is almost the same as in the first embodiment, and the packet is transferred as shown in the sequence diagram shown in FIG. However, in steps S703 and S707 of FIG. 15, the path information caches shown in FIGS. 18A and 18B are created in the recording units 370 of the boundary forwarding node 301a and the boundary forwarding node 301b, respectively.
  • the route information cache in FIG. 18 includes creation time information, but this is not always necessary.
  • HH: MM: SS of the creation time information indicates hour: minute: second, respectively.
  • the communication node 100b transmits the packet to the communication node 100a.
  • a series of flow from when it is sequentially transferred to finally reaching the communication node 100a which is an IP node will be described.
  • step S900 When an IP packet is transmitted from the communication node 100b (step S900) and reaches the boundary forwarding node 300b, the boundary forwarding node 301b executes processing according to the flowchart shown in FIG. 17 (step S901).
  • a forward route information cache search is executed in step S801 in FIG. That is, a process for searching for an entry having a destination address 192.168.0.50 is performed by scanning the destination address field of the route information cache shown in FIG.
  • the reverse route information cache search is performed in step S804 in FIG. Is executed. That is, a process for searching for an entry having the destination address 192.168.0.50 by scanning the transmission source address field of the path information cache shown in FIG.
  • the route acquisition unit 360A reads the route information of the entry found by the search.
  • each field of the route information header is set as follows.
  • the path information header is added to the received packet, and the transfer process is executed (step S902).
  • the internal forwarding node 400 executes the forwarding process as a packet to which the route information header is attached and performs forwarding in the reverse direction according to the flowchart shown in FIG. S903).
  • the boundary forwarding node 301a executes the forwarding process as a packet to which the route information header is attached and performs forwarding in the reverse direction according to the flowchart shown in FIG. S905).
  • “CurrentOffset” of the route information header is “0”, it is determined that the transfer is to the external network in step S203 of FIG. 10, and the route information header is deleted in step S205.
  • the entry shown in FIG. 18A is already recorded in the route information cache of the boundary forwarding node 301a, the entry time of the entry is recorded without adding a new route information cache having duplicate contents. Update. Thereafter, transfer processing is performed using the packet information (destination address 192.168.0.50) after the route information header is deleted. As a result, the packet is transferred to the destination communication node 100a (step S906).
  • the path management server 500 when the boundary forwarding nodes 301a and 301b acquire path information from the path management server 500 or delete the path information header, the path management server The route information acquired from 500 and the route information included in the route information header are recorded and used as a route information cache. For this reason, the frequency of transmitting a route request to the route management server 500 can be reduced, and the load on the route management server 500 can be reduced.
  • a cache of route information recorded when a packet is sent to a destination is used for a packet in the reverse direction, that is, a packet sent to the transmission source of the packet. Since the route information header is also used when configuring the route management header 500, the load reduction effect of the route management server 500 can be enhanced.
  • 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.
  • the communication interface identifiers may be exchanged between neighboring nodes to share information.
  • 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 route management server can also obtain the connection relationship of each forwarding node and can set a local ID so that adjacent nodes do not overlap each other, the neighborhood information notification unit of each forwarding node also includes It can be omitted.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

 簡略化された転送テーブルを用いて実現可能であり、しかも、データパケットの経路制御にも適用できる通信システムを提供する。経路管理サーバは、自装置に備えられている通信インタフェースまたは自装置とその隣接ノードとの間に張られたリンクを識別するためのリンクIDを並べることによって構成されている転送経路情報を構成する。転送ノードは、前記転送経路情報を格納したヘッダが付加されたパケットについて、前記転送経路情報に従ってパケット転送処理を実行する。

Description

通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム
[関連出願についての記載]
 本発明は、日本国特許出願:特願2009-212221号(2009年9月14日出願)の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
 本発明は、通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムに関し、特に、ネットワークに配置された転送ノードによりパケットを転送して通信を実現する通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムに関する。
 図20にIP(Internet Protocol)を使ったネットワーク構成を示す。図20において、通信ノード100(通信ノード100aおよび通信ノード100b)は、IPを使って通信を行う通信ノードである。転送ノード200は、通信ノード100が送信したIPパケットを受信した際に、前記IPパケットの転送先を決定し、決定された転送先に転送する。転送ノードは、これを繰り返し、最終的に宛先とする通信ノードにIPパケットを転送する。
 前記IPパケットの転送先の決定には、転送ノード200が内部に保持するルーティングテーブルが使用される。ルーティングテーブルとは、どのネットワーク宛のパケットを、どのインタフェースを介して次の転送処理を担う転送ノードに送れば良いかを示すテーブルであり、宛先ネットワークアドレス、次の転送先のIPアドレス、送信先とするインタフェースの対応を1つのエントリとして、これを列挙したテーブルである。エントリには前述した情報以外の情報も含むが、ここでは簡単のため省略する。
 前記ネットワークアドレスとは、IPアドレスの内、上位から一部のビット数を抜き出したアドレスであり、例えば、192.168.1.0/24といった形式で表現される。この場合、アドレスの上位24bitがネットワークアドレスであり、当該ネットワークには、192.168.1.1から192.168.1.255までのアドレスが含まれる。このとき、24をプレフィクス長と呼ぶ。
 転送ノード200は、ルーティングテーブルから適切なルート情報を決定する際に、ロンゲストマッチという方法を使用する。これは、IPパケットの宛先アドレスとルーティングテーブルの個々のエントリを比較し、前記宛先アドレスの上位ビットから、より長いビット数が一致したものに決定するという方法である。
 前記ルーティングテーブルは、転送ノード200に手動などの方法により事前に設定するか、ルーティングプロトコルと呼ばれるルート情報を交換するプロトコルにより自動的に設定される。
 IPネットワークでは、以上の転送方式によりパケットを転送するが、この場合パケットの転送は、個々の転送ノードのルーティングテーブルに依存し、経路を完全には制御できないという問題点がある。また、宛先アドレスのみで転送先を決定するので、送信元アドレスや、どのアプリケーションによる通信か、といった違いによる緻密な経路制御ができない問題点もある。
 上記経路制御を行う方式として、ソースルーティングという手法が存在する。ソースルーティングとは、送信元となるノード(例えば、通信ノード100a)が、転送経路としたい転送ノード200のアドレスを送信パケット中に明示的に列挙する方法である。この場合、通信ノード100aは使用するアプリケーションなどにより意図した転送経路で宛先とするノード(例えば、通信ノード100b)にパケットを転送することができる。
 また、MPLS(Multi-Protocol Label Switching)というパケット転送技術にも、ソースルーティングに相当する技術が存在する。MPLSは、受信したパケットに対してラベルを付与し、ラベルに基づいて転送処理を行う技術である。
 前記ラベルの付与は、パケットがMPLSネットワークの境界に配置された転送ノードに入力された後、当該パケットを転送する際に実施され、以降MPLSネットワーク内の転送ノードは、当該パケット転送するたびラベルを張り替えながら、転送処理を繰り返す。そして、MPLSネットワークの境界に配置された転送ノードにより外部のネットワークへ転送される際に、当該転送ノードによりラベルが除去される。
 MPLSにおける、ソースルーティングに相当する技術とは、CR-LDP(Constraint Routing-Label Distribution Protocol)である。LDPは、MPLSネットワーク内の転送ノード間で前記ラベルを交換するためのプロトコルであるが、トラフィック・エンジニアリングなどの目的で、パケットの転送経路を厳密に指定することを目的としたLDPがCR-LDPである。
 特許文献1には、アドホックネットワークにおいて、すべての移動端末装置が、隣接する移動端末装置との間のリンク情報を送信するのではなく、クラスタヘッドとなった移動端末装置のみがリンク情報を送信することによって制御パケットの総量を削減できる方法が開示されている。
 また同じく経路制御を行うものとして、非特許文献1にオープンフロー(OpenFlow)という技術が提案されている。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するルールと、処理内容を定義したアクションと、フロー統計情報との組が定義される。
 例えば、オープンフロースイッチは、最初のパケット(first packet)を受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するルール(FlowKey)を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、前記検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。
特開2007-235444号公報
Nick McKeownほか7名、"OpenFlow: Enabling Innovation in Campus Networks"、[online]、[平成21年7月17日検索]、インターネット〈URL:http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉
 上記特許文献1及び非特許文献1の全開示内容はその引用をもって本書に繰込み記載する。
 以下に本発明による関連技術の分析を与える。
 IP技術に基づく転送ノード、すなわちスイッチやルータが保持するルーティングテーブルは増大の一途をたどり、ルート情報の爆発と呼ばれる問題が指摘されている。ルート増大の結果、ルーティングテーブルを保持するためのメモリの必要量が増えるとともに、ルート決定処理に時間がかかるため、パケット転送処理能力が劣化する。
 MPLSは、IPルーティングと比してルート決定時間が削減できるものの、多様な転送ポリシを適用すれば、やはりルーティングテーブルのエントリ数は増大し、処理性能の劣化につながる。
 以上のように、ルーティングテーブルのエントリ数の抑制は、メモリ削減や処理能力向上の観点で転送ノードの重要な課題となっている。
 一方、上記したソースルーティングでは、パケット中に転送ノード100のアドレスを格納するため、パケットが含むことができる正味のデータ量が小さくなってしまうという問題点がある。このため、ソースルーティングは、ネットワークの試験など一部の用途に限られ、アプリケーションなどの通信で使われるパケット(これを以降「データパケット」と呼称する。)には使用されない。なお、正味のデータ以外の情報をオーバヘッドと呼ぶ。すなわち、前述の問題は、オーバヘッドが大きくなる問題と言い換えられる。
 また、CR-LDPで使われるパケット中には、前述のIPルーティングにおけるソースルーティングと同様に、転送毎(1hop毎)の転送ノードの情報が含まれる。転送ノードの情報としては、例えばIPv4アドレスやIPv6アドレスが使われるが、この場合も転送経路中のすべての転送ノードの情報を列挙する場合は当該情報が大きくなるため、制御用パケット以外に用いるのは現実的ではない。結果として、データパケットの転送経路を厳密に決定する際には、前記CR-LDPなどで、転送ポリシごとの転送情報を転送ノード内に設定する必要が生じる。
 特許文献1の方法は、移動通信ネットワークの基盤となる設備を要せず、複数の移動端末装置のみで構成されるアドホックネットワークに関するものである。ネットワークの構成も絶えず変わりうるため、上記したソースルーティングのような送信元が経路を指定できる経路制御を実現するものではない。
 また、非特許文献1の方法は、冒頭に述べたルーティングテーブルを参照する方式と同様に、個々の転送ノードが、フローテーブルを参照する必要があり、エントリの増大に従って、レイテンシ(遅延時間)の発生やノードへの負荷が掛かってしまうことが考えられる。
 以上説明したように、ルーティングテーブルやフローテーブルに様々な転送ポリシごとのエントリを追加する方式は、エントリの追加・更新・削除の処理負荷と、ルーティングテーブルの情報量が増大するという問題点があり、転送経路を明示的に指定するソースルーティング等は、オーバヘッドが大きくなり、データパケットの送信には適さないという問題点がある。
 本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、簡略化された転送テーブルを用いて実現可能であり、しかも、データパケットの経路制御にも適用できる通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムを提供することにある。
 本発明の第1の視点によれば、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって転送経路情報を構成する経路管理サーバと、前記転送経路情報を格納したヘッダが付加されたパケットについて、前記転送経路情報に従ってパケット転送処理を実行する転送ノードと、を含む通信システムが提供される。
 本発明の第2の視点によれば、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって転送経路情報を構成する経路管理サーバと接続され、前記転送経路情報を格納したヘッダが付加されたパケットについて、前記転送経路情報に従ってパケット転送処理を実行する転送ノードが提供される。
 本発明の第3の視点によれば、送信元の通信ノードから送信されたパケットに付加するためのヘッダに含める転送経路情報を作成して提供する経路管理サーバが提供される。
 本発明の第4の視点によれば、データ転送ネットワークの転送経路上の個々の転送ノードが、個々の転送ノードが備える通信インタフェースまたは自装置隣接する転送ノード間に張られたリンクを識別するための識別子を並べることによって構成されている転送経路情報を格納したヘッダが付加されたパケットを受信するステップと、前記パケットについて、前記転送経路情報に従ってパケット転送処理を実行するステップとを含む通信方法が提供される。本方法は、データ転送ネットワークを構成する転送ノードという、特定の機械に結びつけられている。
 本発明の第5の視点によれば、上記した転送ノード、経路管理サーバを構成するコンピュータに実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
 本発明によれば、膨大なボリュームの転送テーブルを用いずに、しかも、正味データ量を圧迫しない、パケットの経路制御が可能となる。その理由は、転送ノードがパケットヘッダに含まれる転送経路情報に従ってパケット転送処理を実行するように構成するとともに、その転送経路情報を、通信インタフェースまたはリンクの識別子を並べた構成としたことにある。
本発明の第1の実施形態に係る通信システムを示す図である。 本発明の第1の実施形態に係る通信システムの境界転送ノードの構成を示す図である。 境界転送ノードおよび内部転送ノードの記録部に記録される転送テーブルを示す図である。 境界転送ノードにて付加される経路転送ヘッダのフォーマットの例である。 本発明の第1の実施形態に係る通信システムの内部転送ノードの構成を示す図である。 本発明の第1の実施形態に係る通信システムの経路管理サーバの構成を示す図である。 各転送ノードからの近隣情報を示す図である。 図7の近隣情報から構築したネットワークトポロジの例である。 境界転送ノードがパケットを受信した際の動作を示すフローチャートである。 図9の転送処理の詳細を示すフローチャートである。 内部転送ノードがパケットを受信した際の動作を示すフローチャートである。 境界転送ノードおよび内部転送ノードが近隣情報通知を送信する動作を示すフローチャートである。 経路管理サーバが近隣情報通知を受信した際の動作を示すフローチャートである。 経路管理サーバが経路情報を要求された際の動作を示すフローチャートである。 通信ノードが、パケットを対向の通信ノードに送信した際のパケット転送の流れを示すシーケンス図である。 本発明の第2の実施形態に係る通信システムの境界転送ノードの構成を示す図である。 本発明の第2の実施形態の境界転送ノードがパケットを受信した際の動作を示すフローチャートである。 本発明の第2の実施形態の境界転送ノードまたは内部転送ノードが含む経路情報キャッシュの内容を示す図である。 本発明の第2の実施形態の通信システムにおいて、通信ノードが受信したパケットの送信元にパケット送信した際のパケット転送の流れを示すシーケンス図である。 背景技術として説明する、パケット転送を行う通信システムを示す図である。
 はじめに、本発明の概要を説明する。本発明の通信システムの転送ノードは、受信パケットに、転送経路情報が含まれるヘッダが付与されている場合、ヘッダ内の経路情報に基づき転送処理を実施する。
 ここで、前記転送経路は、転送経路上に配置された各々の転送ノードが転送先とする通信インタフェースを識別可能な識別子を転送順に並べたものとすることができる。前記識別子は、各転送ノード内で、転送先の一意性を確保するに足る長さがあればよい。
 冒頭に述べたソースルーティングと異なり、本発明の転送経路情報を構成する識別子は、例えば1バイト長などの短い情報で記述することが可能となるため、正味のデータ量に与える影響は軽微である。従って、一部の制御用パケットのみならず、データパケットなど、すべてのパケットに対して、転送経路を1hop毎に記述した情報を格納することが可能となり、高度な転送制御が可能となる。
 さらに、個々の転送ノードは、前記識別子と、転送先の通信インタフェースとの対応関係を保持すればよく、膨大な数となる冒頭に述べたルーティングテーブル等の転送テーブルを保持する必要はないため、メモリ量が削減できる。また、転送先の決定も、簡単かつ高速に行えるため、パケットの転送遅延も小さくすることが可能となる。さらに、個々の転送ノードのCPUの処理能力も低くて済む。
 なお、上記転送経路情報を含んだヘッダの付加および削除は、転送ノードのうち、外部ネットワークとの境界に配置された転送ノード(境界転送ノード)に次のように実行させればよい。外部ネットワークからパケットを受信した境界転送ノードは、当該パケットの転送経路を、別途設けられた経路管理サーバまたは当該境界転送ノード内に記録された情報から取得し、前記転送経路の情報を格納したヘッダを受信したパケットに付与する。また、境界転送ノードは、外部ネットワークにパケットを送信する場合、前記ヘッダを削除する。
[第1の実施形態]
 続いて、本発明の第1の実施形態について図面を参照して詳細に説明する。図1は、本発明の第1の実施形態に係る通信システムを示す図である。図1を参照すると、通信ノード100a、100bと、境界転送ノード300a、300bと、内部転送ノード400と、経路管理サーバ500とが示されている。
 データ転送ネットワーク600は、本発明の方式によりパケットの転送処理を行うネットワークであり、外部ネットワーク700は、IPネットワークなどのように、ネットワーク600とは異なる方式によりパケット転送処理を実施するネットワークである。ただし、ネットワーク600と同様の転送方式を使っている場合も、管理者が異なる場合は外部ネットワーク700となり得る。ここでは外部ネットワーク700は、IPネットワークとした説明を行う。外部ネットワーク700は、データ転送ネットワーク600と、境界転送ノード300a、300bを介して接続される。
 通信ノード100a、100bは、それぞれ外部ネットワーク700に属する通信ノードであり、外部ネットワーク700のパケット転送方式に沿ったパケットの送受信を行う。つまり、本実施形態においてはIPパケットの送受信を行うノードである。通信ノード100a、100bは、一般的なIPノードと同様であるので詳細な説明は省略する。
 境界転送ノード300a、300bは、データ転送ネットワーク600と外部ネットワーク700との間に配置され、通信ノード100a、100bから送信されたパケットを受信した場合には、後述の転送経路情報を含むヘッダ(以降、「経路情報ヘッダ」と呼称する。)を付与し、さらにヘッダ中の転送経路情報に基づきデータ転送ネットワーク600内の内部転送ノード400に当該パケットを転送する。
 また、境界転送ノード300a、300bは、内部転送ノード400から送られたパケットを受信した場合であってそのヘッダ中の転送経路情報からデータ転送ネットワーク600内の最後の転送経路であると判定された場合、受信したパケットから前記ヘッダを削除し、その後、外部ネットワーク700の通信ノード100a、100b側にパケットを送信する。
 なお、以下の説明では、転送経路情報は、経路管理サーバ500から取得するものとして説明するが、これに拘らず、境界転送ノード300内に保持した情報により転送経路情報を生成しても良い。
 以下、本実施形態の境界転送ノード300a(300b)、内部転送ノード400、経路監視サーバ500の順に、その構成を説明する。
 図2は、図1の境界転送ノード300a、300bの構成を示す図である。図2に示すとおり、境界転送ノード300は、通信インタフェース310と、パケット転送部320と、ヘッダ操作部330と、ローカルID決定部340と、近隣情報通知部350と、経路取得部360と、記録部370とを備えて構成される。
 通信インタフェース310は、パケットの送受信を行うためのインタフェースであり、例えばLANカードのようなNetwork Interface Card(NIC)と、それを動作させるソフトウェア(ドライバ)により実現される。ただし、前記のような物理的なインタフェースのみならず、論理的なインタフェースであっても良い。この場合、物理的なインタフェース1つを使って、複数のインタフェースを備えているように動作させることができる。
 境界転送ノード300は、上記のような1つ以上の物理インタフェース、あるいは論理インタフェースを備える。各々の通信インタフェース310は、データ転送ネットワーク内の内部転送ノード400や他の境界転送ノード300と接続される。また、一部の通信インタフェース310は、外部ネットワーク700の通信ノード100とも接続される。さらに、一部の通信インタフェース310は、経路管理サーバ500とも接続される。経路管理サーバ500は、データ転送ネットワーク600内に配置していても構わないし、経路管理サーバ500専用のネットワークを介して接続することとしても構わない。
 パケット転送部320は、受信パケットに経路情報ヘッダが付与されていた場合、前記経路情報ヘッダと、記録部370に記録された情報に基づき、パケットを転送する機能を備える。
 記録部370には、図3に示すとおり、ローカルIDと、転送先とする通信インタフェースと、当該通信インタフェース310と接続している近隣の境界転送ノード300、あるいは内部転送ノード400の識別子の対応情報を1つのエントリとした転送テーブルが記録されている。パケット転送部320は、前記ローカルIDに対応する次ノードにパケットを転送することができる。
 なお、以降では、境界転送ノード300と内部転送ノード400の総称を転送ノードとする。また、直接接続しているノード(通信ノード100、境界転送ノード300、内部転送ノード400)同士を近隣ノードと呼称する。
 図3は、境界転送ノード300および内部転送ノード400の記録装置に記録される転送テーブルを示す図である。本実施形態では、図3に示すとおり、ローカルIDとして、隣接する転送ノード間あるいは境界転送ノード300と通信ノード100a(100b)間の、物理リンクあるいは論理リンクに割当てた識別子(リンクID)を使用する。したがって、「ローカルID」のフィールドには前記リンクIDが設定される。転送先とする通信インタフェースを示す「インタフェース」のフィールドには、リンクIDが割当てられたリンクに接続した通信インタフェース310を識別する情報が設定される。また、図3の例では、近隣ノードの情報を示す「次ホップ」のフィールドに、前記リンクに接続された転送ノードの識別子が設定されている。
 なお、転送先とする通信インフェースがIPにより通信を行う通信ノード100a(100b)と接続されていた場合は、「次ホップ」のフィールドの識別子として、例えば、通信ノード100a(100b)のIPアドレスを使用できる。一方、境界転送ノード300、あるいは内部転送ノード400の場合は、一意に割当てた識別子(例えば、図3のNode_1、Node_2等)を使用する。前記転送ノードの識別子は、事前に設定することとしても良いし、経路管理サーバ500など、外部のノードから設定する方式としても構わない。さらに、前記「次ホップ」フィールドの識別子は、転送処理に必ず必要なわけではなく、省略することもできる。
 また、ローカルIDとして、通信インタフェース310を識別する情報そのものを使うこともできる。通信インタフェース310を識別する情報は、短い情報量(例えば、1~2バイト程度)で記述できる情報であることが望ましいため、通信インタフェース310を識別する情報が長い場合(例えば、通信インタフェースの名前などを使う場合)は、1バイトなど短い情報で記述できる別の識別子を別途割り振った上でローカルIDとして適用する。ただし、ここでは特に説明しない場合、ローカルIDとしてリンクIDを使用するものとして説明する。
 一般的なレイヤ3で転送処理を行うルータやL3スイッチ、また、レイヤ2での転送処理を行うL2スイッチが備えている通信インタフェースは基本的に数十個程度であるため、リンクの識別子や通信インタフェースの識別子は、1バイトで十分表現できる。実際の通信インタフェースの識別子が数バイトを要するような長い情報である場合は、1バイト、あるいは2バイトに格納可能な範囲とした識別子を別途作成し、通信インタフェースの識別子に対応づければよい。
 なお、図3の転送テーブルは、本発明を端的説明するために例示したものであり、個々のエントリに、他の情報をさらに対応づけて記録することとしても構わない。
 図4は、本実施形態で用いる経路情報ヘッダのフォーマットの1例である。図4において、’Direction’は転送方向を示す。例えば、’1’なら順方向の転送を示し、’2’なら逆方向の転送を示す。’Current Offset’は、転送時に参照すべきローカルID情報のオフセット情報が設定される(単位はバイト)。この値は、’LocalID #0’からのオフセットバイト数で示される。境界転送ノード300で経路情報ヘッダを付与する際には、’Current Offset’の値は’0’に設定される。’Header Length’は、’Route Length’以降のヘッダの長さをバイト数で示す。パケットの整形を考慮し、4バイト単位の値とする。正味のデータの終わりが4バイト単位の境界に合わない場合は、スタッフィング(パディング)を行う(0を設定したダミーの情報を後置する。)。’Route Length’は、後に続くローカルIDの列挙により示された経路情報の合計バイト数を示す。’Local ID#n’は、n hop目の境界転送ノード300、あるいは内部転送ノード400が転送先として参照すべきローカルIDが設定される。上記図4のフォーマットはあくまで一例であり、種々の変形フォーマットで情報を格納したとしても構わない。
 上記のように、転送経路の情報として、転送ノード内、あるいは、隣接する転送ノード間といった局所的な範囲において一意となるローカルIDを用いることで、経路情報ヘッダの情報量を削減できる。なお、本実施形態では、各々のローカルIDは1バイトとしたが、論理的なリンクでは1バイトでは表現できない可能性がある。この場合は、’LocalID#n’の最上位bitを、ローカルIDが1バイト表記か2バイト表記かを示すローカルID拡張フラグとして使用しても良い。すなわち、この場合、最上位ビットが0の場合は、ローカルIDを1バイトの識別子と解釈し、最上位ビットが1の場合、ローカルIDを2バイトの識別子として解釈するものとすればよい。
 パケット転送部320は、受信パケットの経路情報ヘッダの’Direction’フィールドが’1’であった場合、すなわち順方向への転送を示していた場合、経路情報ヘッダの’Current Offset’を参照し、対応するローカルIDを参照して転送先の通信インタフェース310を決定した後、’Current Offset’の値を参照したローカルIDの長さ分(例えば、1バイト、あるいは2バイト)増やし、前記決定した通信インタフェース310からパケットを送出する。一方、’Direction’が’2’である場合、すなわち逆方向への転送を示していた場合、経路情報ヘッダの’Current Offset’を参照し、対応するローカルIDの1つ手前のローカルIDを参照し、転送先とする通信インタフェース310を決定する。その後、経路情報ヘッダの’Current Offset’の値を参照したローカルIDの長さ分減らし、決定した通信インタフェース310からパケットを送出する。
 なお、本実施形態では双方向の転送を行うものとして説明するが、一方向の転送しか実施しない通信システムとしても構わない。この場合、’Direction’フィールドを常に’1’に設定するようにしても構わないし、当該フィールドをなくしても構わない。
 ヘッダ操作部330は、外部ネットワーク700からパケットを受信した場合、経路取得部360から、当該境界転送ノード300から出口となる境界転送ノード300までの1hop毎の経路情報を取得し、図4に示した経路情報ヘッダを構成し、前記パケットに付与する機能を備える。例えば、ヘッダ操作部330は、経路情報ヘッダを付与する際には、’Direction’には順方向への転送を意味する’1’を、’CurrentOffset’には’0’を、’LocalID#n’には取得した1hop毎の経路情報(ローカルID)を設定する。また、ヘッダ操作部330は、上述したルールに従い、他のフィールドにもそれぞれ適切な値を設定する。
 ヘッダ操作部330は、また、経路情報ヘッダが付与されていたパケットを外部ネットワーク700に転送する場合は、経路情報ヘッダを削除する機能を備える。
 ローカルID決定部340は、当該境界転送ノード300と近隣ノードとの間で情報交換を行って、重複しないリンクIDを決定する機能を備える。例えば、以下の方法で隣接するノードとのリンクIDの重複設定を回避することができる。
 まず、転送ノードは、自身が既に割当てたリンクID以外のリンクIDを設定したパケットを近隣ノードに送信することでリンクID候補を提案する。リンクIDを提案された近隣ノードは、自ノード内に重複したリンクIDがないかどうか確認し、重複するリンクIDがない場合は、提案されたリンクIDと自ノードの識別情報を設定した応答パケットを、提案元となる転送ノードに送信する。一方、近隣ノードにおいて重複するリンクIDがあった場合は、重複することを意味する情報と自ノードの識別子を設定した応答パケットを送信する。この処理を、重複するリンクIDがなくなるまで繰り返す。
 このようにして決定されたリンクIDや、近隣ノードの情報は、記録部370に転送テーブルとして記録される。
 以上、リンクIDの決定方法の例を示したが、他の方法でリンクIDを決定することとしても構わない。例えば、経路管理サーバ500など、他のノードが決定し、各転送ノードに通知することとしても良い。
 なお、ローカルIDとして通信インタフェースの識別子を使う場合において、前記した逆方向の転送が不要である場合には、上記近隣ノードとのネゴシエーションを省略することができる。一方、逆方向への転送が必要である場合には、ローカルIDとしてインタフェースの識別子を使う場合においても、近隣ノードとネゴシエーションを行うことにより、近隣の転送ノードのどの通信インタフェースが、自身の通信インタフェースに接続されているかの情報を取得することができ、上記したリンクIDを用いる場合と同様に、Directionによる転送方向によるインタフェースの選択が可能となる。
 近隣情報通知部350は、ローカルID決定部340によりローカルIDとして決定したリンクIDと、リンクに接続された近隣ノードの識別子と、自らの識別子と、を格納した近隣情報を経路管理サーバ500に送信する機能を備える。リンクに接続されているのが外部ネットワーク700の通信ノード100a、100bであった場合は、外部ネットワークのノードと判定できる情報も前記情報に追加する。また、経路管理サーバ500での経路計算のため、前記近隣情報には、各リンクの帯域、信頼性、混雑状況といった情報や、近隣ノードの故障情報などを含めることとしても良い。経路管理サーバ500に前記近隣情報を送信する契機は、ローカルIDの決定処理が完了したタイミングでも良いし、所定の時間間隔で送信するものとしてもよい。また、リンクの情報や、近隣ノードの故障情報も含めて送信する場合は、これらの情報に変化が生じた契機で送信しても良い。
 経路取得部360は、外部ネットワーク700の通信ノード100a、100bからパケットを受信した際に、当該受信パケットの情報と、当該境界転送ノード300の識別子を格納した経路要求信号を経路管理サーバ500に送信し、当該パケットの転送経路を取得する機能を備える。前記受信パケットの情報とは、転送経路決定に影響を与えうる情報であり、最も単純な場合は、宛先アドレスのみである。しかし、より緻密な経路制御を実施する場合には、宛先アドレスに加え、送信元アドレス、当該パケットヘッダ以降に格納されたプロトコル情報、TCP(Transmission Control Protocol)あるいはUDP(User Datagram Protocol)使用時の宛先ポート番号、送信元ポート番号といった情報の一部、あるいはすべてを含めることができる。さらに、他の情報を含むこととしてもかまわない。
 前記経路要求信号を送った結果、経路管理サーバ500から経路応答信号が返される。前記経路応答信号に含まれる転送経路情報には、当該境界転送ノード300を起点とした転送経路に沿って、ローカルIDを1hop毎に列挙した情報が格納される。
 なお、宛先アドレスなど、前記転送経路に影響を与えうる情報と、転送経路を示すローカルID群との対応情報は、当該境界転送ノード300に事前に設定し、予め経路管理サーバから受信しておくこともできる。この場合は、経路取得部360は、経路管理サーバ500ではなく、内部に設定された情報から転送経路情報を取得する。
 また、上記の例では、当該境界転送ノード300が最初に転送先とする通信インタフェースを識別可能なローカルIDを起点としたが、前記パケットを受信した通信インタフェース310を識別可能なローカルIDを、起点としても構わない。
 記録部370は、図3に示す転送テーブルを保持し、パケット転送部320や、ローカルID決定部340や、近隣情報通知部350に、参照させる。
 内部転送ノード400は、データ転送ネットワーク600内に配置され、近隣ノードから送信されたパケットを受信した場合には、パケット中の経路情報ヘッダの情報に基づきデータ転送ネットワーク600内の近隣ノードに当該パケットを転送する機能を備える。
 図5は、図1の内部転送ノード400の構成を示す図である。内部転送ノード400は、図5に示すように、通信インタフェース410と、パケット転送部420と、ローカルID決定部430と、近隣情報通知部440と、記録部450とを備えて構成されている。
 通信インタフェース410、パケット転送部420、ローカルID決定部430、近隣情報通知部440および記録部450は、それぞれ、境界転送ノード300の、通信インタフェース310、パケット転送部320、ローカルID決定部340、近隣情報通知部350、記録部370と同等であるため、ここでは詳細な説明を省略する。
 つまり内部転送ノード400は、境界転送ノード300から、ヘッダ操作部330と、経路取得部360を差し引いたものとみなすことができる。反対に、境界転送ノード300は、内部転送ノード400に、ヘッダ操作部330と、経路取得部360を追加した転送ノードであるということができる。
 経路管理サーバ500は、境界転送ノード300と内部転送ノード400から通知された近隣情報を収集し、データ転送ネットワーク600内の境界転送ノード300および内部転送ノード400の接続関係を記述したネットワークトポロジ情報を構築する。このネットワークトポロジ情報には、境界転送ノード300に接続する通信ノード100a、100bとの接続情報も含まれる。前記通知された経路情報に、各転送ノード間のリンクや転送ノードの状態を示す情報(混雑状況、故障状況など)が含まれていた場合は、それも前記接続情報に対応づけて管理する。そして、境界転送ノード300から、転送経路情報を要求された場合には、経路要求に含まれる情報と、内部に構築したネットワークトポロジ情報を使って適切な転送経路を求める計算を実施し、経路要求を行った境界転送ノード300を起点として、外部ネットワーク700への出口となる境界転送ノード300までの転送経路を、1hop毎のローカルID(リンクID)を順に列挙した情報として応答する機能を備える。
 図6は、図1の経路管理サーバ500の構成を示す図である。経路管理サーバ500は図6に示すようにさらに、通信インタフェース510と、経路情報収集部520と、経路要求処理部530と、経路計算部531と、経路情報記録部540とを備えて構成されている。
 通信インタフェース510は、パケットの送受信を行うためのインタフェースである。前述のように、例えばLANカードのようなNICと、それを動作させるソフトウェア(ドライバ)により実現できる。
 経路情報収集部520は、境界転送ノード300および内部転送ノード400から送られた近隣情報を受信すると、近隣情報に格納された、前記近隣情報を送信したノードの識別子、ローカルID(リンクID)、近隣ノード識別子を使って、経路情報記録部540内にデータ転送ネットワーク600内のネットワークトポロジ情報を構築する。前記近隣情報に、リンクの帯域、信頼性、混雑状況や、近隣ノードの故障情報といった付帯情報が含まれていた場合は、前記ネットワークトポロジ情報に前記付帯情報を関連づけて記録する。これらの情報は、例えば、後述する経路計算のときにリンクのコストとして使用することができる。
 図7は、各転送ノードから受信した近隣情報の例である。図8は、図7の近隣情報から構築したネットワークトポロジの例である。図8の例では、簡単のため、付帯情報は省略している。また、外部ネットワークはIPネットワークであることを想定している。
 図7中の’senderID’は近隣情報を送信した転送ノードの識別子を示している。図7中の’LinkID’は、前記転送ノードが接続するリンクに割当てたリンクIDを示している。図7中の’neighborID’は前記リンクに接続している近隣ノードの識別子を示している。外部ネットワークはIPネットワークとの想定なので、通信ノード100の識別子としてIPアドレスを使用する。また、上述のように隣接する転送ノード間でネゴシエーションが行われているため、リンクIDは、一の転送ノードに重複して設定されないが、隣接しない転送ノード同士が同一のリンクIDを用いることは許容される。例えば、LinkID=1のリンクは、ID=1のノードと、ID=10のノード間およびID=5のノードと、ID=6のノード間に用いられているが、それぞれの転送ノード内で一意にリンクを識別することが可能である。つまり、リンクIDの長さは、一の転送ノード内で一意性を確保するに足る長さがあればよい。
 経路情報収集部520は、例えば、図7の近隣情報が得られている場合、図8に示すようなネットワークトポロジを構築し、経路情報記録部540に記録する。
 図7の近隣情報と、それに基づいて構築された図8のネットワークトポロジ情報にはリンクIDを使ったが、インタフェース識別子など、他の情報をローカルIDとした場合でも、同様にネットワークトポロジ情報の構築は可能である。
 経路要求処理部530は、境界転送ノード300から送信された経路要求信号を受信し、そこに含まれる情報と共に、経路計算要求を経路計算部531に通知する。
 経路要求処理部530はまた、経路計算部531から、転送経路情報(1hop毎のリンクIDを転送経路順に列挙した情報)を取得した際に、当該転送経路情報を格納した経路応答信号を前記経路要求信号の送信元となる境界転送ノード300に送信する。
 経路計算部531は、経路要求処理部530から経路計算要求を通知された場合、共に入力された、経路要求元の境界転送ノード300の識別子と、宛先アドレスをそれぞれ始点、終点ポイントとして、経路情報記録部540に記録された図8のようなネットワークトポロジ情報を使って、経路の計算を行う。経路計算には、Dijkstra法と呼ばれる最短経路を求めるアルゴリズムを適用することができる。ただし、他のアルゴリズムを適用することとしても構わない。
 経路計算要求にIPパケットの送信元アドレスを含む場合は、始点として送信元アドレス(即ち境界転送ノード300が受信したパケットの送信元となる通信ノード100aまたは100bの識別子)を使っても良い。また、前記したように経路計算を行う上で、TCP、あるいはUDPの宛先/送信元ポート番号など、他の情報を使って経路計算を行っても良い。さらには、リンクに付帯する情報(帯域、混雑具合など)や、故障した境界/内部転送ノードの識別子といった情報を経路計算に使用しても良い。
 経路情報記録部540は、経路情報収集部520により、図8に示すようなネットワークトポロジ情報が記録される。前記ネットワークトポロジ情報は、経路計算のため経路計算部531から参照される。
 以上本発明の実施の形態で説明した、通信インタフェース310、410、510は、前記したとおり、例えばLANカードのようなNICと、それを動作させるソフトウェア(ドライバ)により実現できる。
 また、記録部370、記録部450、経路情報記録部540は、半導体メモリ、ハードディスクドライブなど情報を記録可能な装置で実現することができる。
 その他の機能ブロックについては、それぞれの機器に搭載された1つあるいは複数のCPUにて実行されるコンピュータプログラム(ソフトウェア)あるいはハードウェアで実現できる。機能ブロックが行うべき処理の一部をソフトウェアで実施し、それ以外をハードウェアで実施することとしても良い。
 続いて、本実施形態の動作について図面を参照して詳細に説明する。はじめに、境界転送ノード300の動作を説明する。
 図9は、境界転送ノード300が、データ転送ネットワーク600あるいは外部ネットワーク700からパケットを受信した場合の処理を示している。
 まず、パケット転送部320は、通信インタフェース310を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする(ステップS100)。
 経路情報ヘッダが付与されていた場合は’Y’に進み、その経路情報ヘッダに従って転送処理が行われる(ステップS103へ)。一方、経路情報ヘッダが付与されていなかった場合は’N’に進み、経路取得部360から、経路要求信号を経路管理サーバ500に送信することで転送経路情報を取得する経路取得処理が行われる(ステップS101)。
 転送経路情報の取得が完了すると、ヘッダ操作部330は、前記取得した転送経路情報の転送経路の順に従って、図4の経路情報ヘッダのローカルIDフィールド(’LocalID#n’)に、ローカルIDを設定する。また、ヘッダ操作部330は、’Direction’を’1’に設定し、’Current Offset’を’0’に設定する。ヘッダ操作部330は、その他のフィールドも適切な値に設定した上で、経路情報ヘッダを、前記受信したパケットの先頭に付加する(ステップS102)。
 パケット転送部320は、前記した経路情報ヘッダに従って転送処理を実施する(ステップS103)。
 図10は、図9のステップS103の転送処理の詳細を表したフローチャートである。図10を参照すると、まず、パケット転送部320は、経路情報ヘッダの’Direction’フィールドをチェックし順方向への転送をすべきか、逆方向の転送をすべきかを判定する(ステップS200)。
 ’Direction’フィールドの値が順方向の転送を示す(’1’)場合は、’Y’に進み、当該パケットの転送先が外部ネットワーク700であるかどうかが判定される(ステップS201)。順方向の転送において、外部ネットワーク700への転送かどうかの判定は、’Current Offset’と’Route Length’を比較することにより判定できる。判定方法は他にも、ローカルIDを外部ネットワーク700への転送かどうかを区別可能な値とすることとしても良いし、経路情報ヘッダ中の最後のローカルIDの後に、終端を意味する情報を格納しても良い。さらに、他の方法としても構わない。
 外部ネットワーク700への転送でないと判定された場合は、’N’に進み、経路情報ヘッダの’Current Offset’に1hop分のバイト数が加算される(ステップS202)。1hop分のバイト数とは、現在参照している’LocalID#n’フィールドのバイト数となる。ここで、’Current Offset’の値を加算する前に参照先となっていたローカルIDを保持しておく。
 そして、パケット転送部320は、前記保持しておいたローカルIDを用いて、順方向へのパケットの転送処理を行う(ステップS206)。具体的には、記録部370に記録された転送テーブルの情報を使ってローカルIDから、転送先とすべき通信インタフェース310を決定し、当該通信インタフェース310からパケットを転送する。
 一方、ステップS200にて’Direction’フィールドの値が逆方向の転送を示す(’2’)場合は、’N’に進み、当該パケットの転送先が外部ネットワーク700であるかどうかが判定される(ステップS203)。逆方向の転送における、外部ネットワーク700への転送かどうかの判定は、’Current Offset’の値が’0’かどうかにより判定することができる(’0’のとき外部ネットワークへの転送)。これは、パケットをはじめに送信する通信ノード100a、100bと、それを受信する境界転送ノード300間のリンクのリンクIDを、1番最初のローカルIDとして使わない場合の判定方法となる。前記リンクIDを1番最初のローカルIDとして使う場合は、現在の’Currrent Offset’を、1hop分減算した値が’0’の場合、外部ネットワークへの転送と判定できる。逆方向への転送時の判定方法は他にも、ローカルIDを、外部ネットワーク700への転送かどうかを区別可能な値とすることとしても良いし、経路情報ヘッダ中の最初のローカルIDの前に、開始を意味する情報を格納しても良い。さらに、他の方法としても構わない。
 外部ネットワーク700への転送でないと判定された場合は、’N’に進み、経路情報ヘッダの’Current Offset’の値が1hop分減算される(ステップS204)。ここで、減算後の’Current Offset’で参照先となるローカルIDを保持しておく。
 そして、パケット転送部320は、前記保持しておいたローカルIDを用いて、逆方向へのパケットの転送処理を行う(ステップS206)。具体的には、記録部370に記録された転送テーブルの情報を使ってローカルIDから、転送先とすべき通信インタフェース310を決定し、当該通信インタフェース310からパケットを転送する。
 上記ステップS201またはS203において、外部ネットワーク700への転送と判定された場合は、それぞれ’Y’に進み、ヘッダ操作部330により、経路情報ヘッダの除去処理が行われる(ステップS205)。ここで、経路情報ヘッダを除去する前に、転送先となるローカルIDを保持しておく。
 そして、パケット転送部320は、前記保持しておいたローカルIDを用いて、外部ネットワーク700へのパケットの転送処理を行う(ステップS206)。具体的には、記録部370に記録された転送テーブルの情報を使ってローカルIDから、転送先とすべき通信インタフェース310を決定し、当該通信インタフェース310からパケットを転送する。
 なお、’Direction’フィールドを使わず、常に順方向に転送する場合は、ステップS200の転送方向の判定は不要であり、ステップS201の外部ネットワークへの転送であるか否かの判定を行うようにすればよい。
 続いて、内部転送ノード400の動作を説明する。
 図11は、内部転送ノード400が、データ転送ネットワーク600の境界転送ノード300あるいは内部転送ノード400からパケットを受信した場合の処理を示している。
 図11を参照すると、まず、パケット転送部420は、通信インタフェース410を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする(ステップS300)。
 経路情報ヘッダが付与されていた場合は’Y’に進み、経路情報ヘッダの’Direction’フィールドをチェックし、順方向への転送をすべきか、逆方向の転送をすべきかを判定する(ステップS302)。一方、経路情報ヘッダが付与されていなかった場合は’N’に進み、受信したパケットが破棄処理が行われる(ステップS301)。
 ステップS302でチェックした’Direction’フィールドの値が順方向の転送を示す(’1’)場合は、’Y’に進み、経路情報ヘッダの’Current Offset’に1hop分のバイト数が加算される(ステップS303)。ここで、’Current Offset’の値を加算する前に参照先となっていたローカルIDを保持しておく。
 一方、ステップS302でチェックした’Direction’フィールドの値が逆方向の転送を示す(’2’)場合は、’N’に進み、経路情報ヘッダの’Current Offset’に1hop分のバイト数が減算される(ステップS304)。ここで、ここで、減算後の’Current Offset’で参照先となるローカルIDを保持しておく。
 最後に、上記ステップS303あるいはステップS304で保持されたローカルIDに基づき、パケットの転送処理が行われる。具体的には、記録部450に記録された転送テーブルの情報を使ってローカルIDから、転送先とすべき通信インタフェース410を決定し、当該通信インタフェース410からパケットを転送する(ステップS305)。
なお、’Direction’フィールドを使わず、常に順方向の転送とする場合は、ステップS302の転送方向の判定は不要であり、常にステップS303の’Current Offset’加算処理が行われる。
 続いて、境界転送ノード300および内部転送ノード400によるローカルIDの決定およびその結果を経路管理サーバ500に近隣情報として通知する処理を説明する。
 図12は、境界転送ノード300および内部転送ノード400が近隣情報通知を送信する動作を示すフローチャートである。
 図12を参照すると、まず、ローカルID決定部340(430)が、ローカルIDを決定する(ステップS400)。ローカルIDとしてリンクIDを使う場合は、近隣ノードとリンクIDのネゴシエーションを実施することでリンクIDを決定する。なお、ローカルIDとして、通信インタフェースの識別子を使う場合は、当該境界転送ノード300あるいは内部転送ノード400は、自らが備える通信インタフェース310(410)に割当てた識別子をローカルIDとする。
 ここで、前記リンクIDは、当該境界転送ノード300あるいは内部転送ノード400が使用可能なすべての物理的あるいは論理的なリンクに対して決定される。同じように、通信インタフェースの識別子は、全ての物理的あるいは論理的な通信インタフェースに対して決定される。ただし、管理上の理由などにより、一部のリンクや、通信インタフェースを対象外としても構わない。
 次に、ローカルID決定部340(430)は、前記決定したローカルIDと通信インタフェース情報(当該通信インタフェースをパケット転送先とするのに必要な情報)とを対応づけて、記録部370(450)中の転送テーブル(図3参照)に記録する(ステップS401)。転送テーブルには、各リンクの先に接続された近隣ノードの識別子も対応づけて記録する。さらに、各リンクに関連する情報や、近隣ノードの故障情報なども付帯情報として記録しても良い。
 前記転送テーブルへの記録が完了すると、近隣情報通知部350(440)が、記録部370(450)に記録された転送テーブルの情報から、ローカルIDと、近隣ノードの識別子を設定した近隣情報(図7参照)を構成し、これを経路管理サーバ500へ送信する(ステップS402)。近隣情報には、各リンクに関連する情報や、近隣ノードの故障情報などといった付帯情報も格納することとしても良い。
 続いて、経路管理サーバ500の動作を説明する。
 図13は、上記近隣情報を受信した経路管理サーバ500の処理を表したフローチャートである。図13を参照すると、まず、経路情報収集部520にて境界転送ノード300あるいは内部転送ノード400から送られた近隣情報を受信すると(ステップS500)、経路管理サーバ500は、受信した近隣情報から、ローカルIDや近隣ノードの識別子といった情報を取得し、取得した情報を用いてネットワークトポロジ情報を構築し、記録部540に記録する(ステップS501)。
 図14は、境界転送ノード300から経路情報を要求された経路管理サーバ500の処理を表したフローチャートである。図14を参照すると、まず、境界転送ノード300から経路要求信号を受信すると、経路要求処理部530は、経路要求信号に含まれる情報を経路計算部531に通知する(ステップS600)。
 次に、経路計算部531は、ステップS600で通知された経路要求信号に含まれていた情報と、経路情報記録部540に記録されたネットワークトポロジ情報とにより、最適な転送経路の計算を行う(ステップS601)。転送経路の計算が完了すると、経路計算部531は、決定された経路の転送順に1hop毎のローカルIDを読み出し、経路要求処理部530に通知する。
 前記転送経路の計算結果を受け取った経路要求処理部530は、通知された転送経路情報(ローカルIDの並び)を、経路情報応答信号に設定して、経路要求信号の送信元である境界転送ノード300に送信する(ステップS602)。
 最後に、図15のシーケンス図を参照して、IPノードである通信ノード100aが境界転送ノード300aにパケットを送信し、それが順次転送処理され、最終的にIPノードである通信ノード100bに届くまでの一連の流れを説明する。
 ここでは、例として、各ノードの接続状況が図8に示したネットワークトポロジのようになっているものとして説明する。境界転送ノード300aは、図8のID=1のノードに相当する。境界転送ノード300bは、図8のID=8のノードに相当する。IPパケットの送信元アドレスは、192.168.0.50であり、宛先アドレスは、192.168.0.20であるものとする。
 通信ノード100aから送信されたIPパケットが境界転送ノード300aに届くと(ステップS700)、境界転送ノード300aは、図9に示すフローチャートに従った処理を実行する。ここでは、IPパケットには経路情報ヘッダが付与されていないため、図9のステップS101において経路情報要求信号が経路管理サーバ500に送信される(ステップS701)。
 前記経路情報要求信号を受信した経路管理サーバ500は、図14のフローチャートに従い、経路情報を計算し、転送経路を決定した後、経路情報応答信号を境界転送ノード300aに送信する(ステップS702)。
 リンクの帯域や、混雑具合は考慮せず、最短パスを計算する場合、以下のとおり、転送経路が計算される。図8のネットワークトポロジの最短パスは、ID=1のノード -> ID=10のノード -> ID=8のノード -> 192.168.0.20のノード(パケットの宛先となる外部ネットワークのIPノード)が転送経路として選択される。従って、前記経路情報応答信号には、図8のネットワークトポロジのパス上のリンクIDである、1、2、0の値がローカルIDとして上記順番で格納される。
 ここで、ID=192.168.0.50のノード(外部ネットワーク700のIPノード)からID=8のノード間のリンクID(=0)を経路情報応答に含めることとしても構わない。この場合、前記経路情報応答信号に含めるローカルIDの格納順序は、0、1、2、0となる。また逆に、外部ネットワーク(通信ノード100b)へのリンクID(=0)を経路情報応答に含めないこととしても構わない。この場合、ローカルIDの格納順序は。1、2となる。
 さらに、外部ネットワークのIPノードのIDとしてIPアドレスを使ったが、IPアドレスの上位から任意のbit長を抜き出したネットワークアドレスとしても良いし、MAC(Media Access Control)アドレスなどレイヤ2の情報や、それ以外の情報を用いても構わない。
 境界転送ノード300は前記経路情報応答信号を受信すると(ステップS703)、図9のステップS102以降の処理にしたがい、ステップS700で受信したIPパケットに経路情報ヘッダを付与し、その後、図9のステップS103において、付与した経路情報ヘッダに従い、転送すべきローカルID(=1)に対応した通信インタフェースからパケットを送出する(ステップS704)。この結果、ID=10の内部転送ノード400にパケットが転送される。
 内部転送ノード400は、経路情報ヘッダが付与されたパケットを受信すると(ステップS705)、図11に示すフローチャートに従い転送処理を行う(ステップS706)。ここでは、転送経路情報に従って、転送すべきローカルID(=2)に対応した通信インタフェースからパケットが送出され、ID=8の境界転送ノード300bにパケットが転送される。
 境界転送ノード300bは、経路情報ヘッダが付与されたパケットを受信すると(ステップS707)、図9に示すフローチャートにそって処理を実施する。さらに図9のステップS103では、さらに図10に示すフローチャートに示した転送処理が実施される。ここでは、図10のステップS201で外部ネットワークへの転送と判定されるため、境界転送ノード300bは、前記受信したパケットから経路情報ヘッダが除去した後、除去前の経路情報ヘッダの情報に従い、転送すべきローカルID(=0)に対応した通信インタフェースからパケットを送出する(ステップS708)。この結果、最終的に通信ノード100bへとIPパケットが転送される。
 以上のとおり、本実施形態によれば、IPアドレス等のグローバルに一意性が確保される経路情報ではなく、転送ノード内、あるいは、隣接する転送ノード間といった局所的な範囲での一意性だけが保証されたローカルIDを使って転送先を指定するよう構成している。このため、1バイトあるいは2バイト程度の情報量に1hop分の転送経路が格納可能となり、当該転送経路の情報を経路情報ヘッダに格納してパケットに付与した場合でも、付与するヘッダによるオーバヘッドを極めて小さいサイズに抑制することが可能になる。この結果、用途を限らずすべてのパケットに経路情報ヘッダを格納することが可能となる。
 また本実施形態では、転送ノードに備える転送テーブルのエントリ数を、各転送ノードが備える通信インタフェースの数程度とすることが可能になる。また、転送テーブルの格納・更新・利用のため、転送ノードに必要とされるメモリのサイズやCPUの処理能力も抑制可能となり、転送ノードを安価とすることができる。
 これらの結果として、本実施形態によれば、転送経路を1hop毎に厳密に指定した場合においても正味の情報を効率よく、さらに高速に転送可能となる。
[第2の実施形態]
 続いて、本発明の第1の実施形態に変更を加えた本発明の第2の実施形態について図面を参照して詳細に説明する。
 本発明の第2の実施形態の全体の構成は、第1の実施形態とほぼ同じ構成、機能であるので、以下、その相違点を中心に説明する。
 図16は、本発明の第2の実施形態の境界転送ノード301の構成を表した図である。図16を参照すると、本実施形態の境界転送ノード301は、第1の実施形態の境界転送ノード300の構成に、キャッシュ管理部380を追加した構成となっている。また、経路取得部360Aの動作や、記録部370Aの記録する情報も第1の実施形態と異なっている。
 経路取得部360Aは、本発明の第1の実施形態の経路取得部360とほぼ同じ機能を備えるが、経路管理サーバ500に転送経路情報の要求を行う前に、後述する経路情報キャッシュを検索する機能をさらに備える。経路情報キャッシュを検索した結果、受信パケットに対応する経路情報キャッシュが見つかった場合、経路管理サーバ500に経路情報の要求は行なわず、見つかった経路情報キャッシュから転送経路情報を取得する。また、経路情報キャッシュが見つからなかった場合、経路取得手段360Aは、経路情報キャッシュとして記録するようキャッシュ管理部380に経路管理サーバ500から取得した転送経路情報と受信パケットの情報とを送信する。
 キャッシュ管理部380は、経路取得部360Aが経路管理サーバ500から転送経路情報を取得した際、また、ヘッダ操作部330が経路情報ヘッダを削除する際、受信パケットの情報と、経路情報ヘッダに設定された情報とを対応づけて経路情報キャッシュとして記録部370Aに記録する機能を備える。
 本実施形態では、前記受信パケットの情報として、宛先アドレスおよび送信元アドレスを記録するものとする。ただし、宛先アドレスおよび送信元アドレスに加え、他の情報を使っても良い。
 経路情報キャッシュは、一定の時間の経過や、一定量の経路情報キャッシュが蓄積されたことを契機として古い経路情報キャッシュから削除することとしても良い。また、管理上の理由などで、任意の経路情報キャッシュを削除しても良い。
 記録部370Aは、第1の実施形態における記録部370が記録する情報に加えて、さらに、経路情報キャッシュを記録する。経路情報キャッシュは、キャッシュ管理部380により、追加・更新・削除といった管理がなされる。
 続いて、上記第2の実施形態の境界転送ノード301の動作を説明する。
 図17は、境界転送ノード301が、データ転送ネットワーク600あるいは外部ネットワーク700からパケットを受信した場合の処理を示している。
 図17を参照すると、まず、パケット転送部320は、通信インタフェース310を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする(ステップS800)。
 経路情報ヘッダが付与されていた場合は’Y’に進み、その経路情報ヘッダに従って転送処理が行われる(ステップS809へ)。一方、経路情報ヘッダが付与されていなかった場合は’N’に進み、経路取得部360Aが、順方向の経路情報キャッシュの検索処理が行われる(ステップS801)。前記順方向の経路情報キャッシュの検索は、受信パケットの宛先アドレスと、経路情報キャッシュ中の宛先アドレスとを比較することで行うことができる。
 前記順方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つかった場合(ステップS802の’Y’)、当該経路情報キャッシュを用いた経路情報ヘッダの付加処理が行われる(ステップS808へ)。
 一方、前記順方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つからなかった場合(ステップS802の’N’)、経路取得部360Aは、逆方向の経路情報キャッシュの検索処理を行う(ステップS804)。前記逆方向の経路情報キャッシュの検索は、受信パケットの宛先アドレスと、経路情報キャッシュ中の送信元アドレスとを比較することで行うことができる。
 前記逆方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つかった場合(ステップS805の’Y’)、当該経路情報キャッシュを用いた経路情報ヘッダの付加処理が行われる(ステップS808へ)。
 一方、前記逆方向の経路情報キャッシュの検索の結果、経路情報キャッシュが見つからなかった場合(ステップS805の’N’)、経路取得部360Aは、経路管理サーバ500に経路要求信号を送信し転送経路情報を取得する経路取得処理を行なう(ステップS806)。
 転送経路情報の取得が完了すると、キャッシュ管理部380が、受信パケットに含まれる宛先アドレスおよび送信元アドレスと、ステップS806で取得した転送経路情報とを対応づけて経路情報キャッシュとして記録部370Aに記録する(ステップS807)。
 また、ヘッダ操作部330は、経路情報キャッシュまたは前記取得した転送経路情報の転送経路の順に従って、経路情報ヘッダを構成し、前記受信したパケットの先頭に付加する(ステップS808)。経路情報ヘッダの各フィールドに設定する値は、次のようになる。
 経路管理サーバ500から転送経路情報を取得した場合は、図4に示す経路情報ヘッダのローカルIDフィールド(’LocalID#n’)に、転送順に従って経路情報を設定する。また、’Direction’を’1’に設定し、’Current Offset’を’0’に設定する。
 また、ステップS801の順方向キャッシュ検索において経路情報キャッシュから経路情報を取得した場合には、’Direction’を’1’に、’Current Offset’を’0’に設定する。’LocalID#n’には、経路情報キャッシュに記録された値を、順番を維持したまま設定する。
 一方、ステップS804の逆方向キャッシュ検索において経路情報キャッシュから経路情報を取得した場合には、’Direction’を’2’に、’Current Offset’を経路情報キャッシュに記録された値に設定する。’LocalID#n’には、経路情報キャッシュに記録された値を、順番を維持したまま設定する。
 なお、ステップS804の逆方向キャッシュ検索において経路情報キャッシュから経路情報を取得した場合には、経路情報キャッシュに記録された値を、逆の順番で’LocalID#n’に設定することもできる。この場合は、’Direction’を’1’に、’Current Offset’を最初の転送先となるローカルID#nを示すオフセットバイト数に設定する。
 パケット転送部320は、上記のように構成した経路情報ヘッダに従って転送処理を実施する(ステップS809)。ステップS809の処理の詳細は、図10に示した第1の実施形態における境界転送ノード300の転送処理とほぼ同様であるので省略する。ただし、本実施形態においては、図10のステップS205において、経路情報ヘッダが削除される際にキャッシュ管理部380が、受信パケットの情報と、経路情報ヘッダに設定された情報とを対応づけて経路情報キャッシュとして記録部370Aに記録する。
 続いて、第2の実施形態における通信ノード100aおよび通信ノード100b間のパケット転送処理の流れを説明する。
 最初(往路側)のパケットの転送手順は、第1の実施形態とほぼ同様であり、図15に示したシーケンス図のとおりパケットが転送される。但し、図15のステップS703と、ステップS707において、それぞれ、境界転送ノード301a、境界転送ノード301bの記録部370に、図18(a)、(b)に示す経路情報キャッシュが作成される。
 図18の経路情報キャッシュ中の経路情報フィールドに記録された’Direction’、’CurrentOffset’、’RouteLength’には、経路情報ヘッダの同名のフィールドに設定された値が記録される。’LocalIDs’には、経路情報ヘッダの’LocalID#n’フィールドの値が、順番を維持したまま記録される。
 経路管理サーバ500から経路情報を取得した場合は、’Direction’に’0’を、’CurrentOffset’に’0’を記録する。また’RouteLength’、’LocalIDs’には、それぞれ取得した転送経路数分のローカルIDの総バイト長、転送経路数分のローカルIDが設定される。なお、カッコの中の値は、図15のシーケンス図に従ってパケット転送を処理した場合に記録される値を示している。
 図18の経路情報キャッシュには、作成時刻情報も含めているが、これは必ずしも必要ではない。なお、作成時刻情報のHH:MM:SSはそれぞれ、時:分:秒を示す。
 続いて、図19のシーケンス図を参照して、通信ノード100aにより送信されたパケットが宛先の通信ノード100bに転送された後、今度は、前記通信ノード100bが、通信ノード100aにパケットを送信し、それが順次転送処理され、最終的にIPノードである通信ノード100aに届くまでの一連の流れを説明する。
 以下においても、各ノードの接続状況が図8に示したネットワークトポロジのようになっているものとして説明する。境界転送ノード301aは、図8のID=1のノードに相当する。境界転送ノード301bは、図8のID=8のノードに相当する。IPパケットの送信元アドレスは、192.168.0.20であり、宛先アドレスは、192.168.0.50であるものとする。
 通信ノード100bからIPパケットが送信され(ステップS900)、境界転送ノード300bに届くと、境界転送ノード301bは、図17に示すフローチャートに従った処理を実行する(ステップS901)。まず、IPパケットには経路情報ヘッダが付与されていないため、図17のステップS801において順方向の経路情報キャッシュ検索が実行される。すなわち、図18(b)に示す経路情報キャッシュの宛先アドレスフィールドを走査して、宛先アドレス192.168.0.50を持つエントリを検索する処理が行われる。
 図18(b)に示す経路情報キャッシュには、宛先アドレスフィールドに、宛先アドレス192.168.0.50を持つエントリはないため、今度は、図17のステップS804において逆方向の経路情報キャッシュ検索が実行される。すなわち、図18(b)に示す経路情報キャッシュの送信元アドレスフィールドを走査して、宛先アドレス192.168.0.50を持つエントリを検索する処理が行われる。
 図18(b)に示す経路情報キャッシュの例では、送信元アドレスフィールドに、宛先アドレス192.168.0.50を持つエントリがある。経路取得部360Aは、前記検索により見つかったエントリの経路情報を読み出す。
 図18(b)に示す経路情報キャッシュから読み出される経路情報は、以下となる。
’Direction’     = 1
’CurrentOffset’ = 2
’RouteLength’   = 3
’LocalIDs’  ={1、2、0}
 ここでは、前記読み出された経路情報から経路情報ヘッダを構成する際に、転送経路’LocalIDs’の順番を維持するものとする。この場合、経路情報ヘッダの各フィールドは、以下のように設定される。
’Direction’     = 2
’CurrentOffset’ = 2
’HeaderLength’  = 4
’RouteLength’   = 3
’LocalID#0’     = 1
’LocalID#1’     = 2
’LocalID#2’     = 0
 このように、’Direction’が’2’であるため、逆方向の転送が実施される。
 また、図15のシーケンス図に示す順方向の転送処理において、経路情報ヘッダに格納するローカルIDの情報に、外部ネットワークへの転送に対応する情報を含まない構成も考えられる。この場合、経路情報キャッシュには当該情報が含まれず、その結果、構成される経路情報ヘッダの各フィールドは以下のとおりとなる。
’Direction’     = 2
’CurrentOffset’ = 2
’HeaderLength’  = 4
’RouteLength’   = 3
’LocalID#0’     = 1
’LocalID#1’     = 2
 経路情報ヘッダが構成された後、受信パケットに経路情報ヘッダが付与され、転送処理が実行される(ステップS902)。この結果、ローカルID(=2)に対応した通信インタフェースからパケットが送出され、ID=10の内部転送ノード400にパケットが転送される。
 内部転送ノード400は、経路情報ヘッダが付与されたパケットを受信すると、図11に示すフローチャートに従い、経路情報ヘッダが付与されており、かつ逆方向の転送を行うパケットとして転送処理を実行する(ステップS903)。ここでは、転送経路情報に従って、転送すべきローカルID(=1)に対応した通信インタフェースからパケットが送出され、ID=1の境界転送ノード301aにパケットが転送される(ステップS904)。
 境界転送ノード301aは、経路情報ヘッダが付与されたパケットを受信すると、図17に示すフローチャートに従い、経路情報ヘッダが付与されており、かつ逆方向の転送を行うパケットとして転送処理を実行する(ステップS905)。
さらに経路情報ヘッダの’CurrentOffset’が’0’であることから、図10のステップS203において外部ネットワークへの転送と判定され、ステップS205において経路情報ヘッダが削除される。このとき、境界転送ノード301aの経路情報キャッシュには既に図18(a)に示すエントリが記録されているため、内容が重複する新たな経路情報キャッシュを追加することなく、前記エントリの記録時刻の更新を行う。その後、経路情報ヘッダ削除後のパケットの情報(宛先アドレス192.168.0.50)を使って転送処理を実施する。この結果、前記パケットは、宛先である通信ノード100aへと転送される(ステップS906)。
 以上のように、本発明の第2の実施形態によれば、境界転送ノード301a、301bが、経路管理サーバ500から経路情報を取得した際、あるいは経路情報ヘッダを削除する際に、経路管理サーバ500から取得した経路情報、また、経路情報ヘッダに含まれる経路情報を記録し、経路情報キャッシュとして利用する。このため、経路管理サーバ500に経路要求を送信する頻度を減らし、経路管理サーバ500の負荷を低減することができる。
 さらに、本発明の第2の実施形態によれば、パケットがある宛先に送られた際に記録された経路情報のキャッシュを、逆方向のパケット、つまり前記パケットの送信元に送られたパケット用の経路情報ヘッダを構成する際にも利用しているため、経路管理サーバ500の負荷の低減効果を高めることができている。
 以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、上記した各実施形態では、リンクの両端の近隣ノード間で共有しているリンクIDを用いるものとして説明したが、ローカルIDとして、通信インタフェースの識別子を用いることも可能である。この場合、双方向の転送を実施する場合は、近隣ノード間で通信インタフェースの識別子を交換し、情報を共有すればよい。もちろん、近隣ノード間で通信インタフェースの識別子の交換を行わずに、一方向の転送を実施することも可能である。
 またさらに、リンクIDや通信インタフェースの識別子に代えて、第3のローカルIDを採番し、これをリンクIDや通信インタフェースに紐付けておく変形構成も採用可能である。
 また、例えば、上記した実施形態では、個々の転送ノードがローカルID決定部を備えて、それぞれローカルIDを決定するものとして説明したが、経路管理サーバにて各転送ノードの構成情報を入手可能である場合には、経路管理サーバがローカルIDを決定し、それぞれの記録部に転送テーブルを記憶させる構成も採用可能である。この場合、個々の転送ノードのローカルID決定部を省略することができる。またさらに、経路管理サーバが各転送ノードの接続関係も入手可能であり、隣接するノード同士でが重複しないようにローカルIDを設定可能である場合には、個々の転送ノードの近隣情報通知部も省略することが可能である。
 また、上記した実施形態の経路管理サーバ500は、非特許文献1のオープンフローコントローラにて実現することができ、この場合、転送ノードは、オープンフロースイッチにて実現することができる。
 また、上記した実施形態の経路管理サーバ500は、専用のサーバとして実現することもでき、転送ノードとしては、上記オープンフロースイッチのほか、IP網におけるルータ、MPLS網におけるMPLSスイッチにて実現することができる。その他、サーバがネットワーク内の転送ノードを集中管理するようなネットワークであれば、本発明を適用することが可能である。
 データセンタなどの商用ネットワークでは、QoS(Quality of Service)や、負荷分散のため、宛先アドレス、送信元アドレス、使用プロトコルといった様々な条件により、パケットの転送経路を厳密に制御する必要がある。本発明によれば、経路情報を増やすことなくパケットのオーバヘッドを抑制しつつ、転送経路を厳密に指定することを可能とする。したがって、本発明はデータセンタなどの商用ネットワークへ好適に適用可能である。
 なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示(請求の範囲を含む)の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
100、100a、100b 通信ノード
200 転送ノード
300、300a、300b、301、301a、301b 境界転送ノード
 310 通信インタフェース
 320 パケット転送部
 330 ヘッダ操作部
 340 ローカルID決定部
 350 近隣情報通知部
 360 経路取得部
 370 記録部
 360A 経路取得部
 370A 記録部
 380 キャッシュ管理部
400 内部転送ノード
 410 通信インタフェース
 420 パケット転送部
 430 ローカルID決定部
 440 近隣情報通知部
 450 記録部
500 経路管理サーバ
 510 通信インタフェース
 520 経路情報収集部
 530 経路要求処理部
 531 経路計算部
 540 経路情報記録部
600 データ転送ネットワーク
700 外部ネットワーク

Claims (28)

  1.  データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって転送経路情報を構成する経路管理サーバと、
     前記転送経路情報を格納したヘッダが付加されたパケットについて、前記転送経路情報に従ってパケット転送処理を実行する転送ノードと、
     を含むことを特徴とする通信システム。
  2.  前記識別子は、少なくとも一の転送ノード内で一意性を有することを特徴とする請求項1の通信システム。
  3.  前記識別子は、少なくとも一の転送ノードと、該転送ノードと隣接する転送ノードとの間において一意性を有することを特徴とする請求項1の通信システム。
  4.  前記ヘッダは、さらに、転送方向を示す情報を含む請求項1から3いずれか一の通信システム。
  5.  前記転送ノードのうち、外部ネットワークとの境界に位置する転送ノード(境界転送ノード)が、前記外部ネットワークから受信したパケットへの前記転送経路情報を格納したヘッダの付加または前記外部ネットワークへ送信するパケットから前記転送経路情報を格納したヘッダの削除を行うヘッダ操作部を備える請求項1から4いずれか一の通信システム。
  6.  前記境界転送ノードは、さらに、前記ヘッダに含まれる情報を保持するキャッシュ管理部を備え、
     同一の宛先パケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項5の通信システム。
  7.  前記境界転送ノードは、さらに、前記ヘッダを削除した際に、当該ヘッダに含まれる情報を保持するキャッシュ管理部を備え、
     前記ヘッダを削除したパケットの送信元に対して送られた逆方向のパケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項5の通信システム。
  8.  前記ヘッダには、外部のネットワークへ転送する場合と、それ以外の場合とを前記境界転送ノードが区別するための情報を含めることが可能である請求項5から7いずれか一の通信システム。
  9.  さらに、前記個々の転送ノードの接続情報を保持し、前記境界転送ノードからの要求に応じて、転送経路情報を作成して提供する経路管理サーバを備える請求項5から8いずれか一の通信システム。
  10.  前記個々の転送ノードが、前記経路管理サーバに対して、自装置に備えられている通信インタフェースまたは自装置と隣接するノードとの間に張られたリンクを識別するための識別子を通知する近隣情報通知部を備え、
     前記経路管理サーバは、前記個々の転送ノードから通知された情報に基づいて、前記境界転送ノードに提供する転送経路情報を作成する請求項9の通信システム。
  11.  前記個々の転送ノードが、隣接する転送ノードと情報交換を行って、自装置と隣接する転送ノード間の通信インタフェースの対応関係を取得し、前記ヘッダに含まれる転送方向に基づいたパケット転送処理を実行する請求項4の通信システム。
  12.  データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって転送経路情報を構成する経路管理サーバと接続され、
     前記転送経路情報を格納したヘッダが付加されたパケットについて、前記転送経路情報に従ってパケット転送処理を実行する転送ノード。
  13.  前記識別子は、少なくとも一の転送ノード内で一意性を有することを特徴とする請求項12の転送ノード。
  14.  前記識別子は、少なくとも一の転送ノードと、該転送ノードと隣接する転送ノードとの間において一意性を有することを特徴とする請求項12の転送ノード。
  15.  前記転送経路情報を管理する経路管理サーバに対して、自装置に備えられている通信インタフェースまたは自装置とその隣接ノードとの間に張られたリンクを識別するための識別子を通知する近隣情報通知部を備える請求項12から14いずれか一の転送ノード。
  16.  データ転送ネットワークと外部ネットワークとの境界に配置され、
     データ転送ネットワークに配置された各転送ノードの通信インタフェースまたは各転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成されている転送経路情報を格納したヘッダが付加されたパケットについて、前記転送経路情報に従ってパケット転送処理を実行するとともに、
     前記外部ネットワークから受信したパケットへの前記転送経路情報を格納したヘッダの付加または前記外部ネットワークへ送信するパケットから前記転送経路情報を格納したヘッダの削除を行うヘッダ操作部を備える境界転送ノード。
  17.  さらに、前記ヘッダに含まれる情報を保持するキャッシュ管理部を備え、
     同一の宛先パケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項16の境界転送ノード。
  18.  さらに、前記ヘッダを削除した際に、当該ヘッダに含まれる情報を保持するキャッシュ管理部を備え、
     前記ヘッダを削除したパケットの送信元に対して送られた逆方向のパケットに対して、前記保持した情報を用いて構成したヘッダを付与する請求項16の境界転送ノード。
  19.  データ転送ネットワークに配置された個々の転送ノードの接続情報に基づいて、前記個々の転送ノードが備える通信インタフェースまたは個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成した転送経路情報を作成する経路計算部と、
     前記データ転送ネットワークと外部ネットワークとの境界に配置された境界転送ノードからの要求に応じて、前記作成した転送経路情報を送信する経路要求処理部と、を備える経路管理サーバ。
  20.  少なくとも一の転送ノード内で一意性を有する識別子を並べた転送経路情報を作成する請求項19の経路管理サーバ。
  21.  少なくとも一の転送ノードと、該転送ノードと隣接する転送ノードとの間において一意性を有する識別子を並べた転送経路情報を作成する請求項19または20の経路管理サーバ。
  22.  前記転送経路情報に加えて、転送方向を示す情報を前記境界転送ノードに送信し、前記境界転送ノードに転送方向を示す情報を含んだヘッダを作成させる請求項19から21いずれか一の経路管理サーバ。
  23.  前記転送経路情報に加えて、前記境界転送ノードに対し、外部のネットワークへ転送する場合とそれ以外の場合とを前記境界転送ノードが区別するための情報を送信し、前記外部のネットワークへ転送するものであるか否かの情報を含んだヘッダを作成させる請求項19から22いずれか一の経路管理サーバ。
  24.  前記個々の転送ノードから通知された情報に基づいて、データ転送ネットワーク内のネットワークトポロジ情報を構築する経路情報収集部を備え、
     前記経路計算部は、前記ネットワークトポロジ情報に基づいて経路計算を行う請求項19から23の経路管理サーバ。
  25.  データ転送ネットワークの転送経路上の個々の転送ノードが、個々の転送ノードが備える通信インタフェースまたは個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成されている転送経路情報を格納したヘッダが付加されたパケットを受信するステップと、
     前記パケットについて、前記転送経路情報に従ってパケット転送処理を実行するステップとを含む通信方法。
  26.  データ転送ネットワークに配置された転送ノードを構成するコンピュータに実行させるプログラムであって、
     個々の転送ノードが備える通信インタフェースまたは個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成されている転送経路情報を格納したヘッダが付加されたパケットを受信する処理と、
     前記パケットについて、前記パケットの前記転送経路情報に従ってパケットを転送する処理と、を前記コンピュータに実行させるプログラム。
  27.  データ転送ネットワークと外部ネットワークとの境界に配置された境界転送ノードを構成するコンピュータに実行させるプログラムであって、
     個々の転送ノードが備える通信インタフェースまたは個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成されている転送経路情報を格納したヘッダが付加されたパケットを受信する処理と、
     前記パケットについて、前記パケットの前記転送経路情報に従ってパケットを転送する処理と、
     前記外部ネットワークから受信したパケットへの前記転送経路情報を格納したヘッダの付加または前記外部ネットワークへ送信するパケットから前記転送経路情報を格納したヘッダの削除を行うヘッダ操作処理と、を前記コンピュータに実行させるプログラム。
  28.  データ転送ネットワークに配置された個々の転送ノードの接続情報を保持する経路管理サーバを構成するコンピュータに実行させるプログラムであって、
     データ転送ネットワークと外部ネットワークとの境界に配置された境界転送ノードからの要求に応じて、個々の転送ノードが備える通信インタフェースまたは個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成した転送経路情報を作成する処理と、
     前記作成した転送経路情報を前記境界転送ノードに送信する処理と、を前記コンピュータに実行させるプログラム。
PCT/JP2010/065712 2009-09-14 2010-09-13 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム WO2011030889A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN2010800408171A CN102498694A (zh) 2009-09-14 2010-09-13 通信系统、转发节点、路径管理服务器、通信方法和程序
EP10815479.0A EP2479938A4 (en) 2009-09-14 2010-09-13 COMMUNICATION SYSTEM, FORWARDING NOTIFICATION, PATH MANAGEMENT SERVER, COMMUNICATION PROCESS AND PROGRAM
JP2011530901A JP5640982B2 (ja) 2009-09-14 2010-09-13 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム
US13/176,610 US8750163B2 (en) 2009-09-14 2011-07-05 Communication system, forwarding node, path management server, communication method, and program
US14/244,701 US9900249B2 (en) 2009-09-14 2014-04-03 Communication system, forwarding node, path management server, communication method, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-212221 2009-09-14
JP2009212221 2009-09-14

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/176,610 Continuation US8750163B2 (en) 2009-09-14 2011-07-05 Communication system, forwarding node, path management server, communication method, and program

Publications (1)

Publication Number Publication Date
WO2011030889A1 true WO2011030889A1 (ja) 2011-03-17

Family

ID=43732551

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/065712 WO2011030889A1 (ja) 2009-09-14 2010-09-13 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム

Country Status (5)

Country Link
US (2) US8750163B2 (ja)
EP (1) EP2479938A4 (ja)
JP (2) JP5640982B2 (ja)
CN (1) CN102498694A (ja)
WO (1) WO2011030889A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102984053A (zh) * 2011-09-07 2013-03-20 普天信息技术研究院有限公司 一种射频拉远基站中的数据交换方法
WO2013059991A1 (zh) * 2011-10-25 2013-05-02 华为技术有限公司 数据报文处理方法和系统、报文转发设备
WO2013179542A1 (ja) * 2012-05-31 2013-12-05 日本電気株式会社 ネットワークシステム、経路制御装置、経路制御方法及びプログラムを格納した非一時的なコンピュータ可読媒体
JP5699939B2 (ja) * 2010-01-08 2015-04-15 日本電気株式会社 通信システム、転送ノード、経路管理サーバおよび通信方法
JP2016158225A (ja) * 2015-02-26 2016-09-01 日本電信電話株式会社 ノード装置、転送方法、制御装置、及びプログラム

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140193154A1 (en) * 2010-02-22 2014-07-10 Vello Systems, Inc. Subchannel security at the optical layer
EP2668751B1 (en) * 2011-01-28 2016-08-24 Nec Corporation Communication system, forwarding node, control device, communication control method, and program
JP5673840B2 (ja) * 2011-09-20 2015-02-18 富士通株式会社 ノード装置および通信方法
WO2013069190A1 (en) * 2011-11-09 2013-05-16 Nec Corporation Mobile communication terminal, communication method, communication system, and control apparatus
US8644149B2 (en) * 2011-11-22 2014-02-04 Telefonaktiebolaget L M Ericsson (Publ) Mechanism for packet forwarding using switch pools in flow-based, split-architecture networks
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
US9419941B2 (en) * 2012-03-22 2016-08-16 Varmour Networks, Inc. Distributed computer network zone based security architecture
US9225635B2 (en) 2012-04-10 2015-12-29 International Business Machines Corporation Switch routing table utilizing software defined network (SDN) controller programmed route segregation and prioritization
CN103004147B (zh) * 2012-09-25 2015-07-08 华为技术有限公司 报文转发路径确定方法及网络设备、控制设备
US9253042B2 (en) * 2012-10-05 2016-02-02 Nec Laboratories America, Inc. Network management
US9049233B2 (en) * 2012-10-05 2015-06-02 Cisco Technology, Inc. MPLS segment-routing
US9042234B1 (en) * 2012-10-31 2015-05-26 Big Switch Networks, Inc. Systems and methods for efficient network traffic forwarding
CN103051539B (zh) * 2012-12-14 2015-09-16 中兴通讯股份有限公司 一种基于dht的控制网络实现方法、系统和网络控制器
US10476787B1 (en) 2012-12-27 2019-11-12 Sitting Man, Llc 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
US10447575B1 (en) 2012-12-27 2019-10-15 Sitting Man, Llc Routing methods, systems, and computer program products
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
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
US10587505B1 (en) 2012-12-27 2020-03-10 Sitting Man, Llc Routing methods, systems, and computer program products
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
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
US10404582B1 (en) 2012-12-27 2019-09-03 Sitting Man, Llc Routing methods, systems, and computer program products using an outside-scope indentifier
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
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
US10374938B1 (en) 2012-12-27 2019-08-06 Sitting Man, Llc Routing methods, systems, and computer program products
US9253035B2 (en) 2013-02-21 2016-02-02 International Business Machines Corporation Reducing switch state size in flow-based networks
US9954781B2 (en) 2013-03-15 2018-04-24 International Business Machines Corporation Adaptive setting of the quantized congestion notification equilibrium setpoint in converged enhanced Ethernet networks
US9537718B2 (en) 2013-03-15 2017-01-03 Cisco Technology, Inc. Segment routing over label distribution protocol
US9219689B2 (en) 2013-03-15 2015-12-22 International Business Machines Corporation Source-driven switch probing with feedback request
US9253096B2 (en) 2013-03-15 2016-02-02 International Business Machines Corporation Bypassing congestion points in a converged enhanced ethernet fabric
US9401857B2 (en) 2013-03-15 2016-07-26 International Business Machines Corporation Coherent load monitoring of physical and virtual networks with synchronous status acquisition
WO2014176729A1 (zh) * 2013-04-28 2014-11-06 华为技术有限公司 传送网控制方法、控制器和节点
CN104158749A (zh) * 2013-05-14 2014-11-19 华为技术有限公司 软件定义网络中报文转发方法、网络设备及软件定义网络
CN104348727B (zh) * 2013-08-05 2018-05-15 新华三技术有限公司 OpenFlow网络中的流表表项处理方法及设备
EP3059909B1 (en) * 2013-11-22 2018-03-21 Huawei Technologies Co., Ltd. Method, apparatus and system for controlling forwarding of service data in virtual network
US9560081B1 (en) 2016-06-24 2017-01-31 Varmour Networks, Inc. Data network microsegmentation
US9973472B2 (en) 2015-04-02 2018-05-15 Varmour Networks, Inc. Methods and systems for orchestrating physical and virtual switches to enforce security boundaries
US9762488B2 (en) 2014-03-06 2017-09-12 Cisco Technology, Inc. Segment routing extension headers
US9491031B2 (en) * 2014-05-06 2016-11-08 At&T Intellectual Property I, L.P. Devices, methods, and computer readable storage devices for collecting information and sharing information associated with session flows between communication devices and servers
JP6367375B2 (ja) * 2014-06-02 2018-08-01 アイデバイシーズ エルエルシー リンキングアドレスを用いたネットワーク上でのセキュア通信のためのシステムと方法
US9807001B2 (en) 2014-07-17 2017-10-31 Cisco Technology, Inc. Segment routing using a remote forwarding adjacency identifier
US9819573B2 (en) 2014-09-11 2017-11-14 Microsoft Technology Licensing, Llc Method for scalable computer network partitioning
CN105791169A (zh) * 2014-12-16 2016-07-20 电信科学技术研究院 软件定义网络中交换机转发控制、转发方法及相关设备
KR101989333B1 (ko) 2014-12-17 2019-09-30 후아웨이 테크놀러지 컴퍼니 리미티드 소프트웨어 정의 네트워킹에서의 데이터 전달 방법, 기기 및 시스템
CN104581863A (zh) * 2015-02-05 2015-04-29 北京哈工大计算机网络与信息安全技术研究中心 一种基于拓扑快速校验的物联网安全路由方法
CN105991435B (zh) * 2015-02-05 2019-08-27 华为技术有限公司 用于获取端口路径的方法及装置
US10341221B2 (en) 2015-02-26 2019-07-02 Cisco Technology, Inc. Traffic engineering for bit indexed explicit replication
US9438634B1 (en) 2015-03-13 2016-09-06 Varmour Networks, Inc. Microsegmented networks that implement vulnerability scanning
US9609026B2 (en) 2015-03-13 2017-03-28 Varmour Networks, Inc. Segmented networks that implement scanning
US9467476B1 (en) 2015-03-13 2016-10-11 Varmour Networks, Inc. Context aware microsegmentation
US10178070B2 (en) 2015-03-13 2019-01-08 Varmour Networks, Inc. Methods and systems for providing security to distributed microservices
US9525697B2 (en) 2015-04-02 2016-12-20 Varmour Networks, Inc. Delivering security functions to distributed networks
CN106161269A (zh) * 2015-04-17 2016-11-23 华为技术有限公司 一种数据包传输方法、控制器及交换机
CN106533503B (zh) * 2015-09-10 2019-05-31 深圳市中兴微电子技术有限公司 一种电力线网络通信的方法及装置
JP2017103519A (ja) * 2015-11-30 2017-06-08 日本電気株式会社 制御装置、通信システム、制御方法及びプログラム
CN105681223B (zh) * 2015-12-31 2019-05-14 清华大学 一种sdn的数据包转发方法及装置
WO2017145838A1 (ja) * 2016-02-23 2017-08-31 株式会社Nttドコモ 制御ノード及び経路制御システム
US10263881B2 (en) 2016-05-26 2019-04-16 Cisco Technology, Inc. Enforcing strict shortest path forwarding using strict segment identifiers
US9787639B1 (en) 2016-06-24 2017-10-10 Varmour Networks, Inc. Granular segmentation using events
US11032197B2 (en) 2016-09-15 2021-06-08 Cisco Technology, Inc. Reroute detection in segment routing data plane
CN108965121B (zh) * 2017-05-19 2021-06-01 华为技术有限公司 传输数据的方法、主机和交换机
US10917334B1 (en) * 2017-09-22 2021-02-09 Amazon Technologies, Inc. Network route expansion
CN109587198B (zh) * 2017-09-29 2021-11-19 北京国双科技有限公司 图文信息推送方法及装置
CN109615080B (zh) * 2018-09-20 2020-05-26 阿里巴巴集团控股有限公司 无监督模型评估方法、装置、服务器及可读存储介质
WO2020085014A1 (ja) * 2018-10-25 2020-04-30 ソニー株式会社 通信装置、通信方法及びデータ構造
CN109981765B (zh) * 2019-03-18 2023-03-24 北京百度网讯科技有限公司 用于确定内容分发网络的访问路径的方法和装置
US11140074B2 (en) 2019-09-24 2021-10-05 Cisco Technology, Inc. Communicating packets across multi-domain networks using compact forwarding instructions
CN111865401B (zh) * 2020-08-06 2022-04-26 四川安迪科技实业有限公司 卫星网络分组通信方法、系统
US11716278B1 (en) 2022-01-25 2023-08-01 Bank Of America Corporation System and method for determining the shortest data transfer path in data communication
CN114827006B (zh) * 2022-06-21 2022-11-18 广州慧睿思通科技股份有限公司 数据业务数据发送方法、对讲机、系统及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07336383A (ja) * 1994-06-08 1995-12-22 Sumitomo Electric Ind Ltd ソースルーティングブリッジ
JP2002198989A (ja) * 2000-12-25 2002-07-12 Yaskawa Electric Corp 制御システムにおけるネットワーク中継方法および制御システム
JP2004080637A (ja) * 2002-08-21 2004-03-11 Nec Corp パスルーティング設定システム
JP2004356883A (ja) * 2003-05-28 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> データ通信システム、および方法
JP2007235444A (ja) 2006-02-28 2007-09-13 Nagoya Institute Of Technology 移動端末装置、制御方法及び移動通信システム

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3688877B2 (ja) * 1997-08-08 2005-08-31 株式会社東芝 ノード装置及びラベルスイッチングパスのループ検出方法
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
KR100703499B1 (ko) * 2000-12-09 2007-04-03 삼성전자주식회사 다중 프로토콜 레이블 교환 시스템에서 트래픽 엔지니어링기능을 구현하기 위한 데이터구조 및 구축 방법
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
US6778498B2 (en) * 2001-03-20 2004-08-17 Mci, Inc. Virtual private network (VPN)-aware customer premises equipment (CPE) edge router
US20020176363A1 (en) * 2001-05-08 2002-11-28 Sanja Durinovic-Johri Method for load balancing in routers of a network using overflow paths
JP3648470B2 (ja) * 2001-09-18 2005-05-18 株式会社東芝 移動端末、ルータ装置、ノード装置、移動エージェント、パケット転送方法及び移動エージェント処理方法
EP1320224B1 (en) * 2001-12-12 2007-11-21 Alcatel Lucent Telecommunications network and a packet header therefor
US7496096B1 (en) * 2002-01-31 2009-02-24 Cisco Technology, Inc. Method and system for defining hardware routing paths for networks having IP and MPLS paths
US8923292B2 (en) * 2004-04-06 2014-12-30 Rockstar Consortium Us Lp Differential forwarding in address-based carrier networks
US7471669B1 (en) 2004-09-30 2008-12-30 Nortel Networks Limited Routing of protocol data units within a communication network
CN1988498A (zh) * 2005-12-25 2007-06-27 华为技术有限公司 一种转发控制分离系统中路由转发的方法
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网络环境中流传输路径建立方法和数据传输系统
US8208372B2 (en) * 2006-06-02 2012-06-26 Cisco Technology, Inc. Technique for fast activation of a secondary head-end node TE-LSP upon failure of a primary head-end node TE-LSP
US7710902B2 (en) * 2006-11-27 2010-05-04 Cisco Technology, Inc. Path diversity for customer-to-customer traffic
KR100819055B1 (ko) * 2006-12-08 2008-04-02 한국전자통신연구원 이동 IPv6 네트워크에서 플로우 기반 QoS 보장을위한 3 계층 핸드오버 경로 설정 방법
US8230108B2 (en) * 2007-04-13 2012-07-24 Hart Communication Foundation Routing packets on a network using directed graphs
WO2010022767A1 (en) 2008-08-26 2010-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Packet forwarding in a network
CN101436998A (zh) * 2008-12-16 2009-05-20 华为技术有限公司 报文转发路径获取方法和报文转发装置
US8509248B2 (en) * 2008-12-29 2013-08-13 Juniper Networks, Inc. Routing frames in a computer network using bridge identifiers
US8125928B2 (en) * 2009-07-24 2012-02-28 Juniper Networks, Inc. Routing frames in a shortest path computer network for a multi-homed legacy bridge node

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07336383A (ja) * 1994-06-08 1995-12-22 Sumitomo Electric Ind Ltd ソースルーティングブリッジ
JP2002198989A (ja) * 2000-12-25 2002-07-12 Yaskawa Electric Corp 制御システムにおけるネットワーク中継方法および制御システム
JP2004080637A (ja) * 2002-08-21 2004-03-11 Nec Corp パスルーティング設定システム
JP2004356883A (ja) * 2003-05-28 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> データ通信システム、および方法
JP2007235444A (ja) 2006-02-28 2007-09-13 Nagoya Institute Of Technology 移動端末装置、制御方法及び移動通信システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
NICK MCKEOWN, OPENFLOW: ENABLING INNOVATION IN CAMPUS NETWORKS, 17 July 2009 (2009-07-17)
See also references of EP2479938A4

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5699939B2 (ja) * 2010-01-08 2015-04-15 日本電気株式会社 通信システム、転送ノード、経路管理サーバおよび通信方法
CN102984053A (zh) * 2011-09-07 2013-03-20 普天信息技术研究院有限公司 一种射频拉远基站中的数据交换方法
WO2013059991A1 (zh) * 2011-10-25 2013-05-02 华为技术有限公司 数据报文处理方法和系统、报文转发设备
CN103181129A (zh) * 2011-10-25 2013-06-26 华为技术有限公司 数据报文处理方法和系统、报文转发设备
WO2013179542A1 (ja) * 2012-05-31 2013-12-05 日本電気株式会社 ネットワークシステム、経路制御装置、経路制御方法及びプログラムを格納した非一時的なコンピュータ可読媒体
JPWO2013179542A1 (ja) * 2012-05-31 2016-01-18 日本電気株式会社 ネットワークシステム、経路制御装置、経路制御方法及びプログラム
JP2016158225A (ja) * 2015-02-26 2016-09-01 日本電信電話株式会社 ノード装置、転送方法、制御装置、及びプログラム

Also Published As

Publication number Publication date
EP2479938A4 (en) 2016-09-07
US9900249B2 (en) 2018-02-20
JPWO2011030889A1 (ja) 2013-02-07
JP2014207716A (ja) 2014-10-30
US8750163B2 (en) 2014-06-10
EP2479938A1 (en) 2012-07-25
US20140219281A1 (en) 2014-08-07
JP5640982B2 (ja) 2014-12-17
US20110261722A1 (en) 2011-10-27
CN102498694A (zh) 2012-06-13
JP5790850B2 (ja) 2015-10-07

Similar Documents

Publication Publication Date Title
JP5790850B2 (ja) 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム
JP6137384B2 (ja) 通信システム、転送ノード、経路管理サーバおよび通信方法
US8065434B2 (en) Method and device for maintaining routes
JP5674107B2 (ja) 通信システム、制御装置、処理規則の設定方法およびプログラム
JP5672235B2 (ja) 通信システム、フロー制御装置、フローテーブルの更新方法およびプログラム
JP5304947B2 (ja) 通信システム、制御装置、ノードの制御方法およびプログラム
JP5483149B2 (ja) 通信システム、管理計算機、スタックドスイッチ、フロー経路決定方法
JP5800019B2 (ja) 通信経路制御システム、経路制御装置、通信経路制御方法および経路制御プログラム
US20130176861A1 (en) Control apparatus, a communication system, a communication method and a recording medium having recorded thereon a communication program
JP6752141B2 (ja) パケットを処理するための方法およびフォワーダ
JP2009239401A (ja) パケット転送装置
JP4638849B2 (ja) 機能分散型通信装置および経路制御方法
JP5657505B2 (ja) ネットワークシステム、中継装置、通信方法、中継方法及び中継プログラム
JP5022412B2 (ja) 経路情報管理システム、経路情報管理方法、およびプログラム
JP5204294B2 (ja) パケット転送装置
JP6724427B2 (ja) コントローラ、通信スイッチ、通信システム、通信制御方法、及びプログラム
JP6314970B2 (ja) 通信システム、制御装置、通信方法およびプログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080040817.1

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10815479

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011530901

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010815479

Country of ref document: EP