(Speculative) 10GbE management, UDLR
Chuck Harrison <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Ladies & Gents, Please accept apologies if this posting is too far off topic or is better raised elsewhere. The motion picture production industry is in early stages of defining methods for moving high-resolution uncompressed image data between equipment (such as film-to-video scanners -- a.k.a. telecine -- and disk arrays). The desired data rates are typically in the 3 - 8 Gb/s range. Solutions based on anticipated availability of merchant-market 10Gb Ethernet may be attractive. Within today's postproduction facilities, data rates up to ~ 1.5 Gb/s are commonly handled with point-to-point coax links using SMPTE 292M modulation which is "framed" as a video raster and operates at 1.485 Gb/s. This is an HDTV standard and is strictly unidirectional from the source to the receiver. Unidirectional links can easily be "split" through distribution amplifiers and can be routed to multiple viewing monitors and destination equipment bays. It is common for some types of motion picture postproduction equipment to have Ethernet interaces for communications and control functions, separate from the datapath used for bulk video data. Some users have suggested that the low-cost 10/100/1000 Ethernet connection could be used to manage a separate unidirectional 10Gb/s transmitter or receiver which is dedicated to realtime video content. The attached file shows a highly speculative protocol stack for real-time operation of a telecine film scanner. The very bottom of the diagram is of concern here. Note that RFC3077 Unidirectional Link Routing is suggested for dividing traffic between the 10GbE and 10/100/1000 links. 802.3 bonding or "trunking" of multiple 10GbE links could be applied if it is necessary to scale to higher data rates. A 10GbE transceiver in full compliance with 802.3ae will not operate as a unidirectional transmitter, as the lack of light from a receive fiber will create a fault condition which is reflected out the transmit port. However, an implementation for this application might intentionally ignore the receive fault and transmit unidirectionally. I believe that SNMP management would be pertinent to such unidirectional ethernet implementations. RFC3077 proponents such as http://www.udcast.com/udlr/ may suggest other applications in which these management tools would be useful. Individuals who are interested in the motion picture postproduction interconnect problem may wish to contact the SMPTE N26 or DC28 committees, http://www.smpte.org/engineering_committees/ . Thank you for your attention. Cheers, Chuck Harrison Far Field Associates, LLC +1 360 863 8340 (voice) PDT = GMT-0700
TK-RTP.pdf
(application/pdf, 3.5 KB) - not displayed