WO2007077819A1 - 通信装置、その動作方法、及び動作プログラム - Google Patents

通信装置、その動作方法、及び動作プログラム Download PDF

Info

Publication number
WO2007077819A1
WO2007077819A1 PCT/JP2006/325881 JP2006325881W WO2007077819A1 WO 2007077819 A1 WO2007077819 A1 WO 2007077819A1 JP 2006325881 W JP2006325881 W JP 2006325881W WO 2007077819 A1 WO2007077819 A1 WO 2007077819A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
packet
modules
information
processing
Prior art date
Application number
PCT/JP2006/325881
Other languages
English (en)
French (fr)
Inventor
Shuuichi Karino
Masahiro Jibiki
Original Assignee
Nec Corporation
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 Nec Corporation filed Critical Nec Corporation
Priority to US12/159,566 priority Critical patent/US20100238921A1/en
Priority to JP2007552934A priority patent/JP4986265B2/ja
Publication of WO2007077819A1 publication Critical patent/WO2007077819A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/60—Router architectures

Definitions

  • the present invention relates to a communication device that relays a packet and terminates a protocol, an operation method thereof, and an operation program thereof, and in particular, a communication device in which software that processes packets etc. is componentized and a communication software configuration method thereof. About.
  • communication software used in this type of communication device is implemented as a group, and a part of them is removed and replaced with another implementation, or the detailed configuration of the software is not conscious of it. It was assumed that there was no software to implement additional functions of communication.
  • Non-Patent Document 1 data transmission / reception processing is defined in a plurality of layers, and an interface between layers is defined so that processing of each layer can be implemented individually as a module. Is adopted. Furthermore, the connection order of each layer is not fixed. Applications can be freely connected and used!
  • components of communication software can be described in an object-oriented language, and the configuration of components is defined by declaring an interface in a base class, and the components can be expanded by extending the components. It can be implemented.
  • a language that describes the connection of components and expresses nodes is defined. Nodes can be easily configured by connecting
  • Non Patent Literature 1 Uresh Vahalia, Hideyuki Tokuda, Translated by 3 people, "The Kernel of the Front Line UNIX (registered trademark)", Chapter 17, STREAMS, Pearson Co., Ltd., 2000 May, p. 643-690
  • Non Patent Literature 2 Robert Morris, 3 others, "The Click Modular Router", In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP '99), (US), Dece mber 1999, p. 217-231
  • the object of the present invention is to automatically connect necessary modules according to a packet to be processed, etc., without giving the processing order of each module that performs protocol processing by prior setting.
  • a communication apparatus is a communication apparatus that causes a computer to execute network protocol software configured by a set of a plurality of modules that perform protocol processing, and each implements a protocol. It is characterized by comprising: meta-information holding means for holding predetermined meta-information for each module; and calculation means for calculating the connection order of the respective modules from the meta-information and the processing object packet.
  • the meta information may include a type of service that can be provided on the protocol stack for each module, a rule for determining non-existence of packet processing of the processing target packet, and the packet. And the non-decided module information required for the non-decision of the packet processing, and the calculation means determines whether the respective modules can process the packet to be processed in accordance with the rule. Connection order in which the non-determination can be made for all portions of the process target packet while adding the service type information to the process target packet and acquiring the module information from the process target packet. You may calculate
  • a communication device is a communication device that causes a computer to execute network protocol software configured by a set of a plurality of modules that perform protocol processing, and a predetermined meta function for each of the plurality of modules.
  • a module capable of processing at least the header information of the packet for each of the plurality of modules based on the packet and the meta information individually stored in the plurality of modules. And a module capable of processing at least the header information of the packet among the plurality of modules as a result of the non-determination, and the identification information of the identified modules is sequentially linked.
  • the information processing apparatus may further include means for passing and processing the packet by the module.
  • application software that communicates via the plurality of modules, a transmission application program interface (API) and a reception application program connected between the plurality of modules and the application software
  • the apparatus may further comprise a program interface (API) and means for calling a means for determining the packet processing order among the plurality of modules from the transmission API.
  • API program interface
  • the apparatus may further comprise means for acquiring the corresponding module from the module repository, and means for deleting the unnecessary module among the plurality of modules from the communication device.
  • means for storing and holding information on the packet processing order among the plurality of modules in a cache, and a packet among the plurality of modules by searching the information on the cache may further comprise means for determining the processing order.
  • means for detecting the update of the module, and a module after update when the module is updated are obtained. It may further comprise means for applying the updated module for the new session, and applying the module before updating for the existing session processed by the module before updating.
  • An operation method of a communication apparatus is an operation method of a communication apparatus that causes a computer to execute network protocol software configured by a set of a plurality of modules performing protocol processing. Based on the step of individually storing predetermined meta information, the packet to be processed, and the meta information separately stored in the plurality of modules, and packets among the plurality of modules.
  • the module determines the packet based on the steps of determining the processing order, attaching the determined information on the packet processing order to the packet, and the information on the packet processing order attached to the packet. And determining the destination of the
  • An operation program of a communication apparatus is an operation program of a communication apparatus that causes a computer to execute network protocol software configured by a set of a plurality of modules performing protocol processing, and the computer Packet processing between the plurality of modules based on the step of individually holding predetermined meta information for each of a plurality of modules, the packet to be processed, and the meta information held in each of the plurality of modules. Determining the order, attaching the determined information on the packet processing order to the packet, and the packet processing order attached to the packet. And the step of determining the destination of the packet based on the information.
  • a communication device capable of processing
  • FIG. 1 is a block diagram showing an entire configuration of a communication apparatus according to a first example of the present invention.
  • FIG. 2 is a diagram for explaining an example of description (definition) of meta information of an Ethernet reception processing module according to the first embodiment.
  • FIG. 3 A diagram for explaining an example of description (definition) of meta information of an IPv4 packet reception processing module in the first embodiment.
  • FIG. 4 is a diagram for describing an example of description (definition) of meta information of a UDP datagram reception processing module according to the first embodiment.
  • FIG. 5 is a diagram for explaining an Ethernet frame including sample packets in the case of performing propagation path calculation using the meta information of the protocol module shown in FIGS. 2 to 4;
  • FIG. 6 is a diagram for explaining the Ethernet frame shown in FIG. 5 divided into a protocol header and a payload.
  • FIG. 7 is a diagram for explaining metadata attached to received data by the packet receiving unit when propagation path calculation is performed using the meta information of the protocol module shown in FIGS. 2 to 4.
  • FIG. 7 is a diagram for explaining metadata attached to received data by the packet receiving unit when propagation path calculation is performed using the meta information of the protocol module shown in FIGS. 2 to 4.
  • FIG. 8 is a diagram for explaining meta-information attached to received data using the meta-information of the Ethernet frame reception processing module shown in FIG. 2;
  • FIG. 9 A diagram for explaining meta-information attached to received data using the meta-information of the IP packet reception processing module shown in FIG.
  • FIG. 10 is a view for explaining meta information attached to received data using meta information of the UDP datagram reception processing module shown in FIG. 4;
  • FIG. 11 is a view for explaining the module connection order obtained as a result of propagation path calculation using the meta-information of the protocol module shown in FIGS. 2 to 4;
  • FIG. 12 is a diagram for explaining received data to be delivered to a module when performing protocol processing by an IPv4 packet reception processing module in the first embodiment.
  • FIG. 13 is a block diagram showing an entire configuration of a communication apparatus according to a second embodiment of the present invention.
  • FIG. 14 is a diagram for explaining data prepared by an application when performing a UDP transmission process by the communication apparatus in the second embodiment.
  • FIG. 15 is a view for explaining the transmission context in the case where the communication apparatus performs UDP transmission processing in the second embodiment.
  • FIG. 16 is a diagram for explaining metadata to be added to transmission data in the UDP transmission processing by the communication apparatus in the second embodiment.
  • FIG. 17 is a block diagram showing an entire configuration of a communication apparatus according to a third example of the present invention.
  • FIG. 18 is a block diagram showing an entire configuration of a communication apparatus according to a fourth example of the present invention. Explanation of sign
  • the communication apparatus calculates meta-module connection order from meta-information holding means for holding predetermined meta-information for each module implementing a protocol, and the meta-information and the processing object packet.
  • a configuration having calculation means is adopted. For meta information,
  • each module makes the non-judgment according to the rule of (2) for the packet to be processed according to the calculation means, and attaches the information of (1) to the packet to be processed.
  • it outputs a concatenation order such that all the parts of the packet can be undecided.
  • software that does not adopt a module configuration can also be used as part of the same device. This is because an API (Application Program Interface) is provided between the protocol module and other software, and the configuration of the modularized protocol part is hidden from other software. It is for.
  • API Application Program Interface
  • communication is performed to automatically use resources automatically by deleting modules from the device automatically, and to perform function update 'addition.
  • a device processing device
  • a module necessary for processing an arrived packet can be acquired via the network.
  • a communication apparatus that updates a module without stopping and without setting.
  • This uses the functions of the third and fourth communication devices to automatically acquire the module whose function has been updated, and further, packets of flows opened before the function is updated are updated before the update.
  • the module processing order is held in the cache to be processed by the module, and packets of flows opened after the function is updated are similarly held in the cache so that the module after the update processes.
  • FIG. 1 is a block diagram showing a configuration of a first example of the present invention.
  • the communication device 100 functionally includes one or more packet reception units 110-1 to 110-X, a module search information application unit 120, and a propagation path constraint meter. It consists of an arithmetic unit 130, one or more protocol modules (hereinafter referred to as modules) 140-1 ⁇ ⁇ 140- ⁇ , and one or more socket transmissions 150-l "-150-y.
  • modules protocol modules
  • the packet reception unit 110-1-110-X is connected to the module search information application unit 120.
  • the module search information application unit 120 is connected to the propagation path constraint calculation unit 130 and the modules 140-1 ⁇ ⁇ ⁇ 140- ⁇ , respectively.
  • the propagation path constraint calculation unit 130 Besides, it is connected to the modius 140-1 ⁇ ⁇ ⁇ 140-X!
  • the module 150 – 1 ... 140 — n is also connected to the packet sender 150 — 1 ... 150 — x! .
  • Packet receiving section 110-1-110-The data receiving packet (hereinafter referred to as “received data”) is an interface of communication software realized by the configuration of this embodiment with the outside of apparatus 100. It has a function of passing it to the module search information application unit 120.
  • the packet transmission unit 150-1 ⁇ ⁇ ⁇ 150-y is an interface of the communication software realized by the configuration of the present embodiment with the outside of the device 100, the module 140-1 ⁇ ⁇ ⁇ 140-n is another device It has a function to send out transmission data (hereinafter referred to as “transmission packet”) created to the outside of the device 100.
  • Modules 140-1 to 140-n are software components that implement one of the communication protocols and process received data and create transmission data to be transmitted to other communication devices.
  • the communication protocol is, for example, all seven layers (from the lower layer to the upper layer, the physical layer, the data link layer, the network layer) based on the Open Systems Interconnection (OSI) reference model in which the communication functions that a computer should have are divided into hierarchical structures. , Transport layer, session layer, presentation layer, and application layer). Alternatively, all four layers (from lower layer to upper layer, network interface layer, Internet layer, transport layer) based on TCP / IP (Internet Protocol / Transmission Control Protocol) protocol group built based on OSI reference model And the application module (which consists of application layers).
  • OSI Open Systems Interconnection
  • processing modules of physical layer and data link layer are processing module of Ethernet (registered trademark) equivalent network layer (Internet layer), etc.
  • Processing modules in the transport layer include UDP (User Datagram Protocol) and TCP (Transmission Protocol).
  • the modules 140-1 to 140-n of this embodiment are implemented as processing modules such as Ethernet IP, UDP, etc., which constitute these communication protocols.
  • Module search information appending section 120 appends information (module search information) for searching a module necessary for processing received data according to a predetermined procedure for received data.
  • the propagation path constraint calculation unit 130 is a module 140-1 ... 140-n necessary for processing the received data from the received data and the meta information of each module 140-1-140-n (see below). And determine the processing order.
  • the modules 140-1 ⁇ 140- ⁇ functionally include a protocol processing unit (not shown), a next module search unit 141, and a meta information holding unit 142.
  • the module search information giving unit 120 or other modules 140 are included in the protocol processing unit.
  • the next module search unit 141 determines the next module 140-1 ⁇ ⁇ ⁇ 140-— to be processed next based on the module search information attached to the received data, and the module 140-1
  • ••• 140- ⁇ ⁇ has the function of handing over the processed data to its module 140-1 ... 140- ⁇ .
  • the meta information holding unit 142 holds meta information of the modules 140-1 to 140- ⁇ , and as the meta information, the types of received data that can be processed by the modules 140-1 to 140- ⁇ , Module 140-1 ⁇ ⁇ ⁇ Prerequisite necessary for processing 140- ⁇ , Module 140-: L ⁇ l 40-Module such as changes made to the received data by the processing of n 140 ⁇ ⁇ ⁇ 140- ⁇ Feature information is given.
  • the meta information held in the meta information holding unit 142 includes, for example, the following:
  • This meta information includes conditions (processing target determination conditions) for determining whether or not the module 140-1 ⁇ ⁇ 140- ⁇ should process the received data. For example, in the case of IPv4 reception processing, whether the first 4 bits are 0010, whether or not the upper layer of the corresponding layer is IP for each lower layer, and if the lower layer is Ethernet, the protocol number is 0x0 800. Whether or not the upper layer is IP-in-IP, in the case of IP, it is the protocol number strength. How is the IP header checksum correct! /, And each judgment condition of whether it is a value is included.
  • This meta-information includes meta-information necessary for the processing of the modules 140-1 to 140-n attached to the received data.
  • It contains offset information that indicates the position of the header.
  • This meta-information includes meta-information that will be attached to the received data after processing when the module 140-1 ⁇ 140-n processes the received data. For example, in the case of IPv4 reception processing, the information on the protocol number of the next layer and the IP header length are included.
  • This meta information includes meta information useful for identifying the corresponding module 140-1 ... 140-n. For example, the creation date and time of creation of module 140-1 ⁇ ⁇ ⁇ 140-n, etc., and the URL (Uniform Resource Locator) of the distribution source of module 140-1 ⁇ ⁇ 140-n are included.
  • the creation date and time of creation of module 140-1 ⁇ ⁇ ⁇ 140-n, etc. and the URL (Uniform Resource Locator) of the distribution source of module 140-1 ⁇ ⁇ 140-n are included.
  • the Ethernet frame reception processing module, the IPv4 packet reception processing module, and the UDP datagram reception processing module are targeted as examples of the modules 140-1 to 140-n.
  • An example of a complete description for defining the meta-information of module 140-1 to 140-n so that it can be processed by computer will be shown.
  • the representation and items of meta information are not limited to this example.
  • the meta information is expressed as a nested structure of elements described by tags for each of modules 140-1. That is, in the example of FIGS. 2 to 4, the meta information of each module 140-1 ... 140- ⁇ is an element indicated by a tag metadata> tag, among which ⁇ necessary information>, ⁇ processing target judgment It includes the elements indicated by> and ⁇ attached information> tags. Each of these corresponds to the content item of the meta information described above.
  • the ⁇ and> and ⁇ or> tags are descriptions for taking the logical product and the logical sum of the conditions, respectively.
  • the or> tag and the attached information> tag are included in the and> tag, and in each tag The condition is described.
  • An OR condition is described.
  • the condition is whether it is the string “Ethernet”, so in the example of Figure 2, the condition is described in the byte-data> and bit-data> tags in the or> tag respectively.
  • the AND condition of the OR condition (first condition) and the condition described in the ⁇ attachment information> tag (second condition), ie, whether both the first condition and the second condition are satisfied Indicates that it is a processing target judgment condition.
  • ⁇ offset calculation ⁇ addition 14> 14 ⁇ Z offset> indicates that the integer value 14 is added to the value of the meta information indicated by the ⁇ offset attached to the received data. .
  • the element included in the ⁇ payload information> tag indicates that the element indicated by the ⁇ protocol> tag is attached as the meta information indicated by the ⁇ payload information ⁇ . That is, the contents are described in the ⁇ switch> tag so that the protocol can be selected according to the setting conditions.
  • the strings "Offset” and “Payload Information” included in the "Required Information” tag are indicated by “Offset” and "Payload Information” in the corresponding reception data for the IPv4 reception processing module to process the reception data.
  • the and tag is a description for calculating the logical product of the conditions.
  • Length "20" /> indicates that 20 bytes of reception data from the beginning of the data to be processed are attached as meta information indicated by "protocol header".
  • the element included in the ⁇ payload information> tag indicates that the element indicated by the ⁇ protocol> tag is attached as the meta information indicated by ⁇ payload information ⁇ . That is, the contents are described in the ⁇ switch> tag so that the protocol can be selected according to the setting conditions.
  • the protocol can be selected according to the setting conditions.
  • ICMP Internet Control Message Protocol
  • the target judgment condition is described as to whether or not it is the character string "UDP"!
  • Length "8>" indicates that 8 bytes of reception data from the beginning of the data to be processed are attached as meta information indicated by "protocol header".
  • ⁇ offset operation “addition ⁇ > 8 ⁇ Z offset>” indicates that “integer value 8 is added to the value of meta information indicated by offset” attached to the received data.
  • the elements included in the “payload information> tag” are attached as the meta information indicated by “payload information” as the elements indicated by ⁇ start end point>, ⁇ end point>, and ⁇ length> tag.
  • the module indicated by the above metadata is determined to be a processing target of received data, the above attached information is added or updated to the received data.
  • modules 140-1 140-n It is not necessary that these meta-information be detailed enough to completely determine the connection order of modules 140-1 140-n. If the processing order of modules 140-1 ... 140-n can not be determined from the meta information, the received data is actually processed by the protocol processor of modules 140-1 ... 140-eta. , The next module 140-1 ... 140- ⁇ is determined.
  • meta information is a power that directly describes the offset value required for processing determination, the value of a specific field in the header, etc.
  • the syntactic syntax may be defined so that the name of the header field to be defined can be used for meta information definition.
  • the packet receiving units 110-1 to 110-X receive the packet.
  • the identifier of the corresponding packet reception unit 110-1 ... 110-X and the information for identifying the transmission device connected to the corresponding packet reception unit 110-1 ... 110-X are attached as meta information.
  • the received data that is the packet is transferred from the packet reception unit 110-1 to 110-X to the module search information application unit 120.
  • the module search information assignment unit 120 further passes the received data passed on to the propagation path constraint calculation unit 130.
  • each module 140-1 ⁇ ⁇ ⁇ ⁇ based on 140 ⁇ ⁇ meta information! Perform calculations according to the procedure described below.
  • propagation path constraint calculation section 130 applies the received data and the meta information attached to packet reception section 110-1-110-X to the received data in order to the meta information condition of each module. Perform the process of picking out the matching modules 140-1 ... 140- ⁇ ⁇ in order.
  • the processing object determination condition included in the meta information of each module 140-1 to 140- ⁇ can include the presence or absence of information to be attached to the received data by the other modules 140-1 to 140- ⁇ . Because of this, it is possible to make the modules 140-1 ⁇ ⁇ ⁇ 140 ⁇ have a dependency.
  • the dependency between the modules 140 '140' can be changed dynamically by changing the meta information attached to the data according to the contents of the received data.
  • the socket reception units 110-1 to 110-X are connected to Ethernet.
  • the packet reception unit 110-1 ⁇ ⁇ ⁇ 110-X knows in advance that the received data is an Ethernet frame, it is Ethernet protocol data as shown in FIG. 7 in the received data. Payload information indicating that is attached as meta information. Also attach processing offset 0 similarly.
  • the Ethernet reception processing module is to be processed among modules 140-1 ⁇ ⁇ ⁇ 140- ⁇ . Also, the other modules 140-1 ⁇ ⁇ 140-n! From these, it is the Ethernet reception processing module that should process this received data first.
  • the Ethernet reception processing module updates the attached information of the received data, and Attach the information shown in 8. If processing target determination is similarly performed on the basis of the received data and the metadata, the module 140-1 ⁇ 140-— to be processed next is an IPv4 reception processing module.
  • the IPv4 reception processing module updates the attached information of the received data, and attaches the information shown in FIG. If processing target determination is similarly performed on the basis of the received data and the metadata, the module 140-1 ⁇ 140- ⁇ to be processed next is a UDP reception processing module.
  • the UDP reception processing module updates the attached information of the received data and attaches the information shown in FIG. Based on the received data and metadata, if the processing target is determined in the same manner, it can be understood that the module to be processed next is 140-1 ⁇ ⁇ ⁇ ⁇ 140- ⁇ force S.
  • transmission path constraint calculation unit 130 determines the arrangement order (module connection order) of modules 140-1 to 140- eta for processing received data passed thereto. Do.
  • the arrangement order is, from the top one, an Ethernet reception processing module, an IPv4 reception processing module, and a UDP reception processing module.
  • the arrangement order is transmitted to the module search information application unit 120.
  • the packet receiving unit 110-1 ⁇ 110-X receives an Ethernet frame including the sample packet shown in FIG.
  • This Ethernet frame is composed of a protocol header and a payload as shown in Fig.6.
  • the packet receiving unit 110-1-110-X attaches the element of the metadata shown in FIG. 7 to the received data.
  • the element of the metadata includes “ ⁇ Ethernet described in protocol” indicated by “payload information”.
  • the packet reception unit 110-1 ⁇ 110-X passes the received data with the above metadata element attached to the propagation path constraint calculation unit 130.
  • the propagation path constraint calculation unit 130 causes the received data and the element of the metadata attached thereto to be stored in the meta information holding unit 442 of each module 140-1 ⁇ ⁇ ⁇ 140- ⁇ . It is stored and checked whether it matches (matches) the subject of the meta information processing target judgment condition ⁇ And the matching test results identify the matching module 140-1 140-n.
  • matching modules 140-1 to 140- ⁇ are only Ethernet reception processing modules. This is a module in which Ethernet is described in "Protocol" in the "payload information" of the metadata shown in Fig. 7 and this matches the selection processing condition in the meta information 140-1 ⁇ ⁇ ⁇ 140 — N is for the Ethernet reception processing module only!
  • the specified Ethernet reception processing module follows the “attached information” (see FIG. 2) of the meta information stored in its own meta information storage unit 442 and shows the elements of the meta information shown in FIG. Is attached to the received data, and the attached information is updated.
  • the elements indicated by "protocol header", "offset” and "payload information” are attached as elements of meta information.
  • the element of the decoy protocol header is a value (0x0003476a8b990004cd738a30800) for the first 14 bytes of the processing target data.
  • the element of " ⁇ offset" is 14, and the element of "protocol” in "payload information” is IP.
  • the propagation path constraint calculation unit 130 holds the above received data and the element force of the above meta information attached and updated thereto: Retaining meta information of each module 140-1 ⁇ ⁇ ⁇ 140- ⁇ The module stored in the unit 442 is checked whether it matches (matches) the processing object determination condition of the meta information, and the matching module 140-1 ⁇ ⁇ ⁇ 140- ⁇ ⁇ ⁇ according to the matching check result. Identify In this example, the matching module is only the IP reception processing module. This is a module in which IP is described in the protocol in the payload information in the payload information shown in Fig. 8 and this and the "processing decision condition in meta information" match 140-1 ⁇ ⁇ ⁇ 140- ⁇ ⁇ is only IP In addition, the first 4 bits of the received data are 0010 (IPv4).
  • the identified IPv4 reception processing module follows the “attached information” (see FIG. 3) of the meta information stored in the meta information holding unit 442 of its own, and the elements of the meta information shown in FIG. Is attached to the received data.
  • the elements indicated by "protocol header", "facefed” and "payload information” are attached as elements of meta information.
  • the elements of "h" protocol header are data to be processed.
  • the value of the first 20 bytes (0x4500005c9fla0000401 15725c0a80180c0a80181) is 34.
  • the element of 'offset' is 34, and the element of 'protocol' in 'payload information' is UDP.
  • the propagation path constraint calculation unit 130 attaches the above received data and the received data and Elemental force of the above meta information updated
  • the matching module is only the UDP reception processing module. This is shown in Fig. 9: UDP is described in the ⁇ protocol in the ⁇ payload information ⁇ , and the module that matches this with the "processing judgment condition" in the meta information 140-1 ⁇ ⁇ ⁇ 140- ⁇ ⁇ is only UDP It is because there is not.
  • the identified UDP reception processing module follows the “attachment information of meta information stored in its own meta information holding unit 442” (see FIG. 4), and the meta information shown in FIG. An element is attached to the received data.
  • an element indicated by " ⁇ ", “offset ⁇ ,” "payload information” is attached as an element of meta information.
  • "The element of the protocol header ⁇ ⁇ ⁇ is the value of the first 8 bytes of the data to be processed (0xffd83584004845 af).
  • the element of the" offset is 42, and the" start point “in the” payload information
  • the propagation path constraint calculation unit 130 holds the above received data and the element force of the above meta information attached and updated thereto.
  • Each module 140-1 ⁇ ⁇ ⁇ 140- ⁇ meta information holding It is stored in the part 442 and it is judged whether or not it matches (matches) the processing object judgment condition of the meta information, and the matching module 140-1 ⁇ ⁇ ⁇ 140- ⁇ is specified according to the result. It will In this example, there are no more matching modules.
  • the propagation path constraint calculation unit 130 finally creates the module connection order shown in FIG.
  • the module connection order is described by “module search information” tag, and the order of the module order is the Ethernet reception processing module, IPv4 reception processing module, and UDP reception processing module in order from the top. ! /.
  • the module search information giving unit 120 attaches the information of the module connection order which is the arrangement order of the transmitted modules 140-1 ⁇ 140-n to the received data as meta information.
  • the information of the modules 140-1 to 140- ⁇ (in this example, corresponding to the Ethernet reception processing module) at the head of the order of arrangement is taken out and received to the modules 140-1 to 140-n.
  • the module 140-1 ⁇ 140- ⁇ that has received the above-mentioned received data is the protocol processing procedure that the module 140-1 ... 140- ⁇ implements the received data by its own protocol processing unit Process according to This protocol processing includes, for example, changing the node state for each protocol, rewriting of headers and payloads, and attachment of meta information on protocol processing to packets.
  • the packet reception unit 110-1 ⁇ ⁇ ⁇ 110-Ethernet receives an Ethernet frame, and the processing by the Ethernet reception processing module among modules 140-1 ⁇ ⁇ 140 ⁇ is completed normally.
  • the received data shown in Figure 12 is passed to the IPv4 reception processing module.
  • the IP reception processing module first reads the data from the processing offset described in the attached meta information among the received data passed through the Ethernet reception processing module. .
  • the data from 0x4500 of the 14th byte (refer to the value of ⁇ offset in FIG. 8) of the received data is read as the processing offset.
  • the IP reception processing module confirms that the first 4 bits (version number) of the received data read are 0100.
  • the IP reception processing module multiplies the 5th to 8th bits (in the above case, 0011) of the read reception data by 4 to obtain the header length, and the header length is the range specified by the specification. Check that it is smaller than the remaining length of received data.
  • the IP reception processing module checks the header checksum stored in the 10-11th bytes of the received data read.
  • the IP reception processing module confirms that the total packet length stored in the 3rd to 4th bytes of the read reception data is equal to or less than the reception data length.
  • the IP reception processing module processes IP options, if any.
  • the IP reception processing module checks whether the own node can receive this packet by collating the interface address with the destination address of the packet (in this example, The case where it can receive is applicable.)
  • the IP reception processing module performs re-send processing.
  • the next module search unit 142 in the module 140-1 ⁇ ⁇ 140- ⁇ receives the meta information of the received data. From this, the module 140-1... 140-.eta. Which performs the next processing of the data is determined. The processing procedure at this time is shown below.
  • the next module search unit 142 determines the next processing module 140-1... 140- ⁇ ⁇ ⁇ which is different from the meta information, by the protocol processing by its own module 140-1. If it is, it passes to the next processing module 140-1 ... 140- ⁇ determined by the protocol processing.
  • next module search unit 142 ends the packet processing and stands by until the next packet processing.
  • next module search unit 142 delivers the data to the packet transmission unit 150-1... 150-y.
  • next module search unit 142 discards the packet and performs predetermined processing when discarding the packet.
  • any module 140-1 ⁇ ⁇ ⁇ 140-eta ends processing of the received data, or V, any module 140-1 ⁇ ⁇ ⁇ 140-eta transmits the data to the packet transmission unit 150-1 ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • the module 1 to be processed in the received data is selected. 40-1 ⁇ ⁇ ⁇ 140-Parts that can not be determined ⁇ can occur.
  • received data including ESP (Encapsulated Security Payload) (S. Kent, 1 person, IP Encapsulating Security Payload (ESP), RF 2406, Nov, 1998) has a payload portion following the ESP header. Because it is encrypted, it is not possible to decide the processing content of the subsequent part of ESP as long as the corresponding encrypted part is not decrypted. In such a case, the processing order up to the ESP receiving module is determined, and after processing the received data in the ESP module, the next module is determined from the protocol information included in the decoded payload.
  • ESP Encapsulated Security Payload
  • the module connection order is determined as far as possible. At this time, if the received data processing reaches the end of the predetermined connection order, the next module is determined from the result of processing of the received data by the protocol processor of the module.
  • next processing module can be predicted in advance in terms of protocol processing
  • information on the default next processing module can also be included in the meta information of the module. In this case, if the next processing module can not determine the received data strength, the above default next processing module is adopted for processing. If the received data is actually processed and processing by a module different from the default module is required, the received data may be delivered in preference to the latter module.
  • FIG. 13 is a block diagram showing the configuration of this example.
  • one or more transmission APIs 260 1 "-260-reception reception 1 270 1"-270 may be added to the configuration of the first embodiment.
  • one or more application software (hereinafter abbreviated as application) 280 – l ”'280 – r has been added
  • Applications 280-l-"280-r transmit ⁇ 260-1 ⁇ ⁇ 260- ⁇ ⁇ ⁇ and receive ⁇ 270-1--270-q! / /.
  • Transmit API 260 -1 ... 260-p is connected to the module search information giving unit 230.
  • Reception API 270-1 ⁇ ⁇ ⁇ 270-q is connected to each module — 250 1 ... 250-n!
  • Applications 280-1 to 280-r are considered to be applications such as HTTP (Hyper Text Transfer Protocol) and SIP (session Initiation Protocol) that use the socket API as an example.
  • HTTP Hyper Text Transfer Protocol
  • SIP session Initiation Protocol
  • the type of application 280-1 ⁇ ⁇ ⁇ 280-r is not limited to the above example.
  • Module 250-1 ⁇ ⁇ ⁇ 250-n is through other nodes, and communicates with other applications If so, any software! / ⁇
  • the packet received with the external power is processed in the same manner as in the first embodiment, but in this embodiment, the packet transmission unit is processed after the processing of the modules 250-1 ⁇ ⁇ ⁇ 250-n is completed. 220-1 ⁇ ⁇ ⁇ In addition to 220-y, there is an additional case where receiving API 270-1 ... 270-q is passed. Reception API 270 — 1 ⁇ 270 ⁇ The reception data passed to q is further passed to an application to be received 280 ⁇ 1 ⁇ “280 ⁇ r and processed.
  • the data sent by the application 280—l ′ ′ ′ 280 ⁇ r is delivered to the sending API 260 ⁇ 1 ⁇ 260 ⁇ p.
  • Sending ⁇ 260 ⁇ 1 ⁇ ⁇ 260 ⁇ ⁇ is the sending party etc.
  • Application Case 280-1 ⁇ ⁇ ⁇ 280- ⁇ Adds specified information as metadata to transmission data and passes the transmission data to module search information giving unit 230.
  • module search information giving unit 230 arranges modules 250-1... 250- ⁇ ⁇ ⁇ that should process the corresponding data based on the given transmission data and metadata, and sends them as meta information
  • the transmission data is returned to the module search information application unit 230 by adding it to the communication data. Thereafter, the transmission data is processed by processing the transmission data from the top modules 250-1 ... 250-n.
  • the application 280-1 ⁇ 280 ⁇ r prepares a transmission destination address and a port number as transmission context of transmission UDP data shown in FIG.
  • the application 280 — 1 ⁇ 280 ⁇ r sends the prepared data to the API 260 — 1 ⁇ 260 ⁇ p.
  • the module search information addition unit 230 creates the metadata shown in FIG. 16 from the transmission context of the transmission UDP data shown in FIG. 15 and adds it to the packet.
  • the application 280- 1 ⁇ ⁇ 280- r force to send UDP data to impart information of use protocol and endpoint send API260- 1 ... 260- p
  • the API 260-1 ⁇ ⁇ ⁇ 260-p Upon passing to the API 260-1 ⁇ ⁇ ⁇ 260-p will use the corresponding meta information to use module 2 50-1 ⁇ ⁇ 250- ⁇ to determine ⁇ !
  • SOAP Simple Object Access Protocol
  • SOA Applications that perform RPCs with P messages may specify only the URL of the called application, and the selection of the transmission path may be forced to the protocol module.
  • the protocol module selects an appropriate transmission protocol based on name resolution and reachability information.
  • the present embodiment is configured to include means for acquiring the module from the network.
  • a module repository 300 is installed on the network to which the communication device 100 of this embodiment is connected.
  • the module repository 300 holds all of the modules 310 used by the communication device 100 of the present embodiment, and has a function of sending the modules 310 ⁇ 320 to the communication device 100 in response to a request from the communication device 100.
  • the module repository 300 can be configured not only by a single server, but also by a configuration in which modules are distributed and held by a plurality of servers. Also, each communication device itself holds a module 310 ⁇ according to a request from another communication device. A configuration is also conceivable in which 320 can be copied to the request source, and the function of the module repository 300 can be provided in the entire communication device.
  • the module repository 300 is realized by a plurality of devices, it is necessary to prepare a separate search system which can search for and obtain the location of the modules 310 ⁇ ⁇ ⁇ ⁇ ⁇ . This search system performs processing of identifying modules using the meta information of modules 310 ⁇ ⁇ ⁇ 320 as a key. In order to speed up the search, for example, a short identifier for uniquely identifying meta information, such as a 32-bit integer, may be included in the meta information.
  • a module management unit 390 is prepared for each communication device 100.
  • the module management unit 390 holds a list of the modules 140-1 ⁇ ⁇ ⁇ 140- ⁇ held in the apparatus 100, and has means for communicating with the module repository 300.
  • the module management unit 390 checks the use module information determined by the propagation path constraint calculation unit 130 and does not exist in the modules 140-1 to 140- ⁇ in the apparatus 100, if there is a module. , Module repository 300 power etc. The corresponding module 310 ⁇ ⁇ ⁇ 320 is acquired. This makes it possible to obtain the necessary modules dynamically.
  • module deletion means can be configured as follows.
  • the module usage monitoring unit is provided in the communication device 100.
  • the module usage monitoring unit collects usage information of modules in the device, and assembles information for determining unnecessary modules.
  • the module usage information includes, for example, the number of received data processing times, memory usage, and CPU time usage for a certain period of time in the past.
  • a resource monitoring unit that monitors the degree of use of resources in the communication apparatus 100 is prepared.
  • a module management unit will be separately prepared to determine the retention priority of the module based on the above module usage information and resource utilization (A module management unit for module addition and implementation may be single. , Functions are different).
  • the module management unit determines a module to be discarded according to a predetermined rule, from information such as system resource usage and module usage frequency. Applicable if there is a module to be destroyed Delete a module or data held by that module from the device.
  • the present embodiment is applied to the configuration in which the module connection order is cached.
  • the module connection order is calculated each time a packet is received. In this case, packet processing efficiency may be significantly reduced. Therefore, in the present embodiment, in order to avoid this, for example, once the module connection order is calculated for packets for which a flow is opened, the connection order is cached, and then packets belonging to the flow arrive.
  • the first embodiment is modified to process packets in accordance with the order of connection.
  • FIG. 18 is a block diagram showing a configuration of the present example.
  • the packet processing device 400 of the present embodiment shown in the figure includes a propagation path cache 432 and a propagation path high-speed search unit 431 in the propagation path constraint calculation unit 430! / Scold.
  • propagation path constraint calculation unit 430 calculates the module connection order based on the meta information by receiving a packet, if a predetermined condition is satisfied, the corresponding module connection order is used as the propagation path cache. Keep it in 431. From the next time, when the packet is received and the propagation path constraint calculation unit 430 determines the module connection order, the corresponding cache is searched using a predetermined portion of the header of the packet as a key, and the search is recorded in the cache entry that hit the search. The module processing order given back is returned to the module search information giving unit 420.
  • Module search information such as "IPv4 reception” and "TCP reception group” is generated. Also, as a key matching this condition, for example, information identifying the TCP end point, ie, the IP address and port number of the local side and remote side Hold as cache search condition.
  • the portion of header information of the packet used when searching the cache is, for example, the source and destination addresses of the IP header, and the source and destination port of the TCP header.
  • the source is the local side
  • for received packets the source is the remote side and the above cache search conditions are checked, and if there is a matching entry, module search information stored in that cache is used. Do.
  • the corresponding process is performed when processing the packets satisfying the corresponding condition. It is possible to store and hold information on the module processing order used in the cache, search the corresponding cache in the subsequent packet processing, and determine the module processing order without performing the non-determination of the processing. Become.
  • the present embodiment is applied to a configuration in which modules are switched with non-stop Z non-setting.
  • Module power that implements a certain protocol It may be updated due to the correction of a defect or the addition of a function. In such a case, if you can not update the module without stopping and setting it, the service may be interrupted at the time of updating the module, or the user or maintenance person must spend time for setting work. You must.
  • the non-stop and non-setting module update can be performed.
  • the meta information of the module before and after the update may be the same, or if there is an additional function, etc., identification information indicating the additional function may be added to the meta information.
  • the cache information described in the fourth embodiment is prepared for each flow.
  • the corresponding cache holds the identifier of the module to be used.
  • the module at the time the flow was opened will continue to be used.
  • propagation path constraint calculation is newly performed, so if there are new and old modules with the same function, the newer one is used. In this manner, in the present embodiment, only by adding a new module to the device, module updating can be realized without interrupting the bucketing process.
  • the operation of explicitly adding the updated module to each communication device can be omitted.
  • an update module is added to the module repository, modules that can be searched by meta information become updated.
  • the module management unit of each communication device is added with a function to check for an update of a module existing in the device at a predetermined time.
  • the predetermined time is, for example, when the amount of communication in the early morning every morning is small, time, etc., or when the amount of communication falls below a predetermined threshold.
  • the module management unit acquires the module repository module if it detects that the module that can be searched is updated, such as a module newer than the module in the apparatus.
  • the present invention is applicable to packet relay devices, protocol termination devices and the like that constitute an IP network.
  • it is effective to apply the present invention to a device having a complicated function and expected to be updated in the future.
  • firewall devices providing security functions, intrusion detection devices, content filters, etc., and household set-top boxes providing network functions to home appliances etc. are conceivable.

Landscapes

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

Abstract

　プロトコル処理用の各モジュールの処理順を予め設定により与えなくとも、パケットに応じて必要なモジュールを連結してパケットを処理できる通信装置を提供する。通信装置は、プロトコルを実装する各モジュール毎にメタ情報を保持し、該メタ情報および処理対象パケットから各モジュールの連結順を計算する計算手段（伝播経路制約計算部）を備える。メタ情報は、各モジュール毎に、プロトコルスタック上で提供できるサービスの種類と、処理対象パケットのパケット処理の該非を判定する規則と、パケット処理の該非判定に必要とする該非判定済のモジュール情報とを含む。計算手段は、パケットに対して上記規則に従い各モジュールが処理可能かどうかの該非判定を行い、上記サービス種類の情報をパケットへ付加し、上記モジュール情報をパケットから取得しながら、パケットの全部分につき該非判定が可能となる各モジュールの連結順を出力する。

Description

通信装置、その動作方法、及び動作プログラム
技術分野
[0001] 本発明は、パケットの中継およびプロトコルの終端を行う通信装置、その動作方法、 及び動作プログラムに関し、とくにパケット等の処理を行うソフトウェアがコンポーネン ト化された通信装置及びその通信ソフトウェア構成方法に関する。
背景技術
[0002] 従来、この種の通信装置で用いる通信ソフトウェアは、ひとかたまりのものとして実 装され、それらの一部を取り外して他の実装と入れ替えたり、あるいは該ソフトウェア の詳細な構成を意識せずに通信の追加機能を提供するソフトウェアを実装したりする ことは想定されて 、なかった。
[0003] しかし、近年では通信機能が多様ィ匕して通信ソフトウェアの複雑さが増しており、さ らに通信ソフトウェア開発が短期間化しており、機能毎にコンポーネントを個別に開 発して組み合わせる構成が必要とされてきて 、る。
[0004] たとえば、非特許文献 1に示す" STREAMS"では、データの送受信処理を複数の層 に分けて定義し、各層の処理をモジュールとして個別に実装できるよう、層間のインタ フェースを定義する構成を採用している。さらに各層の連結順序は、固定ではなぐ アプリケーションが自由に連結して使うことができるようになって!/、る。
[0005] これを利用すれば、複雑なプロトコル処理をモジュールに分割して実装して、各モ ジュールの複雑さを低減したり、また、特定のモジュールだけを入れ替えたりすること により、システム全体を変更しなくても機能の拡張や更新が可能になる。
[0006] また、非特許文献 2に示す" click modular router"では、より細粒度でモジュールを 記述し、それを組み合わせられるようになつている。
[0007] 同文献によれば、通信ソフトウェアのコンポーネントをオブジェクト指向言語により記 述できるようにし、インタフェースを基底クラスにて宣言することでコンポーネントの構 成を規定し、それを拡張することでコンポーネントが実装できるようになつている。また 、コンポーネントの接続を記述してノードを表現する言語が定義されており、コンポ一 ネントを接続して容易にノードを構成できるようになって 、る。
非特許文献 1：ユーレッシュ'ヴァハリ (Uresh Vahalia)著、徳田英幸、外 3名訳、「最前 線 UNIX (登録商標）のカーネル」、第 17章 STREAMS、株式会社ピアソン.ェデ ュケーシヨン、 2000年 5月、 p. 643-690
非特許文献 2 : Robert Morris,外 3名、 "The Click Modular Router", In Proceedings o f the 17th ACM Symposium on Operating Systems Principles(SOSP '99), (米) , Dece mber 1999, p.217-231
発明の開示
発明が解決しょうとする課題
[0008] 従来の方式では、プロトコル処理を行う各モジュールの連結順をあら力じめ設定な どにより与えておく必要があるため、複雑で動的に構成が変わる可能性のあるモジュ ール群の管理に手間がかかる。たとえば、あるプロトコルのモジュールが不具合の修 正や機能追加などにより更新された場合、古 、モジュールを切り離して新 、モジュ ールを繋ぎ直す処理を行う必要がある。
[0009] 上記のシステムでは、次のような制約がある。
(1)アプリケーションや設定プログラムが繋ぎ変え処理を明示的に行う必要がある。
(2)繋ぎ変えをして!/、る間はパケット処理を停止しなければならな!/、。
[0010] 本発明の目的は、プロトコル処理を行う各モジュールの処理順をあら力じめ設定に より与えなくとも、処理対象のパケット等に応じて必要なモジュールを自動的に連結し て、パケットを処理できるような通信装置を提供することにある。
課題を解決するための手段
[0011] 上記目的を達成するため、本発明に係る通信装置は、プロトコル処理を行う複数の モジュールの集合により構成されるネットワークプロトコルソフトウェアをコンピュータに 実行させる通信装置であって、プロトコルを実装する各モジュール毎に所定のメタ情 報を保持するメタ情報保持手段と、前記メタ情報および処理対象パケットから前記各 モジュールの連結順を計算する計算手段とを有することを特徴とする。
[0012] 前記メタ情報は、前記各モジュール毎にプロトコルスタック上で提供できるサービス の種類と、前記処理対象パケットのパケット処理の該非を判定する規則と、前記パケ ット処理の該非判定に必要とする該非判定済のモジュール情報とを有し、前記計算 手段は、前記処理対象パケットに対して前記規則に従 、前記各モジュールが処理可 能かどうかの該非判定を行!、、前記サービス種類の情報を前記処理対象パケットへ 付加し、前記モジュール情報を前記処理対象パケットから取得しながら、前記処理対 象パケットの全部分につき前記該非判定が可能となる連結順を計算してもよい。
[0013] また本発明に係る通信装置は、プロトコル処理を行う複数のモジュールの集合によ り構成されるネットワークプロトコルソフトウェアをコンピュータに実行させる通信装置 であって、前記複数のモジュール毎に所定のメタ情報を個別に保持する手段と、処 理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基 づいて、前記複数のモジュール間でのパケット処理順を決定する手段と、決定された 前記パケット処理順の情報を前記パケットに添付する手段と、前記パケットに添付し た前記パケット処理順の情報に基づ 、て、前記モジュールが前記パケットの伝播先 を決定する手段とを備えることを特徴とする。
[0014] 本発明において、前記パケットと、前記複数のモジュールに個別に保持されたメタ 情報とに基づ!、て、前記複数のモジュール毎に前記パケットの少なくともヘッダの情 報を処理可能なモジュールかどうかの該非判定を行う手段と、前記該非判定の結果 、前記複数のモジュールのうち前記パケットの少なくともヘッダの情報を処理可能な モジュールを特定し、特定されたモジュールの識別情報を順番に連結した情報を前 記複数のモジュール間でのパケット処理順の情報として前記パケットに添付する手段 と、前記パケットに添付された情報の順番に従 、前記パケットを前記複数のモジユー ルのうち該当するモジュールへ受け渡し、当該モジュールにより前記パケットを処理 させる手段とをさらに備えてもよい。
[0015] 本発明にお 、て、前記複数のモジュールを介して通信を行うアプリケーションソフト ウェアと、前記複数のモジュールと前記アプリケーションソフトウェアとの間に接続され る送信アプリケーションプログラムインタフェース (API)および受信アプリケーションプ ログラムインタフェース（API)と、前記送信 APIから前記複数のモジュール間でのパ ケット処理順を決定する手段を呼び出す手段とをさらに備えてもよい。
[0016] 本発明にお 、て、前記複数のモジュールを格納するモジュールリポジトリとの間で 通信を行う手段と、前記複数のモジュールのメタ情報のみを当該複数のモジュールと 分離して保持する手段と、前記メタ情報により前記複数のモジュールのうち所定のモ ジュールがパケット処理に必要と判断したときは、該当モジュールを前記モジュールリ ポジトリより取得する手段と、前記複数のモジュールのうち不要となったモジュールを 前記通信装置上力 削除する手段とをさらに備えてもよい。
[0017] 本発明にお 、て、前記複数のモジュール間でのパケット処理順の情報をキャッシュ へ格納して保持する手段と、前記キャッシュの情報を検索して前記複数のモジユー ル間でのパケット処理順を決定する手段とをさらに備えてもよい。
[0018] 本発明にお 、て、前記モジュールリポジトリに格納された前記モジュールが更新さ れた場合、当該モジュールの更新を検知する手段と、前記モジュールの更新時に更 新後のモジュールを取得し、新規のセッションにつ!/ヽては更新後のモジュールを適 用し、更新前のモジュールが処理している既存セッションについては更新前のモジュ ールを適用する手段とをさらに備えてもよい。
[0019] 本発明に係る通信装置の動作方法は、プロトコル処理を行う複数のモジュールの 集合により構成されるネットワークプロトコルソフトウェアをコンピュータに実行させる通 信装置の動作方法であって、前記複数のモジュール毎に所定のメタ情報を個別に保 持するステップと、処理対象のパケットと、前記複数のモジュールに個別に保持され た前記メタ情報とに基づ!/、て、前記複数のモジュール間でのパケット処理順を決定 するステップと、決定された前記パケット処理順の情報を前記パケットに添付するステ ップと、前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュ ールが前記パケットの伝播先を決定するステップとを有することを特徴とする。
[0020] 本発明に係る通信装置の動作プログラムは、プロトコル処理を行う複数のモジユー ルの集合により構成されるネットワークプロトコルソフトウェアをコンピュータに実行さ せる通信装置の動作プログラムであって、コンピュータに、前記複数のモジュール毎 に所定のメタ情報を個別に保持するステップと、処理対象のパケットと、前記複数の モジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール 間でのパケット処理順を決定するステップと、決定された前記パケット処理順の情報 を前記パケットに添付するステップと、前記パケットに添付した前記パケット処理順の 情報に基づ 、て、前記モジュールが前記パケットの伝播先を決定するステップとを実 行させることを特徴とする。
発明の効果
[0021] 本発明によれば、プロトコル処理を行う各モジュールの処理順をあら力じめ設定に より与えなくとも、処理対象のパケット等に応じて必要なモジュールを自動的に連結し て、パケットを処理できるような通信装置を提供することができる。
図面の簡単な説明
[0022] [図 1]本発明の第 1の実施例に係る通信装置の全体構成を示すブロック図である。
[図 2]第 1の実施例にぉ 、て、 Ethernet受信処理モジュールのメタ情報の記述（定義 )例を説明する図である。
[図 3]第 1の実施例において、 IPv4パケット受信処理モジュールのメタ情報の記述（ 定義)例を説明する図である。
[図 4]第 1の実施例にぉ 、て、 UDPデータグラム受信処理モジュールのメタ情報の記 述 (定義)例を説明する図である。
[図 5]図 2〜図 4に示すプロトコルモジュールのメタ情報を用 、て伝搬経路計算を行う 場合のサンプルパケットを含む Ethernetフレームを説明する図である。
[図 6]図 5に示す Ethernetフレームをプロトコルヘッダとペイロードに分解したものを 説明する図である。
[図 7]図 2〜図 4に示すプロトコルモジュールのメタ情報を用いて伝搬経路計算を行う 場合のパケット受信部により受信データに添付されるメタデータを説明する図である。
[図 8]図 2に示す Ethernetフレーム受信処理モジュールのメタ情報を用いて受信デ ータに添付されるメタ情報を説明する図である。
[図 9]図 3に示す IPパケット受信処理モジュールのメタ情報を用いて受信データに添 付されるメタ情報を説明する図である。
[図 10]図 4に示す UDPデータグラム受信処理モジュールのメタ情報を用 、て受信デ ータに添付されるメタ情報を説明する図である。
[図 11]図 2〜図 4に示すプロトコルモジュールのメタ情報を用いて伝搬経路計算を行 つた結果得られるモジュール連結順を説明する図である。 [図 12]第 1の実施例において、 IPv4パケット受信処理モジュールによるプロトコル処 理を行う場合のモジュールに受け渡される受信データを説明する図である。
[図 13]本発明の第 2の実施例に係る通信装置の全体構成を示すブロック図である。
[図 14]第 2の実施例において、通信装置による UDP送信処理を行う場合のアプリケ ーシヨンにより用意されるデータを説明する図である。
[図 15]第 2の実施例において、通信装置による UDP送信処理を行う場合の送信コン テキストを説明する図である。
[図 16]第 2の実施例において、通信装置による UDP送信処理で送信データに付カロ されるメタデータを説明する図である。
[図 17]本発明の第 3の実施例に係る通信装置の全体構成を示すブロック図である。
[図 18]本発明の第 4の実施例に係る通信装置の全体構成を示すブロック図である。 符号の説明
100、 200、 400 通信装置
110— 1· ·· 110— x、 210— 1· ··210— χ、 410— 1· ··410— χ ノケッ卜受信部 120、 230、 420 モジュール検索情報付与部
130、 240、 430 伝搬経路制約計算部
140— 1〜140— η、 250— 1· ··250— η、 310— 1· ··310— η、 440— 1· ··410— η プロトコノレモジユーノレ
141、 441 次モジュール検索部
142、 442 メタ情報保持部
150— 1· ·· 150— y、 220— 1· ··220— y、 450— 1· ··450— y ノケッ卜送信部
260— 1· "250— p 送信 API
270— 1· ··270— q 受信 API
270- 1· ··250-Γ アプリケーション
300 モジユーノレリポジトリ
330 モジュール検索部
431 伝播経路高速検索部
432 伝播経路キャッシュ 発明を実施するための最良の形態
[0024] 次に、本発明を実施するための最良の形態について図面を参照して詳細に説明 する。
[0025] 本実施の形態による通信装置は、プロトコルを実装する各モジュール毎に所定のメ タ情報を保持するメタ情報保持手段と、該メタ情報および処理対象パケットからモジ ユールの連結順を計算する計算手段とを有する構成を採用している。メタ情報には、
(1)各モジュールがプロトコルスタック上で提供できるサービスの種類、（2)各モジュ ールが処理対象パケットのパケット処理の該非を判定する規則、 (3)各モジュールが パケット処理の該非判定に必要とする該非判定済のモジュール情報がそれぞれ含ま れる。
[0026] このような構成を採用し、前記計算手段が処理対象パケットに対して前記 (2)の規 則により各モジュールが該非判定を行って、前記（1)の情報を処理対象パケットへ付 加し、前記（3)の情報をパケットから取得しながら、パケットの全部分について該非判 定ができるような連結順を出力する。
[0027] これによれば、モジュールの連結順をあら力じめ与えることなぐ処理対象パケット に応じてモジュールを適切に連結する機構を有する通信装置 (パケット処理装置)を 提供できる。その理由は、各モジュールが、自身の前に置かれるべきモジュールの特 徴情報、 自身の後に続くべきモジュールに与えるべき特徴情報、自身が処理できる パケットの特徴情報を保持して 、るため、これらがすべて満たされるモジュールの連 結順を入力パケットから決定できるためである。
[0028] 本実施の形態では、上記の構成に加えて、さらに、モジュール構成を採用しないソ フトウェアも、同装置の一部として利用することができる。これは、プロトコルモジユー ルとその他のソフトウェアの間に送受信 API (Application Program Interface :アプリケ ーシヨンプログラムインタフェース）が用意され、モジュール化されたプロトコル部分の 構成が他のソフトウェアに対して隠蔽されているためである。
[0029] 本実施の形態では、上記の構成に加えて、さらに、モジュールを自動的に装置に 追カ卩 ·削除することで自動的に資源を有効に利用し、機能更新'追加を行う通信装置 (処理装置)を提供できる。これは、下記の特徴により、資源が無駄に消費されないた めである。
[0030] (1)到着したパケットの処理に必要なモジュールをネットワーク経由で取得できる。
[0031] (2)不要になったモジュールを装置から削除することにより、パケットの到着に応じ て必要なモジュールを常に保持できる。
[0032] (3)パケットの処理に必要ないモジュールを削除できる。
[0033] 本実施の形態では、上記の構成に加えて、さらに、プロトコル処理を高速に行える 通信装置を提供できる。これは、あるフローに属するなどの決まったパターンに従う一 連のパケットに対して、その最初のパケットのモジュール処理順をキャッシュに保持し ておき、後続のパケットの処理順をそのキャッシュ力も検索して決定するため、高速に 処理内容を決定できるためである。
[0034] 本実施の形態では、上記の構成に加えて、さらに、無停止かつ無設定でモジユー ルを更新する通信装置を提供できる。これは、第 3及び第 4の通信装置の機能を使つ て、機能が更新されたモジュールを自動的に取得し、さらに、機能が更新される前に 開設されたフローのパケットは更新前のモジュールが処理するようにキャッシュにモジ ユール処理順を保持し、機能が更新された後に開設されたフローのパケットは、更新 後のモジュールが処理するように、同様にキャッシュにモジュール処理順を保持する ことにより、いずれのフローについても、処理を中断させることなぐパケット処理を新 し 、モジュールが行うように切り替えることができるためである。
[0035] 以下、図面を参照して、本発明の種々の実施例について説明する。
実施例 1
[0036] 図 1は、本発明の第 1の実施例の構成を示すブロック図である。
[0037] 図 1を参照すると、本実施例による通信装置 100は、機能上、ひとつ以上のパケット 受信部 110—1· ·· 110— Xと、モジュール検索情報付与部 120と、伝搬経路制約計 算部 130と、ひとつ以上のプロトコルモジュール（以下、モジュールと略称する） 140 — 1· ·· 140—ηと、ひとつ以上のノ ケット送信咅 150—l"- 150—yと力らなる。
[0038] パケット受信部 110— 1· ·· 110— Xは、モジュール検索情報付与部 120に接続され ている。モジュール検索情報付与部 120は、伝搬経路制約計算部 130と、モジユー ル 140— 1· ·· 140— ηにそれぞれ接続されている。伝搬経路制約計算部 130は、こ の他にモジユーノレ 140— 1 · · · 140— Xに接続されて!、る。モジユーノレ 140— 1… 140 — nは、この他にパケット送信部 150— 1… 150— xに接続されて！、る。
[0039] パケット受信部 110—1· ·· 110—χは、装置 100外部と本実施例の構成により実現 する通信ソフトウェアのインタフェースとして、受信パケットのデータ（以下「受信デー タ」と記す)をモジュール検索情報付与部 120へ渡す機能を持つ。
[0040] パケット送信部 150— 1· ·· 150— yは、装置 100外部と本実施例の構成により実現 する通信ソフトウェアのインタフェースとして、モジュール 140— 1· ·· 140— nが他の装 置宛に作成した送信データ (以降「送信パケット」と記す)を装置 100外へ送出する機 能を持つ。
[0041] モジュール 140— 1· ·· 140— nは、通信プロトコルのひとつを実装するソフトウェアコ ンポーネントであって、受信したデータの処理や他の通信装置へ送信する送信デー タの作成などを行う。なお、通信プロトコルは、例えばコンピュータの持つべき通信機 能を階層構造に分割した OSI (Open Systems Interconnection)参照モデルに基づく 全 7層（下位レイヤから上位レイヤへ、物理層、データリンク層、ネットワーク層、トラン スポート層、セッション層、プレゼンテーション層、アプリケーション層から成る）にそれ ぞれ対応する処理モジュールから構成される。或は、 OSI参照モデルをベースに構 築された TCP/IP (Internet Protocol/Transmission Control Protocol)プロトコル群 に基づく全 4層（下位レイヤから上位レイヤへ、ネットワークインタフェース層、インター ネット層、トランスポート層、アプリケーション層から成る）にそれぞれ対応する処理モ ジュール力も構成される。このうち、物理層及びデータリンク層（ネットワークインタフエ ース層）の処理モジュールとして、 Ethernet (登録商標）等力 ネットワーク層（インタ 一ネット層）の処理モジュールとして、 IP (Internet Protocol)等が、トランスポート層の 処理モジュールとして、 UDP (User Datagram Protocol)や TCP (Transmission Contr ol Protocol)等がそれぞれ含まれる。本実施例のモジュール 140— 1· ·· 140— nは、 これらの通信プロトコルを成す Ethernet IP、 UDP等の処理モジュールとして実装 されている。
[0042] モジュール検索情報付与部 120は、受信データに対して所定の手順により受信デ ータの処理に必要なモジュールを検索するための情報 (モジュール検索情報）を付 与する。
[0043] 伝搬経路制約計算部 130は、受信データと各モジュール 140— 1· ·· 140— nのメタ 情報 (後述参照）より、受信データの処理に必要なモジュール 140— 1… 140— nお よびその処理順を決定する。
[0044] モジュール 140—1· ·· 140—ηは、機能上、プロトコル処理部（非図示）と、次モジュ ール検索部 141と、メタ情報保持部 142とを有して 、る。
[0045] プロトコル処理部では、モジュール検索情報付与部 120または他のモジュール 140
— 1… 140— ηから受け渡された受信データを該当モジュール 140— 1… 140— ηが 実装するプロトコルにしたがって処理する。
[0046] 次モジュール検索部 141は、受信データに添付されたモジュール検索情報に基づ き、次に処理すべきモジュール 140— 1· ·· 140—ηを決定し、該モジュール 140— 1
•••140- ηが処理したデータをそのモジュール 140— 1… 140— ηへ引き渡す機能を 持つ。
[0047] メタ情報保持部 142は、モジュール 140— 1〜140—ηのメタ情報を保持するもので 、そのメタ情報として、モジュール 140— 1· ·· 140— ηが処理できる受信データの種類 、モジュール 140— 1· ·· 140—ηの処理に必要な前提条件、モジュール 140—： L〜l 40— nの処理により受信データになされる変更などのモジュール 140— 1· ·· 140—η の特徴情報が付与されて 、る。
[0048] メタ情報保持部 142に保持されるメタ情報には、たとえば次のようなものが含まれる
[0049] (1)このメタ情報には、モジュール 140— 1· ·· 140— ηが受信データを処理すべきか どうかを判断するための条件 (処理対象判定条件)が含まれる。たとえば、 IPv4受信 処理の場合には、先頭 4ビットが 0010であるかどうか、下位レイヤごとに該当レイヤの 上位層が IPであるかどうか、下位レイヤが Ethernetの場合にはプロトコル番号が 0x0 800であるかどうか、上位レイヤが IP— in— IPの場合にはプロトコル番号力 であるか どう力 IPヘッダチェックサムが正し!/、値であるかどうかの各判定条件が含まれる。
[0050] (2)このメタ情報には、受信データに添付されたモジュール 140— 1· ·· 140— nの処 理に必要なメタ情報が含まれる。たとえば、 IPv4受信処理の場合には、下位レイヤの ヘッダの位置を示すオフセット情報が含まれる。
[0051] (3)このメタ情報には、モジュール 140— 1· ·· 140— nが受信データを処理する場 合に、処理後に受信データに添付されるであろうメタ情報が含まれる。たとえば、 IPv 4受信処理の場合には、次レイヤのプロトコル番号の情報と、 IPヘッダ長が含まれる。
[0052] (4)このメタ情報には、該当モジュール 140— 1… 140— nの識別に有用なメタ情報 が含まれる。たとえば、モジュール 140— 1· ·· 140— nの作成日時や作成者等、モジ ユール 140— 1· ·· 140— nの配布元の URL (Uniform Resource Locator)等が含まれ る。
[0053] 図 2〜図 4に、モジュール 140— 1· ·· 140— nの例として、 Ethernetフレーム受信処 理モジュール、 IPv4パケット受信処理モジュール、 UDPデータグラム受信処理モジ ユールを対象とし、それぞれのモジュール 140— 1· ·· 140— nのメタ情報をコンビユー タで処理できるように定義するための完全な記述例を示す。ここで、メタ情報の表現 や項目は、本例に制約されるものではない。
[0054] 図 2〜図 4を参照すると、メタ情報は、モジュール 140—1· ·· 140—ηごとにタグで記 述される要素の入れ子構造にて表現される。すなわち、図 2〜図 4の例では、各モジ ユール 140— 1… 140— ηのメタ情報は、くメタデータ >タグで示される要素からなり 、そのなかに <必要情報 >、 <処理対象判定 >、および <添付情報 >タグで示され る要素が含まれる。これらは、各々上述したメタ情報の含有項目に該当する。
[0055] まず、図 2に示す Ethernetフレーム受信処理モジュールのメタ情報について説明 する。
[0056] 図 2の例では、くメタデータ >タグで示される要素は、 Ethernet受信処理モジユー ル（モジュール名 = "Ethernet受信"）のバージョン 1 (バージョン = "1")のメタ情報で あることを示している。このうち、く必要情報〉タグ内に含まれる文字列"オフセッド は、 Ethernet受信処理モジュールが受信データを処理するには、該当受信データ に"オフセッドで示されるメタ情報が添付されて 、る必要があることを示して 、る。
[0057] また、 <処理対象判定 >タグ内に含まれる要素のうち、 < and>および < or>タグ は、条件の論理積および論理和をそれぞれ取るための記述である。図 2の例では、 く and>タグ内にく or>タグと、く添付情報 >タグとが含まれ、それぞれのタグ内に 条件が記述されている。すなわち、く or>タグ内には、く byte-data>タグ内に示され る受信データの処理オフセット位置から 6バイト目（オフセット = "6")力 の 6バイト（長 さ = "6")の値が 0x00004cd738a3と一致するかどうかという条件と、 < bit-data >タグ 内に示される受信データの処理オフセット位置力 48ビット目（オフセット = "48")が 1であるかどうかという条件との OR条件が記述されている。また、く添付情報〉タグ 内には、ペイロード情報で示されるメタ情報が受信データに添付されており（key=〃 ペイロード情報"）、かつ、そのメタ情報の値が <プロトコル >タグ内に含まれる文字 列" Ethernet"であるかどうかという条件である。従って、図 2の例では、く or>タグ内 のく byte-data >およびく bit-data >タグにそれぞれ記述されて 、る条件の OR条件 (第 1の条件）と、 <添付情報 >タグ内に記述されている条件 (第 2の条件）との AND 条件、すなわち第 1の条件と第 2の条件の両方を満たすかどうかが、処理対象判定条 件であることを示している。
[0058] さらに、 <添付情報 >タグ内に含まれる要素のうち、 <プロトコルヘッダ オフセット
= "0" 長さ = "14"Z >は、 "プロトコルヘッダ"で示されるメタ情報として、処理対象 データの先頭から 14バイト分の受信データを添付することを示して 、る。
[0059] また、 <オフセット 演算 =〃加算〃 > 14< Zオフセット >は、受信データに添付さ れた〃オフセッドで示されるメタ情報の数値に、整数値 14を加算することを示して ヽ る。
[0060] また、 <ペイロード情報 >タグ内に含まれる要素は、〃ペイロード情報〃で示されるメ タ情報として、くプロトコル〉タグで示される要素を添付することを示している。すなわ ち、その内容は、 < switch>タグ内で設定条件に応じて〃プロトコル〃を選択可能に記 述されている。図 2の例では、 < byte- data オフセット = "12〃 長さ =〃2"Z >は、処 理対象データの先頭から 12バイト目力もの 2バイトの値を意味し、その値が、 0x0800 であれば（case value="0x0800")、 IPとし、 0x0806であれば（case value="0x0806")、 ARP (Address Resolution Protocol)とする、ということを示している。
[0061] 次に、図 3に示す IPv4パケット受信処理モジュールのメタ情報について説明する。
[0062] 図 3の例では、 <メタデータ >タグで示される要素は、 IPv4受信処理モジュール（ モジュール名 = "IPv4受信"）のバージョン 1 (バージョン = "1")のメタ情報であること を示している。このうち、く必要情報〉タグ内に含まれる文字列"オフセッドおよび" ペイロード情報〃は、 IPv4受信処理モジュールが受信データを処理するには、該当 受信データに〃オフセッドおよび〃ペイロード情報〃で示されるメタ情報が添付されて V、る必要があることを示して 、る。
[0063] また、く処理対象判定 >タグ内に含まれる要素のうち、く and>タグは、条件の論 理積を取るための記述である。図 3の例では、く and >タグ内にく bit-data >と、く添 付情報 >タグとが含まれ、それぞれのタグ内に条件が記述されている。すなわち、く bit-data>タグ内には、受信データの処理オフセット位置から 0ビット目（オフセット =" 0")力 の 4ビット（長さ = の値が 0010と一致するかどうかと!/、う条件が記述されて いる。また、く添付情報〉タグ内には、ペイロード情報で示されるメタ情報が受信デ ータに添付されており（key ="ペイロード情報"）、かつ、そのメタ情報の値が <プロト コル〉タグ内に含まれる文字列 ΊΡ"であるかどうかという条件である。従って、図 3の 例では、く bit-data>タグにそれぞれ記述されている条件 (第 1の条件）と、く添付情 報 >タグ内に記述されている条件 (第 2の条件）との AND条件、すなわち第 1の条件 と第 2の条件の両方を満たす力どうかが、処理対象判定条件であることを示している。
[0064] さらに、 <添付情報 >タグ内に含まれる要素のうち、 <プロトコルヘッダ オフセット
= "0" 長さ = "20"/ >は、 "プロトコルヘッダ"で示されるメタ情報として、処理対象 データの先頭から 20バイト分の受信データを添付することを示している。
[0065] また、くオフセット 演算 ="加算 "> < bit-data オフセット = "4" 長さ = "4" シフ ト = "4 > < Zオフセット〉は、受信データに添付された"オフセッドで示されるメ タ情報の数値に、受信データの処理オフセット位置から 4ビット目力 の 4ビットの値を 加算することを示している。
[0066] また、 <ペイロード情報 >タグ内に含まれる要素は、〃ペイロード情報〃で示されるメ タ情報として、くプロトコル〉タグで示される要素を添付することを示している。すなわ ち、その内容は、 < switch>タグ内で設定条件に応じて〃プロトコル〃を選択可能に記 述されている。図 3の例では、 < byte-data オフセット = "9〃 長さ = "1"Z >は、処 理対象データの先頭から 9バイト目力もの 1バイトの値を意味し、その値が、 0x01であ れば (case
Figure imgf000015_0001
、 ICMP (Internet Control Message Protocol)とし、 0x04で あれば（case value="0x04")、 IP— in— IPとし、 0x06であれば（case value="0x06")、 TCPとし、 Oxl lであれば（case
Figure imgf000016_0001
、 UDPとし、 0x46であれば（case value= "0x46")、 IPv6— over— IPとするということを示している。
[0067] 次に、図 4に示す UDPデータグラム受信処理モジュールのメタ情報について説明 する。
[0068] 図 4の例では、 <メタデータ >タグで示される要素は、 UDP受信処理モジュール（ モジュール名 = "UDP受信"）のバージョン 1 (バージョン = "1")のメタ情報であること を示している。このうち、く必要情報〉タグ内に含まれる文字列"オフセッドおよび" ペイロード情報"は、 Ethernet受信処理モジュールが受信データを処理するには、 該当受信データに"オフセッドおよび"ペイロード情報"で示されるメタ情報が添付さ れて 、る必要があることを示して 、る。
[0069] また、 <処理対象判定 >タグ内には、 <添付情報 >タグが含まれ、そのタグ内に条 件が記述されている。すなわち、く添付情報〉タグ内には、ペイロード情報で示され るメタ情報が受信データに添付されており（key=〃ペイロード情報"）、かつ、そのメタ 情報の値がくプロトコル〉タグ内に含まれる文字列" UDP"であるかどうかという処理 対象判定条件が記述されて!ヽる。
[0070] さらに、 <添付情報 >タグ内に含まれる要素のうち、 <プロトコルヘッダ オフセット
= "0" 長さ = "8 >は、 "プロトコルヘッダ"で示されるメタ情報として、処理対象デ ータの先頭から 8バイト分の受信データを添付することを示している。
[0071] また、 <オフセット演算 ="加算〃 > 8<Zオフセット >は、受信データに添付された "オフセッドで示されるメタ情報の数値に、整数値 8を加算することを示して 、る。
[0072] また、くペイロード情報〉タグ内に含まれる要素は、〃ペイロード情報"で示されるメ タ情報として、 <始端点>、 <終端点 >、 <長さ >タグで示される要素を添付するこ とを示している。すなわち、 <始端点 >タグで示される要素は、処理対象データの先 頭 (オフセット = "0")力も 2バイト (長さ = "2")分の受信データである。また、く終端点 >タグで示される要素は、処理対象データの先頭 (オフセット = "0")から 2バイト (長 さ = "2")分の受信データである。さらに、く長さ >タグで示される要素は、処理対象 データの 4バイト目（オフセット = "0")力 2バイト (長さ = "2")分の受信データである [0073] 上記のメタデータで示されるモジュールが受信データの処理対象として判定された 場合、上記の添付情報が、受信データに対して付加あるいは更新される。
[0074] これらメタ情報は、完全にモジュール 140— 1 140— nの連結順を決定できるだ けの詳細なものである必要はな 、。メタ情報からモジュール 140— 1 · · · 140— nの処 理順が決定できないときは、実際に受信データがモジュール 140— 1···140—ηのプ 口トコル処理部にて処理された結果、次のモジュール 140— 1… 140— ηが決定され る。
[0075] また、これらのメタ情報は、処理判定に必要なオフセット値やヘッダ内の特定フィー ルドの値などを直接記述している力 実用的なシステムにする上では、プロトコルの 仕様書などで定義されるヘッダフィールドの名前などを、メタ情報定義に利用できる よう、糖衣構文を定めても良い。
[0076] たとえば、上記の例で言えば、 Ethernetフレーム受信処理モジュールのメタ情報 の処理対象判定条件内に記載された、 < byte-data オフセット = "6〃 長さ =〃6">0 x00004cd738a3 < /byte-data >と!、う記述を、 < EtherDest > 0x00004cd738a3 < /Eth erDest >等と書けるようにしてもよ！、。
[0077] 次に、本実施例の全体動作について詳細に説明する。
[0078] まず、パケットが本通信装置 100のいずれかのパケット受信部 110— 1···110—χ により受信されると、パケット受信部 110— 1···110— Xは、到達したパケットに、該当 パケット受信部 110— 1···110— Xの識別子と、該当パケット受信部 110— 1···110— Xに接続する伝送デバイスを区別するための情報をメタ情報として添付する。該パケ ットである受信データは、パケット受信部 110— 1 · · · 110— Xからモジュール検索情報 付与部 120へ受け渡される。
[0079] 次 、で、モジュール検索情報付与部 120では、受け渡された受信データをさらに伝 搬経路制約計算部 130へ受け渡す。
[0080] 次 、で、伝搬経路制約計算部 130では、パケットを適切に処理できるようにモジュ ール 140— 1···140— ηが順に並ぶよう、受け渡された受信データと、メタ情報保持 部 142に保持されて!、る各モジュール 140— 1 · · · 140—ηのメタ情報とに基づ!/、て、 後述の手順により計算を行う。
[0081] すなわち、伝搬経路制約計算部 130は、受信データと、受信データにパケット受信 部 110— 1· ·· 110— Xが添付したメタ情報を、各モジュールのメタ情報の条件に順に 適用し、適合するモジュール 140— 1… 140— ηを順に拾 、出す処理を行う。
[0082] 各モジュール 140— 1〜140—ηのメタ情報に含まれる処理対象判定条件には、他 のモジュール 140— 1… 140— ηが受信データに添付する情報の有無を含めることが できる。このため、モジュール 140— 1· ·· 140— η間に依存関係を持たせることができ る。このモジュール 140— ' 140— η間の依存関係は、受信データの内容などによ り該データへ添付するメタ情報を変えることで動的に変更できる。
[0083] これにより、モジュール間に新しい機能をもったモジュールを差し挟んで処理を行 わせたい場合等に、従来では、モジュールィ匕された通信ソフトウェアであっても、モジ ユールの連結グラフの再構成などが必要だった力 本方式では、メタ情報を適切に 記述した新しいモジュールを装置に追加するだけでよい。このため、静的に結合され たプロトコルモジュール群により構成される通信ソフトウェアよりもモジュールの入れ替 えや機能の変更を容易に行える。
[0084] 次に、図 5〜図 11を参照して、 Ethernet, IP、および UDPを実装した通信装置 10 0により上記モジュール連結順を決定する処理の具体例を説明する。
[0085] 図 5〜図 11の例では、ノ ケット受信部 110— 1· ·· 110— Xは、 Ethernetに接続して いることを仮定している。その場合、パケット受信部 110— 1· ·· 110— Xは、受信した データが Ethernetのフレームであることをあらかじめ知っているため、受信データに 、図 7に示すように Ethernetプロトコルのデータであることを示すペイロード情報をメ タ情報として添付する。また同様に処理オフセット 0も添付する。
[0086] これらの情報と、 Ethernet受信処理モジュールのメタ情報とから、モジュール 140 — 1· ·· 140—ηのうち Ethernet受信処理モジュールが処理対象になることがわかる。 また、他のモジュール 140— 1 · · · 140— nは!、ずれも処理対象にならな!/、こともわ力る 。これらより、この受信データを最初に処理すべきは Ethernet受信処理モジュール である。
[0087] 次いで、 Ethernet受信処理モジュールは、受信データの添付情報を更新して、図 8で示される情報を添付する。この受信データとメタデータより、同様に処理対象判定 を行えば、次に処理対象になるモジュール 140—1· ·· 140—ηは、 IPv4受信処理モ ジュールである。
[0088] 次いで、 IPv4受信処理モジュールは、受信データの添付情報を更新して、図 9で 示される情報を添付する。この受信データとメタデータより、同様に処理対象判定を 行えば、次に処理対象になるモジュール 140—1· ·· 140—ηは、 UDP受信処理モジ ユールである。
[0089] 次 、で、 UDP受信処理モジュールは、受信データの添付情報を更新して、図 10で 示される情報を添付する。この受信データとメタデータより、同様に処理対象判定を 行えば、次に処理対象になるモジュール 140— 1 · · · 140— η力 Sな 、ことがわかる。
[0090] 上記の手順により、伝送経路制約計算部 130は、受け渡された受信データに対し てそれを処理するモジュール 140— 1· ·· 140— ηの並び順（モジュール連結順）を決 定する。本例では、図 11に示すように、その並び順は、先頭のものから順に、 Ether net受信処理モジュール、 IPv4受信処理モジュール、 UDP受信処理モジュールとな る。この並び順をモジュール検索情報付与部 120へ伝達する。
[0091] ここで、 Ethernetフレームを受信してからモジュール連結順を決定するまでの処理 の流れについて説明する。
[0092] (1)まず、パケット受信部 110— 1 · ·· 110— Xは、図 5に示すサンプルのパケットを含 む Ethernetフレームを受信する。この Ethernetフレームは、図 6に示すようにプロト コルヘッダとペイロードとから構成される。この Ethernetフレーム受信後、パケット受 信部 110— 1· ·· 110— Xは、その受信データに図 7に示すメタデータの要素を添付す る。図 7の例では、そのメタデータの要素として、 "ペイロード情報"で示される"プロトコ ル〃に記述された〃 Ethernet"が含まれる。
[0093] (2)そして、パケット受信部 110— 1· ·· 110— Xは、上記メタデータの要素が添付さ れた受信データを伝播経路制約計算部 130に渡す。
[0094] (3)すると、伝播経路制約計算部 130は、上記受信データおよびこれに添付された 上記メタデータの要素が、各モジュール 140— 1· ·· 140— ηのメタ情報保持部 442に 格納されて 、るメタ情報の〃処理対象判定条件〃にマッチ (適合)するかどうかを検査 し、その適合検査結果により、マッチしているモジュール 140— 1 140— nを特定す る。本例では、マッチするモジュール 140—1· ·· 140—ηは、 Ethernet受信処理モジ ユールのみとなる。これは、図 7に示すメタデータの"ペイロード情報"内の"プロトコル "に Ethernetが記述され、これとメタ情報内の〃処理判定条件"とがマッチするモジュ ール 140— 1 · · · 140— nは、 Ethernet受信処理モジュールしかな!/、ためである。
[0095] (4)特定された Ethernet受信処理モジュールは、自身のメタ情報保持部 442に格 納されているメタ情報の"添付情報"（図 2参照）に従い、図 8に示すメタ情報の要素を 受信データに添付し、その添付情報を更新する。図 8の例では、メタ情報の要素とし て、 "プロトコルヘッダ"、 "オフセット"、 "ペイロード情報"で示される要素が添付される 。このうち、〃プロトコルヘッダ〃の要素は、処理対象データの先頭から 14バイト分の値 (0x0003476a8b990004cd738a30800)である。また、〃オフセット"の要素は、 14であり、 "ペイロード情報"内の"プロトコル"の要素は IPである。
[0096] (5)次 、で、伝播経路制約計算部 130は、上記受信データおよびこれに添付及び 更新された上記メタ情報の要素力 各モジュール 140— 1· ·· 140—ηのメタ情報保持 部 442に格納されて 、るメタ情報の〃処理対象判定条件〃にマッチ (適合)するかどう かを検査し、その適合検査結果により、マッチしているモジュール 140— 1· ·· 140—η を特定する。本例では、マッチするモジュールは、 IP受信処理モジュールのみとなる 。これは、図 8に示す〃ペイロード情報〃内の〃プロトコル〃に IPが記述され、これとメタ 情報内の〃処理判定条件"とがマッチするモジュール 140— 1· ·· 140—ηは IPしかなく 、さらに受信データの先頭 4ビットが 0010 (IPv4)であるためである。
[0097] (6)特定された IPv4受信処理モジュールは、 自身のメタ情報保持部 442に格納さ れているメタ情報の"添付情報"（図 3参照）に従い、図 9に示すメタ情報の要素を受 信データに添付する。図 9の例では、メタ情報の要素として、〃プロトコルヘッダ"、〃ォ フセッド、〃ペイロード情報〃で示される要素が添付される。このうち、〃プロトコルへッ ダ〃の要素は、処理対象データの先頭から 20バイト分の値（0x4500005c9fla0000401 15725c0a80180c0a80181)である。また、〃オフセッド 'の要素は、 34であり、〃ペイロー ド情報〃内の〃プロトコル〃の要素は UDPである。
[0098] (7)次 、で、伝播経路制約計算部 130は、上記受信データおよびこれに添付及び 更新された上記メタ情報の要素力 各モジュール 140— 1· ·· 140—ηのメタ情報保持 部 442に格納されて 、るメタ情報の〃処理対象判定条件〃にマッチ (適合)するかどう かを検査し、その適合検査結果により、マッチしているモジュール 140— 1· ·· 140—η を特定する。本例では、マッチするモジュールは UDP受信処理モジュールのみとな る。これは、図 9に示す〃ペイロード情報〃内の〃プロトコル〃に UDPが記述され、これと メタ情報内の"処理判定条件"とがマッチするモジュール 140— 1· ·· 140— ηは UDP しかないためである。
[0099] (8)次いで、特定された UDP受信処理モジュールは、自身のメタ情報保持部 442 に格納されているメタ情報の〃添付情報"（図 4参照）に従い、図 10に示すメタ情報の 要素を受信データに添付する。図 10の例では、メタ情報の要素として、〃プロトコルへ ッダ〃、 "オフセット〃、 "ペイロード情報"で示される要素が添付される。このうち、 "プロト コルヘッダ〃の要素は、処理対象データの先頭から 8バイト分の値（0xffd83584004845 af)である。また、 "オフセッドの要素は、 42であり、 "ペイロード情報"内の"始端点"の 要素は 0xffd8、 "終端点"の要素は 0x3584、 "長さ"の要素は 0x0048である。
[0100] (9)次 、で、伝播経路制約計算部 130は、上記受信データおよびこれに添付及び 更新された上記メタ情報の要素力 各モジュール 140— 1· ·· 140—ηのメタ情報保持 部 442に格納されて 、るメタ情報の〃処理対象判定条件〃にマッチ (適合)するかどう かを判断し、その結果により、マッチしているモジュール 140— 1· ·· 140—ηを特定す る。本例では、これ以上マッチするモジュールはない。
[0101] (10)上記より、伝播経路制約計算部 130は、図 11に示すモジュール連結順を最 終的に作成する。図 11の例では、モジュール連結順は、くモジュール検索情報〉タ グで記述され、その並び順が先頭のものから順に、 Ethernet受信処理モジュール、 I Pv4受信処理モジュール、 UDP受信処理モジュールとなって!/、る。
[0102] モジュール検索情報付与部 120では、伝達されたモジュール 140— 1· ·· 140— nの 並び順であるモジュール連結順の情報を受信データにメタ情報として添付する。次 に、その並び順の先頭にあるモジュール 140— 1· ·· 140—η (本例では Ethernet受 信処理モジュールが該当する。）の情報を取出し、該当モジュール 140— 1〜140— nへ受信データを受け渡す。 [0103] さらに、上記の受信データを受け取ったモジュール 140—1· ·· 140—ηは、自身の プロトコル処理部により、該受信データをそのモジュール 140— 1… 140— ηが実装 するプロトコル処理手順にしたがって処理する。このプロトコル処理は、たとえば、プ ロトコルごとのノード状態の変更をはじめ、ヘッダやペイロードの書き換え、プロトコル 処理に関するメタ情報のパケットへの添付などである。
[0104] たとえば、 IPv4受信処理モジュールによるプロトコル処理の場合は、次のようになる 。なお、ここに記載した処理は、非特許文献 (G. R.ライト、外 1名著，徳田英幸、外 1 名訳、「詳解 TCPZIP vol. 2 実装」、株式会社ピアソン 'エデュケーション、 2002 年 12月）の第 8章の記述に基づ 、て 、る。
[0105] ここでは、パケット受信部 110— 1· ·· 110—χが Ethernetフレームを受信し、モジュ ール 140— 1· ·· 140—ηのうち Ethernet受信処理モジュールによる処理が正常に完 了し、図 12に示す受信データが IPv4受信処理モジュールに受け渡された場合を考 える。
[0106] (1)この場合には、 IP受信処理モジュールは、まず、 Ethernet受信処理モジユー ルカ 受け渡された受信データのうち添付されたメタ情報に記述されている処理オフ セットからのデータを読み込む。図 12の例では、処理オフセットとして受信データの 先頭から 14バイト目（図 8の〃オフセッドの値参照）の 0x4500からのデータが読み込ま れる。
[0107] (2)次 、で、 IP受信処理モジュールは、読み込まれた受信データの先頭 4ビット (バ 一ジョン番号）が 0100であること確認する。
[0108] (3)次いで、 IP受信処理モジュールは、読み込まれた受信データの 5— 8ビット目（ 上記の場合 0011)を 4倍してヘッダ長を得て、そのヘッダ長が仕様の定める範囲に収 まっており、かつ受信データの残り長より短いことを確認する。
[0109] (4)次いで、 IP受信処理モジュールは、読み込まれた受信データの 10— 11バイト 目に格納されたヘッダチェックサムを検査する。
[0110] (5)次いで、 IP受信処理モジュールは、読み込まれた受信データの 3— 4バイト目 に格納されているパケット全長が受信データ長以下であること確認する。
[0111] (6)次!、で、 IP受信処理モジュールは、 IPオプションがあれば処理する。 [0112] (7)次!、で、 IP受信処理モジュールは、インタフェースアドレスとパケットの宛先アド レスを照合する等して、このパケットを自ノードで受信できるかどうか検査する（本例で は、受信できる場合が該当する。 )
[0113] (8)次いで、 IP受信処理モジュールは、パケットがフラグメントされていれば、リアセ ンブル処理を行う。
[0114] 以上のようなモジュール 140— 1···140—ηによるプロトコル処理が終わると、モジュ ール 140— 1···140— η内の次モジュール検索部 142は、受信データのメタ情報から 該データの次処理を行うモジュール 140—1···140—ηを決定する。このときの処理 手順を以下に示す。
[0115] (1)まず、次モジュール検索部 142は、メタ情報に次処理モジュール 140— 1···14 0— ηが記録されていれば、該モジュール 140— 1···140— ηへ該パケットを受け渡す
[0116] (2)次モジュール検索部 142は、自身のモジュール 140—1···140—ηによるプロト コル処理により、メタ情報とは異なる次処理モジュール 140— 1···140—ηが決定され たときは、そのプロトコル処理により決定される次処理モジュール 140— 1···140—η へ受け渡す。
[0117] (3)次モジュール検索部 142は、次処理モジュール 140—1···140—ηがないとき は、該パケット処理を終了して、次のパケットの処理まで待機する。
[0118] (4)次モジュール検索部 142は、処理済データを送出する必要があれば、該デー タをパケット送信部 150— 1··· 150— yへ受け渡す。
[0119] (5)次モジュール検索部 142は、次処理が決定できなければ、パケットを破棄し、 破棄する場合にあら力じめ定められた処理を行う。
[0120] 上記のモジュール 140— 1···140—ηによるプロトコル処理は、受信データの処理 が終わるか、 V、ずれかのモジュール 140— 1 · · · 140—ηが該データをパケット送信部 150— 1··· 150— yへ受け渡すまで続く。そして、処理済データがパケット送信部 150 — 1···150— yに受け渡されると、該パケット送信部 150— 1···150— yは、接続され たデータリンクへ該データをパケットとして送出して処理を終える。
[0121] ここで、上記メタ情報の適合検査では、受信データの中で処理対象のモジュール 1 40— 1 · · · 140—ηを決められない部分が発生しうる。たとえば、 ESP (Encapsulated S ecurity Payload) (S. Kent,外 1名, IP Encapsulating Security Payload (ESP) , RFし 2 406, Nov, 1998参照）を含む受信データは、 ESPヘッダに後続するペイロード部分が 暗号化されて 、るため、該当暗号部分を復号しな 、かぎり ESPの後続部分の処理内 容は決められない。このような場合は、 ESP受信モジュールまでの処理順を決めてお き、 ESPモジュールで受信データを処理した後、復号されたペイロードに含まれるプ ロトコル情報より、次のモジュールを決定するようにしてもよ 、。
[0122] 上記のような場合や、メタ情報の記述が受信データの処理順を決定できるほど十分 に詳細ではない場合は、可能な範囲でモジュールの連結順を決めておく。このとき、 あらかじめ決められた連結順の最後まで受信データ処理が到達したらば、実際に受 信データがモジュールのプロトコル処理部にて処理された結果から、次のモジュール が決定される。
[0123] あるいは、プロトコル処理上、あらかじめ次処理モジュールが予測できるような場合 には、ディフォルトの次処理モジュールの情報をモジュールのメタ情報に含めておく こともできる。この場合、次処理モジュールが受信データ力 決定できなければ、上 記ディフォルト次処理モジュールを採用して処理を行う。もし、実際に受信データを処 理して、ディフォルトモジュールとは異なるモジュールによる処理が必要になれば、後 者のモジュールに優先して受信データを受け渡せば良い。
実施例 2
[0124] 次に、本発明の第 2の実施例を説明する。本実施例は、第 1の実施例の構成にカロ え、モジュールィ匕して ヽな 、アプリケーションを含む構成を採用して 、る。
[0125] 第 1の実施例の通信装置では、受信および送信データの処理に使われるすべての ソフトウェア力 本発明の方式によるモジュールとして存在して 、ることを仮定して 、る 。この仮定を満たすには、既成の通信アプリケーションなどを本方式にあわせてモジ ユール構成に書き換える必要があることになる。これは、書き換え作業のコストがかか るうえ、書き換えに伴って新たな不具合が混入するリスクもあるなど、好ましくない場 合もある。これを解決するには、本方式の通信ソフトウェアと本方式によらないソフトゥ エアとの間にインタフェースを用意して、本方式の構成を他のソフトウェアに対して隠 蔽すればよい。本実施例は、その点を踏まえ構成されている。
[0126] 図 13は、本実施例の構成を示すブロック図である。図 13を参照すると、本実施例 による通信装置 200では、第 1の実施例の構成にカ卩えて、一つ以上の送信 API260 1"-260— ぉょび受信八？1270—1"-270— と、一つ以上のアプリケーションソ フトウェア（以下、アプリケーションと略称する） 280— l"'280—rとが追加されている
[0127] アプリケーション 280— l- "280—rは、各々、禾 する送信 ΑΡΙ260— 1· ··260— ρおよび受信 ΑΡΙ270 - 1- --270— qと接続して!/、る。送信 API260— 1… 260— pは 、モジュール検索情報付与部 230と接続している。受信 API270— 1· ··270— qは、 各モジユーノレ 250— 1… 250— nと接続して!/、る。
[0128] アプリケーション 280— 1· ··280— rは、その一例として、ソケット APIを利用するよう な、 HTTP (Hyper Text Transfer Protocol)、 SIP (session Initiation Protocol)などの アプリケーションが考えられる。ただし、アプリケーション 280— 1· ··280— rの種類は 、上記の例に限られるものではなぐモジュール 250— 1· ··250— nを通じて他のノー ドある 、は他のアプリケーションと通信するものであれば、何れのソフトウェアでもよ！/ヽ
[0129] 次に、本実施例の動作について説明する。
[0130] まず、外部力も受信したパケットは、第 1の実施例と同様に処理されるが、本実施例 では、モジュール 250— 1· ··250— nの処理が終わったあと、パケット送信部 220— 1 • · · 220—yではなく、受信 API270— 1… 270— qへ受け渡される場合が追加されて いる。受信 API270— 1· ··270— qへ受け渡された受信データは、さらに受信対象ァ プリケーシヨン 280— 1· "280— rに渡されて処理される。
[0131] 次いで、アプリケーション 280—l"'280—rが送信するデータは、送信 API260— 1· ··260— pに受け渡される。送信 ΑΡΙ260— 1· ··260— ρは、送信相手などのアプリ ケーシヨン 280— 1· ··280—ι:が指定した情報をメタデータとして送信データに付与し 、送信データをモジュール検索情報付与部 230へ渡す。
[0132] 次いで、モジュール検索情報付与部 230では、与えられた送信データとメタデータ より該当データを処理すべきモジュール 250— 1… 250— ηを並べ、メタ情報として送 信データに付与して、モジュール検索情報付与部 230へ送信データを戻す。以降、 先頭のモジュール 250— 1… 250— nから送信データを処理することで、該当送信デ ータが処理される。
[0133] 次に、図 14〜図 16を参照して、本実施例による UDPデータグラムの具体的な送 信処理について説明する。この例では、アプリケーション 280— 1· ··280— rから UD P送信を行う場合である。
[0134] (1)まず、アプリケーション 280— 1· "280— rは、図 14に示す送信 UDPデータを 用意する。
[0135] (2)次いで、アプリケーション 280— 1· ··280— rは、図 15に示す送信 UDPデータ の送信コンテキストとして、送信先アドレスとポート番号を用意する。
[0136] (3)次いで、アプリケーション 280— 1· ··280— rは、用意したデータを送信 API260 — 1· ··260— pに渡す。
[0137] (4)次!ヽで、送信 ΑΡΙ260— 1· ··260— piま、アプリケーション 280— 1· ··280— r力 らのデータをモジュール検索情報付与部 230へ渡す。
[0138] (5)次いで、モジュール検索情報付与部 230が図 15に示す送信 UDPデータの送 信コンテキストから図 16に示すメタデータを作成してパケットに付加する。
[0139] (6)以後、受信時と同様の手順により処理する。
[0140] 以上のように、本実施例では、アプリケーション 280— 1· ··280— r力 送信 UDPデ ータに利用プロトコルとエンドポイントの情報を付与して、送信 API260— 1… 260— pに渡すと、送信 API260— 1· ··260— pは、該当メタ情報を使って利用モジュール 2 50- 1· · · 250— ηを決定するよう【こなって!/ヽる。
[0141] なお、本実施例では、アプリケーションが UDPを使うことをメタデータにより指定して いる場合を説明したが、本発明はこれに限定されず、もっと抽象的なメタデータを用 V、るような構成ち考免られる。
[0142] たとえば、 SOAP (例えば、 Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http：〃 www.w3.org/TR/2000/NOTE-SOAP-20000508/参照）によりリ モートノードに置かれたオブジェクトのメソッドを呼び出す場合、リモートノードへ SOA Pメッセージを伝送するための通信プロトコルにはとくに制限はない。このため、 SOA Pメッセージにて RPCを行うアプリケーションは、呼び出し先アプリケーションの URL のみを指定し、伝送路の選択はプロトコルモジュールにま力せても良い。このような場 合、プロトコルモジュールは名前解決や到達性の情報などに基づき、適切な伝送プ ロトコルを選択する。
実施例 3
[0143] 次に、本発明の第 3の実施例を説明する。本実施例は、メタ情報だけを手元に置い ておく構成について適用したものである。
[0144] 第 1の実施例では、全てのモジュールが通信装置内にあら力じめ存在していること を仮定していた。しかし、通信装置によっては、搭載されるメモリ等が少ないために、 利用する可能性のあるモジュールをすベて保持することが困難なものもある。たとえ ば、小規模オフィス向け小型ルータや、テレビ受像機等の家電製品に通信機能を提 供するセットトップボックス、携帯電話端末などの装置がこれに該当する。
[0145] このような装置では、資源の利用を節約するため、次のように必要なモジュールをネ ットワーク経由で取得し、不要になつたら該当モジュールや利用資源を削除する手段 を設けることが有効である。すなわち、通信に利用する可能性のあるモジュールのメ タ情報のみを装置内に保持しておき、到着したパケットの処理に該当モジュールが 必要であることが伝搬経路制約計算により分力つた時点で、該当モジュールをネット ワーク経由で取得することにより必要なモジュールを動的に取得できるようにする。
[0146] そこで、本実施例は、第 1の実施例に加え、前記モジュールをネットワークより取得 する手段を備えた構成として 、る。
[0147] 図 17に本実施例の構成を示す。図 17において、本実施例の通信装置 100が接続 されるネットワーク上には、モジュールリポジトリ 300が設置されている。モジュールリ ポジトリ 300は、本実施例の通信装置 100が利用するモジュール 310を全部保持し ていて、通信装置 100からの要求に応じてモジュール 310· ··320を通信装置 100へ 送る機能を持つ。
[0148] モジュールリポジトリ 300は、単一のサーバにて構成できるのはもちろんのこと、複 数のサーバで分散してモジュールを保持する構成も考えられる。また、各通信装置 自身が、他の通信装置からの要求に応じて、自身が保持しているモジュール 310· ·· 320を要求元へコピーできるようにし、通信装置全体でモジュールリポジトリ 300の機 能を持つようにする構成も考えられる。複数の装置でモジュールリポジトリ 300を実現 する場合には、モジュール 310· ··320の所在を検索して取得できるような、検索シス テムを別途用意する必要がある。この検索システムは、モジュール 310· ··320のメタ 情報をキーとしてモジュールを特定する処理を行う。検索を高速にするため、たとえ ば、 32ビット整数などの、メタ情報を一意に識別するための短い識別子をメタ情報に 含めても良い。
[0149] 各通信装置 100には、モジュール管理部 390を用意する。モジュール管理部 390 は、装置 100内に保持しているモジュール 140— 1· ·· 140—ηの一覧を保持しており 、モジュールリポジトリ 300と通信する手段を備えている。
[0150] モジュール管理部 390は、伝搬経路制約計算部 130が決定した利用モジュール情 報を検査し、装置 100内のモジュール 140— 1 · · · 140— ηに存在しな!、モジュールが あれば、モジュールリポジトリ 300力ら該当モジュール 310· ··320を取得する。これに より、必要なモジュールを動的に取得する機能を実現できる。
[0151] さらに、資源が不足しているときなどに、当面利用する見込みがないモジュールが 装置 100内にある場合は、該当モジュールや、該当モジュールが利用する資源を一 時的に削除できるようにする。このようなモジュール削除手段は、次のようにすれば構 成できる。
[0152] 通信装置 100内にモジュール利用監視部を用意する。モジュール利用監視部は、 装置内にあるモジュールの利用情報を収集し、不要なモジュールを決定するための 情報をまとめる。モジュール利用情報には、たとえば、過去一定時間の受信データ処 理回数、メモリ使用量、 CPU時間使用量がある。
[0153] また、通信装置 100内の資源の利用度合いを監視する資源監視部を用意する。さ らに、上記モジュール利用情報と資源の利用度合いから、モジュールの保持優先度 を決定するモジュール管理部を別途用意する（モジュール追加用のモジュール管理 部と実装上は、単一にしても良いが、機能は異なる）。このモジュール管理部は、シス テムの資源の利用量とモジュールの利用頻度などの情報から、所定の規則にしたが つて破棄すべきモジュールを決定する。破棄すべきモジュールがある場合は、該当 モジュールや、そのモジュールが保持するデータを装置から削除する。
[0154] 本実施例によれば、以上のように構成することで、必要なモジュールを入れ替えな 力 Sら処理を継続することができるため、少ない資源で多くの機能を実現する装置を提 供できる。
実施例 4
[0155] 次に、本発明の第 4の実施例を説明する。本実施例は、モジュール連結順をキヤッ シュしておく構成について適用したものである。
[0156] 第 1の実施例では、モジュール連結順をパケット受信毎に毎回計算している。こうす ると、パケット処理の効率が著しく低下する場合も想定される。そこで、本実施例では 、これを避けるため、たとえば、フローを開設するパケットについて、モジュール連結 順を一度計算したら、該当連結順をキャッシュしておき、その後該フローに属するパ ケットが到着したら、同パケットについては該当連結順にしたがって処理するよう、第 1の実施例を変更している。
[0157] 図 18は、本実施例の構成を示すブロック図である。同図に示す本実施例のパケット 処理装置 400は、伝搬経路制約計算部 430内に、伝搬経路キャッシュ 432と、伝搬 経路高速検索部 431とを備えて！/ヽる。
[0158] この構成により、パケットの受信により、伝搬経路制約計算部 430がメタ情報に基づ くモジュール連結順の計算を行うと、所定の条件を満たす場合には該当モジュール 連結順を伝搬経路キャッシュ 431内に保持しておく。次回以降、パケットを受信して、 伝搬経路制約計算部 430がモジュール連結順を決定するときには、該当キャッシュ をパケットのヘッダの所定部分をキーとして検索し、検索にヒットしたキャッシュのェン トリに記録されたモジュール処理順を、モジュール検索情報付与部 420へ返戻する。
[0159] 上記のモジュール連結順をキャッシュに格納する条件として、例えば TCPコネクシ ヨンが開設されるパケット（SYNフラグが含まれている）を送受信処理する場合は、た とえば" Ethernet受信"、 "IPv4受信"、 "TCP受信〃のようなモジュール検索情報が 生成される。また、この条件にマッチするキーとしては、例えば TCP端点を識別する 情報、すなわちローカル側とリモート側の IPアドレスおよびポート番号をキャッシュ検 索条件として保持する。 [0160] 上記の例で格納されたモジュール連結順について、キャッシュを検索するときに使 われるパケットのヘッダ情報の部位は、例えば IPヘッダの送信元および宛先アドレス と、 TCPヘッダの送信元および宛先ポートとである。送信パケットについては、送信 元がローカル側、受信パケットについては、送信元がリモート側として上記キャッシュ 検索条件を検査し、マッチするエントリがあれば、そのキャッシュに格納されたモジュ ール検索情報を利用する。
[0161] 従って、本実施例によれば、モジュールの処理順が同一順であるようなパケットが 継続して到着することが予測できる場合には、該当条件を満たすパケットを処理する ときに該当処理に使ったモジュール処理順の情報をキャッシュへ格納して保持し、次 回以降のパケット処理では該当キャッシュを検索し、処理の該非判定を行わずにモ ジュールの処理順を決定することが可能になる。
実施例 5
[0162] 次に、本発明の第 5の実施例を説明する。本実施例は、無停止 Z無設定でモジュ ールを入れ替える構成について適用したものである。
[0163] あるプロトコルを実装するモジュール力 不具合の修正や機能追加などにより更新 される場合がある。このような場合に、モジュールの更新を無停止かつ無設定にて行 えないと、モジュールの更新時にサービスがいったん中断したり、設定作業のために ユーザーやメンテナンス担当者が時間を費やしたりしなければならない。
[0164] そこで、本実施例では、無停止かつ無設定のモジュール更新が行えるように構成し ている。この場合、更新前と更新後のモジュールのメタ情報は、同一であっても良い し、機能追加がある場合などはメタ情報に追加機能を示す識別情報を入れても良い
[0165] また、本実施例では、フロー毎に、第 4の実施例で説明したキャッシュ情報を用意し ておく。該当キャッシュは、利用するモジュールの識別子をあら力じめ保持しておく。 キャッシュにマッチしたパケットについては、フローが開設された時点のモジュールが 使われ続ける。一方、新しく開設されるフローについては、新規に伝搬経路制約計算 が行われるため、同一機能をもつ新旧のモジュールがある場合は、新しいほうのモジ ユールが使われる。 [0166] このようにして、本実施例では、新 、モジュールを装置に追加するだけで、バケツ ト処理を中断させずにモジュールの更新が実現できる。
[0167] さらに、第 3の実施例と組み合わせると、更新されたモジュールを明示的に個々の 通信装置へ追加する作業も省略できる。更新モジュールをモジュールリポジトリへ追 加すると、メタ情報で検索できるモジュールは更新済のものになる。また、各通信装 置のモジュール管理部に、所定の時点で、装置内に存在するモジュールの更新を検 查する機能を追加する。上記所定の時点は、具体的には、たとえば毎日の早朝の通 信量の少な 、時間などや、通信量があら力じめ定めた閾値を下回った時などである
[0168] モジュール監理部は、モジュールリポジトリ力 検索できるモジュールが装置内にあ るモジュールよりも新しいなど、更新されていることを検知した場合には、該モジユー ルを取得する。
[0169] 本実施例によれば、以上のように構成することで、新 U、モジュールをモジュールリ ポジトリへ追加すれば、通信装置にはいつさい設定を行うことなぐモジュールを更新 することができる。
産業上の利用可能性
[0170] 本発明は、 IPネットワークを構成するパケット中継装置、プロトコル終端装置などに 適用できる。とくに、機能が複雑で今後更新が予想される機器に対して本発明を適 用すると有効である。具体的には、セキュリティ機能を提供するファイアウォール装置 、侵入検知装置、コンテンツフィルタなどや、家電製品などにネットワーク機能を提供 する家庭用のセットトップボックスなどが考えられる。

Claims

請求の範囲
[1] プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコ ルソフトウェアをコンピュータに実行させる通信装置であって、
プロトコルを実装する各モジュール毎に所定のメタ情報を保持するメタ情報保持手 段と、
前記メタ情報および処理対象パケットから前記各モジュールの連結順を計算する 計算手段とを有することを特徴とする通信装置。
[2] 前記メタ情報は、前記各モジュール毎にプロトコルスタック上で提供できるサービス の種類と、前記処理対象パケットのパケット処理の該非を判定する規則と、前記パケ ット処理の該非判定に必要とする該非判定済のモジュール情報とを有し、
前記計算手段は、前記処理対象パケットに対して前記規則に従い前記各モジユー ルが処理可能力どうかの該非判定を行 、、前記サービス種類の情報を前記処理対 象パケットへ付加し、前記モジュール情報を前記処理対象パケットから取得しながら
、前記処理対象パケットの全部分につき前記該非判定が可能となる前記各モジユー ルの連結順を出力することを特徴とする請求項 1記載の通信装置。
[3] プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコ ルソフトウェアをコンピュータに実行させる通信装置であって、
前記複数のモジュール毎に所定のメタ情報を個別に保持する手段と、
処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報と に基づ!/、て、前記複数のモジュール間でのパケット処理順を決定する手段と、 決定された前記パケット処理順の情報を前記パケットに添付する手段と、 前記パケットに添付した前記パケット処理順の情報に基づ 、て、前記モジュールが 前記パケットの伝播先を決定する手段とを備えることを特徴とする通信装置。
[4] 請求項 3記載の通信装置であって、
前記パケットと、前記複数のモジュールに個別に保持されたメタ情報とに基づいて、 前記複数のモジュール毎に前記パケットの少なくともヘッダの情報を処理可能なモジ ユールかどうかの該非判定を行う手段と、
前記該非判定の結果、前記複数のモジュールのうち前記パケットの少なくともへッ ダの情報を処理可能なモジュールを特定し、特定されたモジュールの識別情報を順 番に連結した情報を前記複数のモジュール間でのパケット処理順の情報として前記 パケットに添付する手段と、
前記パケットに添付された情報の順番に従い前記パケットを前記複数のモジュール のうち該当するモジュールへ受け渡し、当該モジュールにより前記パケットを処理さ せる手段とをさらに備えることを特徴とする通信装置。
[5] 請求項 4記載の通信装置であって、
前記複数のモジュールを介して通信を行うアプリケーションソフトウェアと、 前記複数のモジュールと前記アプリケーションソフトウェアとの間に接続される送信 アプリケーションプログラムインタフェース（API)および受信アプリケーションプログラ ムインタフェース（API)と、
前記送信 APIから前記複数のモジュール間でのパケット処理順を決定する手段を 呼び出す手段とをさらに備えたことを特徴とする通信装置。
[6] 請求項 4記載の通信装置であって、
前記複数のモジュールを格納するモジュールリポジトリとの間で通信を行う手段と、 前記複数のモジュールのメタ情報のみを当該複数のモジュールと分離して保持す る手段と、
前記メタ情報により前記複数のモジュールのうち所定のモジュールがパケット処理 に必要と判断したときは、該当モジュールを前記モジュールリポジトリより取得する手 段と、
前記複数のモジュールのうち不要となったモジュールを前記通信装置上から削除 する手段とをさらに備えることを特徴とする通信装置。
[7] 請求項 4記載の通信装置であって、
前記複数のモジュール間でのパケット処理順の情報をキャッシュへ格納して保持す る手段と、
前記キャッシュの情報を検索して前記複数のモジュール間でのパケット処理順を決 定する手段とをさらに備えることを特徴とする通信装置。
[8] 請求項 6記載の通信装置であって、 前記モジュールリポジトリに格納された前記モジュールが更新された場合、当該モ ジュールの更新を検知する手段と、
前記モジュールの更新時に更新後のモジュールを取得し、新規のセッションにつ!/ヽ ては更新後のモジュールを適用し、更新前のモジュールが処理して 、る既存セッショ ンについては更新前のモジュールを適用する手段とをさらに備えることを特徴とする 通信装置。
[9] プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコ ルソフトウェアをコンピュータに実行させる通信装置の動作方法であって、
前記複数のモジュール毎に所定のメタ情報を個別に保持するステップと、 処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報と に基づ!/、て、前記複数のモジュール間でのパケット処理順を決定するステップと、 決定された前記パケット処理順の情報を前記パケットに添付するステップと、 前記パケットに添付した前記パケット処理順の情報に基づ 、て、前記モジュールが 前記パケットの伝播先を決定するステップとを有することを特徴とする通信装置の動 作方法。
[10] 請求項 9記載の通信装置の動作方法であって、
前記パケットと、前記複数のモジュールに個別に保持されたメタ情報とに基づいて、 前記複数のモジュール毎に前記パケットの少なくともヘッダの情報を処理可能なモジ ユールかどうかの該非判定を行うステップと、
前記該非判定の結果、前記複数のモジュールのうち前記パケットの少なくともへッ ダの情報を処理可能なモジュールを特定し、特定されたモジュールの識別情報を順 番に連結した情報を前記複数のモジュール間でのパケット処理順の情報として前記 パケットに添付するステップと、
前記パケットに添付された情報の順番に従い前記パケットを前記複数のモジュール のうち該当するモジュールへ受け渡し、当該モジュールにより前記パケットを処理さ せるステップとをさらに有することを特徴とする通信装置の動作方法。
[11] 請求項 10記載の通信装置の動作方法であって、
前記複数のモジュールと、モジュール化されて 、な 、アプリケーションソフトウェアと の間に接続された送信アプリケーションプログラムインタフェース (API)および受信 A PIにより、前記複数のモジュールを介して前記アプリケーションソフトウェアが通信を 行うステップと、
前記送信 APIから前記複数のモジュール間でのパケット処理順を決定する機構を 呼び出すステップとをさらに有することを特徴とする通信装置の動作方法。
[12] 請求項 10記載の通信装置の動作方法であって、
前記複数のモジュールを格納するモジュールリポジトリとの間で通信を行うステップ と、
前記複数のモジュールのメタ情報のみを当該複数のモジュールと分離して保持す るステップと、
前記メタ情報により前記複数のモジュールのうち所定のモジュールがパケット処理 に必要と判断したときは、該当モジュールを前記モジュールリポジトリより取得するス テツプと、
前記複数のモジュールのうち不要となったモジュールを前記通信装置上から削除 することを特徴とする通信装置の動作方法。
[13] 請求項 10記載の通信装置の動作方法であって、
前記複数のモジュール間でのパケット処理順の情報をキャッシュへ格納して保持す るステップと、
前記キャッシュの情報を検索して前記複数のモジュール間でのパケット処理順を決 定するステップとをさらに有することを特徴とする通信装置の動作方法。
[14] 請求項 12記載の通信装置の動作方法であって、
前記モジュールリポジトリに格納された前記モジュールが更新された場合、当該モ ジュールの更新を検知するステップと、
前記モジュールの更新時に更新後のモジュールを取得し、新規のセッションにつ!/ヽ ては更新後のモジュールを適用し、更新前のモジュールが処理して 、る既存セッショ ンにつ 、ては更新前のモジュールを適用するステップとをさらに有することを特徴と する通信装置の動作方法。
[15] プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコ ルソフトウェアをコンピュータに実行させる通信装置の動作プログラムであって、 コンピュータに、
前記複数のモジュール毎に所定のメタ情報を個別に保持するステップと、 処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報と に基づ!/、て、前記複数のモジュール間でのパケット処理順を決定するステップと、 決定された前記パケット処理順の情報を前記パケットに添付するステップと、 前記パケットに添付した前記パケット処理順の情報に基づ 、て、前記モジュールが 前記パケットの伝播先を決定するステップとを実行させることを特徴とする通信装置 の動作プログラム。
PCT/JP2006/325881 2005-12-28 2006-12-26 通信装置、その動作方法、及び動作プログラム WO2007077819A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/159,566 US20100238921A1 (en) 2005-12-28 2006-12-26 Communication apparatus, its operating method, and operating program
JP2007552934A JP4986265B2 (ja) 2005-12-28 2006-12-26 通信装置、その動作方法、及び動作プログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005-377591 2005-12-28
JP2005377591 2005-12-28

Publications (1)

Publication Number Publication Date
WO2007077819A1 true WO2007077819A1 (ja) 2007-07-12

Family

ID=38228172

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/325881 WO2007077819A1 (ja) 2005-12-28 2006-12-26 通信装置、その動作方法、及び動作プログラム

Country Status (4)

Country Link
US (1) US20100238921A1 (ja)
JP (1) JP4986265B2 (ja)
CN (1) CN101352008A (ja)
WO (1) WO2007077819A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5501052B2 (ja) * 2010-03-24 2014-05-21 キヤノン株式会社 通信装置、通信装置の制御方法、プログラム
US20150193129A1 (en) * 2014-01-07 2015-07-09 Samsung Electronics Co., Ltd. Method for executing application and electronic apparatus
US9887939B2 (en) 2015-03-11 2018-02-06 International Business Machines Corporation Transmitting multi-destination packets in overlay networks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05210548A (ja) * 1992-01-29 1993-08-20 Nec Corp プログラム動的格納方式
JPH06274328A (ja) * 1993-03-17 1994-09-30 Kanebo Ltd 複数の処理モジュールからなるプログラムの実行方法
JP2000330808A (ja) * 1999-05-19 2000-11-30 Mitsubishi Electric Corp トランザクション処理システム
JP2003046552A (ja) * 2001-07-30 2003-02-14 Fujitsu Ltd データ処理プログラム及びデータ処理装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7242681B1 (en) * 2002-05-17 2007-07-10 Sandstorm Enterprises, Inc. System and method for intercepting and authenticating packets during one or more communication sessions and automatically recognizing content

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05210548A (ja) * 1992-01-29 1993-08-20 Nec Corp プログラム動的格納方式
JPH06274328A (ja) * 1993-03-17 1994-09-30 Kanebo Ltd 複数の処理モジュールからなるプログラムの実行方法
JP2000330808A (ja) * 1999-05-19 2000-11-30 Mitsubishi Electric Corp トランザクション処理システム
JP2003046552A (ja) * 2001-07-30 2003-02-14 Fujitsu Ltd データ処理プログラム及びデータ処理装置

Also Published As

Publication number Publication date
JP4986265B2 (ja) 2012-07-25
US20100238921A1 (en) 2010-09-23
CN101352008A (zh) 2009-01-21
JPWO2007077819A1 (ja) 2009-06-11

Similar Documents

Publication Publication Date Title
US6262983B1 (en) Programmable network
US8539062B1 (en) Method and system for managing network traffic
CN107925674B (zh) 在内容为中心的网络（ccn）中推送数据的方法和装置
US6578084B1 (en) Packet processing using encapsulation and decapsulation chains
US9185185B2 (en) System and method for implementing application functionality within a network infrastructure
US7467078B2 (en) Portable distributed application framework
US7278061B2 (en) Building packets of data for testing a communication network
US20030018774A1 (en) System and method for load balancing in ad hoc networks
US20070110068A1 (en) Reply communication apparatus and ARP reply communication apparatus
WO2004112326A1 (ja) パケット転送方法及び装置
US7853695B2 (en) Using expressive session information to represent communication sessions in a distributed system
Gopalan et al. TCP/IP ILLUSTRATED
US6965574B1 (en) Network traffic data collection and query
WO2007077819A1 (ja) 通信装置、その動作方法、及び動作プログラム
KR100501080B1 (ko) 인터넷상 트래픽의 상위 계층 프로토콜들을 구분하는 방법및 장치
CN110505300A (zh) 一种ip网络与命名数据网络混合的新型链式代理方法
EP2139193A1 (en) A method of performing data mediation, and an associated computer program product, data mediation device and information system
US20020181507A1 (en) System and method of incremental parsing
EP3163838B1 (en) Header compression for ccn messages using dictionary learning
US6601106B1 (en) Packet processing using non-sequential encapsulation and decapsulation chains
WO2006073066A1 (ja) 通信装置、ルーティング方法及びプログラム
US9614772B1 (en) System and method for directing network traffic in tunneling applications
JP2009217841A (ja) パケット中継処理装置
JP4365397B2 (ja) パケット中継処理装置
JP2013534105A (ja) データネットワークのストリームを監視するためのデータ収集装置

Legal Events

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

Ref document number: 200680050023.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2007552934

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 12159566

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06843265

Country of ref document: EP

Kind code of ref document: A1