[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sketchy laugh test: device discovery BOF

So I'm a little unclear where the boundary between device discovery and
service discovery lies. Maybe because I haven't read 802.1ab.
I don't think there is a lot of intrinsic difference -- other than the fact that link layer device discovery may need to occur prior to the availability of IP connectivity, and therefore occurs at layer 2. For example, IEEE 802.11 includes support for broadcast announcements (Beacons) as well as unicast discovery requests and responses (Probe Request/Response). Note that IEEE 802.11 discovery does nt include support for filtered queries, so that the Probe Responses can always be "canned".

The reason why I am somewhat suspicious on this is because the Bluetooth SIG
essentially took SLP and put it into Layer 2, making their specification
lots more complicated than it needed to be.
Haven't read this closely. Did they include filtered queries too?


but when it involves
attributes (as, apparently, 802.1ab does from your description below), it
seems like it might be shading over into service discovery.
LLDP, Cisco CDP, and IEEE 802.11 discovery support extensibility in some form. LLDP, CDP and DDP are broadcast announcements only; IEEE 802.11 supports probe request/response too. I think we move over the line into service discovery once we have the ability to do filtered queries.

Perhaps the intent of the BOF is to sort out these issues?



From the looks of it, the purpose is more to propose an alternative that 

runs over IP.  However there are important implications of running such a 
protocol over IP -- such as the fact that it might not be usable for 
discovery on links that aren't authenticated if dynamic addressing is 
required. Currently LLDP doesn't support use over unauthenticated links, but 
in the next revision, it might.



I'm not entirely clear that the IEEE 802.1ab problem statement is clear 
enough, let alone the DDP one.  For example, neither LLDP nor DDP include 
support for request/response, yet I'm told that IEEE is looking at creating 
yet another discovery protocol to handle the probe request/response 
functionality.

Logically, it would appear to me that the addition of request/response 
should not require design of a completely new protocol, just perhaps 
addition of an opcode.  So I'm looking for signs of coherent architecture 
here, but not finding them so far.



I have to admit that I do like aspects of the DDP design though -- such as 
the extensibility and separation of data from protocol. One could see for 
example, how additional opcodes could be added for request/response, or how 
the protocol could be extended for different purposes so as to satisfy 
multiple link technologies.  So it might be a contribution toward a more 
coherent approach.



Then again, given the past history of duplication of effort between IEEE and 
IETF, I'm probably just dreaming :)



_________________________________________________________________

Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail