WO2000065781A1 - Method of and apparatus for implementing and sending an asynchronous control mechanism packet - Google Patents

Method of and apparatus for implementing and sending an asynchronous control mechanism packet Download PDF

Info

Publication number
WO2000065781A1
WO2000065781A1 PCT/US2000/010844 US0010844W WO0065781A1 WO 2000065781 A1 WO2000065781 A1 WO 2000065781A1 US 0010844 W US0010844 W US 0010844W WO 0065781 A1 WO0065781 A1 WO 0065781A1
Authority
WO
WIPO (PCT)
Prior art keywords
control mechanism
mechanism packet
asynchronous control
designation
bridge
Prior art date
Application number
PCT/US2000/010844
Other languages
French (fr)
Inventor
Richard K. Scheel
David V. James
Original Assignee
Sony Electronics Inc.
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 Sony Electronics Inc. filed Critical Sony Electronics Inc.
Priority to AU44820/00A priority Critical patent/AU4482000A/en
Publication of WO2000065781A1 publication Critical patent/WO2000065781A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40058Isochronous transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40091Bus bridging
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone

Definitions

  • the present invention relates to the field of sending control communications to devices within a network. More particularly, the present invention relates to the field of sending control communications to bridges within a network for effecting control and allocating resources along a communications route.
  • Isochronous data transfers are real-time transfers which take place based on the universal clock such that the time intervals between significant instances have the same duration at both the transmitting and receiving applications.
  • Each packet of data transferred isochronously is transferred in its own time period.
  • An example of an ideal application for the transfer of data isochronously would be from a video recorder to a television set. The video recorder records images and sounds and saves the data in discrete chunks or packets.
  • the video recorder then transfers each packet, representing the image and sound recorded over a limited time period, during that time period, for display by the television set.
  • the IEEE Std 1394-1995 standard bus architecture provides multiple independent channels for isochronous data transfer between applications. A six bit channel number is broadcast with the data to ensure reception by the appropriate application. This allows multiple applications to simultaneously transmit isochronous data across the bus structure.
  • Asynchronous transfers are traditional reliable data transfer operations which take place as soon as arbitration is won and transfer a maximum amount of data from a source to a destination. Asynchronous transfers are used for control purposes, including the setup of isochronous communications.
  • the IEEE Std 1394-1995 standard provides a high-speed serial bus for interconnecting digital devices thereby providing a universal I/O connection.
  • the IEEE Std 1394-1995 standard provides a high-speed serial bus for interconnecting digital devices thereby providing a universal I/O connection.
  • Std 1394-1995 standard defines a digital interface for the application thereby eliminating the need for an application to convert digital data to analog data before it is transmitted across the bus.
  • a receiving application will receive digital data from the bus, not analog data, and will therefore not be required to convert analog data to digital data.
  • the cable required by the IEEE Std 1394-1995 standard is very thin in size compared to other bulkier cables used to connect such devices in other connection schemes.
  • Devices can be added and removed from an IEEE Std 1394-1995 bus while the bus is operational. If a device is so added or removed the bus will then automatically reconfigure itself for transmitting data between the then existing nodes.
  • a node is considered a logical entity with a unique address on the bus structure. Each node provides in a standard address space, an identification ROM, a standardized set of control registers and in addition, its own address space.
  • the IEEE Std 1394-1995 standard defines a protocol as illustrated in Figure 1.
  • This protocol includes a serial bus management block 10 coupled to a transaction layer 12, a link layer 14 and a physical layer 16.
  • the physical layer 16 provides the electrical and mechanical connection between a device or application and the IEEE Std 1394-1995 cable.
  • the physical layer 16 also provides arbitration to ensure that all devices coupled to the IEEE Std 1394-1995 bus have access to the bus as well as actual data transmission and reception.
  • the link layer 14 provides data packet delivery service for both asynchronous and isochronous data packet transport. This supports both asynchronous data transport, using an acknowledgement protocol, and isochronous data transport, providing real-time guaranteed bandwidth protocol for just-in-time data delivery.
  • the transaction layer 12 supports the commands necessary to complete asynchronous data transfers, including read, write and lock.
  • the serial bus management block 10 contains an isochronous resource manager for managing isochronous data transfers.
  • the serial bus management block 10 also provides overall configuration control of the serial bus in the form of optimizing arbitration timing, guarantee of adequate electrical power for all devices on the bus, assignment of the cycle master, assignment of isochronous channel and bandwidth resources and basic notification of errors.
  • IEC-61883 is a ratified international standard for the transport of audio/video command requests and responses. This standard uses the concept of plugs and plug control registers to manage and control the attributes of isochronous data flows. It should be noted that plugs do not physically exist on an audio/video device, but a plug is used to establish an analogy with existing audio/video devices where each flow of information is routed through a physical plug.
  • An isochronous data flow flows from one transmitting device to one or more receiving devices, by transmitting isochronous packets on an isochronous channel of the
  • Each isochronous data flow is transmitted to an isochronous channel through one output plug on the transmitting device and is received from that isochronous channel through one input plug on the receiving device.
  • the transmission of an isochronous data flow through an output plug is controlled by an output plug control register (oPCR) and an output master plug register (oMPR) located on the transmitting device.
  • the output master plug register controls all attributes that are common to all isochronous data flows transmitted by the corresponding transmitting device.
  • the output plug control register controls all attributes of the corresponding isochronous data flow that are independent from attributes of other isochronous data flows transmitted by the tr.ansmitting device.
  • the reception of an isochronous data flow through an input plug is controlled by an input plug control register (iPCR) and an input master plug register (iMPR) located on the receiving device.
  • the input master plug register controls all attributes that are common to all isochronous data flows received by the receiving device.
  • the input plug control register controls all attributes of the corresponding isochronous data flow that are independent from attributes of other isochronous data flows received by the receiving device.
  • An isochronous data flow can be controlled by any device connected to the IEEE Std 1394-1995 bus by modifying the corresponding plug control registers.
  • Plug control registers can be modified through asynchronous transactions on the IEEE Std 1394-1995 bus or by internal modifications if the plug control registers are located on the controlling device.
  • a point-to-point connection can only be broken by the application or initiating device that established it.
  • An application can also just start the transmission or reception of an isochronous data flow on its own device by connecting one of its output or input plugs respectively to an isochronous channel.
  • the relationship between one output plug and one isochronous channel is called a broadcast-out connection.
  • the relationship between one input plug and one isochronous channel is called a broadcast- in connection. Broadcast-out and broadcast-in connections are collectively called broadcast connections.
  • a broadcast connection can be established only by the device on which the plug is located, but it can be broken by any device.
  • the IEEE working group "pi 394.1 Draft standard for High Performance Serial Bus Bridges" is a working group draft related to the IEEE Std 1394-1995 standard for implementing bus bridges between multiple IEEE Std 1394-1995 buses. Bridges within a net of multiple buses of devices forward request and response subactions from one bus to another, allowing transaction requester and responder components to be located on different buses.
  • the first bus includes the devices al, a2, and a3 coupled together by IEEE
  • the device al is coupled to the device a2 by the IEEE Std 1394-1995 cable 40.
  • the device a2 is coupled to the device a3 by the IEEE Std 1394- 1995 cable 42.
  • the device a3 is then coupled to a first portal 22 of the bridge 20.
  • the bridge 20 couples the first bus to a second bus which includes the devices bl, b2 and b3.
  • a second portal 24 of the bridge 20 is coupled to the device bl by the IEEE
  • the device bl is coupled to the device b2 by the IEEE Std 1394- 1995 cable 48.
  • the device bl is coupled to the device b2 by the IEEE Std 1394-1995 cable 48.
  • the device b2 is coupled to the device b3 by the IEEE Std 1394-1995 cable 50.
  • the device b3 is coupled to a first portal 32 of the bridge 30.
  • the bridge 30 couples the second bus to a third bus which includes the devices cl and c2.
  • a second portal 34 of the bridge 30 is coupled to the device cl by the IEEE Std 1394-1995 cable 54.
  • the device cl is coupled to the device c2 by the IEEE Std 1394-1995 cable 56.
  • the bridges 20 and 30 allow devices on the different buses to communicate with each other using both asynchronous and isochronous communications. For example, if the device al sends a communication to the device b3, the communication is passed along the first bus until it reaches the portal 22 of the bridge 20. The bridge 20 then recognizes that the communication is addressed to the device b3 and forwards the communication from the portal 22 to the portal 24. The communication is then passed along the second bus until it arrives at the device b3.
  • the components within a bridge device are illustrated in Figure 3.
  • the bridge device 60 includes asynchronous request and response queues and isochronous data and isochronous queues for each portal.
  • the bridge 60 also includes a microprocessor device
  • the queues within the bridge 60 hold packets received on one bus but not yet transmitted to the adjacent bus.
  • the asynchronous request queue 62 holds request and asynchronous-stream packets.
  • the asynchronous response queue 64 holds response packets.
  • Isochronous packets received in cycle (n) are forwarded to the adjacent bus in cycle
  • the isochronous data queue 66 holds isochronous packets which are selectively forwarded based on their channel number.
  • the isochronous clock queue 68 holds the clock synchronization reference information which is forwarded from the primary bus outward and used to calibrate the clock on each bus.
  • the request response, isochronous data and isochronous clock queues may be implemented as separate physical queues, or independently managed portions of a larger shared memory.
  • the bridge 60 also includes routing tables to determine which packets are forwarded to an adjacent bus. For asynchronous routing, the bridge 60 includes a bit-mapped table which specifies which packets are forwarded to the adjacent bus. For isochronous routing, the bridge 60 includes a table which specifies properties of an isochronous channel including whether the isochronous channel is forwarded to the adjacent bus, the channel number to be used on the adjacent bus and the speed to be used on the adjacent bus.
  • the bridge 60 also includes message mailbox locations to access low-band width facilities including initialization and isochronous management.
  • the initialization protocols are responsible for each buses' assigned net-unique bus ID address and bridge routing which utilizes routing tables set to enable asynchronous subaction routing.
  • the messages within the message mailbox are used to manage isochronous resource allocations.
  • directed-asynchronous routing decisions are made using the destination ID addresses of packets being passed through the bridge 60. Accepted packets are directly routed to the opposing part of the bridge 60.
  • This destination routing is based on a bus ID routing table. In the most general case, one or more routing bits can be independently specified for each of the 1024 possible bus numbers. .
  • An isochronous connection between a talker device and listener device is incrementally formed in the talker-to-listener direction.
  • the portal of the bridge coupled to the talker device, on the routing path is first directed to establish the appropriate talker bus connections by an initiation message sent from a controlling device to this portal.
  • This portal acquires the necessary isochronous resources on the talker device's local bus, sends a query transaction to discover next-path identifiers and sends confirmation to the controlling device which includes the next-path identifiers.
  • the controlling device then sends an initiation message to each bridge within the route between the talker device and the listener device, in turn.
  • Each bridge along the route upon receiving the initiation message from the controlling device then acquires the necessary isochronous resources on the corresponding bus in the route, sends a query transaction to discover next-path identifiers and sends a confirmation to the controlling device which includes the next-path identifiers. This continues until all bridges in the route between the talker device and the listener device have acquired the necessary isochronous resources on each of the buses within the route.
  • the isochronous connection between a talker device and a listener device is established by a controlling device.
  • the controlling device communicates with each bridge within the route between the talker device and the listener device. This consumes significant resources of both the controlling device and each bridge and bus within the route between the talker device and the listener device.
  • An asynchronous control mechanism packet is used to send control messages and information to one or more bridge devices within a network of buses of devices.
  • the asynchronous control mechanism packet is addressed to a device on one of the buses and is intercepted by one of the appropriate bridge devices along the path to the destination device.
  • the asynchronous control mechanism packet is targeted at a particular bridge device or used to send control messages and information to bridge devices along a particular communications route between two devices.
  • the asynchronous control mechanism packet includes a designation specifying that it is an asynchronous control mechanism packet and should be treated accordingly, and an indication of whether the packet should be processed by the first of the last portal between the source and destination buses.
  • This designation is recognized by the appropriate bridge devices. Preferably, this designation is included within the extended transaction code field of the packet. In an alternate embodiment, the designation is included within a transaction code field of the packet. In a further alternate embodiment, the designation is included within an address offset value within the packet. Instructional information within the asynchronous control mechanism packet specifies to intercepting bridge devices the type of transaction and control tasks to be performed by the bridge device when the asynchronous control mechanism packet is received.
  • an asynchronous control mechanism packet includes an address value corresponding to a target device on a target bus, a designation and instructional information, wherein the designation within the asynchronous control mechanism packet causes a bridge device coupled to the target device and the target bus to intercept the packet and utilize the instructional information to perform one or more control tasks specified by the designation and the instructional information.
  • the designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet.
  • the designation is included within a transaction code field within the asynchronous control mechanism packet.
  • designation is included within an address offset value within the asynchronous control mechanism packet.
  • the instructional information specifies a type of transaction and the control tasks to be performed. The asynchronous control mechanism packet is not forwarded to the target device.
  • the designation and instructional information instruct the bridge device to establish an isochronous connection between a talker device and a listener device.
  • Each bridge device within a route between the talker device and the listener device intercept the asynchronous control mechanism packet and allocate resources necessary to establish the isochronous connection between the talker device and the listener device.
  • the talker device and the listener device are preferably coupled within a network of buses that substantially complies with a version of an IEEE Std 1394 standard.
  • a method of effecting control of a bridge device coupled to a target device on a target bus includes the steps of sending an asynchronous control mechanism packet directed to the target device which includes an address value corresponding to the target device, a designation and instructional information, receiving the asynchronous control mechanism packet at the bridge device and utilizing the instructional information to perform one or more control tasks specified by the designation and the instructional information.
  • the asynchronous control mechanism packet is not forwarded to the target device.
  • the designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet.
  • the designation is included within a transaction code field within the asynchronous control mechanism packet.
  • the designation is included within an address offset value within the asynchronous control mechanism packet.
  • the step of utilizing establishes an isochronous connection between a talker device and a listener device.
  • the steps of sending, receiving and utilizing are performed by each bridge device within a route between the talker device and the listener device and further wherein each of the bridge devices within the route allocate resources necessary to establish the isochronous connection between the talker device and the listener device.
  • the talker device and the listener device are preferably coupled within a network of buses that substantially complies with a version of an IEEE Std 1394 standard.
  • a method of establishing an isochronous connection between a talker device and a listener device within a network of buses includes the steps of sending .an asynchronous control mechanism packet from an initiating device directed to a selected one of the talker device and the listener devices.
  • the asynchronous control mechanism packet includes an address value corresponding to the selected one of the talker devices and the listener devices and a designation specifying that the packet is an asynchronous control mechanism packet, and then receiving the asynchronous control mechanism packet at a current bridge device within the route between the talker device and the listener device.
  • the designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet.
  • the designation is included within a transaction code field within the asynchronous control mechanism packet.
  • the designation is included within an address offset value within the asynchronous control mechanism packet.
  • the network of buses preferably substantially complies with a version of an IEEE Std 1394 standard.
  • the designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet.
  • the designation is included within a transaction code field within the asynchronous control mechanism packet. In a further alternative embodiment, the designation is included within an address offset value within the asynchronous control mechanism packet.
  • the one or more control tasks performed by the detecting and control circuit establish an isochronous connection between a talker device and a listener device.
  • the bridge device and the two or more buses preferably substantially comply with a version of an IEEE Std 1394 standard.
  • a network of devices coupled together by two or more buses, wherein bridge devices within the network couple different buses of devices to each other, each of the bridge devices include a first portal interface configured for coupling to and communicating with a first bus of devices, a second portal interface configured for coupling to and communicating with a second bus of devices and a detecting and control circuit coupled to the first portal interface and the second portal interface for detecting when the first portal interface and the second portal interface receive an asynchronous control mechanism packet directed to a target device, wherein the asynchronous control mechanism packet includes an address value corresponding to the target device, a designation and instructional information and further wherein the detecting and control circuit performs one or more control tasks specified by the designation and the instructional information.
  • the designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet.
  • the designation is included within a transaction code field within the asynchronous control mechanism packet.
  • the designation is included within an address offset value within the asynchronous control mechanism packet.
  • Figure 1 illustrates a protocol defined by the IEEE Std 1394 standard.
  • Figure 2 illustrates an exemplary network of three buses of devices.
  • Figure 3 illustrates components within a bridge device.
  • Figure 4 illustrates an exemplary network of IEEE Std 1394-1995 buses and bridge devices.
  • Figure 5 illustrates a format of a block write packet according to the IEEE Std 1394-1995 standard.
  • Figure 6 illustrates an exemplary operation of a network of devices utilizing the asynchronous control mechanism packet of the present invention.
  • Figure 7 illustrates an exemplary operation of a network of devices utilizing the asynchronous control mechanism packet of the present invention.
  • the present invention provides an alternative to the above-discussed method for establishing an isochronous connection between a talker device and a listener device.
  • a new transaction type is herein defined for effective control of bridge devices along an isochronous communications route between a talker device and a listener device.
  • the new transaction type is included within an asynchronous command packet which is addressed to a node on a remote bus. The packet is then routed along the bus towards the addressed node.
  • the bridge intercepts and processes the packet. This processing includes allocating the necessary resources for the isochronous connection. If appropriate, the bridge then forwards the packet on towards the addressed node along the routing path.
  • this asynchronous control mechanism packet is sent from bridge to bridge along the routing path between the talker device and the listener device to establish an isochronous connection and allocate the necessary isochronous resources along the routing path.
  • the asynchronous control mechanism packet of the present invention can also be targeted towards a particular bridge device, by addressing it to a specific device and causing it to be intercepted by the bridge device controlling communications on the destination bus.
  • the asynchronous control mechanism packet of the present invention allows an initiating or controlling device to send a single communication to the addressed node which will cause the bridge devices within the routing path to process the packet and establish the isochronous connection.
  • the controlling device does not need to send separate communications to each bridge within the routing path and establish the route for the isochronous communication.
  • the controlling device can send the asynchronous control mechanism packet without knowing the appropriate route or which bridge devices are included within that route.
  • the controlling device takes advantage of the asynchronous routing tables already established by the bridges within the network. Accordingly, the resources of the controlling device are conserved and are not required to actively participate in the establishment of the isochronous connection at each bridge device within the routing path.
  • the asynchronous control mechanism packet of the present invention is used to establish and teardown an isochronous connection between a talker device and a listener device, as described herein.
  • the asynchronous control mechanism packet of the present invention can also be used for other functions, including other bridge control functions.
  • a bridge device preferably includes the components as illustrated in Figure 3 and discussed above and also has the ability to detect an asynchronous control mechanism packet of the present invention. Accordingly, when the bridge device of the present invention receives an asynchronous control mechanism packet, it will treat it appropriately, including implementing any controls and performing any necessary tasks specified in the asynchronous control mechanism packet.
  • FIG. 4 An exemplary network of IEEE Std 1394-1995 buses and bridge devices is illustrated in Figure 4.
  • the horizontal lines 100, 102, 104, 106, 108, 110, 112, 114, 116, 118 and 120 are used to designate buses of one or more devices.
  • the IEEE Std 1394-1995 bus 100 is coupled to a first portal 124 of a bridge device 122.
  • a second portal 126 of the bridge device 122 is coupled to the IEEE Std 1394-1995 bus 102.
  • the bus 102 is coupled to a first portal 130 of a bridge device 128.
  • a second portal 132 of the bridge device 128 is coupled to the IEEE Std 1394-1995 bus 104.
  • a talker device 182 is coupled as a device within the bus 104.
  • the bus 104 is coupled to a first portal 136 of a bridge device 134.
  • a second portal 138 of the bridge device 134 is coupled to the IEEE Std 1394-1995 bus 106.
  • the bus 106 is coupled to a first portal 144 of a bridge device 140 and a first portal 166 of a bridge device 164.
  • a second portal 142 of the bridge device 140 is coupled to the IEEE Std 1394-1995 bus 108.
  • the bus 108 is also coupled to a first portal 148 of a bridge device 146.
  • the second portal 150 of the bridge device 146 is coupled to the IEEE Std
  • the bus 110 is coupled to a first portal 154 of a bridge device 152 and a first portal 160 of a bridge device 158.
  • a second portal 162 of the bridge device 158 is coupled to the IEEE Std 1394-1995 bus 112.
  • a second portal 156 of the bridge device 152 is coupled to the IEEE Std 1394-1995 bus 114.
  • a controlling device 186 is coupled as a device within the bus 114.
  • a second portal 168 of the bridge device 164 is coupled to the IEEE Std 1394-1995 bus 116.
  • the bus 116 is coupled to a first portal 172 of a bridge device 170 and a first portal 178 of a bridge device 176.
  • a second portal 174 of the bridge device 170 is coupled to the IEEE Std 1394-1995 bus 118.
  • a second portal 180 of a bridge device 176 is coupled to the IEEE Std 1394-1995 bus 120.
  • a listener device 184 is coupled as a device within the bus 120.
  • the asynchronous control mechanism packet of the present invention is preferably an asynchronous block write packet. Alternatively, the asynchronous control mechanism packet of the present invention can be included within any appropriate packet type including read, write and lock.
  • the asynchronous block write packet includes a header and a data payload.
  • the header includes the fields destinationJD, tl, rt, tcode, pri, source_ID, destination_offset, data_length, extended_tcode and header_crc.
  • the destinationJD field is a sixteen bit field which specifies the node ID of the receiving node to which the packet is addressed.
  • the transaction label field tl is a six bit field that specifies a unique tag for each outstanding transaction from a node.
  • the retry code field rt is a two bit field which specifies whether the packet is a retry attempt and the retry protocol to be followed by the destination node.
  • the transaction code field tcode is a four bit field that specifies the packet format and the type of transaction that is to be performed. For a write request for data block operation the transaction code field value is 0001. Within the possible values for the transaction code field, there are currently five values that are reserved.
  • the priority field pri is a four bit field that is used by the back plane.
  • the source- ID field is a sixteen bit field that specifies the node ID of the transmitting node of the packet.
  • the destination offset field is a forty-eight bit field that specifies the forty-eight bits of the destination node address of request packet.
  • the data length field is a sixteen bit field that specifies the length of the data field of data block payload packets.
  • the extended transaction code field extended_tcode is a sixteen bit field that conventionally is only meaningful if the transaction code field indicates a lock request or lock response packet.
  • the header_CRC field is a thirty-two bit field that is used to perform a cyclical redundancy check (CRC) on the data within the header.
  • the data portion of the packet includes a data block payload field and a data_crc field.
  • the data_crc field is a thirty-two bit field that is used to perform a cyclical redundancy check (CRC) on the data within the data portion of the packet.
  • CRC cyclical redundancy check
  • a new transaction code value within the transaction code field is utilized to specify that a packet is an asynchronous control mechanism packet according to the present invention.
  • the new transaction code value is any one of the currently available transaction code reserved values.
  • a bridge device receiving this packet will know that this packet is an asynchronous control mechanism packet and should be treated accordingly.
  • an extended transaction code value within the extended transaction code field extended code and an existing transaction code, such as the transaction code for the asynchronous block write packet are used to specify that the packet is an asynchronous control mechanism packet according to the present invention.
  • the extended transaction code field is currently only used with lock transactions. Accordingly, the extended transaction code field is currently unused for block read and write transactions. Even when used with lock transactions, only a few bits of the extended transaction code field are used.
  • the extended transaction code field is not available in quadlet read or write transactions. Accordingly, in this embodiment only block transactions are used for an asynchronous control mechanism packet.
  • the new extended transaction code value is preferably any one of the currently available extended transaction code reserved values. In this embodiment, when the extended transaction code field extendedjcode includes this value, a bridge device receiving this packet will know that this packet is an asynchronous control mechanism packet and should be treated accordingly.
  • an address offset value an otherwise unused address space of a node is utilized with existing transaction codes to specify an asynchronous control mechanism packet according to the present invention.
  • the asynchronous control mechanism packet will include an existing transaction code field value but will include an address offset value in private address space that will signal to a bridge device receiving the packet that the packet is an asynchronous control mechanism packet and should be handled accordingly.
  • a bridge device When a bridge device receives a packet that it determines is an asynchronous control mechanism packet according to the present invention, it processes the packet according to the data included within the packet. If the packet instructs the bridge to establish an isochronous connection, the bridge acquires the necessary bus resources for the appropriate buses and then determines, based on the address of the packet, if the packet should be forwarded to another bridge device. If the packet should be forwarded to another bridge device, the bridge device then puts the packet on the appropriate bus based on the destination address within the packet and the routing tables. If the bridge device is the final bridge within the routing path, the bridge device does not forward the packet, but sends a status packet to the controlling device informing the controlling device that the isochronous connection has been established.
  • FIG. 6 and 7 An example of the operation of a network of devices utilizing the asynchronous control mechanism packet of the present invention is illustrated in Figures 6 and 7.
  • the path of an asynchronous control mechanism packet initiated by the controlling device 186 is illustrated by the bold lines 200, 204 and 206 in Figure 6 and the bold lines 208 and 210 in Figure 7.
  • the example illustrated in Figures 6 and 7 utilizes the asynchronous control mechanism packet of the present invention sent from the controlling device 186 to establish an isochronous connection between the talker device 182 and the listener device 184.
  • the controller device 186 initiates the asynchronous control mechanism packet to establish the isochronous connection between the talker device 182 and the listener device 184.
  • the packet from the controller device 186 is addressed to the talker device 182 and includes a designation and instructional information specifying to the bridge devices that this is an asynchronous control mechanism packet and should be treated accordingly. As discussed above, preferably this designation is an extended transaction code value.
  • the packet When the packet is transmitted from the controller device 186, the packet is put on the bus 114 and accepted by the first portal 156 of the bridge device 152.
  • the bridge device 152 determines that this packet is an asynchronous control mechanism packet, but that the bridge 152 is not in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge 152 forwards the packet to the portal 154 which puts the packet on the bus 110.
  • the packet is then accepted by the portal 150 of the bridge device 146.
  • the bridge device 146 determines that this packet is an asynchronous control mechanism packet, but that the bridge device 146 is not in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge 146 forwards the packet to the portal 148 which puts the packet on the bus 108.
  • the packet is then accepted by the portal 142 of the bridge device 140.
  • the bridge device 140 determines that this packet is an asynchronous control mechanism packet but that the bridge 140 is not in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge 140 forwards the packet to the portal 144 which puts the packet on the bus 106.
  • the packet is then accepted by the portal 138 of the bridge device 134.
  • the bridge device 134 determines that this packet is an asynchronous control mechanism packet and that the bridge device 134 is in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge device 134 then reserves the appropriate isochronous resources on the buses 104 and 106.
  • the bridge device 134 then puts an in-stream version of the asynchronous control mechanism packet on the bus 106 directed to the listener device 184.
  • This in-stream version of the packet is then routed to the portal 166 of the bridge device 164, as illustrated in Figure 7.
  • the bridge device 164 determines that this is an asynchronous control mechanism packet in route to the listener device 184. Accordingly, the bridge device 164 determines that it is in the route from the talker device 182 to the listener device 184 and then reserves the appropriate resources on the bus 116 and sets up the data stream through the bridge device 164. The bridge device 164 then forwards the packet through the portal 168 onto the bus 116 directed to the listener device
  • the packet is then routed to the portal 178 of the bridge device 176.
  • the bridge device 176 determines that this is an asynchronous control mechanism packet in route to the listener device 184. Accordingly, the bridge device 176 determines that it is in the route from the talker device 182 to the listener device 184 and then reserves the appropriate resources on the bus 120 and sets up the data stream through the bridge device 176. Because this bridge device 176 is the final bridge device before the listener device 184, the bridge device 176 does not forward the asynchronous control mechanism packet any further. Instead, the bridge device 176 sends a status packet to the controlling device 186 informing the controlling device 186 that the isochronous connection between the talker device 182 and the listener device 184 has been established. Accordingly, the asynchronous control mechanism packet is preferably never forwarded to the listener device
  • the example illustrated in Figures 6 and 7 is initiated by the controlling device 186 and establishes the isochronous connection from the bridge device 134 closest to the talker device 182 to the bridge device 176 closest to the listener device 184 and every other bridge device within the route between the talker device 182 and the listener device 184.
  • isochronous connection can also be established in the other direction from the bridge device 176 closest to the listener device 184 to the bridge device 134 closest to the talker device 134.
  • the asynchronous control mechanism packet of the present invention is used to send control messages and information to one or more bridge devices within a network of buses of devices.
  • the asynchronous control mechanism packet is addressed to a device on one of the buses and is intercepted by one or more appropriate bridge devices along the path to the destination device.
  • the asynchronous control mechanism packet can be targeted at a particular bridge device or can be used to send control information to bridge devices along a particular communications route between two devices, as described above.
  • the asynchronous control mechanism packet includes a designation which specifies that it is an asynchronous control mechanism packet and should be treated accordingly. Preferably, this designation is included within the extended transaction code field of the packet. In an alternate embodiment, the designation is included within a transaction code field of the packet.
  • the designation is included within an address offset value within the asynchronous control mechanism packet.
  • Instructional information within the asynchronous control mechanism packet specifies to intercepting bridge devices the type of transaction and control tasks to be performed, such as allocating appropriate isochronous resources and forwarding the asynchronous control mechanism packet.
  • the asynchronous control mechanism packet of the present invention allows an initiating device to send a single control packet which effects control over one or more appropriate bridge devices, which are either targeted or within a specified communications route.

