1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" 2 "http://www.w3.org/TR/1998/REC-html40-19980424/loose.dtd"> 3<HTML> 4 5<HEAD> 6<meta http-equiv="content-type" content="text/html; charset=utf-8"> 7<TITLE>How does Zeroconf compare with Viiv/DLNA/DHWG/UPnP?</TITLE> 8</HEAD> 9 10<BODY> 11 12<H1 align="center">How does Zeroconf compare with Viiv/DLNA/DHWG/UPnP?</H1> 13 14<div style="float: right; margin: 0px 10px 10px 20px; width:129px;"> 15<!-- Amazon Product: Zeroconf Book --> 16<p align="center"> 17<iframe src="https://rcm-na.amazon-adsystem.com/e/cm?t=zeroconfigurn-20&o=1&p=8&l=as1&asins=0596101007&nou=1&fc1=000000&IS2=1&lt1=_blank&lc1=0000ff&bc1=000000&bg1=ffffff&f=ifr" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe> 18</p> 19<!-- Amazon Product Search Electronics: axis network camera --> 20<p align="center"> 21<iframe src="https://rcm-na.amazon-adsystem.com/e/cm?t=zeroconfigurn-20&o=1&p=6&l=st1&mode=electronics&search=axis%20network%20camera&=1&fc1=&lt1=_blank&lc1=&bg1=&f=ifr" marginwidth="0" marginheight="0" width="120" height="150" frameborder="0" style="border:none;" scrolling="no"></iframe> 22</p> 23<p align="center"><!-- Google Adsense -->
24<script type="text/javascript"><!-- 25google_ad_client = "pub-2342864080724748"; 26google_ad_width = 120; 27google_ad_height = 600; 28google_ad_format = "120x600_as"; 29google_ad_type = "text_image"; 30google_ad_channel =""; 31google_color_border = "336699"; 32//--></script>
vendor: 1 bytes, line 32
32
33<script type="text/javascript" src="https://pagead2.googlesyndication.com/pagead/show_ads.js"> 34</script>
34 35</p> 36</div> 37 38<P>Taking the broadest view, the stories of Zeroconf and UPnP began with the same high-level observation: âWhy is IP networking so hard? Why canât it be like AppleTalk was in 1986, where you just plug things together and it all works automatically?â</P> 39 40<P>From this initial observation, the development of Zeroconf and UPnP then proceeded in different directions.</P> 41 42<P>Zeroconf is a very precisely defined, compact trio of industry-standard network technologies that work in concert to provide a reliable foundation for effortless networking. The word <i>foundation</i> in that sentence is significant. What vendors choose to build on top of that reliable foundation is largely up to the vendor in question. Zeroconf is mature, stable, and in certain product segments it is already very widely adopted. For example, virtually every network printer sold today, from every printer manufacturer, implements the Zeroconf protocol trio. In fact, if you install Appleâs free 43<!-- 44<a href="http://www.apple.com/support/downloads/ 45bonjourforwindows103.html">Bonjour for Windows</a> 46--> 47<a href="http://support.apple.com/downloads/Bonjour_for_Windows">Bonjour for Windows</a> 48on your Windows PC, you can discover for yourself how many of the network printers on your own company network already implement the Zeroconf protocols. In other product categories, like network-attached cameras, Zeroconf offers obvious benefits that leading vendors like <a href="http://www.axis.com/">Axis</a> have been quick to recognize. Thereâs no network product that doesnât benefit from incorporating the solid Zeroconf foundation, improving the usability and reliability of the product, resulting in simpler documentation, lower support costs, lower product returns, and higher customer satisfaction.</P> 49 50<P>In contrast, UPnP is an open-ended collection of device-specific protocols. As each new device type comes along, the UPnP Forum creates a new working group to talk about how that device type should work. UPnP claims adoption in many network devices, but in reality the adoption is more in name than in spirit. For example, many printers claim to implement UPnP, and indeed examining the network with a packet sniffer will show that the printer is sending UPnP SSDP packets, but Windows doesnât actually use those packets to discover, configure, or use the printer. This lack of any actual useful customer benefit is a common phenomenon in the UPnP world.</P> 51 52<P>A commonly asked question is, âWhy should we adopt Zeroconf instead of UPnP?â</P> 53 54<P>Phrased like this, the question is mis-stated in two ways.</P> 55 56<P>The first is that itâs not an either/or choice. Thereâs no reason a product canât do both. Thereâs no reason a product canât reap the tangible usability and reliability benefits of Zeroconf, while at the same time satisfying the marketing departmentâs requirement to put a sticker on the box saying âSupports UPnPâ. In fact, as explained below, the self-assigned link-local addressing layer is identical in Zeroconf and UPnP, so any product doing UPnP link-local addressing has already implemented the first of the three Zeroconf layers anyway.</P> 57 58<P>The second way the question is mis-stated is that âZeroconfâ and âUPnPâ are not directly comparable concepts. Zeroconf is a three-layer foundation which provides dependable IP networking in the absence of configuration information and infrastructure. UPnP is an organization, actively involved in the ongoing process of producing protocol specifications. Talking about âadopting UPnPâ is like proposing that it would be a good idea to âadopt ISOâ, or IEEE, or ANSI. When someone describes a product as implementing some protocol documented in an IETF RFC or Internet Draft, they say that it âimplements RFC xxxxâ, not that it âimplements IETFâ or that the company is âadopting IETF.â</P> 59 60<P>When people talk about âadopting UPnPâ they donât usually mean that their company has blindly committed to implement and support anything and everything that might come out of the UPnP organization. What they really mean is usually one of two things. Sometimes they mean that they have decided to adopt certain specific UPnP protocols, and theyâre assuming by context that itâs clear which specific UPnP protocols theyâre talking about. Other times — and sadly this is all too common — the person making the statement about âadopting UPnPâ is a high-level executive who knows nothing about network protocols. All he or she knows is that networking products are too hard to use, and someone said that proclaiming âwe support UPnPâ will make that problem disappear. The technical minutiae of deciphering what that statement actually means in concrete terms are beneath the executive — such boring details will be handled by some lowly engineer.</P> 61 62<P>Some people in the Viiv/DLNA/DHWG/UPnP community encourage this impression of an âeither/orâ choice by portraying Zeroconf and UPnP as incompatible competing technologies, perhaps mistakenly, or perhaps intentionally to create confusion. The truth is that Zeroconf and Viiv/DLNA/DHWG/UPnP (which from now on Iâll just refer to as âUPnPâ) only appear to be competing if you view them at a very superficial level. It would be more accurate and helpful to de
62scribe them as complementary.</P> 63 64<P>Zeroconf and UPnP are not really competing or contradictory; theyâre more orthogonal, in the sense of âunrelatedâ. Zeroconf went in a horizontal direction, creating a solid foundation suitable for all IP-based networking protocols. The UPnP Forum went in a vertical direction, creating specific vertical solutions aimed at solving specific vertical problems. For example, while the UPnP Forum is currently working on defining a new printing protocol (a laudable and worthy goal) Zeroconf created a reliable foundation upon which you can run <i>any</i> past, present, or future IP-based printing protocol. Zeroconf automates the TCP/IP configuration aspects of todayâs network printers, making it easy to discover those printers and establish a TCP connection to print to them using the LPR protocol or IPP; Zeroconf itself does nothing to remedy any deficiencies in the LPR protocol or in IPP. In an ideal world, Zeroconf would provide the dependable TCP/IP networking foundation that all networked devices so desperately need; other organizations like the UPnP Forum could then work on designing new application-layer protocols to supplement or supplant todayâs application-layer protocols where necessary. For example, just about every network printer today implements the full three-layer Zeroconf foundation (IPv4LL + mDNS + DNS-SD), and supports LPR printing. However, the LPR printing protocol lacks feature negotiation and has no status back-channel from the printer to tell the user about paper jams and so forth, and hence the time is ripe for some other, more capable, printing protocol to come along and establish itself as the new de jure or de facto printing standard.</P> 65 66<P>Itâs helpful at this stage to examine Zeroconfâs three-layer foundation, and compare that with the equivalents UPnP offers:</P> 67 68<table border="1" cellpadding="10" align="center" summary="UPnP compared to Zeroconf"> 69<COLGROUP> 70 <COL width="100"> 71 <!-- 10.4.4 Safari doesn't seem to work if you specify width 300 here --> 72 <COL width="20%"> <!-- so we use 20% instead --> 73 <COL width="1*"> 74</COLGROUP> 75 <tr> 76 <td> </td> 77 <td align="center">Zeroconf</td> 78 <td align="center">The UPnP Forumâs corresponding foundation layers</td> 79 </tr> 80 <tr> 81 <td>Addressing</td> 82 <td bgcolor="#C0FFC0">The IETF Zeroconf Working Group defined <a href="http://www.ietf.org/rfc/rfc3927.txt">RFC 3927</a>, âIPv4 Link-Local Addressingâ.</td> 83 <td bgcolor="#FFC0C0"><b>UPnPâs link-local addressing is exactly the same.</b> 84<BR>To be precise, the UPnP Forum originally adopted an early draft of the RFC, draft-ietf-zeroconf-ipv4-linklocal-01.txt, as can be seen in this <a href="http://web.archive.org/web/20040408095733/http://www.upnp.org/resources/specifications.asp">snapshot of the UPnP.org specification page as of April 2004</a> (courtesy of the <a href="http://www.archive.org/">Internet Archive</a> WayBack Machine). The draft-01 version lacks some refinements, but is completely compatible with the final protocol standardized by the IETF. The UPnP Forum later pulled the link from their web site, so itâs unclear whether they still feel they have any useful contribution to make regarding the crucial question of how a device is supposed to get itself an IP address.</td> 85 </tr> 86 <tr> 87 <td>Naming</td> 88 <td bgcolor="#C0FFC0">Zeroconf uses <a href="http://www.multicastdns.org/">Multicast DNS</a> to translate host names to addresses in the absence of a conventional unicast DNS server.</td> 89 <td bgcolor="#FFC0C0"><b>UPnP has no equivalent to mDNS.</b> 90<BR>Since the UPnP Forum was focussed on creating new vertical solutions, worrying about improving the usability of existing legacy tools that use host names (ping, telnet, ftp, ssh, etc.) was simply not a problem that UPnP sought to solve. In a UPnP world, if a developer wants to use ssh to connect to a UPnP device under development, the only way to do that is by typing in a raw dotted-decimal IP address, but since UPnP devices use randomly-assigned IPv4 Link-Local Addresses, and since you generally donât know what random address a device has picked for itself, trying to use raw addresses instead of a name lookup protocol is just not practical.</td> 91 </tr> 92 <tr> 93 <td>Discovery</td> 94 <td bgcolor="#C0FFC0">
94Building on its Multicast DNS foundation, Zeroconf adds <a href="http://www.dns-sd.org/">DNS Service Discovery</a> to discover what services are available on the network, providing the dependable Service Discovery thatâs the vital for a good user experience. For Zeroconf, Service Discovery is its <i>raison dâêtre</i>.</td> 95 <td bgcolor="#FFC0C0"><b>UPnP has no dependable Service Discovery protocol.</b> 96 <BR>For UPnP Forum members, the issue of Service Discovery, like the other foundation layers, was not a high priority. 97 It was merely a minor issue that had to be dispensed with before they could get to the more interesting work designing application-layer protocols. 98 For this layer, as with the addressing layer, the UPnP Forum chose to adopt an unfinished IETF draft. 99 However, unlike the addressing layer, where the design was eventually completed and published as a Standards-Track RFC, in the case of SSDP, the IETF draft was abandoned by its authors and never finished. 100 The last update to the SSDP (Simple Service Discovery Protocol) draft was 101 <!-- <a href="http://upnp.org/download/draft_cai_ssdp_v1_03.txt">draft-03</a> --> 102 <!-- <a href="http://tools.ietf.org/html/draft-cai-ssdp-v1-03">draft-03</a> --> 103 <a href="http://web.archive.org/web/20040404065126/www.upnp.org/download/draft_cai_ssdp_v1_03.txt">draft-03</a> 104 in October 1999. 105 A little technical analysis reveals some of the shortcomings that led to the proposal being abandoned: 106 <ul> 107 <li>Zeroconfâs mDNS-SD is more efficient on the network, using techniques like duplicate query suppression and known-answer suppression.</li> 108 <li>Zeroconfâs mDNS-SD is resilient to extended periods of packet loss (often a severe problem on Wi-Fi networks); SSDP is not.</li> 109 <li>Zeroconfâs mDNS-SD is simple and doesnât take a lot of code — itâs been implemented in devices with as little as 16 kilobytes of flash-based firmware, like the <a href="http://www.siteplayer.com/telnet/index.html">SitePlayer serial interface board</a>.</li> 110 <li>Zeroconfâs mDNS-SD uses multicast for both requests and responses, allowing it to function even in the face of many common home network misconfigurations, such as non-matching subnet numbers.</li> 111 </ul> 112 Solutions to the many problems with SSDP were never found, and the abandoned October 1999 draft on the UPnP Forum web site is still full of little editorial ânote to selfâ comments in square brackets. 113 One of the problems that the authors recognized was that if you had more than about ten devices on a network using SSDP, it would rapidly become far too chatty, and one of these little ânote to selfâ comments points out this deficiency: 114<PRE>6.1. Problem Statement 115 116 A mechanism is needed to ensure that SSDP does not cause such a high 117 level of traffic that it overwhelms the network it is running on. 118 1196.2. Proposed Solution 120 121 [Ed. Note: We have a proposed solution but it is still a bit rough, 122 so we will be publishing to the SSDP mailing list for further 123 discussion before including it in the draft.]</PRE> 124 Itâs also noteworthy that <a href="http://goland.org/">Yaron Goland</a>, designer of SSDP and Microsoftâs original lead UPnP architect, gave an endorsement for the âPraise for this Bookâ page in OâReillyâs <a href="https://www.amazon.com/exec/obidos/redirect?path=ASIN%2F0596101007&link_code=as2&camp=1789&tag=zeroconfigurn-20&creative=9325">Zero Configuration Networking: The Definitive Guide</a><img src="http://www.assoc-amazon.com/e/ir?t=zeroconfigurn-20&l=as2&o=1&a=0596101007" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;">.</td> 125 </tr> 126 <tr> 127 <td>Application</td> 128 <td bgcolor="#C0FFC0">Zeroconf is completely agnostic with regard to application-layer protocols. Whatever application-layer protocol you currently use today, or have in mind for the future, the three-layer Zeroconf foundation provides the reliable IP networking you want.</td> 129 <td bgcolor="#FFFFC0">Application-layer protocols are UPnPâs primary focus. If UPnP already defines the particular application-layer protocol your device needs, then you should evaluate that application-layer protocol and make an informed decision about whether you want to use it. If you plan to use some other existing application-layer protocol, or design your own new application-layer protocol, then UPnP has nothing to offer you (except perhaps as a possible venue for forming a new committee to talk about the problem).</td> 130 </tr> 131</table> 132 133<P>The sensible conclusion is that device designers wanting to make reliable products should use Zeroconf as their foundation, and then on top of that, run whatever application protocols are appropriate (possibly including UPnP application-layer protocols, if UPnP offers any that are a sensible choice).</P> 134 135<P>In summary:</P> 136 137<UL> 138 139<LI>Implementing <i>IPv4 Link-Local Addressing</i> is an easy decision, because both Zeroconf and UPnP are identical at that layer.</LI> 140 141<LI>Implementing <i>Multicast DNS</i> is an easy decision, because UPnP doesnât have any alternative to offer.</LI> 142 143<LI>The only area of overlap is the service discovery layer, and itâs important to remember that mDNS-SD and SSDP are not mutually exclusive. Device designers donât have to choose between one and the other. If a device offers certain services via certain application-layer protocols, it can advertise those services via both SSDP and via mDNS-SD, and let the marketplace determine which works most reliably. Thereâs really n
143o sense in making a great product, and then have it die in the marketplace, as so many have over the last five years, because SSDP — an insignificant part of what the product does — let it down.</LI> 144 145</UL> 146 147<P>The related conclusion here is that if youâre not implementing some existing UPnP application-layer protocol, but instead youâre building a new product or designing a new application-layer protocol of your own, then deciding to build your new application-layer protocol on a UPnP foundation would be a truly nonsensical decision, because UPnP isnât a foundation; itâs an organization devoted to producing a few narrowly defined vertical solutions in specific problem spaces.</P> 148 149<HR> 150<address> 151Page maintained by <A HREF="http://www.stuartcheshire.org/">Stuart Cheshire</A> 152</address> 153
154<script type="module" src="https://static.cloudflareinsights.com/beacon.min.js/v31edd6df95cf4e85bb4c19e7a9bdbcba1788362987495" integrity="sha512-iIg7k2xntmwu6/uSb5tpc/hySgZc4eoL31yB29W6tJFo2akwjPWcEqnCEdJvGexCL0KEQwVYv5BlowfhVz26hg==" data-cf-beacon='{"version":"2024.11.0","token":"d796e1804e1f4b58b96831a20b54e20e","r":1,"spa":2}' crossorigin="anonymous"></script>
154 155</BODY> 156 157</HTML>
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.