JPH10308756A - Equipment and method for communication - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute IP multicast while effectively utilizing communication resources by transmitting a 2nd message concerning the identifier of broadcasting type channel on an established network to 2nd communication equipment based on a 1st message containing the securing request of band received from 2nd communication equipment. SOLUTION: A terminal 103 connected to a 1st domestic network 105 transmits the 1st message containing the identifier of network layer multicast data flow(NMD) and the securing request of band. A video server 101, which receives this message through a connector 102 and a public network 104, establishes the broadcasting type channel on the network 105 based on the 1st message. The video server 101 transmits the 2nd message containing the correspondent relation between the respective identifiers of this broadcasting type channel and the NMD to the terminal 103. Thus, the correspondent relation between the secured channel and the IP multicast can be recognized synchronously on the sides of transmission and reception.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention
The present invention relates to a communication device that performs data communication via a broadcast network such as a bus.

[0002]

2. Description of the Related Art In recent years, rapid advances in communication technology such as the Internet have become a topic in various fields, and LANs have been introduced mainly by companies and universities, or WANs have been introduced.
And the connection to the Internet is becoming a topic.

[0003] These technological innovations are likely to change the network environment surrounding homes. That is, P
As digital devices such as C, DVD, and digital set-top boxes have become widespread, it is inevitable that the desire to connect them to one another via a digital network will increase. Currently, mainly for AV vendors, IEEE13
The 94 bus is attracting attention from various directions as the leading candidate.

The IEEE 1394 bus is 100M, 20M
It can be used as a high-speed digital network of 0M and 400Mbps, and has a number of remarkable functions such as plug-and-play and a synchronous transfer function using a synchronous channel.

At the same time, technological innovations in so-called home access networks are also urgent. That is, CATV or ADSL
(Asymmetric Digital Subsc
FTTH (fiber-t)
Progress has been remarkable in high-speed network technologies such as o-the-home, network services such as the Internet, and the like. In particular, Internet technology has been
SVP (Resource Reservation P)
Quality of Service (QOS) using a network layer level signaling protocol such as protocol
f Service) Remarkable technologies such as guarantee and multicast have been born one after another.

In the near future where these technologies will be realized on the Internet, high-speed,
Some of the transfer of information that requires real time may take place over the Internet. This is because it is quite natural that the amount of information stored on the Internet is substantially infinite, and that users will obtain the information via the Internet, which has been conventionally obtained from terrestrial broadcasting, satellite broadcasting, and the like. That is.

[0007]

However, when digital devices in the home are connected via an access network and information is exchanged through the Internet,
The following problems are conceivable.

(Problem 1) At present, studies for distributing data on the Internet over IEEE 1394, ie, studies on “IP over 1394” are being advanced in various fields. However, the study is currently limited to the so-called address resolution method. On the other hand, RSVP, for example, has been proposed as a signaling protocol for exchanging data in a form that guarantees communication quality on the Internet. However, a method for operating these network layer signaling protocols on IEEE 1394 has not yet been determined, and it has to be mapped to a transfer method that does not ensure communication quality on IEEE 1394. Therefore, even if the above-mentioned signaling is performed, data is transferred through IEEE 1394 through best effort (specifically, an asynchronous channel), so that end-to-end communication quality cannot be maintained.

(Problem 2) When the I
When trying to send and receive P multicast, IEEE
To minimize traffic on the 1394 bus, I
It is conceivable to use a synchronous channel or an asynchronous stream of the EEE1394 bus. However, if two or more devices try to join the same IP multicast at the same time, there is a possibility that these two or more devices may independently secure separate channels, making it impossible to effectively use communication resources. Further, there is no mechanism for the transmitting side and the receiving side to synchronously recognize the correspondence between the secured channel and the IP multicast address.

Therefore, the present invention has been made in view of the above problems, and shows a method of applying RSVP on an IEEE 1394 bus. Communication on an IEEE 1394 can be performed while ensuring communication quality in an interconnected environment. It is an object of the present invention to provide a communication device.

[0011] Further, the present invention is capable of performing IP multicast by effectively using communication resources in a broadcast network such as IEEE 1394, and determining the correspondence between a reserved channel and an IP multicast address on the transmitting side. An object of the present invention is to provide a communication device that can be synchronously recognized on a receiving side.

[0012]

[Means for Solving the Problems]

1) Means for solving the above (Problem 1) (Claims 1, 3, and 5) A communication control device of the present invention is a communication device connected to a broadcast network (for example, IEEE 1394), Receiving means for receiving, from a second communication device connected to the network, an identifier for identifying a network layer multicast data flow, and a first message including a request for securing a bandwidth corresponding to the network layer multicast data flow; Based on the first message received by the receiving means, a broadcast-type channel (for example, IEEE13
94 synchronous channel) and a second message including at least a correspondence between the established broadcast type channel identifier and the network layer multicast data flow identifier to the second communication device. Transmitting means, for example, an RSVP allows an upstream node to be connected to an IEEE139
By reserving the synchronization channel No. 4, the requested communication resource received by the receiving means, for example, indicated by the RSVP RESV message, is transmitted to the IEEE 1394.
This can be ensured in the form of a bus synchronization channel, thereby realizing communication in which end-to-end communication resources, which should be realized by a network layer level signaling protocol, are ensured. Further, by having the transmitting means, for example, the receiving terminal can obtain information on the communication resources (that is, the synchronization channel) secured on the IEEE1394 bus corresponding to the RSVP RESV message. The terminal can receive the reception data reserved using RSVP in a form accompanied by the communication resources (see FIG. 2).

[0013] A first request including the request for securing communication resources is provided.
(For example, an RSVP RESV message) and / or a second message including the correspondence (for example, an RSVP PATH message) is a message of a communication resource reservation request protocol for transmitting and receiving data on the Internet. Accordingly, it is not necessary to prepare another message for notifying the correspondence, and the receiving device (such as a table for associating the PATH message with the another message) may be used.
For example, there is no need to prepare a receiving terminal or a relay router.

(Claims 5 and 6) A communication device according to the present invention comprises:
A communication device connected to a broadcast type network,
A register (e.g., the register that describes the correspondence between the identifier of the broadcast-type channel whose bandwidth required when transmitting and receiving the network layer multicast data flow established on the network and the identifier of the network layer multicast data flow. IE corresponding
EE1394, a register called PCR) to notify another node of the correspondence between the synchronization channel number on the 1394 bus described in this register and the information on the flow passing through the synchronization channel. Alternatively, it can be obtained from another node. That is, when the node having the register is a transmitting node, another node on the 1394 bus refers to this register, and thereby, on the synchronization channel on the 1394 bus described in this register, It is possible to know what flow is passing (that is, what flow the transmitting node is transmitting). Further, when the node having the register is a receiving node, another node on the 1394 bus writes a corresponding relationship in the register of the receiving node, so that the receiving node stores the corresponding relationship in the register. It becomes possible to know what flow flows on the described synchronization channel on the 1394 bus (that is, what flow the receiving node receives).

[0015] The register may further include a field for distinguishing between transmission and reception. This allows
It is possible to clarify which of the transmission node and the reception node uses this register.

Further, the register stores the IEEE13.
From another node connected to the H.94 bus, data is transferred between a plurality of networks by referring to the identifier of the network layer multicast data flow based on the synchronization channel number described in the register and describing the contents thereof. You may.

By referring to the register, the node can know the attributes of the flow coming through the synchronization channel, which means that the node does not have to investigate the contents of the flow, Means that the attribute of the flow can be known from the number. Therefore, by directly mapping the identifier of the transfer destination network or the (virtual) channel of the transfer destination network based on the value of the synchronization channel number, data transfer to other connected networks can be performed. This can be directly performed only by referring to and processing the link layer information.

Further, the data flow may be an Internet data flow. In this case, the information about the IP flow, that is, the transmission / reception IP address, the transmission / reception port number, the application protocol type, and the like are notified to other nodes using the register as the information about the flow passing through the synchronization channel. be able to.