Abstract

An asynchronous control mechanism packet is used to send control messages and information to one or more bridge devices within a network of buses of devices. The asynchronous control mechanism packet is addressed to a device (182) on one of the buses and is intercepted by one or more appropriate bridge devices (152, 146, 140, 134) along the path to the destination device. The asynchronous control mechanism packet is targeted at a particular bridge device or used to send control messages and information to bridge devices along a particular communications route between two devices. The asynchronous control mechanism packet includes a designation specifying that it is an asynchronous control mechanism packet and should be treated accordingly. This designation is recognized by the appropriate bridge devices. Preferably, this designation is included within the extended transaction code field of the packet.

Description

METHOD OF AND APPARATUS FOR IMPLEMENTING AND SENDING AN ASYNCHRONOUS CONTROL MECHANISM PACKET
RELATED APPLICATIONS:
This application claims priority under 35 U.S.C. § 119(e) of the co-pending U.S. provisional application Serial Number 60/130,886 filed on April 23, 1999 and entitled "Network Bridging System And Method." The provisional application Serial Number 60/130,886 filed on April 23, 1999 and entitled "Network Bridging System And Method" is also hereby incorporated by reference.
FIELD OF THE INVENTION:
The present invention relates to the field of sending control communications to devices within a network. More particularly, the present invention relates to the field of sending control communications to bridges within a network for effecting control and allocating resources along a communications route.
BACKGROUND OF THE INVENTION: The IEEE Std 1394-1995 standard, "1394 Standard For A High Performance Serial
Bus," is an international standard for implementing an inexpensive high-speed serial bus architecture which supports both asynchronous and isochronous format data transfers. In addition, the IEEE Std 1394-1995 bus has a universal clock called the cycle timer. This clock is synchronized on all nodes. Isochronous data transfers are real-time transfers which take place based on the universal clock such that the time intervals between significant instances have the same duration at both the transmitting and receiving applications. Each packet of data transferred isochronously is transferred in its own time period. An example of an ideal application for the transfer of data isochronously would be from a video recorder to a television set. The video recorder records images and sounds and saves the data in discrete chunks or packets. The video recorder then transfers each packet, representing the image and sound recorded over a limited time period, during that time period, for display by the television set. The IEEE Std 1394-1995 standard bus architecture provides multiple independent channels for isochronous data transfer between applications. A six bit channel number is broadcast with the data to ensure reception by the appropriate application. This allows multiple applications to simultaneously transmit isochronous data across the bus structure. Asynchronous transfers are traditional reliable data transfer operations which take place as soon as arbitration is won and transfer a maximum amount of data from a source to a destination. Asynchronous transfers are used for control purposes, including the setup of isochronous communications.
The IEEE Std 1394-1995 standard provides a high-speed serial bus for interconnecting digital devices thereby providing a universal I/O connection. The IEEE
Std 1394-1995 standard defines a digital interface for the application thereby eliminating the need for an application to convert digital data to analog data before it is transmitted across the bus. Correspondingly, a receiving application will receive digital data from the bus, not analog data, and will therefore not be required to convert analog data to digital data. The cable required by the IEEE Std 1394-1995 standard is very thin in size compared to other bulkier cables used to connect such devices in other connection schemes. Devices can be added and removed from an IEEE Std 1394-1995 bus while the bus is operational. If a device is so added or removed the bus will then automatically reconfigure itself for transmitting data between the then existing nodes. A node is considered a logical entity with a unique address on the bus structure. Each node provides in a standard address space, an identification ROM, a standardized set of control registers and in addition, its own address space.
The IEEE Std 1394-1995 standard defines a protocol as illustrated in Figure 1. This protocol includes a serial bus management block 10 coupled to a transaction layer 12, a link layer 14 and a physical layer 16. The physical layer 16 provides the electrical and mechanical connection between a device or application and the IEEE Std 1394-1995 cable. The physical layer 16 also provides arbitration to ensure that all devices coupled to the IEEE Std 1394-1995 bus have access to the bus as well as actual data transmission and reception. The link layer 14 provides data packet delivery service for both asynchronous and isochronous data packet transport. This supports both asynchronous data transport, using an acknowledgement protocol, and isochronous data transport, providing real-time guaranteed bandwidth protocol for just-in-time data delivery. The transaction layer 12 supports the commands necessary to complete asynchronous data transfers, including read, write and lock. The serial bus management block 10 contains an isochronous resource manager for managing isochronous data transfers. The serial bus management block 10 also provides overall configuration control of the serial bus in the form of optimizing arbitration timing, guarantee of adequate electrical power for all devices on the bus, assignment of the cycle master, assignment of isochronous channel and bandwidth resources and basic notification of errors.
IEC-61883 is a ratified international standard for the transport of audio/video command requests and responses. This standard uses the concept of plugs and plug control registers to manage and control the attributes of isochronous data flows. It should be noted that plugs do not physically exist on an audio/video device, but a plug is used to establish an analogy with existing audio/video devices where each flow of information is routed through a physical plug.
An isochronous data flow flows from one transmitting device to one or more receiving devices, by transmitting isochronous packets on an isochronous channel of the
IEEE Std 1394-1995 serial bus. Each isochronous data flow is transmitted to an isochronous channel through one output plug on the transmitting device and is received from that isochronous channel through one input plug on the receiving device.
The transmission of an isochronous data flow through an output plug is controlled by an output plug control register (oPCR) and an output master plug register (oMPR) located on the transmitting device. The output master plug register controls all attributes that are common to all isochronous data flows transmitted by the corresponding transmitting device. The output plug control register controls all attributes of the corresponding isochronous data flow that are independent from attributes of other isochronous data flows transmitted by the tr.ansmitting device.
The reception of an isochronous data flow through an input plug is controlled by an input plug control register (iPCR) and an input master plug register (iMPR) located on the receiving device. The input master plug register controls all attributes that are common to all isochronous data flows received by the receiving device. The input plug control register controls all attributes of the corresponding isochronous data flow that are independent from attributes of other isochronous data flows received by the receiving device.
An isochronous data flow can be controlled by any device connected to the IEEE Std 1394-1995 bus by modifying the corresponding plug control registers. Plug control registers can be modified through asynchronous transactions on the IEEE Std 1394-1995 bus or by internal modifications if the plug control registers are located on the controlling device. To transport isochronous data between two audio/video devices on the IEEE Std
1394-1995 bus, it is necessary for an application to connect an output plug on the transmitting device to an input plug on the receiving device using an isochronous channel. The relationship between one input plug, one output plug and one isochronous channel is called a point-to-point connection. A point-to-point connection can only be broken by the application or initiating device that established it. An application can also just start the transmission or reception of an isochronous data flow on its own device by connecting one of its output or input plugs respectively to an isochronous channel. The relationship between one output plug and one isochronous channel is called a broadcast-out connection. The relationship between one input plug and one isochronous channel is called a broadcast- in connection. Broadcast-out and broadcast-in connections are collectively called broadcast connections. A broadcast connection can be established only by the device on which the plug is located, but it can be broken by any device.
The IEEE working group, "pi 394.1 Draft standard for High Performance Serial Bus Bridges", is a working group draft related to the IEEE Std 1394-1995 standard for implementing bus bridges between multiple IEEE Std 1394-1995 buses. Bridges within a net of multiple buses of devices forward request and response subactions from one bus to another, allowing transaction requester and responder components to be located on different buses.
An exemplary IEEE Std 1394-1995 network of three buses of devices is illustrated in Figure 2. The first bus includes the devices al, a2, and a3 coupled together by IEEE
Std 1394-1995 cables. Specifically, the device al is coupled to the device a2 by the IEEE Std 1394-1995 cable 40. The device a2 is coupled to the device a3 by the IEEE Std 1394- 1995 cable 42. The device a3 is then coupled to a first portal 22 of the bridge 20.
The bridge 20 couples the first bus to a second bus which includes the devices bl, b2 and b3. A second portal 24 of the bridge 20 is coupled to the device bl by the IEEE
Std 1394-1995 cable 46. The device bl is coupled to the device b2 by the IEEE Std 1394- 1995 cable 48. The device bl is coupled to the device b2 by the IEEE Std 1394-1995 cable 48. The device b2 is coupled to the device b3 by the IEEE Std 1394-1995 cable 50. The device b3 is coupled to a first portal 32 of the bridge 30. The bridge 30 couples the second bus to a third bus which includes the devices cl and c2. A second portal 34 of the bridge 30 is coupled to the device cl by the IEEE Std 1394-1995 cable 54. The device cl is coupled to the device c2 by the IEEE Std 1394-1995 cable 56.
The bridges 20 and 30 allow devices on the different buses to communicate with each other using both asynchronous and isochronous communications. For example, if the device al sends a communication to the device b3, the communication is passed along the first bus until it reaches the portal 22 of the bridge 20. The bridge 20 then recognizes that the communication is addressed to the device b3 and forwards the communication from the portal 22 to the portal 24. The communication is then passed along the second bus until it arrives at the device b3.
The components within a bridge device are illustrated in Figure 3. The bridge device 60 includes asynchronous request and response queues and isochronous data and isochronous queues for each portal. The bridge 60 also includes a microprocessor device
70. The queues within the bridge 60 hold packets received on one bus but not yet transmitted to the adjacent bus. The asynchronous request queue 62 holds request and asynchronous-stream packets. The asynchronous response queue 64 holds response packets.
Isochronous packets received in cycle (n) are forwarded to the adjacent bus in cycle
(n+K), where k is an implementation-dependent constant, using the isochronous data queue 66 and the isochronous clock queue 68. The isochronous data queue 66 holds isochronous packets which are selectively forwarded based on their channel number. The isochronous clock queue 68 holds the clock synchronization reference information which is forwarded from the primary bus outward and used to calibrate the clock on each bus. The request response, isochronous data and isochronous clock queues may be implemented as separate physical queues, or independently managed portions of a larger shared memory.
The bridge 60 also includes routing tables to determine which packets are forwarded to an adjacent bus. For asynchronous routing, the bridge 60 includes a bit-mapped table which specifies which packets are forwarded to the adjacent bus. For isochronous routing, the bridge 60 includes a table which specifies properties of an isochronous channel including whether the isochronous channel is forwarded to the adjacent bus, the channel number to be used on the adjacent bus and the speed to be used on the adjacent bus.
The bridge 60 also includes message mailbox locations to access low-band width facilities including initialization and isochronous management. The initialization protocols are responsible for each buses' assigned net-unique bus ID address and bridge routing which utilizes routing tables set to enable asynchronous subaction routing. The messages within the message mailbox are used to manage isochronous resource allocations.
Within the bridge 60, directed-asynchronous routing decisions are made using the destination ID addresses of packets being passed through the bridge 60. Accepted packets are directly routed to the opposing part of the bridge 60. This destination routing is based on a bus ID routing table. In the most general case, one or more routing bits can be independently specified for each of the 1024 possible bus numbers. .
An isochronous connection between a talker device and listener device is incrementally formed in the talker-to-listener direction. The portal of the bridge coupled to the talker device, on the routing path, is first directed to establish the appropriate talker bus connections by an initiation message sent from a controlling device to this portal. This portal then acquires the necessary isochronous resources on the talker device's local bus, sends a query transaction to discover next-path identifiers and sends confirmation to the controlling device which includes the next-path identifiers.
The controlling device then sends an initiation message to each bridge within the route between the talker device and the listener device, in turn. Each bridge along the route upon receiving the initiation message from the controlling device then acquires the necessary isochronous resources on the corresponding bus in the route, sends a query transaction to discover next-path identifiers and sends a confirmation to the controlling device which includes the next-path identifiers. This continues until all bridges in the route between the talker device and the listener device have acquired the necessary isochronous resources on each of the buses within the route.
In the manner described above, the isochronous connection between a talker device and a listener device is established by a controlling device. To establish this isochronous connection and have the necessary resources allocated, the controlling device communicates with each bridge within the route between the talker device and the listener device. This consumes significant resources of both the controlling device and each bridge and bus within the route between the talker device and the listener device. SUMMARY OF THE INVENTION:
An asynchronous control mechanism packet is used to send control messages and information to one or more bridge devices within a network of buses of devices. The asynchronous control mechanism packet is addressed to a device on one of the buses and is intercepted by one of the appropriate bridge devices along the path to the destination device. The asynchronous control mechanism packet is targeted at a particular bridge device or used to send control messages and information to bridge devices along a particular communications route between two devices. The asynchronous control mechanism packet includes a designation specifying that it is an asynchronous control mechanism packet and should be treated accordingly, and an indication of whether the packet should be processed by the first of the last portal between the source and destination buses.
This designation is recognized by the appropriate bridge devices. Preferably, this designation is included within the extended transaction code field of the packet. In an alternate embodiment, the designation is included within a transaction code field of the packet. In a further alternate embodiment, the designation is included within an address offset value within the packet. Instructional information within the asynchronous control mechanism packet specifies to intercepting bridge devices the type of transaction and control tasks to be performed by the bridge device when the asynchronous control mechanism packet is received.
In one aspect of the present invention, an asynchronous control mechanism packet includes an address value corresponding to a target device on a target bus, a designation and instructional information, wherein the designation within the asynchronous control mechanism packet causes a bridge device coupled to the target device and the target bus to intercept the packet and utilize the instructional information to perform one or more control tasks specified by the designation and the instructional information. The designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet. Alternatively, the designation is included within a transaction code field within the asynchronous control mechanism packet. In a further alternative embodiment, designation is included within an address offset value within the asynchronous control mechanism packet. The instructional information specifies a type of transaction and the control tasks to be performed. The asynchronous control mechanism packet is not forwarded to the target device. The designation and instructional information instruct the bridge device to establish an isochronous connection between a talker device and a listener device. Each bridge device within a route between the talker device and the listener device intercept the asynchronous control mechanism packet and allocate resources necessary to establish the isochronous connection between the talker device and the listener device. The talker device and the listener device are preferably coupled within a network of buses that substantially complies with a version of an IEEE Std 1394 standard.
In another aspect of the present invention, a method of effecting control of a bridge device coupled to a target device on a target bus includes the steps of sending an asynchronous control mechanism packet directed to the target device which includes an address value corresponding to the target device, a designation and instructional information, receiving the asynchronous control mechanism packet at the bridge device and utilizing the instructional information to perform one or more control tasks specified by the designation and the instructional information. The asynchronous control mechanism packet is not forwarded to the target device. The designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet. Alternatively, the designation is included within a transaction code field within the asynchronous control mechanism packet. In a further alternative embodiment, the designation is included within an address offset value within the asynchronous control mechanism packet. In one application, the step of utilizing establishes an isochronous connection between a talker device and a listener device. The steps of sending, receiving and utilizing are performed by each bridge device within a route between the talker device and the listener device and further wherein each of the bridge devices within the route allocate resources necessary to establish the isochronous connection between the talker device and the listener device. The talker device and the listener device are preferably coupled within a network of buses that substantially complies with a version of an IEEE Std 1394 standard.
In yet another aspect of the present invention, a method of establishing an isochronous connection between a talker device and a listener device within a network of buses. The bridge devices .are coupled between buses within the network of buses. The method includes the steps of sending .an asynchronous control mechanism packet from an initiating device directed to a selected one of the talker device and the listener devices. The asynchronous control mechanism packet includes an address value corresponding to the selected one of the talker devices and the listener devices and a designation specifying that the packet is an asynchronous control mechanism packet, and then receiving the asynchronous control mechanism packet at a current bridge device within the route between the talker device and the listener device. At that bridge allocating resources necessary to establish the isochronous connection between the talker device and the listener device. ' Determining if the current bridge device is a final bridge device within the route, passing the asynchronous control mechanism packet on to a next bridge device and repeating the steps of receiving the asynchronous control mechanism packet, allocating resources and determining if the current bridge device is a final bridge device within the route. If it is determined that the current bridge device is not the final bridge device within the route, and sending a control message to the initiating device if it is determined that the current bridge device is the final bridge device within the route. None of the asynchronous control mechanism packets are forwarded to the selected one of the talker device and the listener device. The designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet. Alternatively, the designation is included within a transaction code field within the asynchronous control mechanism packet. In a further alternative embodiment, the designation is included within an address offset value within the asynchronous control mechanism packet. The network of buses preferably substantially complies with a version of an IEEE Std 1394 standard.
In still yet another aspect of the present invention, a bridge device configured for coupling between two or more buses of devices includes a first portal interface configured for coupling to and communicating with a first bus of devices, a second portal interface configured for coupling to and communicating with a second bus of devices and a detecting and control circuit coupled to the first portal interface and the second portal interface for detecting when the first portal interface and the second portal interface receive an asynchronous control mechanism packet directed to a target device, wherein the asynchronous control mechanism packet includes an address value corresponding to the target device, a designation and instructional information and further wherein the detecting and control circuit performs one or more control tasks specified by the designation and the instructional information. The designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet. Alternatively, the designation is included within a transaction code field within the asynchronous control mechanism packet. In a further alternative embodiment, the designation is included within an address offset value within the asynchronous control mechanism packet. The one or more control tasks performed by the detecting and control circuit establish an isochronous connection between a talker device and a listener device. The bridge device and the two or more buses preferably substantially comply with a version of an IEEE Std 1394 standard.
In yet another aspect of the present invention, a network of devices coupled together by two or more buses, wherein bridge devices within the network couple different buses of devices to each other, each of the bridge devices include a first portal interface configured for coupling to and communicating with a first bus of devices, a second portal interface configured for coupling to and communicating with a second bus of devices and a detecting and control circuit coupled to the first portal interface and the second portal interface for detecting when the first portal interface and the second portal interface receive an asynchronous control mechanism packet directed to a target device, wherein the asynchronous control mechanism packet includes an address value corresponding to the target device, a designation and instructional information and further wherein the detecting and control circuit performs one or more control tasks specified by the designation and the instructional information. The designation is preferably included within an extended transaction code field within the asynchronous control mechanism packet. Alternatively, the designation is included within a transaction code field within the asynchronous control mechanism packet. In a further alternative embodiment, the designation is included within an address offset value within the asynchronous control mechanism packet. The one or more control tasks performed by the detecting and control circuit establish an isochronous connection between a talker device and a listener device. The network of devices preferably substantially complies with a version of an IEEE Std 1394 standard.
BRIEF DESCRIPTION OF THE DRAWINGS:
Figure 1 illustrates a protocol defined by the IEEE Std 1394 standard.
Figure 2 illustrates an exemplary network of three buses of devices. Figure 3 illustrates components within a bridge device.
Figure 4 illustrates an exemplary network of IEEE Std 1394-1995 buses and bridge devices. Figure 5 illustrates a format of a block write packet according to the IEEE Std 1394-1995 standard.
Figure 6 illustrates an exemplary operation of a network of devices utilizing the asynchronous control mechanism packet of the present invention. Figure 7 illustrates an exemplary operation of a network of devices utilizing the asynchronous control mechanism packet of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT:
The present invention provides an alternative to the above-discussed method for establishing an isochronous connection between a talker device and a listener device. A new transaction type is herein defined for effective control of bridge devices along an isochronous communications route between a talker device and a listener device. Preferably, the new transaction type is included within an asynchronous command packet which is addressed to a node on a remote bus. The packet is then routed along the bus towards the addressed node. When the packet is received by a bridge within the routing path, the bridge intercepts and processes the packet. This processing includes allocating the necessary resources for the isochronous connection. If appropriate, the bridge then forwards the packet on towards the addressed node along the routing path. In this manner, this asynchronous control mechanism packet is sent from bridge to bridge along the routing path between the talker device and the listener device to establish an isochronous connection and allocate the necessary isochronous resources along the routing path. The asynchronous control mechanism packet of the present invention can also be targeted towards a particular bridge device, by addressing it to a specific device and causing it to be intercepted by the bridge device controlling communications on the destination bus. The asynchronous control mechanism packet of the present invention allows an initiating or controlling device to send a single communication to the addressed node which will cause the bridge devices within the routing path to process the packet and establish the isochronous connection. The controlling device does not need to send separate communications to each bridge within the routing path and establish the route for the isochronous communication. The controlling device can send the asynchronous control mechanism packet without knowing the appropriate route or which bridge devices are included within that route. By sending an asynchronous packet, the controlling device takes advantage of the asynchronous routing tables already established by the bridges within the network. Accordingly, the resources of the controlling device are conserved and are not required to actively participate in the establishment of the isochronous connection at each bridge device within the routing path. Preferably, the asynchronous control mechanism packet of the present invention is used to establish and teardown an isochronous connection between a talker device and a listener device, as described herein. However, it should be apparent to those skilled in the art that the asynchronous control mechanism packet of the present invention can also be used for other functions, including other bridge control functions. A bridge device according to the present invention preferably includes the components as illustrated in Figure 3 and discussed above and also has the ability to detect an asynchronous control mechanism packet of the present invention. Accordingly, when the bridge device of the present invention receives an asynchronous control mechanism packet, it will treat it appropriately, including implementing any controls and performing any necessary tasks specified in the asynchronous control mechanism packet.
An exemplary network of IEEE Std 1394-1995 buses and bridge devices is illustrated in Figure 4. Within Figure 4, the horizontal lines 100, 102, 104, 106, 108, 110, 112, 114, 116, 118 and 120 are used to designate buses of one or more devices. Within the exemplary network of Figure 4, the IEEE Std 1394-1995 bus 100 is coupled to a first portal 124 of a bridge device 122. A second portal 126 of the bridge device 122 is coupled to the IEEE Std 1394-1995 bus 102. The bus 102 is coupled to a first portal 130 of a bridge device 128. A second portal 132 of the bridge device 128 is coupled to the IEEE Std 1394-1995 bus 104. A talker device 182 is coupled as a device within the bus 104. The bus 104 is coupled to a first portal 136 of a bridge device 134. A second portal 138 of the bridge device 134 is coupled to the IEEE Std 1394-1995 bus 106. The bus 106 is coupled to a first portal 144 of a bridge device 140 and a first portal 166 of a bridge device 164. A second portal 142 of the bridge device 140 is coupled to the IEEE Std 1394-1995 bus 108. The bus 108 is also coupled to a first portal 148 of a bridge device 146. The second portal 150 of the bridge device 146 is coupled to the IEEE Std
1394-1995 bus 110. The bus 110 is coupled to a first portal 154 of a bridge device 152 and a first portal 160 of a bridge device 158. A second portal 162 of the bridge device 158 is coupled to the IEEE Std 1394-1995 bus 112. A second portal 156 of the bridge device 152 is coupled to the IEEE Std 1394-1995 bus 114. A controlling device 186 is coupled as a device within the bus 114.
A second portal 168 of the bridge device 164 is coupled to the IEEE Std 1394-1995 bus 116. The bus 116 is coupled to a first portal 172 of a bridge device 170 and a first portal 178 of a bridge device 176. A second portal 174 of the bridge device 170 is coupled to the IEEE Std 1394-1995 bus 118. A second portal 180 of a bridge device 176 is coupled to the IEEE Std 1394-1995 bus 120. A listener device 184 is coupled as a device within the bus 120. The asynchronous control mechanism packet of the present invention is preferably an asynchronous block write packet. Alternatively, the asynchronous control mechanism packet of the present invention can be included within any appropriate packet type including read, write and lock.
A format of a block write packet according to the IEEE Std 1394-1995 is illustrated in Figure 5. The asynchronous block write packet includes a header and a data payload.
The header includes the fields destinationJD, tl, rt, tcode, pri, source_ID, destination_offset, data_length, extended_tcode and header_crc. The destinationJD field is a sixteen bit field which specifies the node ID of the receiving node to which the packet is addressed. The transaction label field tl is a six bit field that specifies a unique tag for each outstanding transaction from a node. The retry code field rt is a two bit field which specifies whether the packet is a retry attempt and the retry protocol to be followed by the destination node. The transaction code field tcode is a four bit field that specifies the packet format and the type of transaction that is to be performed. For a write request for data block operation the transaction code field value is 0001. Within the possible values for the transaction code field, there are currently five values that are reserved.
The priority field pri is a four bit field that is used by the back plane. The source- ID field is a sixteen bit field that specifies the node ID of the transmitting node of the packet. The destination offset field is a forty-eight bit field that specifies the forty-eight bits of the destination node address of request packet. The data length field is a sixteen bit field that specifies the length of the data field of data block payload packets. The extended transaction code field extended_tcode is a sixteen bit field that conventionally is only meaningful if the transaction code field indicates a lock request or lock response packet. The header_CRC field is a thirty-two bit field that is used to perform a cyclical redundancy check (CRC) on the data within the header.
The data portion of the packet includes a data block payload field and a data_crc field. The data_crc field is a thirty-two bit field that is used to perform a cyclical redundancy check (CRC) on the data within the data portion of the packet.
In one embodiment of the present invention, a new transaction code value within the transaction code field is utilized to specify that a packet is an asynchronous control mechanism packet according to the present invention. The new transaction code value is any one of the currently available transaction code reserved values. In this embodiment, when the transaction code field tcode within a packet includes this value, a bridge device receiving this packet will know that this packet is an asynchronous control mechanism packet and should be treated accordingly.
In the preferred embodiment of the present invention, an extended transaction code value within the extended transaction code field extended code and an existing transaction code, such as the transaction code for the asynchronous block write packet, are used to specify that the packet is an asynchronous control mechanism packet according to the present invention. The extended transaction code field is currently only used with lock transactions. Accordingly, the extended transaction code field is currently unused for block read and write transactions. Even when used with lock transactions, only a few bits of the extended transaction code field are used. The extended transaction code field is not available in quadlet read or write transactions. Accordingly, in this embodiment only block transactions are used for an asynchronous control mechanism packet. The new extended transaction code value is preferably any one of the currently available extended transaction code reserved values. In this embodiment, when the extended transaction code field extendedjcode includes this value, a bridge device receiving this packet will know that this packet is an asynchronous control mechanism packet and should be treated accordingly.
In an alternate embodiment, an address offset value an otherwise unused address space of a node is utilized with existing transaction codes to specify an asynchronous control mechanism packet according to the present invention. In this embodiment, the asynchronous control mechanism packet will include an existing transaction code field value but will include an address offset value in private address space that will signal to a bridge device receiving the packet that the packet is an asynchronous control mechanism packet and should be handled accordingly.
When a bridge device receives a packet that it determines is an asynchronous control mechanism packet according to the present invention, it processes the packet according to the data included within the packet. If the packet instructs the bridge to establish an isochronous connection, the bridge acquires the necessary bus resources for the appropriate buses and then determines, based on the address of the packet, if the packet should be forwarded to another bridge device. If the packet should be forwarded to another bridge device, the bridge device then puts the packet on the appropriate bus based on the destination address within the packet and the routing tables. If the bridge device is the final bridge within the routing path, the bridge device does not forward the packet, but sends a status packet to the controlling device informing the controlling device that the isochronous connection has been established.
An example of the operation of a network of devices utilizing the asynchronous control mechanism packet of the present invention is illustrated in Figures 6 and 7. In this example, the path of an asynchronous control mechanism packet initiated by the controlling device 186 is illustrated by the bold lines 200, 204 and 206 in Figure 6 and the bold lines 208 and 210 in Figure 7. The example illustrated in Figures 6 and 7 utilizes the asynchronous control mechanism packet of the present invention sent from the controlling device 186 to establish an isochronous connection between the talker device 182 and the listener device 184.
The controller device 186 initiates the asynchronous control mechanism packet to establish the isochronous connection between the talker device 182 and the listener device 184. The packet from the controller device 186 is addressed to the talker device 182 and includes a designation and instructional information specifying to the bridge devices that this is an asynchronous control mechanism packet and should be treated accordingly. As discussed above, preferably this designation is an extended transaction code value.
When the packet is transmitted from the controller device 186, the packet is put on the bus 114 and accepted by the first portal 156 of the bridge device 152. The bridge device 152 then determines that this packet is an asynchronous control mechanism packet, but that the bridge 152 is not in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge 152 forwards the packet to the portal 154 which puts the packet on the bus 110. The packet is then accepted by the portal 150 of the bridge device 146. The bridge device 146 then determines that this packet is an asynchronous control mechanism packet, but that the bridge device 146 is not in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge 146 forwards the packet to the portal 148 which puts the packet on the bus 108.
The packet is then accepted by the portal 142 of the bridge device 140. The bridge device 140 then determines that this packet is an asynchronous control mechanism packet but that the bridge 140 is not in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge 140 forwards the packet to the portal 144 which puts the packet on the bus 106.
The packet is then accepted by the portal 138 of the bridge device 134. The bridge device 134 then determines that this packet is an asynchronous control mechanism packet and that the bridge device 134 is in the asynchronous route between the talker device 182 and the listener device 184. Accordingly, the bridge device 134 then reserves the appropriate isochronous resources on the buses 104 and 106. The bridge device 134 then puts an in-stream version of the asynchronous control mechanism packet on the bus 106 directed to the listener device 184.
This in-stream version of the packet is then routed to the portal 166 of the bridge device 164, as illustrated in Figure 7. The bridge device 164 then determines that this is an asynchronous control mechanism packet in route to the listener device 184. Accordingly, the bridge device 164 determines that it is in the route from the talker device 182 to the listener device 184 and then reserves the appropriate resources on the bus 116 and sets up the data stream through the bridge device 164. The bridge device 164 then forwards the packet through the portal 168 onto the bus 116 directed to the listener device
184.
The packet is then routed to the portal 178 of the bridge device 176. The bridge device 176 then determines that this is an asynchronous control mechanism packet in route to the listener device 184. Accordingly, the bridge device 176 determines that it is in the route from the talker device 182 to the listener device 184 and then reserves the appropriate resources on the bus 120 and sets up the data stream through the bridge device 176. Because this bridge device 176 is the final bridge device before the listener device 184, the bridge device 176 does not forward the asynchronous control mechanism packet any further. Instead, the bridge device 176 sends a status packet to the controlling device 186 informing the controlling device 186 that the isochronous connection between the talker device 182 and the listener device 184 has been established. Accordingly, the asynchronous control mechanism packet is preferably never forwarded to the listener device
184 to which it was addressed.
The example illustrated in Figures 6 and 7 is initiated by the controlling device 186 and establishes the isochronous connection from the bridge device 134 closest to the talker device 182 to the bridge device 176 closest to the listener device 184 and every other bridge device within the route between the talker device 182 and the listener device 184.
It should be apparent that the isochronous connection can also be established in the other direction from the bridge device 176 closest to the listener device 184 to the bridge device 134 closest to the talker device 134.
The asynchronous control mechanism packet of the present invention is used to send control messages and information to one or more bridge devices within a network of buses of devices. The asynchronous control mechanism packet is addressed to a device on one of the buses and is intercepted by one or more appropriate bridge devices along the path to the destination device. The asynchronous control mechanism packet can be targeted at a particular bridge device or can be used to send control information to bridge devices along a particular communications route between two devices, as described above. The asynchronous control mechanism packet includes a designation which specifies that it is an asynchronous control mechanism packet and should be treated accordingly. Preferably, this designation is included within the extended transaction code field of the packet. In an alternate embodiment, the designation is included within a transaction code field of the packet. In a further alternative embodiment, the designation is included within an address offset value within the asynchronous control mechanism packet. Instructional information within the asynchronous control mechanism packet specifies to intercepting bridge devices the type of transaction and control tasks to be performed, such as allocating appropriate isochronous resources and forwarding the asynchronous control mechanism packet. The asynchronous control mechanism packet of the present invention allows an initiating device to send a single control packet which effects control over one or more appropriate bridge devices, which are either targeted or within a specified communications route. The present invention has been described in terms of specific embodiments incorporating details to facilitate the understanding of the principles of construction and operation of the invention. Such reference herein to specific embodiments and details thereof is not intended to limit the scope of the claims appended hereto. It will be apparent to those skilled in the art that modifications can be made in the embodiment chosen for illustration without departing from the spirit and scope of the invention. Specifically, it will be apparent to one of ordinary skill in the art that the device of the present invention could be implemented in several different ways and the architecture, system and method disclosed above are only illustrative of preferred embodiments of the invention. Specifically, it will be apparent to those skilled in the art that while the preferred embodiment of the present invention is used with an IEEE Std 1394-1995 serial bus structure, the present invention could also be implemented on any other appropriate digital interfaces or bus structures, including other or later versions of the IEEE Std 1394 serial bus.

Claims

C L A I M SWe Claim:
1. An asynchronous control mechanism packet including an address value corresponding to a target device on a target bus, a designation and instructional information, wherein the designation within the asynchronous control mechanism packet causes a bridge device coupled to the target device and the target bus to intercept the packet and utilize the instructional information to perform one or more control tasks specified by the designation and the instructional information.
2. The asynchronous control mechanism packet as claimed in claim 1 wherein the designation is included within an extended transaction code field within the asynchronous control mechanism packet.
3. The asynchronous control mechanism packet as claimed in claim 1 wherein the designation is included within a transaction code field within the asynchronous control meclranism packet.
4. The asynchronous control mechanism packet as claimed in claim 1 wherein the designation is included within an address offset value within the asynchronous control mechanism packet.
5. The asynchronous control mechanism packet as claimed in claim 1 wherein the instructional information specifies a type of transaction and the control tasks to be performed.
6. The asynchronous control mechanism packet as claimed in claim 1 wherein the asynchronous control mechanism packet is initiated by a controlling device.
7. The asynchronous control mechanism packet as claimed in claim 1 wherein the asynchronous control mechanism packet is not forwarded to the target device.
8. The asynchronous control mechanism packet as claimed in claim 1 wherein the designation and instructional information instruct the bridge device to establish an isochronous connection between a talker device and a listener device.
9. The asynchronous control mechanism packet as claimed in claim 8 wherein each bridge device within a route between the talker device and the listener device intercept the asynchronous control mechanism packet and allocate resources necessary to establish the isochronous connection between the talker device and the listener device.
10. The asynchronous control mechanism packet as claimed in claim 9 wherein the talker device and the listener device are coupled within a network of buses that substantially complies with a version of an IEEE Std 1394 standard.
11. A method of effecting control of a bridge device coupled to a target device on a target bus comprising the steps of: a. sending an asynchronous control mechanism packet directed to the target device which includes an address value corresponding to the target device, a designation and instructional information; b. receiving the asynchronous control mechanism packet at the bridge device; and c. utilizing the instructional information to perform one or more control tasks specified by the designation and the instructional information.
12. The method as claimed in claim 11 wherein the asynchronous control mechanism packet is not forwarded to the target device.
13. The method as claimed in claim 11 wherein the designation is included within an extended transaction code field within the asynchronous control mechanism packet.
14. The method as claimed in claim 11 wherein the designation is included within a transaction code field within the asynchronous control mechanism packet.
15. The method as claimed in claim 11 wherein the designation is included within an address offset value within the asynchronous control mechanism packet.
16. The method as claimed in claim 11 wherein the step of utilizing establishes an isochronous connection between a talker device and a listener device.
17. The method as claimed in claim 16 wherein the steps of sending, receiving and utilizing are performed by each bridge device within a route between the talker device and the listener device and further wherein each of the bridge devices within the route allocate resources necessary to establish the isochronous connection between the talker device and the listener device.
18. The method as claimed in claim 17 wherein the talker device and the listener device are coupled within a network of buses that substantially complies with a version of an IEEE Std 1394 standard.
19. A method of establishing an isochronous connection between a talker device and a listener device within a network of buses, wherein bridge devices are coupled between buses within the network of buses, the method comprising the steps of: a. sending an asynchronous control mechanism packet from an initiating device directed to a selected one of the talker device and the listener device, wherein the asynchronous control mechanism packet includes an address value corresponding to the selected one of the talker device and the listener device and a designation specifying that the packet is an asynchronous control mechanism packet; b. receiving the asynchronous control mechanism packet at a current bridge device within the route between the talker device and the listener device; c. allocating resources necessary to establish the isochronous connection between the talker device and the listener device; d. determining if the current bridge device is a final bridge device within the route; e. passing the asynchronous control mechanism packet on to a next bridge device and repeating steps b-d if it is determined that the current bridge device is not the final bridge device within the route; and f. sending a control message to the initiating device if it is determined that the current bridge device is the final bridge device within the route.
20. The method as claimed in claim 19 wherein the asynchronous control mechanism packet is not forwarded to the selected one of the talker device and the listener device.
21. The method as claimed in claim 19 wherein the designation is included within an extended transaction code field within the asynchronous control mechanism packet.
22. The method as claimed in claim 19 wherein the designation is included within a transaction code field within the asynchronous control mechanism packet.
23. The method as claimed in claim 19 wherein the designation is included within an address offset value within the asynchronous control mechanism packet.
24. The method as claimed in claim 19 wherein the network of buses substantially complies with a version of an IEEE Std 1394 standard.
25. A bridge device configured for coupling between two or more buses of devices comprising: a. a first portal interface configured for coupling to and communicating with a first bus of devices; b. a second portal interface configured for coupling to and communicating with a second bus of devices; and c. a detecting and control circuit coupled to the first portal interface and the second portal interface for detecting when the first portal interface and the second portal interface receive an asynchronous control mechanism packet directed to a target device, wherein the asynchronous confrol mechanism packet includes an address value corresponding to the target device, a designation and instructional information and further wherein the detecting and control circuit performs one or more control tasks specified by the designation and the instructional information.
26. The bridge device as claimed in claim 25 wherein the designation is included within an extended transaction code field within the asynchronous control mechanism packet.
27. The bridge device as claimed in claim 25 wherein the designation is included within a transaction code field within the asynchronous control mechanism packet.
28. The bridge device as claimed in claim 25 wherein the designation is included within an address offset value within the asynchronous control mechanism packet.
29. The bridge device as claimed in claim 25 wherein the one or more control tasks performed by the detecting and control circuit establish an isochronous connection between a talker device and a listener device.
30. The bridge device as claimed in claim 25 wherein the bridge device and the two or more buses substantially comply with a version of an IEEE Std 1394 standard.
31. A network of devices coupled together by two or more buses, wherein bridge devices within the network couple different buses of devices to each other, each of the bridge devices comprising: a. a first portal interface configured for coupling to and communicating with a first bus of devices; b. a second portal interface configured for coupling to and communicating with a second bus of devices; and c. a detecting and control circuit coupled to the first portal interface and the second portal interface for detecting when the first portal interface and the second portal interface receive an asynchronous control mechanism packet directed to a target device, wherein the asynchronous control mechanism packet includes an address value corresponding to the target device, a designation and instructional information and further wherein the detecting and confrol circuit performs one or more control tasks specified by the designation and the instructional information.
32. The network of devices as claimed in claim 31 wherein the designation is included within an extended transaction code field within the asynchronous control mechanism packet.
33. The network of devices as claimed in claim 31 wherein the designation is included within a transaction code field within the asynchronous control mechanism packet.
34. The network of devices as claimed in claim 31 wherein the designation is included within an address offset value within the asynchronous control mechanism packet.
35. The network of devices as claimed in claim 31 wherein the one or more control tasks performed by the detecting and control circuit establish an isochronous connection between a talker device and a listener device.
36. The network of devices as claimed in claim 31 wherein the network of devices substantially complies with a version of an IEEE Std 1394 standard.
PCT/US2000/010844 1999-04-23 2000-04-21 Method of and apparatus for implementing and sending an asynchronous control mechanism packet WO2000065781A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU44820/00A AU4482000A (en) 1999-04-23 2000-04-21 Method of and apparatus for implementing and sending an asynchronous control mechanism packet

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13088699P 1999-04-23 1999-04-23
US60/130,886 1999-04-23
US09/556,080 US6445711B1 (en) 1999-04-23 2000-04-21 Method of and apparatus for implementing and sending an asynchronous control mechanism packet used to control bridge devices within a network of IEEE STD 1394 serial buses
US09/556,080 2000-04-21

