Papers /

Cheshire-IET F2010c

Reading

Outdoors

Games

Hobbies

LEGO

Food

Code

Events

Nook

sidebar

Cheshire-IET F2010c

Requirements for a Protocol to Replace AppleTalk NBP

Cheshire, Krochmal

zeroconf mdns slp service discovery multicast network configuration appletalk

@misc{cheshire:ietf-2010c,
  author={Stuart Cheshire and Marc Krochmal},
  title={Requirements for a Protocol to Replace {AppleTalk} {NBP}},
  series={Informational Internet Draft},
  number={draft-cheshire-dnsext-nbp-09},
  publisher={{IETF}},
  organization={{Internet Engineering Task Force}},
  year={2010},
  month={October},
  howpublished={\url{http://tools.ietf.org/id/draft-cheshire-dnsext-nbp-09.txt}},
}

Overviews AppleTalk's support for service discovery, outlines requirements for matching IP based service.

Replacing AppleTalk Name Binding Protocol was a primary motivation for mDNS and DNS-SD

AppleTalk considered by many to be too chatty

Goal of AppleTalk was designed to operate without any human dependency

Three necessary components for zeroconf

  • IP already has self-assigned link local addresses (RFC 2462, RFC 3927)
  • Name-to-address translation (mDNS)
  • Service discovery (DNS-SD)

Don't want to require all three to be in play at once

  • E.g., DNS-SD should work with regular DNS
  • mDNS and DNS should coexist, e.g., former to look up peers, latter Internet services

Need to get away from well-known ports

  • Only so many of them, rapidly used up
  • Hard to run multiple service instances; near impossible to demultiplex between two vendors' software
  • But also need to support people already doing that
    • E.g., print service instance running multiple queues, versus each queue being more directly its own service
      • Interface definition needs to support invoker making that differentiation

AppleTalk names consist of:

  • Name : Type @ Zone
    • Name is human readable label, defined within Type@Zone namespaces; should be/can be very descriptive
    • Type is simple label of the protocol, more or loosely connected to type of service
    • Zone is organizational or geographical grouping

On small networks AppleTalk NBP uses multicast; on larger networks routers aggregate and provide lookups

Name conflicts need to be detected and resolved

  • This must be an ongoing process given that devices go up and down all the time
  • There should be a local namespace that won't clash with the global network

Clients should not store services bindings for long

  • Keep the selected service name and lookup each time

Needs to be simple enough to work even on very low cost, limited hardware

Limited wildcard functionalit, e.g., "=:LaserWriter@My Zone" to find printers of all names (=) that support LaserWriter in My Zone.

Some meta-information is available to client

  • Available zones, for searching and registering
  • Default zone for browsing, which is also the suggested zone in which to register services

Low-power wake-on-messaging modes should be supported

Service discovery must be agnostic of service protocols and implementations

Distributed cache coherency protocol is required for efficiency

Browsing results should be given live, rather than having to be refreshed manually every couple seconds

SLP does not provide (human usable) service naming, automatic name conflict detection, or efficient name-to-address lookup

  • Domain names not human useful, and even then require a separate lookup service
  • SLP does provide very fine-grained query capability
    • Useful on large networks, but not as needed in small networks
Recent Changes (All) | Edit SideBar Page last modified on October 25, 2010, at 09:10 PM Edit Page | Page History