A communication device according to the present invention is a communication device connected to a broadcast type network, in which a band required for transmitting and receiving a network layer multicast data flow is guaranteed. Establishing means for establishing a broadcast-type channel, and transmitting means for transmitting a message including at least the correspondence between the identifier of the established broadcast-type channel and the identifier of the network layer multicast data flow, The required communication resources indicated by, for example, an RSVP PATH message transmitted from the upstream node by the downstream node transmitting the RSVP RESV message reserving a synchronization channel on the upstream side. Can be secured in the form of an IEEE 1394 bus synchronization channel. Thus, communication in which end-to-end communication resources are secured, which should be realized by a network layer level signaling protocol, can be realized.

Further, by providing the transmitting means, information on a communication resource (ie, a synchronization channel) secured on the IEEE 1394 bus corresponding to the previously transmitted PATH message can be transmitted to the upstream node (transmitting terminal). Or a relay router), so that the upstream node can transmit the received data reserved using, for example, RSVP, using the communication resources in a form accompanied by the communication resources. .

In the communication apparatus according to the present invention, the message for notifying the correspondence is a message of a request protocol for securing communication resources when transmitting and receiving data on the Internet (for example, a PATH message of RSVP).
Therefore, it is not necessary to prepare another message for notifying the correspondence, and a table or the like for associating the RESV message with the another message is stored in an upstream node (for example, a transmission terminal or a relay router) Need not be prepared.

(Claim 13 (corresponding to claim 1)) A communication method according to the present invention is characterized in that an identifier for identifying a network layer multicast data flow transmitted from a communication device connected to a broadcast network and the network layer multicast are provided. When receiving a first message including a request for securing a band corresponding to the data flow,
Establishing a broadcast type channel on the network based on the message of the above, and transmitting a second message including at least a correspondence relationship between the identifier of the established broadcast type channel and the identifier of the network layer multicast data flow to the communication device. It is characterized by doing.

2) Means for Solving the (Problem 2) A communication device according to the present invention (claims 7 and 8) is a communication device connected to a broadcast-type network. Receiving means for receiving a request for joining a network layer multicast address from a connected second communication device; establishing means for establishing a broadcast-type channel on the network in response to the request for joining; and at least the established broadcast Notifying means for notifying the second communication device of the correspondence between the type channel identifier and the network layer multicast address, and sending means for sending data addressed to the network layer multicast address to the established broadcast type channel And the corresponding network layer multicast The establishment of the synchronization channel for signal, accepts subscription application to the multicast address IG
By performing the MP router, it is possible to prevent a plurality of channels from being established for the same multicast address and to waste communication resources in the network.

Also, by notifying the second communication device of the correspondence between the established broadcast-type channel identifier and the network layer multicast address, the second communication device (receiving terminal) can determine which channel ,
It becomes possible to notify whether or not the multicast data can be received. Further, since a broadcast-type channel is used, a plurality of receiving terminals can be accommodated through one channel.

Further, the communication device of the present invention (claim 8)
Second receiving means for receiving, from the second communication device, a request for securing a band necessary for receiving data addressed to the network layer multicast from the second communication device, and By further providing a securing unit for securing a band, it is possible to perform transmission in a form in which the communication quality of the multicast is guaranteed.

The communication device of the present invention (claims 9 to 12)
A communication device connected to a broadcast-type network and transmitting data addressed to a network layer multicast address, comprising: a securing unit that secures a communication band for a broadcast-type channel established on the network; When a band is reserved for a broadcast channel, data addressed to the network layer multicast address is transmitted at a cycle or connection in which the band of the broadcast channel is reserved, and when a band is not reserved for the broadcast channel. Transmitting means for transmitting data addressed to the network layer multicast address at a period or connection in which the bandwidth of the broadcast type channel is not secured, when transmitting a network layer multicast packet in a form having a band, That ma By sender of a multicasting packet according to the rules of ensuring bandwidth, such as a plurality of nodes would ensure a bandwidth for the same channel at the same time, it is possible to avoid the double securing of the so-called band. In addition, it is considered that the transmitting node normally knows the value of the normally required band, and thus it is appropriate from this viewpoint.

A communication device according to the present invention (claim 12)
The identifier of the broadcast-type channel when the bandwidth is secured by the securing means is the same identifier as the broadcast-type channel when the bandwidth is not secured, thereby preventing waste of the channel number. Possible, especially the IEEE
For a data link such as an E1394 bus in which the number of channel numbers has a relatively small upper limit (64 in the case of IEEE 1394), the IP to be transmitted with a band is used.
The multicast packet and the IP multicast packet flowing at the best effort without the band can be shared on the same channel, which also leads to effective utilization of communication resources.

The communication method of the present invention (claim 14 (claim 7
)) Establishes a broadcast-type channel on the network in response to an application to join a network layer multicast address from a communication device connected to the broadcast-type network, and at least an identifier of the established broadcast-type channel And transmitting the data addressed to the network layer multicast address to the established broadcast type channel after notifying the communication device of the correspondence between the network device and the network layer multicast address.

The communication method of the present invention (claim 15 (claim 1
1) is connected to a broadcast-type network, and in a communication method for transmitting data addressed to a network layer multicast address, when a communication band is secured for a broadcast-type channel established on the network. Transmitting the data addressed to the network layer multicast address at a cycle or connection in which the bandwidth of the broadcast channel is secured, and when the bandwidth is not secured in the broadcast channel, the data addressed to the network layer multicast address is transmitted. The transmission is performed in a cycle or connection in which the band of the broadcast channel is not secured.

[0030]

Embodiments of the present invention will be described below with reference to the drawings. In the following description, a network (home network) constructed in a home will be described as an example. However, the present invention is not limited to this. For example, the network may be limited to a building such as a hotel or a site. The present invention can be applied to a constructed network.

(First Embodiment) FIG. 1 shows a first embodiment of the present invention.
Shows an example of the configuration of the entire network according to the embodiment, the data from the video server that provides video services, via the public network into the home network, the terminal connected to the home network Is a diagram for explaining the situation of receiving the service.

As shown in FIG. 1, the overall configuration is a video server 101, a public network 104, a connection device 102, for example, a first network 105, a second network 106, and a first network built in a home. Is connected to the terminal 103.

In FIG. 1, the first network 105
Although only one terminal 103 is connected to the network, actually, various other terminals or inter-network connecting devices may be connected to both networks 105 and 106.

The public network is, for example, a CATV network or an I-network.
Various cases are conceivable, such as an SDN / B-ISDN network, an ATM-PON network, a high-speed wireless access network, and an ADSL / HDSL network. However, the video service of the present embodiment is MP
It is assumed that the EG video is provided via the Internet (MPEGoverIP). Therefore, the interface provided with this service is assumed to be a digital interface.

In the present embodiment, the following description will be made assuming that the digital network adopts the ATM system as the data link system. However, the system of the present invention is not limited to the ATM system. Absent. For example, data link layer identifiers such as VPI / VCI of an ATM described below correspond to a B channel identifier for ISDN and a frequency for CATV. Thus, the VPI / VCI in the ATM of the present embodiment is
Are replaced by these other data link layer identifiers are also included in the present invention.

The video server 101 may be a dedicated video server or a server capable of transmitting video signals, such as a video-compatible WWW server. Here, "can transmit a video signal" does not necessarily mean that real-time transmission is performed. For example, this corresponds to a case where video data is distributed not by real-time distribution but by best effort.

The public network 104 and the network constructed in the home are connected by a dedicated connection device 102.

In this case, the public network 1
04 termination function, home networks 105 and 106
Termination function, IP processing function, NAT (Network Address) standardized by RFC1631
In addition to the Translation function, an IP multicast compatible function, an IP signaling function, a data link layer level switch capable of real-time data transfer between a public network and a home network, an address notification function, and the like are implemented. Details will be described later.

Next, the IP on the network shown in FIG.
A description will be given of the subnet configuration and the address assignment of the network. As shown in FIG. 1, in the first embodiment, in the entire home network (the first and second networks 10 and 10).
5, 106) constitute one IP subnet (network address P), and the home network uses a private address standardized by RFC1597.

A global IP address (G.2) is assigned to the public network side of the connection device 102.

The reason for such an address configuration is that, for example, acquisition of a plurality of global IP addresses is more expensive than acquisition of one global IP address, or the global IP address is exhausted. It is. That is, a global I / O is required for a terminal connected to a home network where the number of terminals and addresses is expected to grow rapidly.
New assignment of P address is practically almost impossible,
This is for reasons such as.

The first network 105 and the second network 106 may be in different subnets, provided that they are in different private addresses. In this case, the connecting device 10 between them
2 is a router.

In the present embodiment, the following description will be made assuming that the first and second networks 105 and 106 belong to the same subnet.

Next, the terminal 103 in FIG.
2. A processing procedure until the video is transferred from the video server through the public network 104 will be described with reference to FIG. 3 and 4 show the processing procedure of the terminal 103 and the processing procedure of the connection device 102 at that time, respectively.

FIGS. 2, 3, and 4 show that the connection device 102 is connected to an SBM (Subnet Bandwidth) as described later.
th Manager), and describes a sequence in the case of using communication mechanism to secure communication resources using this mechanism.

The SBM is being discussed in the IETF IntServ working group, and secures communication resources in a subnet by using RSVP.

First, the terminal 103 obtains information on a video to be viewed by using a protocol of layer 5 or higher among the standardized 7 layers of OSI (steps S201 and S203). This is MPEG / DAVI
Various cases are conceivable, such as negotiation using C's DSM-CC, a protocol according to the CSM, and selection of information by performing selection of information from a WWW server on the Web using RTSP or the like. Hereinafter, this is collectively expressed as “upper layer protocol”.

In this embodiment, the exchange of such information is as follows.
It is assumed that this is performed using an IP packet.

Incidentally, this upper layer protocol is:
Communication may be performed while receiving NAT processing in the connection device 102 (step S202).

The NAT processing means that when forwarding an IP packet from a private IP network to the Internet, it is not allowed to send a private IP address to the Internet.
This is a method in which a private IP address is converted into its own global IP address (here, “G.2”) and transmitted.

For details of the NAT processing, see, for example, Japanese Patent Application No. 8-316552 by the present inventors.

In the present embodiment, the video service from the video server is provided through IP multicast. Therefore, when a video to be selected is determined using the upper layer protocol, it is necessary to acquire an IP multicast address for transferring the video.

There are several possible broadcast forms (distribution forms).

(A) First, for each video (for each content)
The following describes the case where different IP multicast addresses are assigned to the IP addresses.

This is because, for example, broadcasting from broadcasting station A is IP
The multicast address = “# 1”, and the broadcast from the B broadcast station is a case where an IP multicast address such as “# 6” is assigned.

Through the upper layer protocol, the video server 101 notifies the terminal 103 of the multicast address “M” for transferring the video. Then
The terminal 103 responds to the QUERY message received from the Internet side according to the IP multicast protocol (for example, IGMP (RFC1112)) by sending a REPO message for the multicast address “M” to be subscribed.
An RT message is sent (step S204).

[0057] The connection device 102 that has received the request, the terminal 1
After storing the correspondence between the private address “P.2” of No. 03 and the requested multicast address “M” (step S205), it notifies the upstream router of a REPORT message (step S206). that time,
The sender address is set to the global IP address “G.2” of the own device (connection device 102).

FIG. 5 shows an example of the correspondence table stored in the connection device 102.

When the joining to the multicast address “M” succeeds, the connection device 102 stores that the terminal 103 has joined the multicast address “M” (step S 205), and notifies the terminal 103 of this.

Next, the terminal 103 reserves communication resources for receiving the video image with good quality. Several methods can be considered for this purpose.

(A) Method using SBM SBM (Subnet Bandwidth Mana)
ger) is an Internet standardization organization, IE
This is a scheme for bandwidth reservation in a subnet proposed by TF, in which bandwidth reservation in a subnet is performed using RSVP.

(B) RSVP (Resource R)
(c) Method using IEC1883 Hereinafter, the method will be described in order.

(A) Method of Using SBM First, the case of using SBM will be described with reference to the sequence shown in FIG.

Since the connection device 102 is an SBM node, the routing protocol is not running.

Although the connection device of this embodiment has a NAT function and thus has a global IP address (G.2), even if there are a plurality of physical interfaces on the home network side, the physical interface IP for each
You do not need to have an address (private address).
For example, it is sufficient for the connection device 102 to have one private address in addition to the global IP address. Here, the connection device 102 has the private IP address “P.1”.

The terminal 103 sends the RSVP PATH message using the upper layer protocol or the like to the video server 1.
01 may be urged. The PATH message is sent to the multicast address “M” and reaches the connection device 102 (step S207).

In the connection device 102, the PATH of RSVP
A state is created (step S208).
A TH message is sent to the multicast address "M", and eventually arrives at the terminal 103 (step S20).
9). At this time, since the connection device 102 recognizes that the terminal 103 belongs to the multicast address “M” from the correspondence table in FIG. 5, the connection device 102 can forward the PATH message to the terminal 103.

A PATH state is created in the connection device 102. Here, the connection device 102 is an SBM node. The terminal 103 sets the R
An SVP RESV message is sent to the upstream connection device 102 (step S210).

The connection device 1 that has received the RESV message
02 is a first network (IEEE1394) 1 to secure communication resources between the connection device 102 and the terminal 103.
Then, it accesses the IEEE 1394 Synchronous Resource Manager 05 and secures the necessary bandwidth and synchronization channel number (step S211). Here, the number of the secured synchronization channel is “#x”.

At this point, the connection device 102
3, the terminal 103 may be notified of "which synchronous channel should be used to transmit the requested program" (step S212).

As this notification method, for example, there is a method using an RSVP PATH message having a format as shown in FIG. That is, as shown in FIG.
In the PATH message of the RSVP, "the data (IP
The flow) describes information such as “transmission is performed with synchronization channel number =“ # x ””.

The second notification method is disclosed in Japanese Patent Application No.
FANP (Flow At) described in US Pat.
tribute Notification Prot
ocol).

The FANP is used to transmit an IP flow or the like (in the present embodiment, for example, an IP multicast address “M”) between adjacent nodes (between the connection device 102 and the terminal 103 in the present embodiment) and a link. In this embodiment, a correspondence relationship with the layer ID information (in the case of the present embodiment, the channel number of IEEE 1394 previously secured) is notified.

The third notification method is based on the CI of IEC1883.
This is a method using a P header. Using the IEC1883, the connection device 102 transmits the PCR (Plu
g Control Register), write the channel number to be used, the header becomes 1394, IEC
CIP (Common Iso) defined in 1883
terminal 1 in the form of a (chronous Packet) header
03 recognizes that the information being transmitted is MPEGOverIP. For example, when extending the CIP header, the terminal 10 writes a value indicating that the packet is an IP packet or MPEGoverIP in the FMP (format ID) area, and
No. 3 can recognize that the attribute of the packet is an IP packet or an IP packet carrying MPEG by looking at the CIP header.

The fourth notification method is, as shown in FIG.
The CR is extended to mean that a part of the meaning of the PCR register is transmitted to the channel number. For example, it is an IP packet or an MPEGoverIP packet. Further, the attribute of the flow transmitting the channel number may be described. For example, it is a combination of a transmission IP address / reception IP address / transmission port number / reception port number. Such a register is prepared in the terminal 103, and the connection device 102 (or the controller) appropriately describes the register in this register, so that the data received by the terminal 103 through the channel number is an IP packet or an MPEGoverIP packet. Or its attributes.

Needless to say, the above-mentioned first to fourth notification methods can be appropriately combined and used.

Regarding the timing, in addition to the timing described here, a form in which the above procedure is performed when the reservation of the communication resources up to the video server 101 is completed and the end-to-end communication becomes possible. Conceivable.

The connection device 102 that has succeeded in securing the communication resources on the downstream side sends the RSVP RESV message further upstream (step S213).

The router in the Internet that receives this is, for example, The communication resources of the downstream ATM network are secured using 2931 or the like (step S214), and after confirming it, transmission of the RESV message further upstream is repeated.

Further, using PATH or FANP, the downstream RSVP / SBM node uses the data link identifier to be used (in this case, the data link technology is A
Since it is a TM, it sends information about VPI / VCI and notifies the RSVP / SBM node of the correspondence between the sending IP flow and the data link identifier (step S215). Here, it is assumed that the value of the ATM VCI secured for the connection device 102 is “#y”.

When the end-to-end communication resources are secured, the video transfer is started (step S21).
6, S217).

Here, in the connection apparatus 102, the video server 101 sends the ATM connection "#y (VCI value =
"#Y") "to recognize that the data of MPEGOverIP is transmitted, and that the IP packet received on the IEEE 1394 synchronization channel"#x"should be transmitted to the terminal 103. It has recognized.

Therefore, in the connection device 102, the VCI "#
The data received through “y” is transmitted directly to the IEEE 1394 synchronization channel “#x” without verifying the contents of the header of the IP packet, after synchronizing the IP packet. That is, by verifying only the VCI value, it is possible to directly transfer data to the 1394 without processing the IP layer. This can be regarded as a data link switch because data is switched only by the information of the data link layer.

As a result, it is possible to replace a series of software processing, which should be performed by the IP layer, such as IP header verification and routing processing, with the data link layer switching processing. Time and processing load can be significantly reduced. This is equivalent to performing data link switching after performing SBM.

In the above description, the connection device 102 has been described as an SBM node.
Reference numeral 2 denotes a router, which may naturally secure communication resources using RSVP.

Further, when reserving communication resources, the method described in Japanese Patent Application No. 8-264496 by the inventors of the present invention, that is, the reservation of communication resources may be performed by FANP. Good.

The above is a description of a case where a communication resource reservation on IEEE 1394 is performed by a node upstream of RSVP. On the other hand, as shown in FIG.
The downstream node (the terminal 103 in the case of the present embodiment) may secure the synchronization channel on the 394 bus.

After the downstream node secures a synchronization channel having necessary communication resources (step S211)
0), the RESV message is sent to the upstream side (step S2111). In this case, the secured synchronization channel number or the like may be included in the RSVP RESV message to be transmitted continuously and transmitted.

If the user of the terminal 103 wants to watch a different video image (for example, a television program on a different channel), the same procedure as described above is performed again. That is, this is realized by obtaining an IP multicast address corresponding to the new video image through an upper layer protocol or the like, and repeating the procedure of subscribing to the IP multicast address. At that time, it is desirable that the IP multicast address that has joined earlier be removed from the viewpoint of effective utilization of communication resources. This is shown in FIG.

Also, when a plurality of terminals are connected to a network built in the home and each of them is watching a different broadcast, data of each of them passes through the public network 104 and the connection device 102. . In the connection device 102, separate ATM-
It is desirable that these data addressed to different terminals be transmitted by VC. Whether or not the procedure using SBM / RSVP / FANP or the like is necessary again for securing communication resources depends on how to reserve RSVP / SBM. That is, in the case of a shared explicit reservation, the reservation is made first as long as the video server of the sender is the same, or if a new video server for transmitting the next video is registered as the address of the shared explicit server. It is only necessary to continue using the same communication resources (ATM VC, 1394 synchronization channel) as they are, and it is only necessary to re-join the IP multicast.

(B) Next, a case where the IP multicast address is the same and the content changes will be described. In this case, the format is such that a plurality of video services are provided to the same user using the same multicast address, and the video content is changed (corresponding to a change in the television channel) using a higher-level protocol. .

At this time, the same procedure is followed until the first communication resource is secured. However, the IP multicast address given through the upper layer protocol may be an IP multicast address uniquely assigned to the terminal in advance (pre-assigned by the network service provider to each user or each terminal). . For example, a method of identifying a terminal using an identifier previously assigned to each terminal by a network service provider and using an upper layer protocol can be considered.

At the time of the next change of the content (corresponding to the change of the television channel), the terminal requests this content change using the upper layer protocol. The video server 101 uses the used IP multicast address without changing it and sends the changed content to the IP multicast address.

As described above, this IP multicast address is not necessarily used for multicast, as shown in FIG. 10, and may be used for content transfer to a single terminal. That is, each multicast address is assigned to a user (terminal) that has requested video distribution, and the change of the transmission content is handled by, for example, an upper layer protocol.

Also, the IP transmitted from the connection device 102
The difference between the port numbers of the packets may be used as a trigger to determine the assignment of different multicast addresses.

As described above, by assigning a different IP multicast address to each user or each application, the IP multicast address can be dynamically assigned to the terminal. In addition, various contents can be transmitted to a terminal having a private address without worrying about duplication with a globally unique IP address.

(Second Embodiment) FIG. 11 shows an example of the configuration of a network according to a second embodiment of the present invention, in which an IGMP (Internet) is connected to an IEEE 1394 bus.
et Group Management Proto
col) router 2101, a synchronous resource manager 2104 of IEEE 1394, and terminals 2102 and 2103 are connected so as to be able to communicate with each other.

(2-1) A case where terminals 2102 and 2103 join IP multicast and receive multicast data in a network having such a configuration will be described. Here, the terminals 2102 and 2103
After joining the IP multicast, the terminal becomes a receiving terminal of the multicast data.
2, 2103.

A procedure when the receiving terminals 2102 and 2103 join the IP multicast will be described with reference to FIG. The IGMP router 2101 at that time
13 is shown in FIG.

As shown in FIG. 11, IEEE1394
On the bus, an IGMP router 2101, a receiving terminal 210
2, 2103 and a synchronous resource manager 2104 are connected. The IP address of the receiving terminal 2102 is “IP
1 "and the IP address of the receiving terminal 2103 is" IP2 ". The function of the synchronous resource manager 2104 may be integrated with any of the other three devices (that is, one of the IGMP router 2101 and the receiving terminals 2102 and 2103 is a synchronous resource manager). May be).

It is assumed that receiving terminals 2102 and 2103 have previously obtained the IP multicast address “IPm” by some means.

First, it is assumed that the receiving terminal 2102 desires to join the IP multicast address “IPm”.
Therefore, the IGMP router 2101 and the receiving terminal 210
IGMP message exchange (IGMP
Queries and IGMP reports).
The receiving terminal 2102 sends a message to the IGMP router 2101.
The IP multicast address “IPm” is notified that the user wants to join (S2101). Where IG
It is assumed that the MP router 2101 is a router that can support the IP multicast address “IPm”.

The IGMP router 2101 may be like a set-top box. That is, a node having a function of extracting a packet addressed to an appropriate IP multicast address from IP multicast packets transmitted through broadcast waves and forwarding the packet may be used.

The IGMP router 2101 is connected to the receiving terminal 21
When a request to join the IP multicast dress “IPm” is received from 02, processing according to the flowchart of FIG. 13 is executed. That is, in the case of the present embodiment, the subscription request from the receiving terminal 2102 is transmitted to the subnet (IEEE).
1394 bus) from the IP multicast address "I
Pm ”, the IGMP router 2101 performs a process of joining a predetermined IP multicast address (step S2201 to step S220).
2203), if the procedure is successful, then access the synchronous resource manager 2104 to secure a synchronous channel number (step S2204 to step S2)
205, step S2102 in FIG. Note that FIG.
In step S2203, the IGMP router 210
1 works further upstream on the IGMP router,
A procedure for joining the P multicast address may be performed. Further, when the joining procedure processing has failed, the fact is notified to the receiving terminal 2102 (step S2 in FIG. 13).
206).

In step S2205 in FIG.
The synchronization channel number secured by the synchronization resource manager 2104 in response to a request from the GMP router 2101 is set to “#x”. Here, it is not always necessary to secure a band at the same time. This is what the IE secures at this point
This is because it is an EE1394 asynchronous stream.

The asynchronous stream is a packet in the format of a synchronous packet transmitted at the arbitration time of the asynchronous packet, and only the synchronous channel number is secured through the synchronous resource manager 2104.

The case where it is necessary to secure a band will be described later.

Returning to the description of FIG.
01, when the synchronization channel number is secured, next, writes information on this IP multicast flow in its own layer 3 flow register (step S220).
6, step S2103 in FIG. 12).

FIG. 14 shows an example of the format of the layer 3 flow register. The layer 3 flow register basically includes a layer 2 identifier (in this embodiment, a synchronization channel number) and its layer 2 identifier. Is a register for registering a correspondence relationship for a layer 3 flow that passes through a channel represented by. This register additionally contains information on whether the flow is input or output, the amount of bandwidth reserved for the channel represented by the layer 2 identifier, and the use of the channel. An area such as a counter that counts the number of terminals is provided.

As shown in FIG. 14, here, since no band is reserved for the reserved channel, for example, "0" is entered in the band column of the layer 3 flow register.

Since an IP flow whose destination is an IP multicast address “IPm” flows into this channel, “IPm” is used as the flow identifier for the receiving IP address and “IPm” is used for the receiving port number as the flow identifier. If the number is limited, the number (for example, PORT1)
For example, "0" is entered when there is no limitation. In the present embodiment, since there is no particular limitation, “0” is entered.
Since the IP multicast address is not limited to the transmitting terminal, the transmitting terminal and the transmitting port number are each set to “0”.
Is filled in.

As the layer 2 identifier, "IEEE1394" is entered as the layer 2 type, and "synchronous channel number" is entered as the identifier type. As the identifier, "#x", which is the previously secured synchronous channel number, is entered. Filled out.

The direction is basically "forward" assuming that this IGMP router transmits these IP multicast packets.

The connection counter is a counter representing the number of nodes considered to be receiving this asynchronous stream. At this point, it is considered that the receiver is only the receiving terminal 2102, so the counter value “1” is input.

Note that this layer 3 flow register is
The present invention may be realized in the form of a combination of a plug control register used in EC1883 and a register for storing information about a layer 3 flow transferred by the channel.

Next, the IGMP router 2101 sends a request to the layer 3 flow register of the receiving terminal 2102 as shown in FIG.
(Step S2207, FIG. 12)
Step S2104).

Thus, the layer 3 flow information and
The correspondence with the layer 2 identifier is written into the layer 3 flow register of the receiving terminal 2102, so that the receiving terminal 2102 will change the channel number “#x” of the asynchronous stream from the IP address addressed to the IP multicast address “IPm” in the future. It can be recognized that it has been allocated for multicast. The receiving terminal 2102 may receive the asynchronous stream of the channel number “#x” for the datagram addressed to the IP multicast address “IPm” (Step S2105).

In the above embodiment, the receiving terminal 210
In the layer 3 flow register of No. 2, information on whether an IP flow flowing from an asynchronous stream or a synchronous channel indicated by the channel number is input or output is written. 3
It is also possible to prepare a flow register separately for input and output, and use these appropriately.

Returning to the description of FIG.
03 followed by the same IP multicast address "IP
m ". The IGMP joining procedure is performed by the IGMP router 2101 and the receiving terminal 210.
3 (S2106).

Then, the IGMP router 2101 executes a processing operation as shown in the flowchart of FIG. That is, since the IGMP router 2101 has already started the service for the IP multicast address “IPm”, the IGMP router 2101 increments the connection counter of its own layer 3 flow register (for example, the value of the connection counter is set to “2”). ) Then, the same information as that of the register of the receiving terminal 2102 is written to the layer 3 flow register of the receiving terminal 2103, and the correspondence between the channel number and the IP flow is notified.

The IP multicast address "IP
The number of terminals subscribed to “m” is the IGMP router 2101
Since each terminal does not necessarily need to know, the value of the connection counter written in the same register of each of the receiving terminals 2102 and 2103 is, for example, “1”.
But it is good.

The above has described the procedure for joining the IP multicast address. Next, the operation of the IGMP router 2101 at the time of withdrawal will be described with reference to the flowchart shown in FIG.

In the case of withdrawal, the IGPM router 2101
When a withdrawal procedure to the IP multicast address “IPm” is received from any of the receiving terminals (step S
2301) or IP from any of the receiving terminals
IGMP REPORT which is a keep-alive signal indicating that the multicast address “IPm” is being continuously received.
Is not received for a predetermined time or more (step S230)
2) The receiving terminal determines that the receiving terminal stops receiving the IP multicast address “IPm”, and decrements the value of the connection count of its own layer 3 flow register (step S2303).

The connection count value written in the layer 3 flow register of the IGMP router 2101 is
Since this is the number of terminals that have subscribed to the IP multicast address “IPm” on the IEEE 1394 bus, this value becomes “0” (step S230).
4), it is determined that the terminal receiving the IP multicast address "IPm" on the IEEE 1394 bus is no longer present, and withdraws from the IP multicast address "IPm" (step S2305).

Around this, in order to inform the receiving terminal that has withdrawn that it has withdrawn, an operation such as writing an all “0” value to the layer 3 flow register of the receiving terminal may be performed.

Even when a bus reset is caused on the IEEE 1394 bus in the process of joining the IP multicast address or in a series of processes after the joining, the information on these IP multicast addresses is kept stored in the register (layer 3 flow). By holding the value of the register (register), it is possible to quickly recover the reception of the IP multicast datagram.

As described above, all packets addressed to the IP multicast address “IPm” are transmitted and received through the asynchronous stream represented by the channel number “#x”. For a control packet such as IGMP, an asynchronous stream corresponding to the multicast address may be used, or a default asynchronous stream (ARP (Address Res
This may be communicated using an asynchronous stream channel or an asynchronous broadcast allocated for the purpose of, for example, an operation protocol or an IP broadcast.

In addition, when the IP multicast
P control packet or IP address = “224.0.
The default asynchronous stream or asynchronous write broadcast is used as a channel through which all hosts such as "0.1" flow IP packets and the like of the destination address.

(2-2) Next, a case where the IP multicast is changed to a state of “with band (QOS)”, that is, a case where a band is given to an asynchronous stream and this is transmitted / received is a sequence diagram of FIG. This will be described with reference to FIG.

Until receiving terminal 2102 can receive a datagram addressed to IP multicast address "IPm" (steps S2501 to S250)
4) corresponds to steps S2101 to S21 in FIG.
Same as 05.

When transmission with a band is possible for this IP multicast, the IGMP router 2101
Is RSVP (Resource Reserve)
on SETUP message) on the receiving terminal (IP multicast address "IP
m ”) (step S2505).

On the other hand, the receiving terminal 2102 that wants to receive the IP multicast in the “with band” state,
For the upstream side (ie, IGMP router 2101), RS
A VP RESV message is sent, and a request for bandwidth reservation is made (step S2506).

In RSVP, which is an example of a bandwidth reservation protocol on IP, a transmitting host (upstream node) is a PAT.
Send H message with data. The transmission host basically sets the communication band and the like. On the other hand, the receiving terminal desiring the bandwidth reservation transmits the RESV message to the transmitting node. Generally, the router monitors the RESV message corresponding to the PATH message,
When an ESV message is detected, a band reservation is executed. Here, it is assumed that the correspondence between the IP multicast address and the channel described above has been set.

Upon detecting the RESV message from the receiving terminal 2102, the IGMP router 2101 accesses the synchronous resource manager 2104 to secure a band. If the band can be secured, the receiver and the receiving terminal 2101
The secured bandwidth information (bandwidth amount y) is written in the layer 3 flow register of the above (step S2507 to step S2508).

Thereafter, datagram delivery to the IP multicast address “IPm” is continuously performed using the synchronous channel (channel number “#x”) in which the band is secured (step S2509).

When there are a plurality of receiving terminals at this time, the IGMP router 2101 may rewrite the band portion of the layer 3 flow register of each receiving terminal. Also, the rewriting of the same register of each receiving terminal
When the number of receiving terminals is large, it becomes troublesome work.
A method that reflects only the value of the layer 3 flow register of the P router 2101) may be considered.