Publications (1)

Publication Number Publication Date
WO2000065781A1 true WO2000065781A1 (en) 2000-11-02

Family

ID=26828927

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/010844 WO2000065781A1 (en) 1999-04-23 2000-04-21 Method of and apparatus for implementing and sending an asynchronous control mechanism packet

Country Status (3)

Country Link
US (2) US6445711B1 (en)
AU (1) AU4482000A (en)
WO (1) WO2000065781A1 (en)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734852B1 (en) 1998-08-06 2010-06-08 Ahern Frank W Modular computer system
JP3353824B2 (en) * 1999-04-22 2002-12-03 日本電気株式会社 Network synchronization system and network synchronization method
WO2000065781A1 (en) 1999-04-23 2000-11-02 Sony Electronics Inc. Method of and apparatus for implementing and sending an asynchronous control mechanism packet
JP4097847B2 (en) * 1999-07-05 2008-06-11 株式会社リコー Bus bridge arbitration method
US7042896B1 (en) * 1999-07-26 2006-05-09 Samsung Electronics Co. Ltd. Method for managing a digital interface connection
US6629159B1 (en) * 1999-07-31 2003-09-30 Lg Electronics Inc. Method for modifying data of specific register in digital interface
JP3449313B2 (en) * 1999-09-28 2003-09-22 日本電気株式会社 Device information collection method, device control device, and bridge
CA2399013A1 (en) * 2000-01-27 2001-08-02 Thomson Licensing S.A. Method for isochronous resource management in a network based on hiperlan 2 technology
EP1277145A4 (en) * 2000-02-16 2003-05-21 Bea Systems Inc Conversation management system for enterprise wide electronic collaboration
US7050453B1 (en) 2000-02-17 2006-05-23 Apple Computer, Inc. Method and apparatus for ensuring compatibility on a high performance serial bus
US6594719B1 (en) * 2000-04-19 2003-07-15 Mobility Electronics Inc. Extended cardbus/pc card controller with split-bridge ™technology
JP2001326669A (en) * 2000-05-16 2001-11-22 Sony Corp Interface unit for digital serial data and bridge portal utilizing the same
US6993022B1 (en) * 2000-07-06 2006-01-31 Sony Corporation Method of and apparatus for directly mapping communications through a router between nodes on different buses within a network of buses
US6686838B1 (en) * 2000-09-06 2004-02-03 Xanboo Inc. Systems and methods for the automatic registration of devices
EP1199840A1 (en) * 2000-10-19 2002-04-24 THOMSON multimedia Method for connecting an IEEE1394 remote device to a cluster of IEEE1394 devices through a wireless link
US7269137B2 (en) * 2001-08-24 2007-09-11 Canon Kabushiki Kaisha Method for setting up an isochronous data stream connection, with the application of a predetermined, total isochronous delay on one or more routing paths
US7721193B2 (en) * 2001-10-18 2010-05-18 Bea Systems, Inc. System and method for implementing a schema object model in application integration
US7552222B2 (en) 2001-10-18 2009-06-23 Bea Systems, Inc. Single system user identity
US6898658B2 (en) * 2001-12-27 2005-05-24 Koninklijke Philips Electronics N.V. Method to prevent net update oscillation
US7516447B2 (en) 2002-02-22 2009-04-07 Bea Systems, Inc. Methods and apparatus for building, customizing and using software abstractions of external entities
US8045548B1 (en) * 2002-03-29 2011-10-25 Advanced Micro Devices, Inc. Data stream labeling and processing
US8135772B2 (en) 2002-05-01 2012-03-13 Oracle International Corporation Single servlets for B2B message routing
US7155438B2 (en) * 2002-05-01 2006-12-26 Bea Systems, Inc. High availability for event forwarding
US7424717B2 (en) 2002-05-01 2008-09-09 Bea Systems, Inc. Systems and methods for business process plug-in development
US7526519B2 (en) 2002-05-01 2009-04-28 Bea Systems, Inc. High availability application view deployment
US7257645B2 (en) * 2002-05-01 2007-08-14 Bea Systems, Inc. System and method for storing large messages
US7493628B2 (en) * 2002-05-02 2009-02-17 Bea Systems, Inc. Shared common connection factory
US7484224B2 (en) 2002-05-02 2009-01-27 Bae Systems, Inc. Adapter deployment without recycle
US7627631B2 (en) 2002-05-02 2009-12-01 Bea Systems, Inc. Systems and methods for collaborative business plug-ins
US7676538B2 (en) 2002-05-02 2010-03-09 Bea Systems, Inc. Systems and methods for application view transactions
US7222148B2 (en) * 2002-05-02 2007-05-22 Bea Systems, Inc. System and method for providing highly available processing of asynchronous service requests
US7350184B2 (en) 2002-05-02 2008-03-25 Bea Systems, Inc. System and method for enterprise application interactions
FR2841007B1 (en) * 2002-06-18 2004-07-23 Schneider Automation SECURITY COMMUNICATION SYSTEM
US7293038B2 (en) 2003-02-25 2007-11-06 Bea Systems, Inc. Systems and methods for client-side filtering of subscribed messages
US7752599B2 (en) 2003-02-25 2010-07-06 Bea Systems Inc. Systems and methods extending an existing programming language with constructs
US20050022164A1 (en) * 2003-02-25 2005-01-27 Bea Systems, Inc. Systems and methods utilizing a workflow definition language
US7584474B2 (en) * 2003-02-25 2009-09-01 Bea Systems, Inc. Systems and methods for transaction chaining
US7774697B2 (en) * 2003-02-25 2010-08-10 Bea Systems, Inc. System and method for structuring distributed applications
US7650276B2 (en) 2003-02-26 2010-01-19 Bea Systems, Inc. System and method for dynamic data binding in distributed applications
US7299454B2 (en) * 2003-02-26 2007-11-20 Bea Systems, Inc. Method for multi-language debugging
US7539985B2 (en) 2003-02-26 2009-05-26 Bea Systems, Inc. Systems and methods for dynamic component versioning
US7707564B2 (en) 2003-02-26 2010-04-27 Bea Systems, Inc. Systems and methods for creating network-based software services using source code annotations
US20050108682A1 (en) * 2003-02-26 2005-05-19 Bea Systems, Inc. Systems for type-independent source code editing
US7076772B2 (en) 2003-02-26 2006-07-11 Bea Systems, Inc. System and method for multi-language extensible compiler framework
US8032860B2 (en) * 2003-02-26 2011-10-04 Oracle International Corporation Methods for type-independent source code editing
US20050044173A1 (en) * 2003-02-28 2005-02-24 Olander Daryl B. System and method for implementing business processes in a portal
US7444620B2 (en) 2003-02-28 2008-10-28 Bea Systems, Inc. Systems and methods for a common runtime container framework
US7636722B2 (en) 2003-02-28 2009-12-22 Bea Systems, Inc. System and method for describing application extensions in XML
US7650592B2 (en) 2003-03-01 2010-01-19 Bea Systems, Inc. Systems and methods for multi-view debugging environment
US20070138506A1 (en) * 2003-11-17 2007-06-21 Braddock Walter D Nitride metal oxide semiconductor integrated transistor devices
DE10356128A1 (en) * 2003-12-02 2005-06-30 Robert Bosch Gmbh Network Bridge
US7237135B1 (en) 2003-12-29 2007-06-26 Apple Inc. Cyclemaster synchronization in a distributed bridge
KR100677143B1 (en) * 2004-10-15 2007-02-02 삼성전자주식회사 Method and apparatus for transmitting isochronous stream
WO2009043762A2 (en) * 2007-10-04 2009-04-09 U-Man Universal Media Access Networks Gmbh Digital multimedia network with hierarchical parameter control protocol
TWI459774B (en) * 2011-04-29 2014-11-01 Ind Tech Res Inst Asynchronous master-slave serial communication systam, data transmission method, and control module using the same thereof

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5517494A (en) * 1994-09-30 1996-05-14 Apple Computer, Inc. Method and system of multicast routing for groups with a single transmitter
US5815668A (en) * 1995-03-17 1998-09-29 Nec Corporation Slave inter-lan connection device, an inter-lan connection system and a hot standby method of said inter-lan connection system
US5941964A (en) * 1992-05-21 1999-08-24 Intel Corporation Bridge buffer management by bridge interception of synchronization events
US6034964A (en) * 1996-06-11 2000-03-07 Hitachi, Ltd. Router device and network system using the same

