WO2007094465A1 - パケット送信方法、中継ノード、および受信ノード - Google Patents

パケット送信方法、中継ノード、および受信ノード Download PDF

Info

Publication number
WO2007094465A1
WO2007094465A1 PCT/JP2007/052879 JP2007052879W WO2007094465A1 WO 2007094465 A1 WO2007094465 A1 WO 2007094465A1 JP 2007052879 W JP2007052879 W JP 2007052879W WO 2007094465 A1 WO2007094465 A1 WO 2007094465A1
Authority
WO
WIPO (PCT)
Prior art keywords
destination
packet
node
multicast
address
Prior art date
Application number
PCT/JP2007/052879
Other languages
English (en)
French (fr)
Inventor
Eiichi Muramoto
Takahiro Yoneda
Toyoki Kawahara
Original Assignee
Matsushita Electric Industrial Co., Ltd.
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 Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to CN200780003058XA priority Critical patent/CN101371534B/zh
Priority to EP07714409.5A priority patent/EP1986380B1/en
Priority to US12/279,164 priority patent/US7876756B2/en
Publication of WO2007094465A1 publication Critical patent/WO2007094465A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing

Definitions

  • the present invention relates to a packet transmission method, a relay node, and a reception node that efficiently distribute packets to a plurality of terminals and routers via a network.
  • IP multicast specifies a group IP address that represents a set of terminals in the packet destination address field, and the router that receives the packet appropriately duplicates the packet and forwards it to multiple terminals beyond the router. Is a method of transmitting a packet.
  • IP multicast a packet received by a router is finally transferred to a network to which a destination group terminal is connected via multiple routers.
  • a router receives an IP multicast packet, it searches the routing table held by the router and determines the forwarding interface. If this interface is connected to broadcast media, the packet is forwarded using the link-level multicast delivery method.
  • This link level multicast (hereinafter "LMC" t) delivery method is to connect to the same broadcast media by specifying the multicast address as the destination address in the second layer packet of the OSI reference model. This is a delivery method that simultaneously delivers packets to multiple terminals. Therefore, according to LMC, when multiple destination group terminals and relay routers are connected on one broadcast medium, packets can be delivered efficiently.
  • Broadcast media is a network where the same media (cable or frequency band) is shared by multiple terminals. For example, broadcast media is specified by Ethernet (registered trademark) or IEEE802 lb specified by IEEE802.3.
  • Wireless LAN Local Area Network
  • FIG. 1 is a diagram showing a packet format of XC AST (Explicit Multicast) 6.
  • XCAST6 performs communication using IPv6 (Internet Protocol version 6) as the IP address.
  • the XCAST header (XCASTHdr) 1401 includes an IPv6 header (IPv6Hdr) 1402 and a routing header (RoutingHdr) 1403.
  • the source address 1404 of the IPv6 header 1402 describes the IP address of the packet source node, and the destination address 1405 describes a multicast address indicating XCAST6.
  • the routing header 1403 In the routing header 1403, all the destination addresses 0 to! 1 (1407) and destination port 0! 1 (1408) is described.
  • the destination bit map 1406 a bit is designated corresponding to the destination node, and the undelivered destination node and the delivered destination node are specified. Specifically, “1” is set to the undelivered destination node, and “0” is set to the destination node that has been delivered.
  • the destination bitmap 1406 and the destination address 1407 are combined into a “destination list” t ⁇ ⁇ .
  • the transmission device when a packet is delivered to a plurality of terminals, the transmission device creates an address list in the packet and transmits it to the first node in the destination list.
  • a router that supports XCAST receives the packet, it refers to the routing table to determine the forwarding interface to the link to which the undelivered destination node in the destination list is connected. Then, the router appropriately duplicates the packet, modifies only the bit corresponding to the undelivered destination node in the destination bit map 1406 to “1” indicating undelivered, and then, unrouted at the top of the destination list. Output the packet to the delivery node.
  • the terminal that is the destination node Upon receiving this, the terminal that is the destination node corrects the bit corresponding to itself in the destination bit map 1406 to “0” indicating that it has been delivered, and the packet is the terminal that is the destination node that has not been delivered. Send to. As a result, even if IP multicast address is not used, one packet is transmitted to multiple terminals sequentially, so that IP multicast Similar to a list, the same data can be transmitted to terminals in a plurality of destination groups.
  • Patent Document 2 discloses a method of performing delivery between XCAST-compatible routers by multicast as a packet delivery method for solving this problem.
  • FIG. 2 is a configuration diagram of a conventional IP network.
  • routers 1 to 4 (1501 to 1504), transmission devices (1511), and reception devices 1 to 4 (1512 to 1515) correspond to XCAST. At this time, the operation when transmitting the same data from the transmission device (1511) to all the reception devices will be described with reference to the drawings.
  • FIG. 3 is a sequence diagram showing an operation of data distribution by XCAST.
  • the transmitting device (1511) generates an XCAST packet in which the addresses of the receiving devices 1 to 4 (1512 to 1515) are described in the destination list, and transmits the packet to the router 1 (1501) (step
  • the router 1 determines a next hop node for transmitting the received XCAST packet to the undelivered destination node based on the route table.
  • router 1 1501
  • the neighbor solicitation message (Neighbor Solicitation Message) Search using a Neighbor Advertisement Message.
  • Router 1 duplicates the received packet for each next hop node so that only the undelivered destination node to which the next hop node relays the destination bit map becomes “1”. Correct it. Then, the multicast address obtained by the search is set as the destination address, and this XCAST socket is transmitted for each next hop node (steps S1602, S1605, S1607).
  • packets to the receiving device (hereinafter referred to as “R” as appropriate) 1 and the receiving device 2 are combined into one packet using the router (hereinafter referred to as “RT” as appropriate) 2 as the next hop node.
  • RT the router
  • the packet to the receiving device 3 (R3) is set to “1” only for the bit corresponding to the receiving device 3 (R3) in the destination bitmap with the router 3 (RT3) as the next hop node.
  • the packet to the receiving device 4 (R4) is also set to “1” for the bit corresponding to the receiving device 4 (R4) in the destination bitmap with the router 4 (RT4) as the next hop node. "Is set.
  • the router 2 transmits the packet to the first undelivered destination node in the destination list (step S1603).
  • the receiving device 1 modifies the bit corresponding to itself in the destination bit map 1406 to “0” and forwards it to the receiving device 2 in which “1” indicating the undelivered destination node is described (step S1). S 1604).
  • router 3 and router 4 also transfer the received packet to receiving apparatuses 3 and 4 that are undelivered destination nodes, respectively (steps S 1606 and S1608).
  • Non-Patent Literature l Y.Imai, M. Shin and Y. Kim, "XCAST6: eXplict Multicast on IPv6", IE EE / IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, Jan. 2003 Patent Literature 1: JP 2000 — No. 354063
  • Patent Document 2 US Patent Application Publication No. 2003Z0046425
  • An object of the present invention is to provide a packet transmission method, a relay node, and a reception node capable of transmitting an explicit multicast packet while suppressing consumption of a communication band of broadcast media.
  • the packet transmission method of the present invention is a packet transmission method for determining a transfer destination of an explicit multicast packet including a destination list in which addresses of a plurality of destination nodes are described based on the destination list.
  • the first node classifies the destination node whose address is described in the destination list into a destination group to be transmitted by multicast to the next hop node and a destination group to be transmitted by link level multicast to the next hop node.
  • a group classification step a transmission step in which the first node transmits an explicit multicast packet by multicast or link level multicast according to the classification in the group classification step, and a second node transmits the link level multicast.
  • Explicit multicast packet received Forward transfer prohibition step for transferring the packet only to an undelivered destination node whose address is described in the destination list included in the packet, which is located on the interface side other than the interface that received the packet. And to have.
  • the relay node of the present invention is a relay node that determines a transfer destination of an explicit multicast packet including a destination list in which addresses of a plurality of destination nodes are described based on the destination list, A multicast discriminator that determines whether or not the destination IP address of the received explicit multicast packet is a registered link-level multicast address, and that the destination IP address is determined to be a registered link-level multicast address.
  • the forwarding interface that sends the packet is determined based on the destination address and routing table described in the destination list included in the packet, and forwarding is performed for the interface other than the interface that received the packet.
  • the destination node address is described in the destination list, Interview to the next hop node - and a destination group that transmits by casting, transmission group classified into a destination group that transmits by the link level multicast to a next hop node And the destination list included in the packet is changed so that only the destination node classified into the link level multicast destination group is valid, and the link level multicast address is set as the destination address of the packet.
  • An explicit multicast packet is generated, and a next hop node to be relayed to a destination node classified in the destination group of the multicast is determined based on the routing table, and a destination list included in the packet is determined.
  • the explicit multicast packet generated by the generation unit is transmitted
  • a configuration is adopted in which the group classification unit includes a transmission unit that transmits to the valid destination node of the packet from the transfer destination interface determined for the packet.
  • the receiving node of the present invention is a receiving node that determines a forwarding destination of an explicit multicast packet including a destination list in which addresses of a plurality of destination nodes are described based on the destination list, A multicast discriminator that determines whether or not the destination IP address of the received explicit multicast packet is a registered link-level multicast address, and that the destination IP address is determined to be a registered link-level multicast address.
  • the forwarding of the explicit multicast packet is prohibited, and the self address among the valid destination addresses in the destination list included in the explicit multicast packet determined that the destination IP address is not a registered link level multicast address.
  • the address is corrected to invalid and the remaining valid Whether it has the capability to prohibit transmission of an explicit multicast packet that is a link-level multi-cache address with a registered destination IP address, and a transmission discriminator that can transmit the packet to one node at the destination address Q !, a receiving unit that receives a match, a route management unit that responds to the question and the combination with the function, and an explicit multicast packet that is allowed to be transmitted by the transmission determination unit. It adopts a configuration having a transmission unit that transmits by one of the destination nodes indicated by the valid destination addresses in the destination list included in the packet.
  • the same packet does not loop on the broadcast link.
  • XCAST packet transmission can be performed using link-level multicast. This makes it possible to efficiently deliver XCAST packets (explicit multicast packets) while consuming as little bandwidth as possible for broadcast media.
  • FIG.4 Diagram showing the contents of a Unicast packet that is also transmitted with conventional router power
  • FIG. 5 is a configuration diagram of an IP network using the packet transmission method according to the embodiment of the present invention.
  • FIG. 6 is a sequence diagram showing the packet transfer operation in this embodiment.
  • FIG. 7 is a diagram illustrating the contents of an XCAST packet transmitted from a router according to an embodiment of the present invention, where FIG. 7A is a diagram illustrating the contents of a link level multicast packet transmitted from the router, and FIG. Figure shows the contents of a unicast packet sent from a router
  • FIG. 8 is a block diagram showing a configuration of a router in the present embodiment
  • FIG. 9 is a diagram showing the structure of a routing table and an address table in the present embodiment, where FIG. 9A is a diagram showing the structure of the routing table, and FIG. 9B is a diagram showing the structure of the address table.
  • FIG. 10 is a format diagram of a neighbor solicitation message and a neighbor announcement message in the present embodiment, where FIG. 10A is a format diagram of a neighbor solicitation message, and FIG. 10B is a format diagram of a neighbor solicitation message.
  • FIG. 11 is a diagram showing a data configuration of entry information recorded in the transfer destination cache in the present embodiment, in which FIG. 11A shows a configuration of the transfer destination cache entry, and FIG. 11B shows a transfer destination entry.
  • 11C is a diagram showing the data structure of the LMC entry, and
  • FIG. 11D is a diagram showing the data structure of the unicast entry.
  • FIG. 12 is a flowchart showing a method for transferring an XCAST packet by the router according to the embodiment of the present invention.
  • FIG. 13 is a flowchart showing multicast processing in the present embodiment.
  • FIG. 14 is a flowchart showing a unicast process according to the present embodiment.
  • FIG. 15 is a block diagram showing a configuration of a receiving apparatus in this embodiment
  • FIG. 16 is a flowchart showing a method for transmitting an XCAST packet by the receiving apparatus in this embodiment.
  • FIG. 5 is a diagram showing a configuration of an IP network using the packet transmission method according to the present embodiment.
  • routers 11 to 13 are routers corresponding to the packet transmission method of the present invention (hereinafter referred to as “LMC compatible”), and router 4 (104) is compatible with XCAST. It is a conventional router.
  • the transmitting device (111) and the receiving devices 1 to 4 (112 to 115) are compatible with XCAS T, and the receiving device 5 (116) is an LMC compatible receiving device.
  • the transmitting device (11 1) is connected to the router 11 (101).
  • the receiving devices 1 and 2 (112 and 113) are on the same broadcast medium as the router 12 (102).
  • the receiving device 3 (114) is connected to the router 13 (10 3).
  • the receiving device 5 (116) is located on the broadcast medium to which the routers 4, 11 to 13 (104, 101 to 103) are connected.
  • FIG. 6 is a sequence diagram showing an operation of packet transfer up to the transmission device power reception device.
  • the transmitting device (111) transmits an XCAST packet in which the addresses of the receiving devices 1 to 5 (112 to 116) are described in the destination list to the router 11 (101) ( Step S1 001).
  • Router 11 (101) replicates the received XCAST packet, modifies the destination bitmap in the destination list, and receives routers 12, 13 (102, 103) that are LMC-compatible next-hop nodes.
  • Device 5 (116) transmits the data by link level multicast (step S1002).
  • FIG. 7A is a diagram showing the contents of the XCAST packet (link level multicast packet) transmitted by the router 11 (101) by link level multicast.
  • XCAST bucket The destination address of the destination describes a preset multicast address (MC).
  • MC preset multicast address
  • the destination bitmap only the power corresponding to the receiving devices 1 to 3 (112 to 114) and the receiving device 5 (116), which are relay destinations of the routers 12 and 13 (102 and 103), has the power S “l” Set to
  • the router 11 (101) transmits eight packets to the router 4 (104) corresponding to the conventional XCAST by multicast (step S1003 in FIG. 6).
  • FIG. 7B is a diagram showing the contents of an XCAST packet (a multicast packet) transmitted from the router 11 (101) by multicast.
  • the destination address of the XCAST packet describes router 4 as the next hop node.
  • the destination bitmap only the bit corresponding to the receiving device 4 (115) that is the relay destination of the router 4 (104) is set to “1”.
  • the router 12 (102) receives this, and transmits the received XCAST packet to the receiving device 1 (112), which is the undelivered destination node at the head of the destination list, by multicast. (Step S1004 in Fig. 6). This is because the receiving devices 1 and 2 (112, 113) do not support LMC and are nodes that support normal XCAST. Assume that router 12 (102) sends an XCAST packet by link level multicast. In this case, the receiving device 1 (112) duplicates and transfers the received packet to the receiving device 2 (113), which is an undelivered destination node, and the receiving device 2 (113) also receives an undelivered destination node. The received packet is duplicated and transferred to device 1 (112). As a result, the receiving device 1 (112) and the receiving device 2 (113) receive the same data twice. Such a situation can be prevented by performing the above-mentioned transmission by the cast.
  • receiving device 1 (112) receives the XCAST packet transmitted by multicast to itself, and copies and forwards the packet to receiving device 2 (113), which is an undelivered destination node. (Step S 1005).
  • the router 13 (103) When the router 13 (103) receives the XCAST packet by the link level multicast of the router 11 (101), the router 13 (103) transfers the packet to the receiving device 3 (114) (step S 1006).
  • Step S 1007 When the router 4 (104) receives the XCAST packet by the router 11 (101) force cast, the router 4 (104) receives the received packet in accordance with the conventional XCAST regulations. ) (Step S 1007).
  • the routers 12 and 13 which are relay nodes according to the present invention, receive an XCA ST packet by link level multicast, and receive an undelivered destination from the reception interface. Do not forward XCAST packets to the node! This is called the reverse path suppression (reverse transfer suppression) function, and this reverse path suppression function can prevent XCA ST packets from being repeatedly transferred on one broadcast medium.
  • An LMC compatible node is a node having a reverse path suppress function.
  • the router 11 (101) when there are a plurality of LMC-compatible nodes in the broadcast media, the router 11 (101) according to the present invention performs packet transmission by link level multicast to these nodes, Sends a packet by multicast. As a result, the router 11 (101) can efficiently use the communication band in the broadcast media.
  • FIG. 8 is a block diagram showing a configuration of the router according to the present invention.
  • the router 11 shown in FIG. 8 is a block diagram showing a configuration of the router according to the present invention. The router 11 shown in FIG.
  • a router 11 (101) includes an internal link port 201, a receiving unit 202, a multicast discrimination unit 203, a path management unit 204, a path storage unit 205, a transmission group classification unit 206, and a transfer destination cache 207. , Packet generation unit 208, transmission IZF unit 209, transmission unit 210, transmission unit
  • the internal link port 201, the external link port 212, the reception unit 202, the transmission unit 211, the transmission unit 210, and the multicast discrimination unit 203 will be described.
  • the internal link port 201 is an input / output port connected to a local area network (LAN) to which a transmitting device and a receiving device are connected.
  • LAN local area network
  • the external link port 212 is an input / output port connected to an uplink such as the Internet.
  • the receiving unit 202 is either the internal link port 201 or the external link port 212. Receive the packet.
  • Transmitting section 210 transmits a packet to internal link port 201.
  • the transmitting unit 211 transmits a packet to the external link port 212.
  • the multicast determination unit 203 determines whether or not the received packet is an explicit multicast packet based on XCAST. Then, when the received packet is an XCAST packet, the multicast discrimination unit 203 extracts a destination list from the received packet. On the other hand, when the received packet is a packet sent by link local multicast, the multicast discriminating unit 203 notifies the transmission group classifying unit 206 of the received interface information.
  • the route management unit 204 generates a neighbor solicitation message, inquires and inquires about route information of neighboring nodes, and receives a neighbor announcement message.
  • the route management unit 204 reflects the route information acquired by the inquiry in the route table and the address table, and stores it in the route storage unit 205 for management. Further, the route management unit 204 inquires at the same time whether or not the next hop node force is LMC compliant, and records the acquired information in the address table of the route storage unit 205 for management. Also, the route management unit 204 generates and responds to a neighbor notification message when it receives an LMC compatible Z non-compatible inquiry from another node.
  • FIG. 9 shows the structure of the route table and the address table stored in the route storage unit 205.
  • FIG. 9A is a diagram showing the structure of the route table stored in the route storage unit 205
  • FIG. 9B is a diagram showing the structure of the address table stored in the route storage unit 205.
  • the IP address of the destination receiving device is recorded in the field of the target node 401, and the IP address of the next hop node is recorded in the field of the next hop node 402. To be recorded.
  • the field of the next hop node 411 records the address of the node on the broadcast medium to which the self (router 11) is connected.
  • the MAC address 412 field records the MAC address of each node
  • the LMC correspondence 413 field records a flag indicating whether or not the packet transmission method of the present invention is supported.
  • Each node connects to the field of connection port 414.
  • “1” is set to the flag when LMC support is possible, and “0” is set to the flag when LMC is not compatible.
  • “2” is set for the connection port on the external link side
  • “1” is set for the connection port on the internal link side.
  • FIG. 10 shows a neighbor solicitation message and a neighbor announcement message used in the present embodiment.
  • FIG. 10A is a format diagram of a neighbor solicitation message
  • FIG. 10B is a format diagram of a neighbor announcement message.
  • the neighbor solicitation message in this embodiment includes the ICMPv6 neighbor solicitation message 303 defined in RFC2461, the IPv6 header 301 and destination option header 302 defined in RFC2460. It is an attached item.
  • the destination option 304 in the destination option header 302 uses a code of "10" for the first two bits.
  • the node that does not support LMC that has received the neighbor solicitation message cannot interpret this code, and therefore responds with an ICMPv6 Parameter Problem Message.
  • the specification of the IPv6 destination option header stipulates that the node that received the neighbor solicitation message can not interpret the destination option 304 and responds to the parameter problem message as a required operation! It is.
  • the document that specifies the IPv6 specification RFC2460 specifies four types of operations when an unknown option header is received. Which of the four types of operation when receiving an unknown option header is specified by the first two bits of the option header number.
  • the first 2 bits are defined as binary notation “10” and an option number corresponding to “Reply riCMP Pammeter Problem” is used.
  • this option number it is guaranteed that a non-LMC compatible node will immediately respond with a parameter problem message even if it receives a neighbor solicitation message in this embodiment.
  • the neighbor advertisement message in this embodiment is the ICMPv6 neighbor advertisement message 305 defined in RFC2461 and the IPv6 protocol defined in RFC2460.
  • a header 301 and a destination option header 302 are added.
  • the destination option 304 uses a code of “10” for the first two bits.
  • the transmission group classifying unit 206 collects undelivered destination nodes described in the destination list extracted by the multicast discriminating unit 203 as forwarding destination entries for each forwarding destination interface, and performs LMC entry group and multicasting. Classify into entry groups.
  • the LMC entry group is a group of destination nodes corresponding to the LMC
  • the multicast entry group is a group of destination nodes not compatible with the LMC.
  • the transmission group classification unit 206 searches for the next hop node corresponding to the undelivered destination node based on the routing table 400. Then, based on the address table 410, the transmission group classification unit 206 obtains the connection port 414 corresponding to the next hop node obtained by searching. In this way, the transmission group classification unit 206 obtains transfer destination interfaces of all undelivered destination nodes, and collects undelivered destination nodes as transfer destination entries for each transfer destination interface.
  • the transmission group classification unit 206 classifies the transfer destination entry into a destination node group (LMC entry group) corresponding to the LMC and a non-corresponding group (cast entry group), and Recorded in the transfer destination cache 207 as entry information. Further, when the reception port information is notified from the multicast discrimination unit 203, the transmission group classification unit 206 records the reception port information in the transfer destination cache 207 as a reception interface (I / F). If there is no notification of receiving port information from the multicast discriminating unit 203, a null code is recorded.
  • FIG. 11 shows the data structure of entry information recorded in the transfer destination cache 207.
  • FIG. 11A is a configuration diagram of the transfer destination cache entry.
  • the transfer destination cache entry 500 includes a transfer destination entry 501, an LMC entry 502, a multicast entry 503, and a reception IZF 504.
  • This transfer destination cache entry 500 is recorded for each packet to be transferred.
  • the reception IZF 504 includes a multicast discrimination unit 2
  • the port information notified from 03 is recorded. In the present embodiment, “1” indicating the internal link port or “2” indicating the external link port is recorded.
  • FIG. 11B is a configuration diagram of the transfer destination entry 501.
  • the transfer destination entry 501 includes a list entry number 511 and a destination field 512.
  • the number of list entries 511 indicates the total number of destination nodes having the same forwarding port among undelivered destination nodes described in the destination list of the received packet.
  • the IP address of the corresponding destination node is recorded.
  • the destination nodes 1 to 4 are recorded as undelivered nodes, but the number of destination nodes is not limited to this.
  • FIG. 11C is a configuration diagram of the LMC entry 502.
  • the LMC entry 5002 includes an LMC list entry number 521 and a destination field 522.
  • the LMC list entry number 521 indicates the total number of destination nodes of the LMC list entry group.
  • the IP address of the corresponding destination node is recorded.
  • the example in Fig. 11C shows the case where destinations 1, 2, and 4 are recorded.
  • FIG. 11D is a configuration diagram of the cast entry 503.
  • the unicast entry 503 is composed of a multicast list entry number 531 and a destination field 532.
  • the cast list entry number 531 indicates the total number of destination nodes of the cast entry group.
  • the IP address of the corresponding destination node is recorded.
  • the example in FIG. 11D shows a case where destination 3 is recorded.
  • the description method includes, for example, “2, IPv6 address 1, IPv6 address 2” in text representation of multiple IPv6 destination addresses using a comma as a delimiter. Can also be written.
  • the first “2” in this expression example indicates the number of list entries, and ⁇ ⁇ 6 address 1 ”and“ IPv6 address 2 ”indicate the destination.
  • the packet generation unit 208 generates a transfer bucket by copying the packet received by the reception unit 202 or receives a request from the route management unit 204 and generates a neighbor solicitation message. Further, the packet generation unit 208, when transferring the XCAST packet, transfers the transfer destination interface. A link level multicast packet and multicast packet are generated for each face.
  • the transmission IZF determination unit 209 determines the output port of the packet generated by the packet generation unit 208.
  • the characteristic difference between the XCAST packet transmission method according to the present invention and the conventional XCAST packet transmission method is that the conventional XCAST packet transmission method is processed for each next hop node.
  • the XCAST packet transmission method according to the present invention is characterized in that transmission processing is performed in units of transfer destination interfaces.
  • FIG. 12 is a flowchart showing a method for transferring an XCAST packet by the router according to the present invention.
  • multicast discriminating section 203 transmits the packet to the link level. It is determined whether or not it is received by multicast (step S702).
  • multicast discrimination section 203 When a packet is received by link level multicast (S702: YES), multicast discrimination section 203 notifies its reception interface to transmission group classification section 206, and transmission group classification section 206 receives the received reception interface. Is recorded in the reception IZF 504 of the transfer destination cache 2007 (step S703).
  • the transmission group classification unit 206 is not notified.
  • the reception interface information is not recorded in the reception IZF 504, but is recorded as null (N ULL) (step S704).
  • multicast discrimination section 203 extracts an undelivered destination node having destination bitmap 1406 force “l”, and sends it to transmission group classification section 206.
  • the transmission group classification unit 206 determines the transfer destination interface based on the routing table 400 and the address table 410 (step S705).
  • the transmission group classification unit 206 excludes the interface described in the reception IZF 504, and sets the destination node for each transfer destination interface. Are created, and transfer destination entry 501 is generated (step S706).
  • the transmission group classification unit 206 describes an undelivered destination node having the same transfer destination interface in the destination field 512 and describes the number of destination nodes in the list entry number 511. If null is described in the reception IZF 504, a transfer destination entry 501 is generated for every interface.
  • the router 11 (101) delivers packets from the transmitting device (111) to the receiving devices 1 to 5 (112 to 116).
  • the router 11 (101) detects from the routing table 400 and the address table 410 that the next hop node to the receiving devices 1 to 5 (112 to 116) is on the same broadcast medium, and the receiving devices 1 to 5 (112 to 116) are combined into one transfer destination entry 501.
  • the transmission group classification unit 206 does not generate the transfer destination entry 501 to the destination node relayed by the next hop node on the connection link of the output port described in the reception IZF 504. . For this reason, the reverse transfer that prevents packet transfer to the receiving port is suppressed.
  • transmission group classification section 206 classifies transfer destination entry 501 into LMC entry 502 and multicast entry 503 (step S707).
  • the transmission group classification unit 206 of the router 11 (101) determines that the next hop node to the receiving device 1 (112) and the receiving device 2 (113) as the destination nodes is the router 1 based on the routing table 400. 2 (102) is detected. Also, the transmission group classification unit 206 detects that the next hop node to the receiving device 3 (114) is the router 13, and the next hop node to the receiving device 4 (115) is the router 4 (104). Is detected. Further, the transmission group classification unit 206 detects that the receiving device 5 (116) is on the broadcast medium.
  • the transmission group classification unit 206 of the router 11 (101) is such that the router 12 (10 2), the router 13 (103), and the receiving device 5 are LMC compatible, and the router 4 (104) And that the transmitter (111) does not support LMC.
  • the transmission group classification unit 206 of the router 11 (101) 1 to 3, 5 (112 to 114, 116) are determined as LMC entry groups, and the receiving device 4 (115) is determined as a unicast entry group.
  • the packet generation unit 208 determines whether or not the destination is described in the LMC entry 521 of the transfer destination cache 207 (step S708), and if it is described (S708: YES)
  • Multicast processing is performed (step S709).
  • the packet generation unit 208 determines whether the destination node is described in the multicast entry 503 of the transfer destination cache 207 (step S710), and if it is described (S
  • the packet generation unit 208 and the transmission IZF determination unit 209 perform steps S706 to S706 described above for all transfer destination cache entries 500 generated for each transfer destination interface.
  • FIG. 13 is a flowchart showing details of multicast processing.
  • the packet generator 208 duplicates the packet received by the receiver 202 and sets the destination bitmap 1406 so that only the bit corresponding to the destination of the LMC entry 502 is “1” ( Step S901).
  • the packet generation unit 208 sets a link level multicast address defined in advance as the destination MAC address, and sets a destination address indicating LMC as the destination IP address (step S902).
  • the transmission IZF determination unit 209 receives the transmission packet from the packet generation unit 208 and determines the output port of the undelivered destination of the destination bitmap 1406 based on the address table 410. Then, the transmission IZF determination unit 209 transmits the XCAST packet from the internal link port 201 or the external link port 212 via the corresponding transmission units 210 and 211 (step S903).
  • FIG. 14 is a flowchart showing the details of the unicast process.
  • the packet generation unit 208 duplicates the packet received by the reception unit 202 and sets the destination bit map 1406 so that only the bit corresponding to the destination of the multicast entry 503 becomes “1”. Set (step S801).
  • the packet generation unit 208 refers to the routing table 400 and obtains the next hop node corresponding to the destination node described in the multicast entry 503. Then, the packet generator 208 sets only the bits of the destination bitmap 1 406 corresponding to all the destination nodes relayed by the obtained next hop node to “1” (step S802).
  • the packet generation unit 208 refers to the address table 410 and obtains the MAC address and output port corresponding to the next hop node. Then, the packet generation unit 208 sets the obtained MAC address as the destination MAC address of the copied packet, and notifies the transmission IZF determination unit 209 of the obtained connection port information (step S803).
  • the transmission IZF determination unit 209 receives the transmission packet from the packet generation unit 208, and transmits the internal link port 201 or the external via the transmission units 210 and 211 corresponding to the notified connection port. A packet is transmitted from the link port 212 (step S804).
  • the packet generation unit 208 determines whether or not the above steps S801 to S804 have been completed for all the destinations described in the cast entry 503, and all the destinations of the cast entry 503 are addressed. Repeat until the above process is completed (step S805).
  • the packet generation unit 208 of the router 11 (101) is LMC-compatible, the router 12 (102) being the next hop node of the receiving devices 1 and 2 (112, 113), and the receiving device 3 (114 The packet is transmitted to the router 13 (103) and the receiving device 5 (116), which are the next hop nodes to), by link level multicast. Further, the packet generation unit 208 of the router 11 (101) transmits the packet to the router 4 (104), which is non-LMC compliant and is the next hop node of the reception device 4 (115), by the multicast.
  • step S805 for all destinations of the cast entry, step Force to repeatedly execute S801 to S804 This step is also diverted when the limit of the number of entries in the transfer method cache is exceeded.
  • the LRU (Least Reset Used) algorithm may be used for the forwarding cache entry, for example, by appropriately aging the entry using the frequency of use of the entry. Alternatively, it may be maintained using another algorithm such as FIFO (First In First Out).
  • an operation may be performed in which a multicast process is performed for all destinations.
  • the router gives up the creation of the forwarding cache entry, and then performs multicast processing and multicast processing based on the forwarding cache entry in the processing of packets that have not been hit by the forwarding cache entry. What are you doing?
  • the above is the method for transferring the XCAST packet by the router according to the present invention.
  • the transmission group classification unit 206 When the transmission group classification unit 206 generates the forwarding destination cache entry 500, the MAC address and LMC correspondence information of the next hop node are registered in the address table! Request address resolution of the next hop node corresponding to.
  • the route management unit 204 instructs the packet generation unit 208 to generate a neighbor solicitation message for the destination address.
  • the packet generation unit 208 generates a neighbor solicitation message in this embodiment for resolving the MAC address of the instructed destination address, and sends it to the transmission IZF determination unit 209.
  • the transmission IZF determination unit 209 transmits a neighbor solicitation message to all output ports via the transmission units 210 and 211 by link local multicast.
  • each node on the broadcast media Upon receiving the neighbor solicitation message in this embodiment, each node on the broadcast media transmits a neighbor advertisement message after enabling link level multicast if it matches the destination address. To do. At this time, the destination address is If the route management unit 204 of the matched node recognizes that the code described in the destination option 304 indicates LMC support, it responds with a neighbor advertisement message in which the code is copied. If the destination option 304 cannot be recognized as indicating the code power LMC correspondence described in the destination option 304, the route management unit 204 of the node with the matching destination address responds with a parameter problem message.
  • the route management unit 204 of the transmission source node of the neighbor solicitation message in the present embodiment when receiving the neighbor advertisement message via the receiving unit 202, is a legitimate response or a parameter problem message? To determine. When the legitimate response is obtained, the route management unit 204 registers the notified MAC address in the MAC address field 412 of the address table 410, and describes “1” in the LMC correspondence field 413 to indicate that the correspondence is possible. To do.
  • the route management unit 204 registers the notified MAC address in the MAC address field 412 of the address table 410, and displays “0” indicating that the LMC correspondence field 413 is not available. ".
  • the router according to the present invention can acquire information related to the node on the broadcast medium necessary for classifying the forwarding destination entry into the LMC entry group and the multicast entry group. become.
  • the neighbor solicitation message and the neighbor advertisement message in the present embodiment are not limited to the power specified by using the IPv6 destination option header, and may use original messages.
  • the destination node when the destination node does not support this neighbor solicitation message, it may not respond.
  • the source node performs a timeout process when it does not respond within a certain period of time, and performs the same process as when a negative response is received when a timeout occurs.
  • the link level multicast address used when delivering a packet by LMC (Linter Level Multicast Delivery Method) according to the packet transmission method of the present invention is a predetermined multicast address.
  • an unused multicast address may be secured using SAP (Session Announcement Protocol) that confirms the usage status of the multicast address and the multicast address may be used prior to packet delivery in the LMC.
  • SAP Session Announcement Protocol
  • an unused multicast can be used by using an extension of MADCAP specified by RFC2907, which is a request response based protocol for assigning an unused multicast address, or DHCP specified by RFC2131, RFC2132, and RFC3315. Try to get an address and use it.
  • FIG. 15 is a block diagram showing a configuration of receiving apparatus 4 and corresponds to FIG. Figure
  • the receiving device 4 includes an internal link port 201, a receiving unit 202, a multicast discriminating unit 203, a path storage unit 205, a transfer destination cache 207, a packet generation unit 208, and a transmission IZF unit 209.
  • Data extraction section 1101 extracts data from the received packet.
  • Application part 1101 extracts data from the received packet.
  • the transmission discrimination unit 1103 Upon receiving notification from the multicast discrimination unit 203 that the explicit multicast packet has been received by link level multicast, the transmission discrimination unit 1103 prohibits the transfer of the received explicit multicast packet.
  • the route management unit 1104 manages the MAC address and connection port of other receiving devices on the broadcast medium using an address table, There is no routing table. Further, when the route management unit 1104 receives an inquiry as to whether or not it is LMC compatible by the router power neighbor request message according to the present invention, it responds that it is LMC compatible by the neighbor advertisement message.
  • FIG. 16 is a flowchart for explaining a method for transferring the XCAST packet by the receiving apparatus of the present invention.
  • the reception unit 202 transmits the packet to the data extraction unit 1101.
  • the data extraction unit 1101 extracts data from the received packet and sends it to the application unit 1102, and the application unit 1102 performs application processing using the received data (step S 1202).
  • the multicast discriminating unit 203 discriminates whether or not the destination address is a predefined multicast address (step S1203), and the result is sent to the transmission discriminating unit. Notify 1103.
  • the transmission discriminating unit 1103 does not receive the XCAST packet even if it is received. Do not create a forwarding entry to 207.
  • the transmission discriminating unit 1103 uses its destination bitmap in the destination list included in the XCAST packet. The bit is updated to “0”, and a destination power transfer destination entry in which “1” of the destination bitmap is set is generated in the transfer destination cache 207 (step S1 204).
  • the packet generation unit 208 duplicates the received packet and sets the destination bitmap to “1” only for the destination of the transfer destination entry. (Step S1205). In addition, the packet generation unit 208 selects the first undelivered destination address of the destination bitmap, and searches for the corresponding MAC address based on the address table. Then, the packet generation unit 208 sets the MAC address obtained by searching for the destination address (step S 1206).
  • transmission IZF determination section 209 determines a connection port corresponding to the destination address based on the address table, and transmits the generated XCAST packet to corresponding transmission section 210 (step S1207). .
  • transmission IZF determination unit 209 is not essential.
  • the router that is a relay node according to the present invention since the receiving device according to the present invention responds with a neighbor notification message indicating that it is LMC compatible, the router that is a relay node according to the present invention has an LMC compatible receiving device on the broadcast.
  • the XC AST packet can be transmitted by link level multicast including the receiving device.
  • the relay node according to the present invention can obtain information as to whether or not each node on the same broadcast medium is LMC-compatible. It becomes possible to classify undelivered nodes into a group of destination nodes whose next hop node is LMC-compliant and a group of destination nodes that are not LMC-compliant. Since the router, which is a relay node according to the present invention, can transmit the XCAST packet to the next hop node corresponding to LMC by link level multicast, it is possible to use the communication band efficiently.
  • the router as the relay node according to the present invention transmits a packet by multicast to the next hop node that does not support LMC, it is possible to prevent the packet from being looped on the broadcast media.
  • the packet transmission method determines a transfer destination based on a destination list in which a plurality of destination addresses are described.
  • the first node classifies it into a destination group that is transmitted by multicast to the next hop node and a destination group that is transmitted by link level multicast.
  • the destination group transmitted by this unicast is the group of the next hop node that relays the explicit multicast packet to the destination node in the destination list.
  • the first node transmits an explicit multicast packet by multicast or link level multicast according to the classification.
  • the second node receives an explicit multicast packet transmitted by link-level multicast, only to the undelivered destination node described in the destination list located on the interface side other than the received interface. Explicit multicast packet Transfer the network.
  • the first node inquires whether or not the next hop node has a reverse transfer prohibition function.
  • This reverse transfer function is a function that does not transfer from the received interface when the XCAST packet is received by link level multicast as described above. Then, if the next hop node responds to the inquiry that it has a reverse transfer prohibition function, the first node in the above classification, the relay destination address relayed by the next hop node that responded as such.
  • nodes as link-level multicast destination groups.
  • the destination node that has made other responses is classified as a destination group of the cast.
  • the first node may classify the destination node of the destination list into an XCAST packet by link level multicast !, a group, and a send !, and a group. can do.
  • the first node further includes a destination node described in the destination list corresponding to the destination node. Classify each interface with the link to which the hop node is connected. Then, the first node classifies the destination group for each transfer destination interface.
  • the first node relays the next hop node relayed to the destination node belonging to the destination group of the multicast.
  • the destination list is changed so that only the destination node that is the relay destination of the next hop node is valid.
  • the first node transmits an explicit multicast packet including the changed destination list to the next hop node by multicast.
  • the first node performs the XCAS by the cast for each next hop node.
  • T packets can be transmitted.
  • the destination list is set so that only the destination node classified into the multicast destination group by the first node is valid. change. Then, the first node transmits an explicit multicast packet including the changed destination list by multicast.
  • the first node can transmit the XCAST packet by link level multicast to the group that may transmit the XCAST packet by link level multicast.
  • the first node acquires an unused link level multicast address.
  • the link level multicast address When sending an explicit multicast packet by the first node force S link level multicast, set the link level multicast address as the destination IP address and send it.
  • the first node can use the multicast address without duplication.
  • the relay node according to the seventh aspect of the present invention determines a transfer destination based on a destination list in which a plurality of destination addresses are described.
  • the relay node of the present invention includes a multicast discrimination unit, a transmission group classification unit, a packet generation unit, and a transmission unit.
  • the multicast discrimination unit discriminates whether or not the destination IP address of the received explicit multicast packet is a registered link level multicast address. Also, the transmission group classification unit, when the multicast determination unit determines that it is a registered link level multicast address, based on the destination address and the route table described in the destination list, the transmission group classification unit This determines the destination interface to send. Then, the transmission group classification unit transmits the explicit multicast packet to the next hop node by multicast for each transfer destination interface other than the interface that has received the explicit multicast packet. Destination lists are classified into destination groups and destination groups that are transmitted by link level multicast.
  • the packet generator changes the destination list included in the received explicit multicast packet so that only the destination of the multicast destination group is valid. Then, the packet generation unit sets a multicast address as the destination address or determines a next hop node to be relayed to a destination node belonging to the destination group of the multicast based on the route table. Furthermore, the packet generator changes the destination list so that only the destination node that is the relay destination of the next hop node is valid, and sets the address of the next hop node as the destination address.
  • the transmission unit also transmits the explicit multicast packet generated by the packet generation unit with the forwarding interface power determined by the transmission group classification unit and corresponding to the valid destination node of the explicit multicast packet. Is.
  • the relay node can distribute the XCAST packet by link level multicast so that the same packet does not loop on the broadcast link. As a result, it is possible to reduce communication bandwidth consumption in broadcast media.
  • the relay node further includes a route management unit.
  • this route management unit inquires of the node on the broadcast media whether or not the explicit multicast packet has a function not to forward the explicit multicast packet to the received interface. .
  • the transmission group classifying unit classifies the next hop node that has responded as having a function without being forward-forwarded to the multicast destination group. Further, the transmission group classification unit classifies the next hop node that has made a response other than the response into a destination group of the cast.
  • the relay node may classify the destination node in the destination list into a group, a group, a group, a group, a group, and a group. be able to.
  • the receiving node determines a forwarding destination based on a destination list in which a plurality of destination addresses are described.
  • the receiving node of the present invention is: A multicast discrimination unit, a transmission discrimination unit, a reception unit, a route management unit, and a transmission unit are included.
  • the multicast discriminating unit discriminates whether or not the destination IP address of the received explicit multicast packet is a registered link level multicast address.
  • the transmission discriminating unit prohibits the transfer of an explicit multicast packet when the multicast discriminating unit discriminates that it is a registered link level multicast address. On the other hand, if it is not determined, the transmission determination unit corrects its own address to be invalid among the valid destination addresses in the destination list included in the explicit multicast bucket, and moves to one node of the remaining valid destination addresses.
  • the explicit multicast packet can be sent.
  • the receiving unit receives an inquiry as to whether or not the transmission determining unit has a function of prohibiting transfer of an explicit multicast packet.
  • the route management unit responds to the inquiry that it has the function.
  • the transmission determination unit determines that the explicit multicast packet can be transmitted
  • the transmission unit transmits the modified explicit multicast packet to one node having a valid destination address by multicast. Is.
  • the receiving device when the receiving device receives the XCAST packet by link level multicasting, it suppresses reverse transfer to other receiving devices on the broadcast media, so that the packet loops on the broadcast media. Can be prevented.
  • the present invention is useful as a packet transmission method, a relay node, and a reception node capable of transmitting an explicit multicast packet while suppressing consumption of a communication band of broadcast media in distribution of an XCAST packet or the like.

Landscapes

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

Abstract

　ブロードキャストメディアの通信帯域の消費を抑えながら、明示的マルチキャストパケットを伝送することができるパケット送信方法。本方法では、リンクレベルマルチキャストにより明示的マルチキャストパケットを受信しても、同じパケットをブロードキャストメディアへ出力してしまうことがない次ホップノードに対してのみリンクレベルマルチキャストによる送信を行い、それ以外の次ホップノードに対しては、ユニキャストにより明示的マルチキャストパケットを送信する。

Description

明 細 書
パケット送信方法、中継ノード、および受信ノード
技術分野
[0001] 本発明は、ネットワークを介して、複数の端末やルータにパケットを効率的に配送す るパケット送信方法、中継ノード、および受信ノードに関する。
背景技術
[0002] 従来より、 OSI (Open Systems Interconnection)参照モデルの第三層のパケット送 信方法として IP (Internet Protocol)マルチキャストがあった。 IPマルチキャストとは、 パケットの宛先アドレス欄に端末の集合を現すグループ IPアドレスを指定し、ノ ケット を受け取ったルータが適切にパケットを複製し、そして、転送することによりルータを 超えて複数の端末にパケットを送信する方法である。 IPマルチキャストでは、ルータ が受け取ったパケットは、複数のルータを経由して、最終的に宛先グループの端末 が接続されているネットワークまで転送される。あるルータで、 IPマルチキャストバケツ トを受け取ると、ルータが保持している経路表を探索して、転送先のインターフェイス を決定する。このインターフェイスがブロードキャストメディアに接続されて ヽる場合、 パケットはリンクレベルマルチキャスト配送方法で転送される。
[0003] このリンクレベルマルチキャスト（以下「LMC」 t 、う）配送方法とは、 OSI参照モデ ルの第二層のパケット中の宛先アドレスにマルチキャストアドレスを指定して、同一の ブロードキャストメディア上に接続された複数の端末にパケットを同時に届ける配送方 法である。このため、 LMCによれば、宛先グループの端末や中継のルータがひとつ のブロードキャストメディア上に複数接続されている場合、効率的にパケットを配送で きる。なお、ブロードキャストメディアは、同一のメディア（ケーブルや周波数帯）を複 数の端末で共有するネットワークであり、例えば、 IEEE802.3で規定されるイーサネ ット（登録商標）や IEEE802 1 lbで規定される無線 LAN (Local Area Network)が該 当する。
[0004] し力し、 IPマルチキャストでは、配送するグループ毎に IPマルチキャストアドレスを 割り当てる必要があり、動的にグループの構成ノードが変化する場合には対応が困 難である。また、経路上のすべてのルータの経路表に IPマルチキャストアドレスの設 定を行う必要がある。
[0005] そこで、別の第三層のパケット配送方法として、非特許文献 1および特許文献 1に 示される明示的マルチキャスト配送方法 (以後「XCAST」と略記する。 )が提案されて いる。
[0006] 図 1は、 XC AST (Explicit Multicast) 6のパケットのフォーマットを示す図である。な お、この XCAST6は、 IPアドレスとして IPv6 (Internet Protocol version 6)を用いて 通信を行うものである。
[0007] 図 1に示すように、 XCASTヘッダ（XCASTHdr) 1401は、 IPv6ヘッダ（IPv6Hdr) 14 02とルーティングヘッダ（RoutingHdr) 1403から構成される。 IPv6ヘッダ 1402の送 信元アドレス 1404には、パケットの送信元ノードの IPアドレスが記述され、宛先アドレ ス 1405には、 XCAST6であることを示すマルチキャストアドレスが記述される。
[0008] ルーティングヘッダ 1403には、マルチキャストの送信先である、すべての宛先アド レス 0〜！ 1 (1407)と宛先ポート（port) 0〜！ 1(1408)が記述される。そして、宛先ビット マップ 1406では、宛先ノードに対応してビットが指定され、未配送の宛先ノードと配 送済みの宛先ノードとが明示される。具体的には、未配送の宛先ノードには「1」がセ ットされ、配送済みの宛先ノードには「0」がセットされる。以下の説明では、宛先ビット マップ 1406と宛先アドレス 1407とを合わせて、「宛先リスト」 t ヽぅ。
[0009] XCASTでは、複数の端末にパケットを配送する場合、送信装置はパケット中に宛 先リストを作成し、宛先リストの先頭ノードへ送信する。 XCASTに対応したルータは、 そのパケットを受信すると、経路表を参照して、宛先リスト中の未配送の宛先ノードが 接続するリンクへの転送先インターフェイスを決定する。そして、そのルータは、適宜 パケットを複製し、宛先ビットマップ 1406のうち未配送の宛先ノードに該当するビット のみを未配送を示す「1」に修正し、その後、宛先リストの先頭に位置する未配送ノー ドへパケットを出力する。宛先ノードである端末は、これを受信すると、宛先ビットマツ プ 1406の自己に該当するビットを配送済みであることを示す「0」に修正し、そのパケ ットを未配送の宛先ノードである端末へ送信する。これにより、 IPマルチキャストァドレ スを使用しなくても、複数の端末に一つのパケットが順次伝わることで、 IPマルチキヤ ストと同様に複数の宛先グループの端末へ同一データを送信することが可能となる。
[0010] しかしながら、 XCASTによる配送方法では、ルータの転送先インターフェイスがブ ロードキャストメディアである場合、リンクレベルマルチキャスト配送方法で配送すると 、複数の XCASTのパケットがそのブロードキャストメディアでループし続けるおそれ がある。これは、 XCASTのパケットを受信したルータ力 宛先リストの未配送ノードへ 受信パケットを転送しょうとして、受信したインターフェイスから XCASTのパケットを 送信してしまうためである。
[0011] 特許文献 2は、この問題を解決するパケット配送方法として、 XCAST対応のルータ 間の配送をュ-キャストによって行う方法を開示している。
[0012] 図 2は、従来の IPネットワークの構成図である。
[0013] 図2にぉぃて、ルータ1〜4 (1501〜1504)、送信装置（1511)、及び受信装置1 〜4 (1512〜1515)は XCASTに対応している。このとき、送信装置（1511)からす ベての受信装置へ同一データを送信するときの動作について図面を用いて説明す る。
[0014] 図 3は、 XCASTによるデータ配信の動作を示すシーケンス図である。
[0015] 図 3において、送信装置（1511)は受信装置 1〜4 (1512〜1515)のアドレスを宛 先リストに記述した XCASTパケットを生成し、ルータ 1 (1501)へ送信する (ステップ
S160 。
[0016] 次に、ルータ 1は、受信した XCASTパケットの未配信宛先ノードへ送信するための 次ホップノードを経路表に基づいて決定する。このとき、ルータ 1 (1501)は、次ホッ プノードであるルータ 2〜4 ( 1502〜 1504)のリンクレベルのュ-キャストアドレスが 不明な場合は、近隣要請メッセージ（Neighbor Solicitation Message)と、近隣告知メ ッセーシ (Neighbor Advertisement Message)を用 ヽて探索する。
[0017] 次に、ルータ 1 (1501)は、次ホップノード毎に受信パケットを複製し、宛先ビットマ ップをその次ホップノードが中継する対象の未配信宛先ノードのみ「1」となるように修 正する。そして、探索して得たュ-キャストアドレスを宛先アドレスに設定し、次ホップ ノード毎【こ XCASTノ ケットを送信する（ステップ S1602、 S1605、 S1607)。
[0018] ここで、ルータ 1 (1501)力も次ホップノードへ送信される XCASTパケットの内容を 図 4に示す。
[0019] 図 4Aに示すように、受信装置（以下適宜「R」という） 1と受信装置 2へのパケットは、 ルータ（以下適宜「RT」という） 2を次ホップノードとして一つのパケットにまとめられる 。また、宛先ビットマップにおいて、受信装置 1 (R1)と受信装置 2 (R2)に該当するビ ットのみが「1」に設定され、他の宛先のビットは「0」が設定される。同様にして、図 4B に示すように、受信装置 3 (R3)へのパケットは、ルータ 3 (RT3)を次ホップノードとし 、宛先ビットマップの受信装置 3 (R3)に該当するビットのみ「1」が設定される。また、 図 4Cに示すように、受信装置 4 (R4)へのパケットも同様に、ルータ 4 (RT4)を次ホッ プノードとし、宛先ビットマップの受信装置 4 (R4)に該当するビットのみ「1」が設定さ れる。
[0020] 次に、ルータ 2は、このパケットを受信すると、宛先リストの先頭の未配信宛先ノード へ送信する (ステップ S1603)。受信装置 1は、このパケットを受信すると、宛先ビット マップ 1406の自己に該当するビットを「0」に修正し、未配信宛先ノードを示す「1」が 記述された受信装置 2へ転送する (ステップ S 1604)。
[0021] 同様にして、ルータ 3、ルータ 4も、それぞれ未配信宛先ノードである受信装置 3、 4 へ受信したパケットを転送する（ステップ S 1606、 S1608)。
[0022] このように、特許文献 2に記載の方法によれば、明示的マルチキャストとュ-キャスト とを組み合わせることにより、ブロードキャストメディア上でパケットのループを生じるこ となぐすべての受信装置へ同一データを配信することができる。
非特許文献 l :Y.Imai, M.Shin and Y.Kim, "XCAST6: eXplict Multicast on IPv6", IE EE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, Jan. 2003 特許文献 1：特開 2000— 354063号公報
特許文献 2：米国特許出願公開第 2003Z0046425号明細書
発明の開示
発明が解決しょうとする課題
[0023] し力しながら、特許文献 2に開示された従来の方法では、ブロードキャストメディアに 接続されている複数の受信装置やルータそれぞれに同一パケットを送信する場合も 、ュ-キャストにより個別に送信を行うため、ブロードキャストメディアの通信帯域の消 費が大きくなるという課題があった。
[0024] 本発明の目的は、ブロードキャストメディアの通信帯域の消費を抑えながら、明示的 マルチキャストパケットを伝送することができるパケット送信方法、中継ノード、および 受信ノードを提供することにある。
課題を解決するための手段
[0025] 本発明のパケット送信方法は、複数の宛先ノードのアドレスが記述された宛先リスト を含む明示的マルチキャストパケットの転送先を、前記宛先リストに基づいて決定す るパケット送信方法であって、第一ノードが、前記宛先リストにアドレスが記述された 宛先ノードを、次ホップノードへのュ-キャストにより送信する宛先グループと、次ホッ プノードへのリンクレベルマルチキャストにより送信する宛先グループとに分類するグ ループ分類ステップと、前記第一ノードが、前記グループ分類ステップによる分類に 従って、明示的マルチキャストパケットをュ-キャストまたはリンクレベルマルチキャス トにより送信する送信ステップと、第二ノードが前記リンクレベルマルチキャストにより 明示的マルチキャストパケットを受信したとき、前記パケットを受信したインターフェイ ス以外のインターフェイス側に位置する、前記パケットに含まれる宛先リストにアドレス が記述された未配送の宛先ノードへのみ、前記パケットを転送する逆方向転送禁止 ステップとを有するようにした。
[0026] また、本発明の中継ノードは、複数の宛先ノードのアドレスが記述された宛先リスト を含む明示的マルチキャストパケットの転送先を、前記宛先リストに基づいて決定す る中継ノードであって、受信した明示的マルチキャストパケットの宛先 IPアドレスが、 登録済みのリンクレベルマルチキャストアドレスであるか否かを判別するマルチキャス ト判別部と、宛先 IPアドレスが登録済みのリンクレベルマルチキャストアドレスであると 判別された明示的マルチキャストパケットについて、当該パケットに含まれる宛先リス トに記述された宛先アドレスと経路表に基づいて当該パケットを送出する転送先イン ターフェイスを決定し、当該パケットを受信したインターフェイス以外の転送先インタ 一フェイス毎に、当該パケットに含まれる宛先リストにアドレスが記述された宛先ノード を、次ホップノードへのュ-キャストにより送信する宛先グループと、次ホップノードへ のリンクレベルマルチキャストにより送信する宛先グループとに分類する送信グルー プ分類部と、前記パケットに含まれる宛先リストを前記リンクレベルマルチキャストの宛 先グループに分類された宛先ノードのみ有効となるように変更して当該パケットの宛 先アドレスにリンクレベルマルチキャストアドレスを設定した明示的マルチキャストパケ ットを生成するとともに、前記ュ-キャストの宛先グループに分類された宛先ノードへ 中継する次ホップノードを前記経路表に基づ 、て決定し、前記パケットに含まれる宛 先リストを当該次ホップノードの中継先の宛先ノードのみ有効となるように変更して当 該パケットの宛先アドレスに当該次ホップノードのアドレスを設定した明示的マルチキ ャストパケットを生成するパケット生成部と、前記パケット生成部により生成された明示 的マルチキャストパケットを、前記送信グループ分類部が当該パケットに対して決定 した転送先インターフェイスから、当該パケットの有効な宛先ノードに送信する送信部 とを有する構成を採る。
[0027] また、本発明の受信ノードは、複数の宛先ノードのアドレスが記述された宛先リスト を含む明示的マルチキャストパケットの転送先を、前記宛先リストに基づいて決定す る受信ノードであって、受信した明示的マルチキャストパケットの宛先 IPアドレスが、 登録済みのリンクレベルマルチキャストアドレスであるか否かを判別するマルチキャス ト判別部と、宛先 IPアドレスが登録済みのリンクレベルマルチキャストアドレスであると 判別された前記明示的マルチキャストパケットの転送を禁止するとともに、宛先 IPアド レスが登録済みのリンクレベルマルチキャストアドレスではないと判別された明示的マ ルチキャストパケットに含まれる宛先リストの有効な宛先アドレスのうち自己のアドレス を無効に修正した上で残りの有効な宛先アドレスの一つのノードへ当該パケットを送 信可とする送信判別部と、宛先 IPアドレスが登録済みのリンクレベルマルチキヤストア ドレスである明示的マルチキャストパケットの転送を禁止する機能を有する力否かの 問!、合わせを受信する受信部と、前記問 、合わせに対して前記機能を有することを 応答する経路管理部と、前記送信判別部が送信可とした明示的マルチキャストパケ ットを、当該パケットに含まれる宛先リストの有効な宛先アドレスが示す宛先ノードの 一つへュ-キャストにより送信する送信部とを有する構成を採る。 発明の効果
[0028] 本発明によれば、ブロードキャストリンク上に同じパケットがループすることがなくなり 、 XCASTにおけるパケット送信においても、リンクレベルマルチキャストによる配信を 行うことが可能となる。これにより、ブロードキャストメディアの通信帯域の消費をできる だけ抑えて、効率的に XCASTパケット（明示的マルチキャストパケット）を配送できる
図面の簡単な説明
[図 1]従来の XCAST6のパケットのフォーマット図
[図 2]従来の IPネットワークの構成図
[図 3]従来の XCASTによるデータ配信の動作を示すシーケンス図
[図 4]従来のルータ力も送信されるュニキャストパケットの内容を示す図
[図 5]本発明の実施の形態に係るパケット送信方法を用いた IPネットワークの構成図
[図 6]本実施の形態におけるパケット転送の動作を示すシーケンス図
[図 7]本発明の実施の形態におけるルータカゝら送信される XCASTパケットの内容を 示す図であって、図 7Aは、ルータから送信されるリンクレベルマルチキャストパケット の内容を示す図、図 7Bは、ルータから送信されるュニキャストパケットの内容を示す 図
[図 8]本実施の形態におけるルータの構成を示すブロック図
[図 9]本実施の形態における経路表およびアドレス表の構造を示す図であって、図 9 Aは、経路表の構造を示す図、図 9Bは、アドレス表の構造を示す図
[図 10]本実施の形態における近隣要請メッセージおよび近隣告知メッセージのフォ 一マット図であって、図 10Aは、近隣要請メッセージのフォーマット図、図 10Bは、近 隣告知メッセージのフォーマット図
[図 11]本実施の形態における転送先キャッシュに記録されるエントリ情報のデータ構 成を示す図であって、図 11Aは、転送先キャッシュエントリの構成を示す図、図 11B は、転送先エントリのデータ構成を示す図、図 11Cは、 LMCエントリのデータ構成を 示す図、図 11Dは、ュニキャストエントリのデータ構成を示す図
[図 12]本発明の実施の形態におけるルータが XCASTパケットを転送する方法を示 すフロー図
[図 13]本実施の形態におけるマルチキャスト処理を示すフロー図 [図 14]本実施の形態におけるュニキャスト処理を示すフロー図
[図 15]本実施の形態における受信装置の構成を示すブロック図
[図 16]本実施の形態における受信装置が XCASTパケットを転送する方法を示すフ ロー図
発明を実施するための最良の形態
[0030] 本発明の実施の形態について、図面を用いて以下に説明する。
[0031] 図 5は、本実施の形態に係るパケット送信方法を用いた IPネットワークの構成を示 す図である。
[0032] 図 5において、ルータ11〜13 (101〜103)は、本発明のパケット送信方法に対応 した（以下「LMC対応」という）ルータであり、ルータ 4 (104)は、 XCASTに対応して いる従来のルータである。送信装置（111)、受信装置1〜4 (112〜115)は、 XCAS Tに対応しており、受信装置 5 (116)は LMC対応の受信装置である。送信装置（11 1)は、ルータ 11 (101)に接続している。、受信装置 1、 2 (112、 113)は、ルータ 12 ( 102)と同一のブロードキャストメディア上にある。受信装置 3 (114)は、ルータ 13 (10 3)に接続している。受信装置 5 (116)は、ルータ 4、 11〜13 (104、 101〜103)が 接続するブロードキャストメディア上に位置して 、る。
[0033] このとき、送信装置（111)が、受信装置1〜5 (112〜116)へ同ーデータを じ八3 Tパケットにより配信するときの動作について、図面を用いて以下に説明する。
[0034] 図 6は、送信装置力 受信装置までのパケット転送の動作を示すシーケンス図であ る。
[0035] 図 6にお 、て、まず、送信装置（ 111)は、宛先リストに受信装置 1から 5 ( 112〜 116 )のアドレスを記述した XCASTのパケットをルータ 11 (101)へ送信する（ステップ S1 001)。
[0036] ルータ 11 (101)は、受信した XCASTのパケットを複製し、宛先リストの宛先ビット マップを修正して、 LMC対応の次ホップノードであるルータ 12、 13 (102、 103)と受 信装置 5 (116)ヘリンクレベルマルチキャストにより送信する（ステップ S1002)。
[0037] 図 7Aは、リンクレベルマルチキャストによりルータ 11 (101)力 送信される XCAST ノ ケット（リンクレベルマルチキャストパケット）の内容を示す図である。 XCASTバケツ トの宛先アドレスには、予め設定されているマルチキャストアドレス（MC)が記述され る。また、宛先ビットマップにおいて、ルータ 12、 13 (102、 103)の中継先である受 信装置 1〜3 (112〜114)と受信装置 5 (116)とに該当するビットのみ力 S「l」に設定 される。
[0038] また、ルータ 11 (101)は、従来の XCASTに対応したルータ 4 (104)へ じ八3丁の パケットをュ-キャストにより送信する（図 6のステップ S 1003)。
[0039] 図 7Bは、ュ-キャストによりルータ 11 (101)力 送信される XCASTパケット（ュ- キャストパケット）の内容を示す図である。 XCASTパケットの宛先アドレスには、次ホ ップノードであるルータ 4が記述される。また、宛先ビットマップにおいて、ルータ 4 (1 04)の中継先である受信装置 4 (115)に該当するビットのみが「1」に設定される。
[0040] 次に、ルータ 12 (102)は、これを受けて、受信した XCASTパケットを、宛先リストの 先頭にある、未配送宛先ノードである受信装置 1 (112)へュ-キャストにより送信する (図 6のステップ S1004)。これは、受信装置 1、 2 (112, 113)が LMC対応でない、 通常の XCASTに対応したノードのためである。仮に、ルータ 12 (102)が XCASTパ ケットをリンクレベルマルチキャストにより送信したとする。この場合、受信装置 1 (112 )は、未配信宛先ノードである受信装置 2 (113)へ受信パケットを複製して転送し、受 信装置 2 (113)は、同じく未配信宛先ノードである受信装置 1 (112)へ受信パケット を複製して転送する。その結果、受信装置 1 (112)と受信装置 2 (113)は、同一デー タを二度受信することになる。上記のようなュ-キャストによる送信を行うことにより、こ のような事態を防ぐことができる。
[0041] 次に、受信装置 1 (112)は、自己宛にュ-キャストで送信された XCASTパケットを 受けて、未配送宛先ノードである受信装置 2 (113)へパケットを複製して転送する (ス テツプ S 1005)。
[0042] また、ルータ 13 (103)は、ルータ 11 (101)力ものリンクレベルマルチキャストにより XCASTパケットを受信すると、そのパケットを受信装置 3 (114)へ転送する (ステツ プ S 1006)。
[0043] また、ルータ 4 (104)は、ルータ 11 (101)力らのュ-キャストによる XCASTパケット を受信すると、従来の XCASTの規定に従って、受信したパケットを受信装置 4 (115 )へ転送する（ステップ S 1007)。
[0044] 以上のように、本発明に係る中継ノードであるルータ 12、 13 (102、 103)は、 XCA STのパケットをリンクレベルマルチキャストによって受信した場合、受信インターフエ イスからは未配送の宛先ノードへ XCASTパケットを転送しな!、。これをリバースパス サプレス（逆方向転送抑止)機能といい、このリバースパスサプレス機能により、 XCA STパケットが、一つのブロードキャストメディア上を繰り返し転送されることを防止でき る。 LMC対応のノードは、リバースパスサプレス機能を有するノードである。
[0045] また、本発明に係るルータ 11 (101)は、ブロードキャストメディアに複数の LMC対 応のノードがある場合、これらのノードへはリンクレベルマルチキャストによるパケット 送信を行い、 LMC対応ではないノードにはュ-キャストによるパケット送信を行う。こ れにより、ルータ 11 (101)は、ブロードキャストメディアにおける通信帯域を効率よく 使用することができる。
[0046] 次に、上記のパケット送信方法を可能にする、本発明に係るルータと受信装置につ いて、以下に図面を用いて説明する。
[0047] 図 8は、本発明に係るルータの構成を示すブロック図であり、図 5に示すルータ 11
〜13 (101〜103)に対応するものである。ここでは、ルータ 11 (101)の構成として 説明する力 ルータ 12、 13 (102、 103)も同様の構成を有する。
[0048] 図 8において、ルータ 11 (101)は、内部リンク用ポート 201、受信部 202、マルチキ ャスト判別部 203、経路管理部 204、経路記憶部 205、送信グループ分類部 206、 転送先キャッシュ 207、パケット生成部 208、送信 IZF部 209、送信部 210、送信部
211、および外部リンク用ポート 212を有する。
[0049] まず、内部リンク用ポート 201、外部リンク用ポート 212、受信部 202、送信部 211、 送信部 210、およびマルチキャスト判別部 203について説明する。
[0050] 内部リンク用ポート 201は、送信装置や受信装置が接続するローカルエリアネットヮ ーク (LAN)と接続する入出力ポートである。
[0051] 外部リンク用ポート 212は、インターネットなどのアップリンクと接続する入出力ポー トである。
[0052] 受信部 202は、内部リンク用ポート 201および外部リンク用ポート 212のそれぞれか らパケットを受信する。
[0053] 送信部 210は、内部リンク用ポート 201へパケットを送出する。
[0054] 送信部 211は、外部リンク用ポート 212へパケットを送出する。
[0055] マルチキャスト判別部 203は、受信パケットが XCASTによる明示的マルチキャスト のパケットである力否かを判別する。そして、マルチキャスト判別部 203は、受信パケ ットが XCASTのパケットである場合には、受信パケットから宛先リストを抽出する。一 方、マルチキャスト判別部 203は、受信パケットがリンクローカルマルチキャストにより 送付されたパケットである場合には、送信グループ分類部 206へ、受信したインター フェイス情報を通知する。
[0056] 次に、経路管理部 204について説明する。
[0057] 経路管理部 204は、近隣要請メッセージを生成し、近隣ノードの経路情報を問 、合 わせ、近隣告知メッセージを受け取る。経路管理部 204は、問い合わせにより取得し た経路情報を、経路表およびアドレス表に反映し、経路記憶部 205に記憶させて管 理する。また、経路管理部 204は、次ホップのノード力LMC対応力否かを同時に問 い合わせ、取得した情報を経路記憶部 205のアドレス表に記録して管理する。また、 経路管理部 204は、他のノードから LMC対応 Z非対応の問い合わせを受けたとき、 近隣告知メッセージを生成して応答する。
[0058] 図 9に、経路記憶部 205が記憶する経路表およびアドレス表の構造を示す。図 9A は、経路記憶部 205が記憶する経路表の構造を示す図であり、図 9Bは、経路記憶 部 205が記憶するアドレス表の構造を示す図である。
[0059] 図 9Aに示すように、経路表 400において、対象ノード 401のフィールドには、宛先 受信装置の IPアドレスが記録され、次ホップノード 402のフィールドには、次ホップノ ードの IPアドレスが記録される。
[0060] また、図 9B示すように、アドレス表 410において、次ホップノード 411のフィールドに は、自己（ルータ 11)の接続するブロードキャストメディア上のノードのアドレスが記録 される。 MACアドレス 412のフィールドには、各ノードの MACアドレスが記録され、 L MC対応 413のフィールドには、本発明のパケット送信方法に対応しているか否かを 示すフラグが記録される。また、接続ポート 414のフィールドには、各ノードが接続し ているリンクのインターフェイスが記録される。なお、本実施の形態においては、 LM C対応 413のフィールドにおいて、 LMC対応可の場合、フラグに「1」がセットされ、 L MC非対応の場合、フラグに「0」がセットされる。また、接続ポート 414のフィールドに は、外部リンク側の接続ポートの場合は「2」が、内部リンク側の接続ポートの場合は「 1」が、それぞれセットされる。
[0061] 図 10に、本実施の形態において使用される近隣要請メッセージと近隣告知メッセ ージを示す。
[0062] 図 10Aは、近隣要請メッセージのフォーマット図であり、図 10Bは、近隣告知メッセ ージのフォーマット図である。
[0063] 図 10Aに示すように、本実施の形態における近隣要請メッセージは、 RFC2461で 規定される ICMPv6の近隣要請メッセージ 303に、 RFC2460で規定される IPv6へ ッダ 301と宛先オプションヘッダ 302とを付カ卩したものである。
[0064] 宛先オプションヘッダ 302内の宛先オプション 304は、先頭 2ビットに「10」のコード を用いる。これにより、近隣要請メッセージを受信した、 LMC対応でないノードは、こ のコードを解釈できないので、 ICMPv6のパラメータ問題メッセージ（Parameter Prob lem Message)を応答することになる。これは、近隣要請メッセージを受信したノードが 、宛先オプション 304を解釈できない場合、パラメータ問題メッセージを応答すること が IPv6の宛先オプションヘッダの仕様にお!、て必須動作として規定されて!、るため である。 IPv6の仕様を規定する文書 RFC2460では、未知のオプションヘッダを受 信した場合、 4種類の動作を規定している。未知のオプションヘッダの受信時の 4種 類の動作のうち、どの動作を行うかは、オプションヘッダ番号の先頭 2ビットで規定さ れている。本実施の形態では、先頭 2ビットを二進数表記「10」と規定し、 riCMP P ammeter Problemを応答する」に該当するオプション番号を利用する。このォプシ ヨン番号を用いることにより、 LMC非対応のノードが本実施の形態における近隣要請 メッセージを受け取った場合でも、即座にパラメータ問題メッセージを応答することが 保証される。
[0065] 図 10Bに示すように、本実施の形態における近隣告知メッセージは、 RFC2461で 規定される ICMPv6の近隣告知メッセージ 305に、 RFC2460で規定される IPv6へ ッダ 301と宛先オプションヘッダ 302を付カ卩したものである。
[0066] 近隣要請メッセージと同様に、宛先オプション 304は、先頭 2ビットに「10」のコード を用いる。
[0067] 以上が経路管理部 204の機能説明である。
[0068] 次に、送信グループ分類部 206について説明する。
[0069] 送信グループ分類部 206は、マルチキャスト判別部 203が抽出した宛先リストに記 述された未配送宛先ノードを、転送先インターフェイス毎に転送先エントリとしてまと め、 LMCエントリグループとュ-キャストエントリグループとに分類する。ここで、 LM Cエントリグループとは、 LMCに対応した宛先ノードのグループであり、ュ-キャスト エントリグループとは、 LMCに非対応の宛先ノードのグループである。
[0070] 具体的には、送信グループ分類部 206は、経路表 400に基づ 、て未配送の宛先ノ ードに対応する次ホップノードを検索する。そして、送信グループ分類部 206は、アド レス表 410に基づ 、て検索して得られた次ホップノードに対応する接続ポート 414を 求める。このようにして、送信グループ分類部 206は、未配送のすべての宛先ノード の転送先インターフェイスを求め、転送先インターフェイス毎に未配送の宛先ノードを 転送先エントリとしてまとめる。
[0071] さらに、送信グループ分類部 206は、その転送先エントリを LMCに対応した宛先ノ ードのグループ（LMCエントリグループ）と非対応のグループ（ュ-キャストエントリグ ループ）とに分類し、エントリ情報として転送先キャッシュ 207に記録する。さらに、送 信グループ分類部 206は、マルチキャスト判別部 203から受信ポート情報が通知さ れた場合は、その受信ポート情報を受信インターフェイス (I/F)として転送先キヤッ シュ 207に記録する。また、マルチキャスト判別部 203から受信ポート情報の通知が ない場合は、ヌル (NULL)コードを記録する。
[0072] 図 11に、転送先キャッシュ 207に記録されるエントリ情報のデータ構成を示す。
[0073] 図 11 Aは、転送先キャッシュエントリの構成図である。図 11 Aに示すように、転送先 キャッシュエントリ 500は、転送先エントリ 501、 LMCエントリ 502、ュ-キャストェント リ 503、および受信 IZF504力 構成される。この転送先キャッシュエントリ 500は、 転送するパケット毎に記録される。また、受信 IZF504には、マルチキャスト判別部 2 03から通知されたポート情報が記録される。本実施の形態では、内部リンク用ポート を示す「1」、あるいは外部リンク用ポートを示す「2」が記録される。
[0074] 図 11Bは、転送先エントリ 501の構成図である。図 11Bに示すように、転送先ェント リ 501は、リストエントリ数 511および宛先フィールド 512から構成される。リストエントリ 数 511は、受信パケットの宛先リストに記述された未配送の宛先ノードの中で、転送 ポートが同一の宛先ノードの総数を示す。また、宛先フィールド 512には、該当する 宛先ノードの IPアドレスが記録される。図 11Bの例では、宛先 1〜4の宛先ノードが未 配送ノードとして記録されて 、る場合を示して 、るが、宛先ノードの個数はこれに限 定されるものではない。
[0075] 図 11Cは、 LMCエントリ 502の構成図である。図 11Cに示すように、 LMCエントリ 5 02は、 LMCリストエントリ数 521および宛先フィールド 522から構成される。 LMCリス トエントリ数 521は、 LMCリストエントリグループの宛先ノードの総数を示す。また、宛 先フィールド 522には、該当する宛先ノードの IPアドレスが記録される。図 11Cの例 では、宛先 1、 2、 4が記録されている場合を示している。
[0076] 図 11Dは、ュ-キャストエントリ 503の構成図である。図 11Dに示すように、ュニキヤ ストエントリ 503は、ュ-キャストリストエントリ数 531および宛先フィールド 532から構 成される。ュ-キャストリストエントリ数 531は、ュ-キャストエントリグループの宛先ノ ードの総数を示す。また、宛先フィールド 532には、該当する宛先ノードの IPアドレス が記録される。図 11Dの例では、宛先 3が記録されている場合を示している。
[0077] なお、記述の方式としては、図 11B〜図 11Dの他に、たとえば、区切り記号をカン マとして、 IPv6の複数の宛先アドレスをテキスト表現で「2、 IPv6アドレス 1、 IPv6アド レス 2」と表記することもできる。この表現例の最初の「2」がリストエントリ数を示し、 Γΐρ ν6アドレス 1」および「IPv6アドレス 2」が宛先を示す。
[0078] 以上が送信グループ分類部 206の機能説明である。
[0079] 次に、パケット生成部 208および送信 IZF決定部 209について説明する。
[0080] パケット生成部 208は、受信部 202が受信したパケットをコピーして転送用のバケツ トを生成したり、経路管理部 204からの要求を受けて近隣要請メッセージを生成する 。さらに、パケット生成部 208は、 XCASTのパケットを転送する場合、転送先インタ 一フェイス毎にリンクレベルのュ-キャスト用パケットとマルチキャスト用パケットを生 成する。
[0081] 送信 IZF決定部 209は、パケット生成部 208が生成したパケットの出力ポートを決 定するものである。
[0082] 以上のように構成された本発明に係るルータについて、以下にその動作および作 用を説明する。
[0083] 本発明による XCASTのパケット送信方法と従来の XCASTのパケット送信方法と の特徴的な差異は、従来の XCASTのパケット送信方法が、次ホップノード毎に処理 が行われたのに対して、本発明による XCASTのパケット送信方法は、転送先インタ 一フェイス単位で送信処理をまとめて ヽる点である。
[0084] 図 12は、本発明に係るルータが XCASTのパケットを転送する方法を示すフロー図 である。
[0085] 図 12において、まず、受信部 202が、 XCASTパケットを内部リンク用ポート 201ま たは外部リンク用ポート 212から受信すると (ステップ S701)、マルチキャスト判別部 2 03は、そのパケットをリンクレベルマルチキャストにより受信したか否かを判別する（ス テツプ S702)。
[0086] リンクレベルマルチキャストによりパケットを受信した場合（S702 : YES)、マルチキ ャスト判別部 203は、その受信インターフェイスを送信グループ分類部 206へ通知し 、送信グループ分類部 206は、通知された受信インターフェイスを転送先キャッシュ 2 07の受信 IZF504へ記録する（ステップ S 703)。
[0087] 一方、自己が送信端末である場合や、リンクレベルマルチキャストではなくュ-キヤ ストによりパケットを受信した場合は（S702 :NO)、送信グループ分類部 206へ通知 しない。これにより、受信 IZF504に受信インターフェイス情報は記録されず、ヌル (N ULL)と記録される（ステップ S 704)。
[0088] 次に、マルチキャスト判別部 203は、宛先ビットマップ 1406力 「l」である未配送の 宛先ノードを抽出し、送信グループ分類部 206へ送出する。送信グループ分類部 20 6は、これを受けて、経路表 400とアドレス表 410とを基〖こ、それぞれの宛先ノードに っ 、て転送先インターフェイスを決定する (ステップ S 705)。 [0089] 次に、送信グループ分類部 206は、受信 IZF504にヌル以外の受信インターフエ イス情報が記録されて 、る場合、受信 IZF504に記述のインターフェイスを除、て、 転送先インターフェイス毎に宛先ノードをまとめ、転送先エントリ 501を生成する (ステ ップ S706)。具体的には、送信グループ分類部 206は、転送先インターフェイスを同 一にする未配送の宛先ノードを宛先フィールド 512に記述し、その宛先ノード数をリ ストエントリ数 511に記述する。また、受信 IZF504にヌルが記述されている場合は、 すべてのインターフェイス毎に転送先エントリ 501を生成する。
[0090] 例えば、図 5に示す IPネットワークにおいて、ルータ 11 (101)が送信装置（111)か ら受信装置1〜5 (112〜116)へ じ八3丁にょりパケット配信する場合を考ぇる。この 場合、ルータ 11 (101)は経路表 400とアドレス表 410とから、受信装置 1〜5 (112〜 116)への次ホップノードは同一ブロードキャストメディア上にあることを検出し、受信 装置 1〜5 (112〜116)を一つの転送先エントリ 501にまとめる。
[0091] なお、上記したように、送信グループ分類部 206は、受信 IZF504に記述された出 力ポートの接続リンク上にある次ホップノードが中継する宛先ノードへの転送先ェント リ 501を生成しない。このため、受信ポートへパケット転送が行われることはなぐ逆方 向転送が抑止される。
[0092] 次に、送信グループ分類部 206は、転送先エントリ 501を LMCエントリ 502とュ- キャストエントリ 503とに分類する（ステップ S707)。
[0093] 例えば、ルータ 11 (101)の送信グループ分類部 206は、経路表 400に基づいて、 宛先ノードである受信装置 1 (112)と受信装置 2 (113)への次ホップノードがルータ 1 2 (102)であることを検出する。また、送信グループ分類部 206は、受信装置 3 (114 )への次ホップノードがルータ 13であることを検出し、受信装置 4 (115)への次ホップ ノードがルータ 4 (104)であることを検出する。さらに、送信グループ分類部 206は、 受信装置 5 (116)がブロードキャストメディア上にあることを検出する。そして、ルータ 11 (101)の送信グループ分類部 206は、アドレス表 410に基づいて、ルータ 12 (10 2)とルータ 13 (103)と受信装置 5とが LMC対応であり、ルータ 4 (104)と送信装置（ 111)とが LMC非対応であることを検出する。
[0094] これらの検出結果から、ルータ 11 (101)の送信グループ分類部 206は、受信装置 1〜3、 5 (112〜114、 116)を LMCエントリグループと決定し、受信装置 4 (115)を ュニキャストエントリグループと決定する。
[0095] 次に、パケット生成部 208は、転送先キャッシュ 207の LMCエントリ 521に宛先が 記述されているか否かを判別し (ステップ S708)、記述されている場合（S708 : YES
)、マルチキャスト処理を行う（ステップ S 709)。
[0096] 次に、パケット生成部 208は、転送先キャッシュ 207のュ-キャストエントリ 503に宛 先ノードが記述されているカゝ否かを判別し (ステップ S710)、記述されている場合 (S
710： YES)、ュ-キャスト処理を行う（ステップ S711)。
[0097] 次に、パケット生成部 208と送信 IZF決定部 209は、転送先インターフェイス毎に 生成されたすベての転送先キャッシュエントリ 500について、上記のステップ S706〜
S711の転送処理が完了したか否かを判別し、完了するまで繰り返す (ステップ S71
2)。
[0098] ここで、上記のマルチキャスト処理とュニキャスト処理について、図面を用いて説明 する。
[0099] 図 13は、マルチキャスト処理の詳細を示すフロー図である。
[0100] まず、パケット生成部 208は、受信部 202が受信した当該パケットを複製し、 LMC エントリ 502の宛先に該当するビットのみ「1」となるように、宛先ビットマップ 1406を設 定する（ステップ S 901)。
[0101] さらに、パケット生成部 208は、宛先 MACアドレスに、予め規定されたリンクレベル マルチキャストアドレスを設定し、宛先 IPアドレスに LMCを示す宛先アドレスを設定 する（ステップ S 902)。
[0102] 次に、送信 IZF決定部 209は、パケット生成部 208から送信パケットを受け取り、宛 先ビットマップ 1406の未配送宛先の出力ポートをアドレス表 410に基づいて決定す る。そして、送信 IZF決定部 209は、該当する送信部 210、 211を介して、内部リンク 用ポート 201あるいは外部リンク用ポート 212から XCASTパケットを送信する（ステツ プ S903)。
[0103] これにより、 XCASTパケット力LMC対応の未配送宛先ノードへリンクレベルのマル チキャストにより送信される。 [0104] 図 14は、ュニキャスト処理の詳細を示すフロー図である。
[0105] 図 14において、パケット生成部 208は、受信部 202が受信した当該パケットを複製 し、ュ-キャストエントリ 503の宛先に該当するビットのみ「1」となるように、宛先ビット マップ 1406を設定する（ステップ S801)。
[0106] 次に、パケット生成部 208は、経路表 400を参照し、ュ-キャストエントリ 503に記述 された宛先ノードに対応する次ホップノードを求める。そして、パケット生成部 208は 、求めた次ホップノードが中継するすべての宛先ノードに該当する宛先ビットマップ 1 406のビットのみを「1」に設定する（ステップ S802)。
[0107] 次に、パケット生成部 208は、アドレス表 410を参照し、その次ホップノードに対応 する MACアドレスと出力ポートを求める。そして、パケット生成部 208は、複製したパ ケットの宛先 MACアドレスに求めた MACアドレスを設定し、求めた接続ポート情報 を送信 IZF決定部 209へ通知する（ステップ S803)。
[0108] 次に、送信 IZF決定部 209は、パケット生成部 208から送信パケットを受け取り、通 知された接続ポートに該当する送信部 210、 211を介して、内部リンク用ポート 201あ るいは外部リンク用ポート 212からパケットを送信する（ステップ S804)。
[0109] 次に、パケット生成部 208はュ-キャストエントリ 503に記述の宛先すべてについて 、上記ステップ S801〜S804の処理が完了したか否かを判別し、すべてのュ-キヤ ストエントリ 503の宛先にっ 、て上記の処理が完了するまで繰り返す (ステップ S805
) o
[0110] これにより、 LMCに対応していない宛先ノードへのパケット転送は、それぞれの次 ホップノードへュ-キャストにより送信される。
[0111] 例えば、ルータ 11 (101)のパケット生成部 208は、 LMC対応である、受信装置 1、 2 (112、 113)の次ホップノードであるルータ 12 (102)と、受信装置 3 (114)への次 ホップノードであるルータ 13 (103)と、受信装置 5 (116)へは、リンクレベルマルチキ ャストによりパケットを送信する。また、ルータ 11 (101)のパケット生成部 208は、 LM C非対応である、受信装置 4 (115)の次ホップノードであるルータ 4 (104)へは、ュ- キャストによりパケットを送信する。
[0112] なお、ステップ S805では、ュ-キャストエントリのすべての宛先について、ステップ S801〜S804を繰り返し実行するようにしている力 このステップは、転送方式キヤッ シュのエントリ数の限界を超えた場合にも転用される。すなわち、上記した転送方式 キャッシュを用いたパケットの処理が終了した後に、同じヘッダを持ったパケットを効 率的に処理するため、転送キャッシュのエントリを生成する。この転送キャッシュのェ ントリは、有限個のエントリのみ保持可能である。このため、転送キャッシュエントリは、 そのエントリの利用頻度を利用して適宜エイジングする運用するなど、 LRU (Least R eset Used)アルゴリズムを用いてもよい。あるいは、 FIFO (First In First Out)など、 他のアルゴリズムを用いて維持しても良い。あるいは、転送キャッシュのエントリ数の 限界を超えて、転送キャッシュのエントリを生成する必要ができた場合に、すべての 宛先に対してュ-キャスト処理をするという運用を行ってもよい。この場合は、ルータ は転送キャッシュのエントリの生成をあきらめて、以後、転送キャッシュのエントリにヒッ トしなかったパケットの処理において、転送キャッシュのエントリに基づいてマルチキ ャスト処理ゃュ-キャスト処理を行わな 、ようにする。
[0113] 以上が、本発明に係るルータが XCASTのパケットを転送する方法である。
[0114] 次に、送信グループ分類部 206が転送先キャッシュエントリ 500を生成するときに行 うアドレス解決について以下に説明する。
[0115] 送信グループ分類部 206は、転送先キャッシュエントリ 500を生成するとき、次ホッ プノードの MACアドレスや LMC対応情報がアドレス表に登録されて!、な!/、場合、経 路管理部 204へ該当する次ホップノードのアドレス解決を要求する。
[0116] 経路管理部 204は、これを受けると、パケット生成部 208へその宛先アドレスの近隣 要請メッセージの生成を指示する。パケット生成部 208は、指示された宛先アドレス の MACアドレス解決のための、本実施の形態における近隣要請メッセージを生成し 、送信 IZF決定部 209へ送出する。送信 IZF決定部 209は、これを受けて、すべて の出力ポートへ送信部 210、 211を介してリンクローカルマルチキャストで近隣要請メ ッセージを送信する。
[0117] ブロードキャストメディア上の各ノードは、本実施の形態における近隣要請メッセ一 ジを受け取ると、自らが宛先アドレスに合致する場合、リンクレベルマルチキャストを 受信可能状態にした後に、近隣広告メッセージを送信する。このとき、宛先アドレスが 合致したノードの経路管理部 204は、宛先オプション 304に記述のコードが LMC対 応を示すものであると認識した場合、当該コードを複製した近隣広告メッセージを応 答する。もし、宛先オプション 304に記述のコード力LMC対応を示すものであると認 識できなかった場合、宛先アドレスが合致したノードの経路管理部 204は、パラメータ 問題メッセージを応答する。
[0118] 本実施の形態における近隣要請メッセージの送信元ノードの経路管理部 204は、 受信部 202を介して近隣広告メッセージを受信すると、正規の応答であるか、パラメ ータ問題メッセージであるかの判別を行う。そして、正規の応答を得た場合、経路管 理部 204は、アドレス表 410の MACアドレスフィールド 412に通知された MACアド レスを登録し、 LMC対応フィールド 413に対応可を示す「 1」を記述する。
[0119] 一方、パラメータ問題メッセージを受けた場合、経路管理部 204は、アドレス表 410 の MACアドレスフィールド 412に通知された MACアドレスを登録し、 LMC対応フィ 一ルド 413に対応不可を示す「0」を記述する。
[0120] これにより、本発明に係るルータは、転送先エントリを LMCエントリグループとュ- キャストエントリグループとに分類するために必要な、ブロードキャストメディア上のノ ードに関する情報を取得することが可能になる。
[0121] なお、本実施の形態では、次ホップノードのアドレス解決を行う際に、それと合わせ て LMCに対応しているか否かの問い合わせも行うとした力 これに限定されず、アド レス解決とは別のシーケンスで LMC対応の可否の問!、合わせを行っても良！、。
[0122] また、本実施の形態における近隣要請メッセージおよび近隣告知メッセージは、 IP v6の宛先オプションヘッダを用いることで規定した力 これに限定されず、独自のメッ セージを使用してもよい。この場合、宛先ノードがこの近隣要請メッセージに対応して いないときに、応答しないことがある。このため、送信元ノードは、一定時間の間に応 答されない場合にタイムアウト処理を行い、タイムアウトしたときには否定応答を受け 取った場合と同じ処理を行う。
[0123] さらに、本実施の形態では、本発明に係るパケット送信方法による LMC (リンタレべ ルマルチキャスト配送方法)でパケットを配送する場合に使用するリンクレベルマルチ キャストアドレスは、予め定められたマルチキャストアドレスを使用するものとして説明 しているが、これに限定されない。例えば、 LMCでのパケット配送に先立って、マル チキャストアドレスの利用状況を確認する SAP (Session Announcement Protocol)を 用いて未使用のマルチキャストアドレスを確保し、そのマルチキャストアドレスを使用 することにしてもよい。あるいは、未使用のマルチキャストアドレスを割り当てる要求応 答ベースのプロトコルである、 RFC2907で規定される MADCAPや、 RFC2131、 R FC2132、 RFC3315で規定される DHCPを拡張したものを用 、て未使用のマルチ キャストアドレスを獲得し、それを利用するようにしてもょ 、。
[0124] 以上が本発明に係るルータの構成と動作の説明である。
[0125] 次に、本発明に係る受信装置の構成について、図面を用いて説明する。
[0126] 図 15は、受信装置 4の構成を示すブロック図であり、図 8に対応するものである。図
8と同一部分には同一符号を付し、これについての説明を省略する。
[0127] 図 15において、受信装置 4 (115)は、内部リンク用ポート 201、受信部 202、マル チキャスト判別部 203、経路記憶部 205、転送先キャッシュ 207、パケット生成部 208 、送信 IZF部 209、送信部 210、データ抽出部 1101、アプリケーション部 1102、送 信判別部 1103、および経路管理部 1104を有する。
[0128] データ抽出部 1101は、受信パケットからデータを抽出する。アプリケーション部 11
02は、アプリケーション処理を行う。
[0129] 送信判別部 1103は、マルチキャスト判別部 203からリンクレベルマルチキャストに より明示的マルチキャストパケットを受信したことの通知を受けると、受信した明示的 マルチキャストパケットの転送を禁止する。
[0130] また、経路管理部 1104は、図 8に示す本発明に係るルータの経路管理部 204とは 異なり、アドレス表によりブロードキャストメディア上の他の受信装置の MACアドレスと 接続ポートを管理し、経路表は有していない。また、経路管理部 1104は、本発明に 係るルータ力 近隣要請メッセージにより LMC対応である力否かの問い合わせを受 けたときに、近隣広告メッセージにより LMC対応であることを応答する。
[0131] その他の構成ブロックについては、本発明に係るルータのものと同一である。
[0132] このように構成された受信装置による XCASTパケットの転送方法について以下に 説明する。 [0133] 図 16は、本発明の受信装置が XCASTパケットを転送する方法を説明するフロー 図である。
[0134] まず、受信部 202は、内部リンク用ポートから受信したパケットが通常のデータパケ ットである場合 (ステップ S1201)、データ抽出部 1101へ送出する。データ抽出部 11 01は、その受信パケットからデータを抽出してアプリケーション部 1102へ送出し、ァ プリケーシヨン部 1102は、受け取ったデータを用いてアプリケーション処理を行う（ス テツプ S 1202)。
[0135] また、マルチキャスト判別部 203は、受信パケットが XCASTパケットである場合、宛 先アドレスが予め規定してあるマルチキャストアドレスであるか否かを判別し (ステップ S1203)、その結果を送信判別部 1103へ通知する。
[0136] 次に、送信判別部 1103は、マルチキャスト判別部 203からリンクレベルマルチキヤ ストによるパケット受信であると通知された場合（S 1203 : YES)、 XCASTパケットの 受信であっても転送先キャッシュ 207への転送先エントリの生成を行わな 、。一方、 送信判別部 1103は、マルチキャスト判別部 203からュ-キャストによる XCASTパケ ットの受信であると通知された場合（S1203 :NO)、 XCASTパケットに含まれる宛先 リストの宛先ビットマップから自己のビットを「0」に更新し、宛先ビットマップの「1」が設 定されている宛先力 転送先エントリを転送先キャッシュ 207に生成する (ステップ S1 204)。
[0137] 次に、パケット生成部 208は、転送先キャッシュ 207に未配送宛先の転送先エントリ が記録されている場合、受信パケットを複製して宛先ビットマップを転送先エントリの 宛先のみ「1」となるように変更する (ステップ S1205)。また、パケット生成部 208は、 宛先ビットマップの先頭の未配送宛先アドレスを選択し、アドレス表に基づ 、て該当 する MACアドレスを検索する。そして、パケット生成部 208は、宛先アドレスに検索し て求めた MACアドレスを設定する（ステップ S 1206)。
[0138] 次に、送信 IZF決定部 209は、アドレス表に基づいて、宛先アドレスに対応する接 続ポートを決定し、該当する送信部 210へ生成された XCASTパケットを送信する (ス テツプ S1207)。本実施の形態では、送信部 210は一つのみであるので、送信 IZF 決定部 209は必須のものではない。 [0139] 以上のように本発明に係る受信装置によれば、 XC ASTパケットをリンクレベルマル チキャストにより受信した場合、ブロードキャストメディア上の他の受信装置への逆方 向転送を抑制するので、ブロードキャストメディア上をパケットがループすることを防 止できる。
[0140] また、本発明に係る受信装置は、 LMC対応であることを近隣告知メッセージで応 答するので、本発明に係る中継ノードであるルータは、ブロードキャスト上に LMC対 応の受信装置があれば、その受信装置も含めてリンクレベルマルチキャストにより XC ASTパケットを送信することができる。
[0141] また、本発明に係るパケット送信方法によれば、本発明に係る中継ノードは、同一 ブロードキャストメディア上の各ノードが LMC対応であるか否かの情報を取得するこ とができるので、次ホップノードが LMC対応である宛先ノードのグループと、 LMC非 対応の宛先ノードのグループとに未配送ノードを分類することが可能になる。そして、 本発明に係る中継ノードであるルータは、 LMC対応の次ホップノードへリンクレベル マルチキャストにより XCASTパケットを送信できるので、通信帯域を効率的に使用す ることが可能になる。
[0142] また、本発明に係る中継ノードであるルータは、 LMC非対応の次ホップノードへは ュ-キャストによるパケット送信するので、ブロードキャストメディア上をパケットがルー プすることを防止できる。
[0143] 本発明の第 1の態様に係るパケット送信方法は、複数の宛先アドレスの記述された 宛先リストに基づいて転送先を決定するものである。すなわち、第一ノードが、次ホッ プノードへュ-キャストにより送信する宛先グループと、リンクレベルマルチキャストに より送信する宛先グループとに分類する。このュニキャストにより送信する宛先グルー プは、宛先リストの宛先ノードへ明示的マルチキャストパケットを中継する次ホップノ ードのグループである。そして、第一ノードが、その分類に従って、明示的マルチキヤ ストパケットをュ-キャスト、あるいはリンクレベルマルチキャストにより送信する。その 後、第二ノードがリンクレベルマルチキャストにより送信された明示的マルチキャストパ ケットを受信したとき、その受信したインターフェイス以外のインターフェイス側に位置 する、宛先リストに記述された未配送の宛先ノードへのみ、明示的マルチキャストパケ ットを転送する。
[0144] これにより、ブロードキャストリンク上に同じパケットがループすることがなくなるので、 XCASTにおけるパケット送信においても、リンクレベルマルチキャストによる配信を 行うことが可能となる。その結果、ュ-キャストにより複数回 XCASTパケットを送信す ることによる通信帯域の消費を削減することができる。
[0145] また、本発明の第 2の態様は、第 1の態様に係るパケット送信方法において、第一ノ 一ドが次ホップノードに逆方向転送禁止機能を有する力否かを問い合わせる。この 逆方向転送機能とは、上記したような、 XCASTパケットをリンクレベルマルチキャスト により受信した場合には、受信したインターフェイスからは転送しない機能をいう。そ して、次ホップノードがその問い合わせに対して逆方向転送禁止機能を有すると応 答すると、第一ノードが上記の分類において、そのように応答した次ホップノードが中 継する中継先の宛先ノードをリンクレベルマルチキャストの宛先グループとみなす。ま た、それ以外の応答をした宛先ノードをュ-キャストの宛先グループと分類する。
[0146] これにより、第一ノードは、宛先リストの宛先ノードを、リンクレベルマルチキャストに よる XCASTパケットの送信をしてもよ!、グループと、送信しては!、けな 、グループと に分類することができる。
[0147] また、本発明の第 3の態様は、第 2の態様に係るパケット送信方法において、第一ノ ードがさらに、宛先リストに記述された宛先ノードを、当該宛先ノードに対応した次ホ ップノードが接続するリンクとのインターフェイス毎に分類する。そして、第一ノードは 、宛先グループの分類を転送先インターフェイス毎に行う。
[0148] これにより、複数の転送先インターフェイスがある場合でも、転送先インターフェイス 毎にリンクレベルマルチキャストを行うことができるので、宛先ノードに効率よく XCAS Tパケットを配信することが可能になる。
[0149] また、本発明の第 4の態様は、第 2の態様に係るパケット送信方法において、第一ノ ードがュ-キャストの宛先グループに属する宛先ノードへ中継する次ホップノードを 経路表に基づいて決定し、その次ホップノードの中継先の宛先ノードのみ有効となる ように宛先リストを変更する。そして、第一ノードが、変更された宛先リストを含む明示 的マルチキャストパケットをその次ホップノードへュ-キャストにより送信する。 [0150] これにより、第一ノードは、次ホップノードの中継先の宛先ノードがュ-キャストの宛 先グループに属するものである場合、次ホップノード単位にュ-キャストにより XCAS
Tパケットを送信することができる。
[0151] また、本発明の第 5の態様は、第 2の態様に係るパケット送信方法において、第一ノ ードがマルチキャストの宛先グループに分類した宛先ノードのみ有効となるように宛 先リストを変更する。そして、第一ノードが、変更された宛先リストを含む明示的マル チキャストパケットをマルチキャストにより送信する。
[0152] これにより、第一ノードはリンクレベルマルチキャストによる XCASTパケットの送信 をしてもよいグループに、 XCASTパケットをリンクレベルマルチキャストによる送信を することができる。
[0153] また、本発明の第 6の態様は、第 2の態様に係るパケット送信方法において、第一ノ ードは、未使用のリンクレベルマルチキャストアドレスを獲得する。そして、第一ノード 力 Sリンクレベルマルチキャストによる明示的マルチキャストパケットを送信するときに、 リンクレベルマルチキャストアドレスを宛先 IPアドレスに設定して送信する。
[0154] これにより、第一ノードは、マルチキャストアドレスを重複することなく使用することが できる。
[0155] また、本発明の第 7の態様に係る中継ノードは、複数の宛先アドレスの記述された 宛先リストに基づいて転送先を決定するものである。特に、本発明の中継ノードは、 マルチキャスト判別部と送信グループ分類部とパケット生成部と送信部とを有してい る。
[0156] そのマルチキャスト判別部は、受信した明示的マルチキャストパケットの宛先 IPアド レスが、登録済みのリンクレベルマルチキャストアドレスであるか否かを判別するもの である。また、送信グループ分類部は、マルチキャスト判別部が登録済みのリンクレ ベルマルチキャストアドレスであると判別した場合に、宛先リストに記述された宛先ァ ドレスと経路表に基づいて、受信した明示的マルチキャストパケットを送出する転送 先インターフェイスを決定するものである。そして、送信グループ分類部は、当該明 示的マルチキャストパケットを受信したインターフェイス以外の転送先インターフェイ ス毎に、明示的マルチキャストパケットを次ホップノードへュ-キャストにより送信する 宛先グループと、リンクレベルマルチキャストにより送信する宛先グループとに宛先リ ストの宛先を分類するものである。
[0157] また、パケット生成部は、受信した明示的マルチキャストパケットに含まれる宛先リス トを、マルチキャストの宛先グループの宛先のみが有効となるように変更するものであ る。そして、パケット生成部は、宛先アドレスにマルチキャストアドレスを設定する、ある いはュ-キャストの宛先グループに属する宛先ノードへ中継する次ホップノードを経 路表に基づいて決定する。さらに、パケット生成部は、当該次ホップノードの中継先 の宛先ノードのみ有効となるように宛先リストを変更し、宛先アドレスに当該次ホップノ ードのアドレスを設定する。
[0158] また、送信部は、パケット生成部により生成された明示的マルチキャストパケットを、 送信グループ分類部により決定された、当該明示的マルチキャストパケットの有効な 宛先ノードに該当する転送先インターフェイス力も送信するものである。
[0159] これにより、中継ノードは、ブロードキャストリンク上に同じパケットがループすること がないように、 XCASTパケットをリンクレベルマルチキャストによる配信できる。その 結果、ブロードキャストメディアにおける通信帯域の消費を削減することができる。
[0160] また、本発明の第 8の態様は、第 7の態様に係る中継ノードにおいて、経路管理部 をさらに有している。この経路管理部は、明示的マルチキャストパケットをリンクレベル マルチキャストにより受信したとき、受信したインターフェイスへ当該明示的マルチキ ャストパケットを逆方向転送しない機能を有するか否かをブロードキャストメディア上の ノードへ問い合わせるものである。そして、送信グループ分類部が問い合わせに対し 、逆方向転送しな 、機能を有すると応答した次ホップノードをマルチキャストの宛先グ ループに分類する。また、送信グループ分類部は、応答以外の応答をした次ホップノ ードをュ-キャストの宛先グループに分類する。
[0161] これにより、中継ノードは、宛先リストの宛先ノードを、リンクレベルマルチキャストに よる XCASTパケットの送信をしてもよ!、グループと、送信しては!、けな 、グループと に分類することができる。
[0162] また、本発明の第 9の態様に係る受信ノードは、複数の宛先アドレスの記述された 宛先リストに基づいて転送先を決定するものである。特に、本発明の受信ノードは、 マルチキャスト判別部と送信判別部と受信部と経路管理部と送信部とを有している。
[0163] そのマルチキャスト判別部は、受信した明示的マルチキャストパケットの宛先 IPアド レスが、登録済みのリンクレベルマルチキャストアドレスであるか否かを判別するもの である。また、送信判別部は、マルチキャスト判別部が登録済みのリンクレベルマル チキャストアドレスであると判別した場合、明示的マルチキャストパケットの転送を禁止 するものである。一方、判別しない場合、送信判別部は、明示的マルチキャストバケツ トに含まれる宛先リストの有効な宛先アドレスの内、自己のアドレスを無効に修正し、 残りの有効な宛先アドレスの一つのノードへ、当該明示的マルチキャストパケットを送 信可とするものである。
[0164] また、受信部は、送信判別部による明示的マルチキャストパケットの転送を禁止する 機能を有する力否かの問い合わせを受信するものである。経路管理部は、問い合わ せに対して当該機能を有することを応答するものである。
[0165] また、送信部は、送信判別部が明示的マルチキャストパケットを送信可と判別したと き、有効な宛先アドレスの一つのノードへ、修正された明示的マルチキャストパケット をュ-キャストにより送信するものである。
[0166] これにより、受信装置は、 XCASTパケットをリンクレベルマルチキャストにより受信し た場合、ブロードキャストメディア上の他の受信装置への逆方向転送を抑制するので 、ブロードキャストメディア上をパケットがループすることを防止できる。
[0167] 2006年 2月 17日出願の特願 2006— 040572の日本出願に含まれる明細書、図 面および要約書の開示内容は、すべて本願に援用される。
産業上の利用可能性
[0168] 本発明は、 XCASTパケットの配信等において、ブロードキャストメディアの通信帯 域の消費を抑えながら明示的マルチキャストパケットを伝送することができるパケット 送信方法、中継ノード、および受信ノードとして有用である。

Claims

請求の範囲
[1] 複数の宛先ノードのアドレスが記述された宛先リストを含む明示的マルチキャストパ ケットの転送先を、前記宛先リストに基づいて決定するパケット送信方法であって、 第一ノードが、前記宛先リストにアドレスが記述された宛先ノードを、次ホップノード へのュ-キャストにより送信する宛先グループと、次ホップノードへのリンクレベルマ ルチキャストにより送信する宛先グループとに分類するグループ分類ステップと、 前記第一ノードが、前記グループ分類ステップによる分類に従って、明示的マルチ キャストパケットをュ-キャストまたはリンクレベルマルチキャストにより送信する送信ス テツプと、
第二ノードが前記リンクレベルマルチキャストにより明示的マルチキャストパケットを 受信したとき、前記パケットを受信したインターフェイス以外のインターフェイス側に位 置する、前記パケットに含まれる宛先リストにアドレスが記述された未配送の宛先ノー ドへのみ、前記パケットを転送する逆方向転送禁止ステップと、
を有するパケット送信方法。
[2] 前記第一ノードが、次ホップノードに前記逆方向転送禁止ステップの実施の可否を 問!、合わせる問 、合わせステップと、
前記問 、合わせステップによる問 、合わせを受けた次ホップノードが、前記問 、合 わせに応答する応答ステップと、をさらに有し、
前記グループ分類ステップにお 、て、
前記第一ノードは、前記応答ステップで前記逆方向転送禁止ステップの実施可と 応答した次ホップノードによる中継先の宛先ノードを前記リンクレベルマルチキャスト の宛先グループに分類し、前記応答ステップで前記逆方向転送禁止ステップの実施 可以外の応答をした次ホップノードによる中継先の宛先ノードを前記ュ-キャストの 宛先グループに分類する、
請求項 1に記載のパケット送信方法。
[3] 前記第一ノードが、前記宛先リストにアドレスが記述された宛先ノードを、当該宛先 ノードへ明示的マルチパケットを中継する次ホップノードが接続するリンクとのインタ 一フェイスで分類するインターフェイス分類ステップ、をさらに有し、 前記グループ分類ステップにお 、て、
前記宛先グループの分類を、前記インターフェイス分類ステップで分類されるインタ 一フ イス毎に行う、
請求項 2に記載のパケット送信方法。
[4] 前記第一ノードが、前記ュ-キャストの宛先グループに分類した宛先ノードへ中継 する次ホップノードを経路表に基づいて決定するュ-キャスト宛先グループ決定ステ ップと、
前記第一ノードが、前記ュニキャスト宛先グループ決定ステップで決定された前記 次ホップノードの中継先の前記宛先ノードのみ有効となるように前記宛先リストを変更 するリスト変更ステップと、をさらに有し、
前記送信ステップにお ヽて、
前記第一ノードが、前記リスト変更ステップで変更された前記宛先リストを含む前記 明示的マルチキャストパケットをュ-キャストにより次ホップノードへ送信する、 請求項 2に記載のパケット送信方法。
[5] 前記第一ノードが、前記リンクレベルマルチキャストの宛先グループに分類した宛 先ノードのみ有効となるように前記宛先リストを変更するリスト変更ステップ、をさらに 有し、
前記送信ステップにお ヽて、
前記第一ノードが、前記リスト変更ステップで変更された前記宛先リストを含む前記 明示的マルチキャストパケットをリンクレベルマルチキャストにより次ホップノードへ送 信する、
請求項 2に記載のパケット送信方法。
[6] 前記第一ノードが、未使用のリンクレベルマルチキャストアドレスを獲得するアドレス 獲得ステップ、をさらに含み、
前記送信ステップにお ヽて、
前記第一ノードが、前記リンクレベルマルチキャストによる明示的マルチキャストパ ケットを送信するときに、前記アドレス獲得ステップで獲得したリンクレベルマルチキヤ ストアドレスを宛先 IPアドレスに設定して送信する、 請求項 2に記載のパケット送信方法。
[7] 複数の宛先ノードのアドレスが記述された宛先リストを含む明示的マルチキャストパ ケットの転送先を、前記宛先リストに基づ 、て決定する中継ノードであって、
受信した明示的マルチキャストパケットの宛先 IPアドレス力 登録済みのリンタレべ ルマルチキャストアドレスであるか否かを判別するマルチキャスト判別部と、
宛先 IPアドレスが登録済みのリンクレベルマルチキャストアドレスであると判別され た明示的マルチキャストパケットについて、当該パケットに含まれる宛先リストに記述 された宛先アドレスと経路表に基づいて当該パケットを送出する転送先インターフエ イスを決定し、当該パケットを受信したインターフェイス以外の転送先インターフェイス 毎に、当該パケットに含まれる宛先リストにアドレスが記述された宛先ノードを、次ホッ プノードへのュ-キャストにより送信する宛先グループと、次ホップノードへのリンクレ ベルマルチキャストにより送信する宛先グループとに分類する送信グループ分類部と 前記パケットに含まれる宛先リストを前記リンクレベルマルチキャストの宛先グルー プに分類された宛先ノードのみ有効となるように変更して当該パケットの宛先アドレス にリンクレベルマルチキャストアドレスを設定した明示的マルチキャストパケットを生成 するとともに、前記ュ-キャストの宛先グループに分類された宛先ノードへ中継する 次ホップノードを前記経路表に基づ!/、て決定し、前記パケットに含まれる宛先リストを 当該次ホップノードの中継先の宛先ノードのみ有効となるように変更して当該パケット の宛先アドレスに当該次ホップノードのアドレスを設定した明示的マルチキャストパケ ットを生成するパケット生成部と、
前記パケット生成部により生成された明示的マルチキャストパケットを、前記送信グ ループ分類部が当該パケットに対して決定した転送先インターフェイスから、当該パ ケットの有効な宛先ノードに送信する送信部と、
を有する中継ノード。
[8] 明示的マルチキャストパケットをリンクレベルマルチキャストにより受信したとき、受信 したインターフェイスへ当該明示的マルチキャストパケットを逆方向転送しない機能を 有する力否かをブロードキャストメディア上のノードへ問 、合わせる経路管理部、をさ らに有し、
前記送信グループ分類部は、
前記問 、合わせに対し、逆方向転送しな 、機能を有すると応答した次ホップノード の中継先の宛先ノードを前記リンクレベルマルチキャストの宛先グループに分類し、 前記応答以外の応答をした次ホップノードの中継先の宛先ノードを前記ュニキャスト の宛先グループに分類する、
請求項 7に記載の中継ノード。
複数の宛先ノードのアドレスが記述された宛先リストを含む明示的マルチキャストパ ケットの転送先を、前記宛先リストに基づいて決定する受信ノードであって、
受信した明示的マルチキャストパケットの宛先 IPアドレス力 登録済みのリンタレべ ルマルチキャストアドレスであるか否かを判別するマルチキャスト判別部と、
宛先 IPアドレスが登録済みのリンクレベルマルチキャストアドレスであると判別され た前記明示的マルチキャストパケットの転送を禁止するとともに、宛先 IPアドレスが登 録済みのリンクレベルマルチキャストアドレスではないと判別された明示的マルチキヤ ストパケットに含まれる宛先リストの有効な宛先アドレスのうち自己のアドレスを無効に 修正した上で残りの有効な宛先アドレスの一つのノードへ当該パケットを送信可とす る送信判別部と、
宛先 IPアドレスが登録済みのリンクレベルマルチキャストアドレスである明示的マル チキャストパケットの転送を禁止する機能を有するか否かの問い合わせを受信する受 信部と、
前記問い合わせに対して前記機能を有することを応答する経路管理部と、 前記送信判別部が送信可とした明示的マルチキャストパケットを、当該パケットに含 まれる宛先リストの有効な宛先アドレスが示す宛先ノードの一つへュ-キャストにより 送信する送信部と、
を有する受信ノード。
PCT/JP2007/052879 2006-02-17 2007-02-16 パケット送信方法、中継ノード、および受信ノード WO2007094465A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN200780003058XA CN101371534B (zh) 2006-02-17 2007-02-16 分组发送方法、中继节点和接收节点
EP07714409.5A EP1986380B1 (en) 2006-02-17 2007-02-16 Packet transmitting method, relay node and receiving node
US12/279,164 US7876756B2 (en) 2006-02-17 2007-02-16 Packet transmitting method, relay node and receiving node

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006-040572 2006-02-17
JP2006040572A JP4487948B2 (ja) 2006-02-17 2006-02-17 パケット送信方法、中継ノード、および受信ノード

Publications (1)

Publication Number Publication Date
WO2007094465A1 true WO2007094465A1 (ja) 2007-08-23

Family

ID=38371641

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/052879 WO2007094465A1 (ja) 2006-02-17 2007-02-16 パケット送信方法、中継ノード、および受信ノード

Country Status (5)

Country Link
US (1) US7876756B2 (ja)
EP (1) EP1986380B1 (ja)
JP (1) JP4487948B2 (ja)
CN (1) CN101371534B (ja)
WO (1) WO2007094465A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070097970A1 (en) * 2005-11-01 2007-05-03 Georgios Margaritis Packet retransmitter
US20080240096A1 (en) 2007-03-29 2008-10-02 Twisted Pair Solutions, Inc. Method, apparatus, system, and article of manufacture for providing distributed convergence nodes in a communication network environment
US8340094B2 (en) * 2008-07-01 2012-12-25 Twisted Pair Solutions, Inc. Method, apparatus, system, and article of manufacture for reliable low-bandwidth information delivery across mixed-mode unicast and multicast networks
JP5387239B2 (ja) * 2009-08-31 2014-01-15 沖電気工業株式会社 無線通信装置及び無線通信プログラム
US8687609B2 (en) * 2009-11-04 2014-04-01 Cisco Technology, Inc. Managing router advertisement messages to support roaming of wireless mobile client devices
US8724583B2 (en) * 2009-11-04 2014-05-13 Cisco Technology, Inc. Neighbor discovery message handling to support roaming of wireless mobile client devices
CN105099959A (zh) * 2010-01-29 2015-11-25 华为技术有限公司 一种多播包的转发方法、设备和系统
US8520595B2 (en) 2010-05-04 2013-08-27 Cisco Technology, Inc. Routing to the access layer to support mobility of internet protocol devices
US8446876B2 (en) 2010-05-04 2013-05-21 Cisco Technology, Inc. Maintaining point of presence at access switch for roaming clients in distributed wireless controller system
US8428006B2 (en) 2010-05-04 2013-04-23 Cisco Technology, Inc. Hierarchical control signaling for mobile clients in distributed wireless controller system
US8441983B2 (en) 2010-05-04 2013-05-14 Cisco Technology, Inc. Maintaining point of presence at tunneling endpoint for roaming clients in distributed wireless controller system
US8675601B2 (en) 2010-05-17 2014-03-18 Cisco Technology, Inc. Guest access support for wired and wireless clients in distributed wireless controller system
CN101873273A (zh) * 2010-07-08 2010-10-27 华为技术有限公司 路由转发方法、路由节点及无线通信网络
US8588198B2 (en) * 2010-10-25 2013-11-19 Comcast Cable Communications, Llc Content transmission architecture
EP2832076B1 (en) * 2012-03-30 2018-05-02 Nokia Solutions and Networks Oy Centralized ip address management for distributed gateways
EP2770744A1 (en) * 2013-02-26 2014-08-27 Ntt Docomo, Inc. Method and apparatus for performing multicast transfer in an optical ring
US9497083B1 (en) * 2013-06-10 2016-11-15 Palo Alto Networks, Inc. Discovering network nodes
FR3009163B1 (fr) * 2013-07-25 2015-09-04 Thales Sa Procede pour l'echange en securite d'une donnee sur un reseau ad-hoc mettant en oeuvre un service de diffusion xcast; noeud associe
JP7232121B2 (ja) * 2019-05-10 2023-03-02 アズビル株式会社 監視装置および監視方法
CN111404701B (zh) * 2019-12-16 2022-04-05 杭州复杂美科技有限公司 一种信息广播方法、设备及存储介质
CN113141579B (zh) * 2020-01-19 2022-05-13 深圳市云海物联科技有限公司 无线通信方法、装置和系统
US11743067B2 (en) * 2021-12-06 2023-08-29 Cisco Technology, Inc. Systems and methods for preventing solicited-node multicast address collisions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000354063A (ja) 1999-06-10 2000-12-19 Fujitsu Ltd パケットのマルチキャスト配送システム
US20030046425A1 (en) 2001-07-06 2003-03-06 Ji-Woong Lee Method and apparatus for explicit multicast service in ethernet
WO2004043019A1 (ja) * 2002-11-05 2004-05-21 Fujitsu Limited ネットワーク中継方法及び装置
JP2006040572A (ja) 2004-07-22 2006-02-09 Toyota Central Res & Dev Lab Inc 水系リチウム二次電池用正極活物質及び水系リチウム二次電池

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100425020B1 (ko) * 2001-11-26 2004-03-27 주식회사 케이티프리텔 명시적 멀티캐스트의 터널링 서비스 방법 및 장치
US6965883B2 (en) * 2002-02-20 2005-11-15 Nokia Corporation Charging mechanism for multicasting
JP2004297180A (ja) 2003-03-25 2004-10-21 Matsushita Electric Ind Co Ltd マルチキャスト配送システム及び方法
JP4328283B2 (ja) * 2003-10-22 2009-09-09 パナソニック株式会社 パケット配送制御方法
US8018964B2 (en) * 2005-12-16 2011-09-13 Cisco Technology, Inc. Multicast operations using prioritized state information

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000354063A (ja) 1999-06-10 2000-12-19 Fujitsu Ltd パケットのマルチキャスト配送システム
US20030046425A1 (en) 2001-07-06 2003-03-06 Ji-Woong Lee Method and apparatus for explicit multicast service in ethernet
JP2003069640A (ja) * 2001-07-06 2003-03-07 Ktfreetel Co Ltd イーサネット（登録商標）上における明示的マルチキャストサービス方法及び装置
WO2004043019A1 (ja) * 2002-11-05 2004-05-21 Fujitsu Limited ネットワーク中継方法及び装置
JP2006040572A (ja) 2004-07-22 2006-02-09 Toyota Central Res & Dev Lab Inc 水系リチウム二次電池用正極活物質及び水系リチウム二次電池

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JIWOONG LEE: "Explicit Multicast over Ethernet", IETF INTERNET-DRAFT, 23 January 2002 (2002-01-23), pages 1 - 10, XP003017124, Retrieved from the Internet <URL:http://www.watersprings.org/pub/id/draft-lee-xcast-ethernet-02.txt> *
Y.IMAI; M.SHIN; Y.KIM: "XCAST6: eXplict Multicast on IPv6", IEEE/IPSJ SAINT2003 WORKSHOP 4, IPV6 AND APPLICATIONS, January 2003 (2003-01-01)

Also Published As

Publication number Publication date
CN101371534B (zh) 2011-12-14
US7876756B2 (en) 2011-01-25
JP2007221521A (ja) 2007-08-30
JP4487948B2 (ja) 2010-06-23
CN101371534A (zh) 2009-02-18
EP1986380A1 (en) 2008-10-29
EP1986380A4 (en) 2013-09-25
US20090059924A1 (en) 2009-03-05
EP1986380B1 (en) 2015-09-02

Similar Documents

Publication Publication Date Title
WO2007094465A1 (ja) パケット送信方法、中継ノード、および受信ノード
KR101256687B1 (ko) 다중 경로 설정 장치 및 방법
Clausen et al. Mobile ad hoc network (manet) neighborhood discovery protocol (nhdp)
US6704293B1 (en) Broadcast as a triggering mechanism for route discovery in ad-hoc networks
JP4817131B2 (ja) Ｉｐネットワークシステム
CN1839585B (zh) 具有增强的可扩展性和可靠性的即插即用网络配置的方法和设备
KR100811890B1 (ko) 인터넷 시스템에서 서비스 플로우를 보장하는 애니캐스트라우팅 방법 및 장치
JP5115819B2 (ja) Ｉｐネットワークシステム
KR20040000633A (ko) 외부망에서의 ｄｎｓ 서버 검색 장치 및 방법
WO2012156852A1 (en) Label switched routing to connect low power network domains
TWI793361B (zh) 用於藍芽網路之獨立冗餘路徑探索
US8774188B2 (en) Communication apparatus and method of controlling same
JP2008271595A (ja) 通信システム及びアクセスルータ並びにモバイルノード
JP2003516034A (ja) ルート発見機構のトリガとしての同報通信
US20130148658A1 (en) Systems and methods for scalable multicast communication using self-rooted forwarding trees
JP2006279168A (ja) アドホック網を構成する通信装置、ブリッジ装置及び通信システム
US20080013538A1 (en) Method of transmitting neighbor discovery protocol message in IEEE 802.16/Wibro network
KR100514742B1 (ko) 통합 캐시를 이용하여 다음 홉 주소를 결정하는 장치 및 방법
US20060209774A1 (en) Wireless base station, wireless mobile device, and wireless access network
US7460511B2 (en) Device connectivity
JP2020010315A (ja) ネットワークトポロジー取得方法及び装置
JP2005311576A (ja) 無線通信装置、無線通信プログラムおよび経路探索方法
US9451420B2 (en) Data processing method, in an ad hoc radio communication network, radio communication stations and corresponding computer programs
US11811658B1 (en) Method for mobile ad-hoc network (manet) multi-hop routing in a broadcast domain
CN102316006B (zh) 一种发送数据报文的方法和装置

Legal Events

Date Code Title Description
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: 200780003058.X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2007714409

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12279164

Country of ref document: US