As described above, when bandwidth is given to an asynchronous stream, a plurality of receiving terminals can simultaneously transmit to the same channel by following the rule that the node transmitting the QOS packet secures the bandwidth. It is possible to avoid so-called double securing of the bandwidth, which would secure the bandwidth. In addition, it is considered that the transmitting node normally knows the value of the normally required band, and thus it is appropriate from this viewpoint.

(2-3) Heretofore, the correspondence between the IP multicast flow and the channel number of the synchronous channel or the asynchronous stream through which the IP multicast flow flows is notified using the layer 3 flow register.
ANP (Flow AttributeNotify)
It is also possible to carry out by using an application protocol. FANP uses IP datagrams to transmit data link layer channels (for example, IEEE13
94 synchronous channels or asynchronous streams or AT
This is a protocol for notifying the correspondence between an M or a virtual channel of a frame relay, etc.) and an upper layer flow (for example, an IP flow) passing through the channel.

The procedure in this case will be described with reference to the sequence diagram shown in FIG. When the receiving terminal 2102 desires to join the IP multicast address “IPm”, the joining procedure using IGMP is performed by the IGMP router 2
The process is performed between the control unit 101 and the server 101 as in the case of FIG. 12 (step S2601). The IGMP router 2101 uses this I
In order to secure a channel for the P multicast address “IPm”, access is made to the synchronous resource manager 2104 to secure a channel number “#x” (step S2602).

Next, the IGMP router 2101 sends a message to the receiving terminal 2102 through “channel“ #x ”.
In order to notify that "P multicast" IPm "is provided", a plug control register of IEEE 1394 and FANP are used.

The plug control register is a register provided by using a certain channel number and acting to receive or transmit a synchronous channel / asynchronous stream, and is separately used for input and output.
Using this plug control register, the IGMP router 2101 urges the receiving terminal 2102 to receive the channel "#x" (step SS60).
3). At this time, the IGMP router 2101 may also fill in its own plug control register. In this case, the number of receiving terminals of the IP multicast address may be entered in the connection counter according to the same rule as in the previous example. As a result, it is possible to grasp the number of nodes receiving the multicast from the channel.

Next, the IGMP router 2101 is connected to the FAN
A message as shown in FIG. 18 is sent to the receiving terminal 2102 as a P offer message. The destination of the FANP message is the IP multicast address “IPm”, and the FANP message is the IEEE139
Layer 3 packet broadcast channel assigned to the 4 bus (for example, a specific asynchronous stream,
(Node ID = packet addressed to all “1”).

As shown in FIG. 18, the FANP offer message includes a flow identifier and a layer 2 identifier. The layer 2 identifier (in the present embodiment, the channel number “#x”) and the The corresponding relationship with the upper layer flow (in this embodiment, the IP multicast address “IPm”) provided through the channel represented by the layer 2 identifier is notified (S2604).

Thereafter, through this channel “#x”,
A datagram addressed to the IP multicast address "IPm" is transmitted (step S2605).

Similarly, when there is a subscription request from another receiving terminal 2102 (step S2606), writing to the plug control register and (step S260)
7), sending a FANP message (step S260)
By performing 8), the correspondence can be notified.

In this case, the FANP message is
Since the address is addressed to the IP multicast address, it is not always necessary to send the FANP message to each of the receiving terminals even if there are a plurality of receiving terminals, and the datagram addressed to the IP multicast address "IPm" is sent once. Since transmission may be performed, it is advantageous in that traffic on the IEEE 1394 bus can be reduced.

In this embodiment, the correspondence between the layer 2 identifier and the layer 3 flow is notified using the plug control register and the FANP offer message. Here, the notification of the correspondence cannot be made unless the FANP message is used. However, the writing of the plug control register causes the receiving terminal to receive data from the synchronization channel. If not necessary, the sending of the FANP message may be omitted. Conversely, FANP
If there is a message, the receiving terminal can recognize which channel number is input which layer 3 flow, so that the procedure for writing to the plug control register can be omitted.

(2-4) Next, a procedure when a plurality of flows are transmitted using the same IP multicast address will be described with reference to a sequence diagram shown in FIG.

In FIG. 19, when a multicast packet whose IP multicast address is “IPm” is transmitted from the IGMP router 2101 to the receiving terminal 2101, a flow in which the port number is represented by “PORT1” (step S2804) This shows a case where a total of two flows of the flow represented by "PORT2" (step S2805) are transmitted at the same time.

Joining to a multicast address by IGMP (step S2801), IGMP router 210
1 to secure a synchronization channel number (step S280)
2) is the same as described above.

When writing in the layer 3 flow register in step S2803, in particular, in step S28
The flow transmitted to the asynchronous stream represented by the synchronous channel number “#x” secured in 02 is not particularly limited,
Since only the transmission of the packet of the IP multicast address “IPm” is limited, step S
Both flows of 2804 and step S2805 are transferred in an asynchronous stream represented by a channel number “#x”.

Now, of these, the IGMP router 2101
Is the QO for the flow represented by "PORT1".
It is assumed that transmission with S is permitted. Therefore, I
The GMP router 2101 transmits an RSVP PATH message to the IP multicast address “IPm” (Step S2806). On the other hand, the receiving terminal 2
101 transmits a RESV message to request the reservation of the bandwidth (S807). Then, the IGMP router accesses the synchronous resource manager and secures a necessary band specified by the RSVP message. Here, this value is set to “y” (step S2808).

Then, the IGMP router 2101 notifies the receiving terminal 2102 that the data of the bandwidth amount “y” is transmitted at the synchronization channel arbitration cycle through the synchronization channel number “#x” to the receiving terminal 2102.
Is written to the layer 3 flow register of the receiving terminal 2102 (step S2809). Step S
In 2809, the content to be notified to the receiving terminal 2102 is not limited to the case where the layer 3 flow register is used, but can also be notified using the above-described FANP or the IEC1883 plug control register. Which one to use depends on the system.

After that, I from the IGMP router 2101
The transmission of the P multicast data is transmitted through an asynchronous stream as in the flow in step S2805 for the flow indicated by “PORT2” for which the bandwidth has not been secured (step S2811). "
It is transmitted as a synchronization channel (that is, during a synchronization arbitration period) (step S2810).

Now, in the IGMP router 2101,
IP multicast data with a bandwidth equal to or greater than the bandwidth amount "y" secured by the synchronization channel "#x" (IP addressed to "IPm")
Multicast packets). Flowing these packets as they are into the synchronization channel “#x” means that the IP multicast packets consume communication resources, even for the unsecured bandwidth, which is not desirable.

Therefore, using an algorithm as shown in FIG. 20, the bandwidth is reserved for the synchronous channel (steps S2901 and S2902), and the bandwidth is reserved for the asynchronous stream (steps S2901 and S2901). S2903) By creating rules for transmitting each data, it is possible to prevent data with a bandwidth amount larger than the secured one from flowing into the synchronization channel.

Here, the T specification is a traffic parameter specified at the time of RSVP reservation, and a peak rate, a bucket depth of a leaky bucket, and the like may be specified.

FIG. 21 shows a configuration example for realizing the mechanism of FIG. WFQ stands for Weighted F
An abbreviation for air queuing, when one output port is shared by packets from a plurality of senders / flows, the amount (weight) designated in advance for each flow
Is a packet scheduling method in which the ratio of the amount of packets to be transmitted is the same according to the ratio.

In the WFQ scheduling, the WFQ processing section 2201 puts, into the synchronous queue 2202, those that satisfy the T specifications, and puts those that do not satisfy the T specifications into the asynchronous queue 2203. The data stored in the asynchronous queue during the synchronous arbitration period via the packet transmission unit 2204 is transmitted via the packet transmission unit 2204 during the asynchronous arbitration period.

[0160] The above description has been given of how to use the same value of the synchronization channel number continuously even when the band is secured. On the other hand, for a channel that needs to secure a band, a method of securing a synchronous channel (“#z”) different from the channel (“#x”) used for the asynchronous stream is also conceivable.

The procedure in this case will be described with reference to the sequence diagram of FIG.

Step S3101 to Step S3 in FIG.
Steps S2801 to S2807 in FIG. 19 are the same until a request for bandwidth reservation (RESV) is received from the receiving terminal 2101 in the RSVP RESV message in 3107.

When the IGMP router 2101 receives the bandwidth reservation request in step S3107, the IGMP router 2101 uses the channel number (“#x”) of the asynchronous stream used so far.
Different from the above, both the synchronization channel number (“#z”) and the bandwidth amount (y) are secured (steps S3108 and S3109).

In this case as well, the rule "the sender (that is, the IGMP router 2101 in the present embodiment) secures a necessary band of the link layer" is used.
After that, the IGMP router 2101
By writing into the layer 3 flow register that the flow represented by “PORT1” is transmitted using the synchronous channel (not the asynchronous stream) represented by the synchronous channel number “#z”, Receiving terminal 210
2 is notified (step S3110). Note that the content notified to the receiving terminal 2102 in step S3111 is not limited to the case where the layer 3 flow register is used, but can also be performed using the plug control register of IEC1883 or FANP as described above.

Thereafter, the IP multicast address “IP
Among the packets addressed to “m”, the flow represented by “PORT1” is transferred by the synchronous channel via the synchronous channel “#z” (step S3111), and the other flows are continuously transmitted by the asynchronous stream. (Step S3112).

(2-5) Next, a case where there are a plurality of senders of multicast data using an asynchronous stream or a synchronous channel indicated by one channel number will be described with reference to FIG. Here,
After joining the IP multicast, the terminals 2102 and 2103 in FIG. 11 become multicast data transmitting / receiving terminals, and the terminals 2102 and 2103 are hereinafter referred to as terminals A and B.

FIG. 23 shows a case where terminal A (IP address “IPm”) receives the same IP multicast address “IPm”.
1 ", 1394 address" FW1 ") and terminal B (IP
2 shows a case where two terminals having addresses “IP2” and 1394 address “FW2” transmit IP multicast packets. Here, the 1394 address is, for example, a node ID of the IEEE 1394 or the like.
I which can uniquely identify the terminal on the 94 bus
Point to D.

Steps S3201 to S320 in FIG.
304, the procedures for joining the multicast, securing the channel number, and notifying the correspondence between the IP multicast address and the channel number in steps S3206 to S33208 are the same as those in FIG.

The characteristic point is that each of the terminals A and B is
The same channel number “#” is assigned to the IP multicast packet.
x ”and adds its own source address (“ FW1 ”or“ FW2 ”) to the channel and transmits the packet (steps S3205, S3209, S3).
210).

This source address is written in a header called a fragment header, which is given to each divided piece when an IP packet is divided into 1394 frames.

IP sent from each of terminals A and B
FIG. 24 shows an outline of the multicast data configuration. FIG. 24A shows the data structure of the IP multicast sent from the terminal A, and FIG. 24B shows the data structure of the IP multicast sent from the terminal B. FIG.
As shown in (a) and (b), an IP multicast packet (or a fragment thereof) 330
Fragment data 33 generated by encapsulating 1, 3304 with a fragment header including a source address
02, 3305 are further contained in a 1394 frame 1303 (in this case, a synchronization frame).

The receiver receives packets from a plurality of senders from the asynchronous stream indicated by the same channel number. In this way, the source address is assigned to each frame, so that each Reassembly of a packet can be performed accurately by referring to the source address.

The above is the description of the case where a plurality of senders transmit to the same IP multicast address without securing the bandwidth. On the other hand, a description will be given below of a case in which a band is secured.

In FIG. 25, for example, in S32 of FIG.
01 to S3210 are completed, and the IP addresses addressed to the same IP multicast address “IPm” from the two senders, that is, the terminal A and the terminal B in the form of an asynchronous stream.
It is assumed that a multicast packet has been transmitted (step S3401, step S3402).

Here, when terminal A is requested to transmit IP multicast data in some form with a band (for example, when RSVP RESV is received).
Alternatively, if the user himself or herself selects data transmission in a form with a band, the synchronous resource manager 2104 is accessed to make a request for securing the band amount (y1) (step S340)
3) Thereafter, the terminal A transmits the IP multicast packet to be transmitted through the synchronous channel of the reserved bandwidth amount y1 and during the synchronous arbitration period (step S3404). Here, although the terminal B that has not secured the band continues to transmit the IP multicast packet on the same channel number “#x”, the transmission is performed as an asynchronous stream during the asynchronous arbitration period (step S3405).

When the terminal B transmits with a band,
The terminal B also accesses the synchronous resource manager 2104 to secure a desired band (step S340).
6), data transmission is performed within the synchronous arbitration period (step S3408).

When canceling the previously secured band, the synchronous resource manager 2104 is requested to cancel the band (step S340).
9) Do not send packets during the synchronous arbitration period, and if there is a packet to send,
Asynchronous stream (asynchronous arbitration period)
(Step S3410).

On the other hand, when transmitting an IP multicast with a band, a synchronous channel having a channel number “#z” different from the channel number “#x” used in the asynchronous stream is used. , And a method of transmitting this. This case will be described with reference to the sequence diagram of FIG.

In FIG. 26, for example, in S32 of FIG.
01 to S3210 are completed, and the IP addresses addressed to the same IP multicast address “IPm” from the two senders, that is, the terminal A and the terminal B in the form of an asynchronous stream.
It is assumed that a multicast packet has been transmitted (step S3501, step S3502).

At this time, transmission of an IP multicast packet with a band is requested by, for example, an RSVP RESV message (for example, as shown in FIG. 26, an RSVP PATH message from terminal A is transmitted). (When receiving the RESV message from the terminal B in response to the request), the terminal A accesses the synchronous resource manager 2104 to secure the synchronous channel number “#z” and secure the bandwidth amount “y1” (steps S3503 to S3503). Step S3506).

Subsequently, a FANP message for notifying the correspondence between the secured synchronization channel number and the flow transmitted through the synchronization channel is transmitted to the IP multicast address “IPm”, for example, by the asynchronous stream “#x”, Alternatively, the data is transmitted using a default asynchronous stream or the like (step S3507). The node receiving this can recognize which flow is input from which synchronization channel with what characteristics. Note that, as described above, here, FANP
This correspondence is notified using a message, which is transmitted by the layer 3 flow register or IEC1.
This can be realized even by using the plug control register used in 883.

[0182]

As described above, the first invention (first embodiment)
According to the embodiment, a method for operating a network layer signaling protocol such as RSVP on IEEE 1394 has not yet been determined, and if mapping is performed as it is, communication quality is not secured on IEEE 1394, and end-to-end communication is not performed. The method of applying RSVP on the IEEE 1394 bus for the problem that the quality cannot be maintained will be described, and communication with communication quality in an interconnected environment can be performed on IEEE 1394.

Further, according to the second invention (second embodiment), in a broadcast network such as IEEE 1394, IP multicast can be performed by effectively using communication resources. The correspondence with the IP multicast address can be synchronously recognized on the transmission side and the reception side.

[Brief description of the drawings]

FIG. 1 shows a configuration example of an entire network according to a first embodiment of the present invention, in which data from a video server providing a video service is taken into a home network via a public network, FIG. 4 is a diagram for explaining a situation in which a terminal connected to a home network receives the service.

FIG. 2 is a diagram showing an entire processing procedure until the terminal of FIG. 1 has a video transferred from a video server through a connection device and a public network, and a communication resource reservation on IEEE1394 is performed by a node upstream of RSVP; Shows the case.

FIG. 3 is an exemplary view showing a processing procedure of the terminal until the terminal of FIG. 1 has a video transferred from a video server through a connection device and a public network;

FIG. 4 is an exemplary view showing a processing procedure of the connection device until the terminal of FIG. 1 has the connection device and the video server transfer the video through the public network;

FIG. 5 is a diagram showing an example of a correspondence table stored in a connection device.

FIG. 6 is a diagram showing an example of the format of an RSVP PATH message.

FIG. 7 is a diagram showing a description example of an IEEE 1394 PCR register.

8 is a diagram showing a processing procedure of the entire communication system until the terminal of FIG. 1 receives a video transfer from a video server through a connection device and a public network, and reserves a communication resource on IEEE 1394 with a downstream node of RSVP. Shows the case of performing.

FIG. 9 leaves an already joined IP multicast address, joins a different IP multicast address,
The figure for demonstrating the case where different contents are delivered.

FIG. 10 is a diagram for explaining a case where the content is changed while the IP multicast address is the same.

FIG. 11 is a diagram showing a configuration example of an entire network (IEEE 1394 bus) according to a second embodiment of the present invention.

FIG. 12 is a sequence diagram illustrating a procedure when a receiving terminal joins an IP multicast.

FIG. 13 is a flowchart for explaining a processing procedure when the IGMP router joins an IP multicast address.

FIG. 14 is a diagram showing an example of a format of a layer 3 flow register.

FIG. 15 is a flowchart for explaining a processing procedure when the IGMP router withdraws from the IP multicast address.

FIG. 16 is a sequence diagram for explaining a procedure when a band is given to an asynchronous stream secured for IP multicast.

FIG. 17 is a sequence diagram for explaining a procedure when a correspondence between an IP multicast flow and a channel number is performed using FANP.

FIG. 18 is a diagram showing an example of a FANP offer message.

FIG. 19: Using the same IP multicast address,
FIG. 9 is a sequence diagram for explaining a procedure when a plurality of flows are transmitted.

FIG. 20 is a diagram illustrating an IGM in the case of transmitting IP multicast data having a bandwidth equal to or greater than a bandwidth amount previously secured in a synchronization channel.
5 is a flowchart for explaining a processing operation of a P router.

FIG. 21 is a diagram showing a configuration example for realizing the algorithm of FIG. 20;

FIG. 22 is a sequence diagram for explaining a procedure in a case where a bandwidth is assigned to an asynchronous stream secured for IP multicast and a channel number different from that of the asynchronous stream is used for a synchronous channel given the bandwidth. .

FIG. 23 is a sequence diagram for explaining a procedure when there are a plurality of senders for the same IP multicast address.

FIG. 24 is a diagram schematically showing a data configuration of IP multicast transmitted from each of terminals A and B.

FIG. 25 is a sequence diagram for explaining a procedure in a case where a plurality of senders transmit to the same IP multicast address and a band is further secured.

FIG. 26 is a sequence diagram for explaining a procedure in a case where a plurality of senders transmit to the same IP multicast address and a channel number different from that of an asynchronous stream is used when further securing a band.

[Explanation of symbols]

101 video server (communication device, transmission terminal) 102 connection device (communication control device) 103 terminal (communication device) 104 public network 105 first home network (IEEE 139)
4) 106: Second home network 2101: IGMP router (communication device) 2102: Terminal device (receiving terminal, communication device) 2103: Terminal device (receiving terminal, communication device) 2104: Synchronous resource manager

Claims (15)

[Claims] 1. A communication device connected to a broadcast type network, comprising: a second communication device connected to the network, an identifier for identifying a network layer multicast data flow; Receiving means for receiving a first message including a corresponding bandwidth reservation request; establishing means for establishing a broadcast channel on the network based on the first message received by the receiving means; A communication unit for transmitting a second message including a correspondence between an identifier of a broadcast type channel and an identifier of the network layer multicast data flow to the second communication device. 2. A communication device connected to a broadcast-type network, comprising: an establishment unit for establishing a broadcast-type channel having a guaranteed bandwidth required for transmitting and receiving a network layer multicast data flow; Transmitting means for transmitting a message including a correspondence between the identifier of the broadcast type channel and the identifier of the network layer multicast data flow. 3. The communication device according to claim 1, wherein the first and / or second messages are messages of a request protocol for securing communication resources when transmitting and receiving data on the Internet. 4. The communication device according to claim 2, wherein the message is a message of a request protocol for securing communication resources when transmitting and receiving data on the Internet. 5. A communication device connected to a broadcast-type network, comprising: a broadcast-type channel identifier whose bandwidth required for transmitting and receiving a network layer multicast data flow established on said network is guaranteed; A communication device, comprising: a register that describes a correspondence relationship with an identifier of a network layer multicast data flow. 6. The broadcast type network is an IEEE 1
The communication device according to claim 1, wherein the communication device is a 394 bus. 7. A communication device connected to a broadcast-type network, comprising: a receiving unit that receives an application to join a network layer multicast address from a second communication device that is connected to the network; Establishing means for establishing a broadcast-type channel on the network in response thereto, notifying means for notifying the second communication device of a correspondence relationship between at least the identifier of the established broadcast-type channel and the network layer multicast address, A transmission unit for transmitting data addressed to the network layer multicast address to the established broadcast-type channel. 8. A second receiving unit for receiving, from the second communication device, a request for securing a band necessary for receiving data destined for the network layer multicast from the second communication device; The communication device according to claim 7, further comprising: a securing unit that secures a band of the broadcast-type channel. 9. A communication device connected to a broadcast type network for transmitting data addressed to a network layer multicast address, comprising: a securing unit for securing a communication band for a broadcast type channel established on the network; And transmitting means for transmitting data addressed to the network layer multicast address at a cycle or connection in which the bandwidth of the broadcast-type channel is secured, when a bandwidth is secured in the broadcast-type channel by the securing means. A communication device characterized by the above-mentioned. 10. A communication device connected to a broadcast type network for transmitting data addressed to a network layer multicast address, comprising: a securing unit for securing a communication band for a broadcast type channel established on the network; And transmitting means for transmitting data addressed to the network layer multicast address at a cycle or connection in which the bandwidth of the broadcast-type channel is not secured, when a bandwidth is not secured in the broadcast-type channel by the securing means. A communication device characterized by the above-mentioned. 11. A communication device connected to a broadcast type network for transmitting data addressed to a network layer multicast address, comprising: a securing unit for securing a communication band for a broadcast type channel established on the network; A first transmission unit that transmits data addressed to the network layer multicast address at a cycle or connection in which the bandwidth of the broadcast channel is secured, when a bandwidth is secured in the broadcast channel by the securing unit; A second transmission unit that transmits data addressed to the network layer multicast address at a period or connection in which the bandwidth of the broadcast channel is not secured when the bandwidth is not secured in the broadcast channel. Characteristic communication device. 12. The broadcast channel identifier when the band is secured by the securing means is the same identifier as the broadcast channel when the band is not secured. The communication device as described. 13. A first message including an identifier for identifying a network layer multicast data flow transmitted from a communication device connected to a broadcast type network and a request for securing a bandwidth corresponding to the network layer multicast data flow is received. When I did this first
Establishing a broadcast type channel on the network based on the message of the above, and transmitting a second message including at least a correspondence relationship between the identifier of the established broadcast type channel and the identifier of the network layer multicast data flow to the communication device. A communication method, comprising: 14. A broadcast-type channel is established on the network in response to an application to join a network-layer multicast address from a communication device connected to the broadcast-type network, and at least an identifier of the established broadcast-type channel and A communication method, comprising: after notifying the communication device of a correspondence relationship with the network layer multicast address, transmitting data addressed to the network layer multicast address to the established broadcast type channel. 15. A communication method for connecting to a broadcast network and transmitting data addressed to a network layer multicast address, wherein when a communication band is secured for a broadcast channel established on the network, Data addressed to a network layer multicast address is transmitted at a cycle or connection in which the bandwidth of the broadcast channel is secured, and when bandwidth is not secured in the broadcast channel, the data addressed to the network layer multicast address is broadcasted. A communication method characterized in that transmission is performed in a cycle or connection in which a bandwidth of a type channel is not secured.