Family Cites Families (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6054543A (en) 1983-09-05 1985-03-29 Sony Corp Data communication device
US4930065A (en) 1987-08-20 1990-05-29 David Computer Corporation Automatic data channels for a computer system
US4933938A (en) * 1989-03-22 1990-06-12 Hewlett-Packard Company Group address translation through a network bridge
JPH03156554A (en) 1989-11-14 1991-07-04 Hitachi Ltd Data transfer control system
JPH04269049A (en) 1991-02-25 1992-09-25 Hitachi Ltd Address management system and communication
US5729755A (en) 1991-09-04 1998-03-17 Nec Corporation Process for transmitting data in a data processing system with distributed computer nodes, communicating via a serial data bus, between which data messages are exchanged, tested for acceptance in a computer node, and stored temporarily
GB9216681D0 (en) 1992-08-06 1992-09-23 D2B Systems Co Ltd Apparatuses interconnected for the communication of control messages
JP3003418B2 (en) 1992-09-25 2000-01-31 株式会社日立製作所 Data communication method between processors
US5499344A (en) 1992-10-07 1996-03-12 Texas Instruments Incorporated Programmable dual port data unit for interfacing between multiple buses
EP0596651A1 (en) 1992-11-02 1994-05-11 National Semiconductor Corporation Network for data communication with isochronous capability
GB9309468D0 (en) 1993-05-07 1993-06-23 Roke Manor Research Improvements in or relating to asynchronous transfer mode communication systems
US5448698A (en) 1993-04-05 1995-09-05 Hewlett-Packard Company Inter-processor communication system in which messages are stored at locations specified by the sender
US5408501A (en) 1993-04-06 1995-04-18 Conner Peripherals, Inc. Data transfer system
US5444709A (en) 1993-09-30 1995-08-22 Apple Computer, Inc. Protocol for transporting real time data
EP0676878A1 (en) 1994-04-07 1995-10-11 International Business Machines Corporation Efficient point to point and multi point routing mechanism for programmable packet switching nodes in high speed data transmission networks
US5434860A (en) 1994-04-20 1995-07-18 Apple Computer, Inc. Flow control for real-time data streams
US5619544A (en) 1994-06-03 1997-04-08 Texas Instruments Incorporated Universal asynchronous receive/transmit circuit with flow control
US5689244A (en) 1994-06-24 1997-11-18 Sony Corporation Communication system and electronic apparatus
US5687316A (en) 1994-07-29 1997-11-11 International Business Machines Corporation Communication apparatus and methods having P-MAC, I-MAC engines and buffer bypass for simultaneously transmitting multimedia and packet data
US5668952A (en) 1994-08-08 1997-09-16 International Business Machines Corporation Method for resolving network address by sending reresolve request to nodes at selected time period after establishing address table, and updating the table with received reply thereto
US5661848A (en) 1994-09-08 1997-08-26 Western Digital Corp Multi-drive controller with encoder circuitry that generates ECC check bytes using the finite field for optical data for appending to data flowing to HDA
US5615404A (en) 1994-10-31 1997-03-25 Intel Corporation System having independently addressable bus interfaces coupled to serially connected multi-ported signal distributors generating and maintaining frame based polling schedule favoring isochronous peripherals
US5664124A (en) 1994-11-30 1997-09-02 International Business Machines Corporation Bridge between two buses of a computer system that latches signals from the bus for use on the bridge and responds according to the bus protocols
GB9501378D0 (en) 1995-01-24 1995-03-15 Ibm A system and method for establishing a communication channel over a heterogeneous network between a source node and a destination node
JP3125842B2 (en) 1995-03-03 2001-01-22 株式会社日立製作所 Communication processing method and system in parallel computer
US5519701A (en) 1995-03-29 1996-05-21 International Business Machines Corporation Architecture for high performance management of multiple circular FIFO storage means
AU6334496A (en) * 1995-06-15 1997-01-15 Intel Corporation Architecture for an i/o processor that integrates a pci to pci bridge
US5991520A (en) 1996-02-02 1999-11-23 Sony Corporation Application programming interface for managing and automating data transfer operations between applications over a bus structure
US6519268B1 (en) * 1996-03-07 2003-02-11 Sony Corporation Asynchronous data pipe for automatically managing asynchronous data transfers between an application and a bus structure
JPH09275402A (en) * 1996-04-04 1997-10-21 Sony Corp Communication control system, communication control equipment, data transmitter/receiver and communication control method
US6006286A (en) * 1996-04-26 1999-12-21 Texas Instruments Incorporated System for controlling data packet transfers by associating plurality of data packet transfer control instructions in packet control list including plurality of related logical functions
JPH09307581A (en) * 1996-05-16 1997-11-28 Oki Electric Ind Co Ltd Bridge
US5748911A (en) 1996-07-19 1998-05-05 Compaq Computer Corporation Serial bus system for shadowing registers
US5835725A (en) 1996-10-21 1998-11-10 Cisco Technology, Inc. Dynamic address assignment and resolution technique
JP3442593B2 (en) * 1996-11-20 2003-09-02 株式会社東芝 Network connection device and network connection method
US6170025B1 (en) * 1997-08-29 2001-01-02 Intel Corporation Distributed computer system supporting remote interrupts and lock mechanism
US6333929B1 (en) * 1997-08-29 2001-12-25 Intel Corporation Packet format for a distributed system
US6189063B1 (en) * 1997-09-30 2001-02-13 Texas Instruments Incorporated Method and apparatus for intelligent configuration register access on a PCI to PCI bridge
US5987555A (en) * 1997-12-22 1999-11-16 Compaq Computer Corporation Dynamic delayed transaction discard counter in a bus bridge of a computer system
US6032261A (en) * 1997-12-30 2000-02-29 Philips Electronics North America Corp. Bus bridge with distribution of a common cycle clock to all bridge portals to provide synchronization of local buses, and method of operation thereof
KR100592526B1 (en) * 1998-01-23 2006-06-23 소니 가부시끼 가이샤 Method of network configuration, method and apparatus for information processing, and computer-readable media
JP3277874B2 (en) * 1998-01-29 2002-04-22 日本電気株式会社 IEEE 1394 bridge
JP2000004256A (en) * 1998-04-17 2000-01-07 Toshiba Corp Stream data processing system and limiting method for stream data
US6308147B1 (en) * 1998-05-21 2001-10-23 Hewlett-Packard Company Data structure synthesis in hardware using memory transaction translation techniques
US6785274B2 (en) * 1998-10-07 2004-08-31 Cisco Technology, Inc. Efficient network multicast switching apparatus and methods
US6167492A (en) * 1998-12-23 2000-12-26 Advanced Micro Devices, Inc. Circuit and method for maintaining order of memory access requests initiated by devices coupled to a multiprocessor system
US6631415B1 (en) * 1999-03-19 2003-10-07 Sony Corporation Method and system for providing a communication connection using stream identifiers
WO2000065781A1 (en) 1999-04-23 2000-11-02 Sony Electronics Inc. Method of and apparatus for implementing and sending an asynchronous control mechanism packet

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5941964A (en) * 1992-05-21 1999-08-24 Intel Corporation Bridge buffer management by bridge interception of synchronization events
US5517494A (en) * 1994-09-30 1996-05-14 Apple Computer, Inc. Method and system of multicast routing for groups with a single transmitter
US5815668A (en) * 1995-03-17 1998-09-29 Nec Corporation Slave inter-lan connection device, an inter-lan connection system and a hot standby method of said inter-lan connection system
US6034964A (en) * 1996-06-11 2000-03-07 Hitachi, Ltd. Router device and network system using the same

Also Published As

Publication number Publication date
US6445711B1 (en) 2002-09-03
US7321592B2 (en) 2008-01-22
US20020167953A1 (en) 2002-11-14
AU4482000A (en) 2000-11-10

Similar Documents

Publication Publication Date Title
US6445711B1 (en) Method of and apparatus for implementing and sending an asynchronous control mechanism packet used to control bridge devices within a network of IEEE STD 1394 serial buses
US6389496B1 (en) Bridge including portals with ability to redefine network topology
JP4150258B2 (en) Selective data frame decimation in network devices
US7180904B2 (en) Interface link layer device to build a distributed network
US7013354B1 (en) Channel protocol for IEEE 1394 data transmission
EP0930747A1 (en) IEEE 1394 Serial bus system using a mapping table for identifying nodes having required capabilities to establish isochronous connections
US5748634A (en) Method and apparatus for implementing a two-port ethernet bridge using a semaphoring technique
US6539450B1 (en) Method and system for adjusting isochronous bandwidths on a bus
KR20010050287A (en) Information communication method and apparatus
US20020061025A1 (en) Data transmitting and receiving apparatus and data transmitting and receiving method
US6631415B1 (en) Method and system for providing a communication connection using stream identifiers
US6728821B1 (en) Method and system for adjusting isochronous bandwidths on a bus
EP1193612B1 (en) Handling bus packets within a node on a bus structure
US8582576B2 (en) Method of bus configuration to enable device bridging over dissimilar buses
US7251703B1 (en) Method of time stamping to enable device bridging over dissimilar buses
US6272114B1 (en) Data processing apparatus/method and electronic apparatus with such apparatus/method
EP1091523B1 (en) Speed converter for IEEE-1394 serial bus network
US20010044861A1 (en) Information processing apparatus, information processing method and bridge utilizing the same
US6993022B1 (en) Method of and apparatus for directly mapping communications through a router between nodes on different buses within a network of buses
US6502158B1 (en) Method and system for address spaces
JPH1155297A (en) Transmission medium connection device and storage medium
JPH0799833B2 (en) Data transmission method and device
JP2002111698A (en) Data transferring equipment, network system and data transferring method
JPH11215132A (en) Device and method for processing information and distribution medium
JP3296305B2 (en) Switching hub and communication method

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP