NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
Dan Zigmond <djz@corp.webtv.net>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Thomas Narten <narten@raleigh.ibm.com>
Mailing Lists:
General Discussion:ipvbi@corp.webtv.net
To Subscribe: ipvbi-request@corp.webtv.net
In Body: subscribe/unsubscribe ipvbi [email_address]
Archive:
Description of Working Group:
IP can be carried by many physical mechanisms. The vertical blanking interval of analog television signals (or VBI) is one more of these with the characteristic that it is unidirectional. It may therefore be only suitable for UDP/IP or multicast applications at present or we may build on this as other internet protocols are enhanced to allow unidirectional operation. A number of companies have already enhanced the functionality (in layers above the NABTS or WST, the two byte encoding standards for VBI) to include FEC, conditional access, encryption, file transfer etc, but each in a proprietary and incompatible way. This is a disincentive for systems to grow, and for the VBI to become widely used as a data transport mechanism.
The broadcast industry is turning to digital TV, which will offer many Mbps broadcast data capacity, but this technology is in its infancy and still not widely available at the right price. VBI may therefore be viewed as an intermediate system (using well known, low cost and currently operating - for more than 10 years - technology) which will serve the data broadcast industry for a few years yet and probably for very many years in the less advanced countries - most countries actually. Sure the data rate is lower, but so is the cost. We already have transmissions, test equipment, test software, decoding software and chipsets. All we are talking of doing is upgrading the software to do a bit more.
The reason for carrying IP is that it is a commonly available well known format to build on. The data broadcast industry then does not have to re-invent the wheel to use higher level protocols, but can simply layer existing protocols on IP. We expect IP and non-IP traffic to co-exist on VBI initially, but as the higher levels of internet are defined for broadcast use the IP traffic would dominate.
The IPVBI group will define a standard mechanism for transmitting IP datagrams on top of both NABTS and WST VBI formats. The standard will include framing mechanisms, header compression, and an FEC system, all based on existing IETF standards where possible. Protocols above the IP layer (like streaming media and broadcast file transfer) will not be considered by IPVBI.
Goals and Milestones:
Mar 98 |
|
First drafts of IP over WST/NABTS submitted as Internet-Draft |
Jun 98 |
|
Second draft of IP over WST/NABTS submitted as Internet-Draft |
Aug 98 |
|
Meet at Chicago IETF |
Sep 98 |
|
Post final version of IP over WST/NABTS as Internet-Draft |
Oct 98 |
|
Submit IP over WST/NABTS to IESG for consideration as a Proposed Standard |
Dec 98 |
|
Meet in Orlando to gather implementation information |
Dec 98 |
|
reassess status of WG: recharter or shutdown |
No Current Internet-Drafts
No Request For Comments
Minutes of the IP over VBI (ipvbi) Working Group
Chairperson: Dan Zigmond
Minutes taken by: Ruston Panabaker
Attendees: See official roster
Agenda presented by chair with no objections or additions.
I. Process Overview
Reviewed by chair. A question raised concerning the status of the WG, which was clarified by Thomas Narten, IESG representative, by explaining we are chartered and can proceed as a WG.
II. FEC Issues
Ruston P gives explanation of the FECs currently published in drafts, explaining that the new draft by Trevor Dee is completely compatible to that proposed by Microsoft, but with an alternative description which allows single and double bit error detection and correction. The Thorn draft for WST is a very similar RS FEC which is not currently compatible to the Norpak FEC, but could be made so without changing FEC performance in WST systems.
Simon W suggested Phillips chose FEC due to lack of commercially available FEC at the time of publishing, and that Phillips claims to have no strong feelings about which FEC version is used.
IOR reminded group of a second choice of FEC in WST systems, which is there own. This FEC is not published at this time. IOR reminds group that FEC is most important aspect of protocol due to large number of systems which will be excluded if FEC performance is not sufficient. IOR requests testing of
FECs.
Norpak comments on the widespread use of their FEC in industry. There is a reminder from Simon W of the timeliness of VBI data, and the need to proceed with standardization. General consensus to this by the group.
Action taken by Ruston P to provide as much data as possible concerning BER, Packet loss rate, and any other relevant info concerning real world FEC performance.
Interleaving at FEC level was agreed to be ineffective in testing.
III. Header Compression
Slide by chair suggesting existing IETF work be examined concerning UDP/IP header compression. Concern in the group that supporting multiple compression schemes will result in market fragmentation.
A suggesting for an MTU of 1500 (the same as Ethernet) was made. Another suggestion made that an MTU of less then 1500 would result in high rate of packet fragmentation.
Action suggested to create MTU. No takers. Suggested that discussion on mailing list take place regarding MTU.
IV. Packet Addresses
Noted that there is a lack of standard for using NABTS packet group addresses. Also noted that there is a need for one.
Microsoft suggests at least a best practices section in standard.
Noted that Europe is a different story from north America.
Suggested that broadcasters could strip VBI and regenerate PGAs. Noted that this would add cost and complication to system.
Action taken by Dan Z to propose a regenerator style model for PGAs.
V. NABTS/WST/525/625
Noted that only Norpak uses NABTS on 625 line systems.
WST cannot be used on 525 line systems due to bandwidth constraints.
Legal and law issues discussed due to concern that some countries would not allow NABTS to be used.
Suggested that having two standards for 625 line systems would fragment the market.
Concern from Microsoft and Phillips that service discovery would be complicated if not impossible. Concern that NABTS and WST could not be decoded simultaneously, thus not allowing multiple services to be decoded at once.
Action by Norpak to provide arguments for NABTS on 625 line systems.
VI. Wrap-up
Consensus to make one doc going forward which includes both 525 and 625 line systems.
Consensus to have informal meeting on Wednesday in which questions can be asked, FEC compared, and header compression examined.
None Received