FYI: eXtensible Service Discovery Framework (XSDF)

Hi all,

As detailed in the rserpool-comparison draft, Rserpool architecture has
many similarities with the SLP one (DA<->ENRP Server, SA<->PE, UA<->PU),
although SLPv2 cannot be employed to fulfill all Rserpool requirements.

However, I've been studying this solution space, and I've designed an
evolution of SLPv2, called XSDF. Among other things, XSDF tries to be
compliant with the Rserpool requirements related to PE location and
selection. Therefore, XSDF tries to integrate service discovery and load
balancing in a single process.

XSDF is collection of 4 protocols designed to locate, register and keep
in sync Service information, including load balancing data. XSLP is
employed by UAs (PUs) to query DAs (ENRP Servers) for Service
information. SAs (PEs) employ XSRP to register its Service information
at DAs (then, ASAP = XSLP + XSRP + failover). XSSP and XSTP are employed
to keep DAs in sync (thus, ENRP = XSSP + XSTP).

XSDF provides several enhancements over SLP, as an extensible service
model, and remote service discovery capabilities. However, I think it
may also have some capabilities that could be useful for Rserpool:

- Service information may include some attributes to allow PUs to select
the better PE from the Pool, as in current Rserpool specifications.
However, in XSDF, PEs may also specify load balancing parameters when
registering a Service at an ENRP server. In that case, the ENRP server
performs a selection process when queried by a PU, and returns the list
of available PEs to the PU, sorted by preference. Also, both selection
processes may be combined, for example the ENRP servers may apply a
Least Used policy (that needs up-to-date info, from local LAN), while
the end PU (over a WAN link), just knows an alternative backup server.

- All XSDF entities, including DAS, are themselves Services. Therefore,
they may also benefit from its load balancing capabilities. For example,
when an ENRP server (DA) boots, it could choose the least loaded
"Mentor" peer to get Pool/Realm information.

I've just submitted several drafts covering XSDF, and I will be very
interested in your comments about them:

http://www.ietf.org/internet-drafts/draft-uruena-xsdf-overview-00.txt
http://www.ietf.org/internet-drafts/draft-uruena-xsdf-common-00.txt
http://www.ietf.org/internet-drafts/draft-uruena-xslp-00.txt
http://www.ietf.org/internet-drafts/draft-uruena-xsrp-00.txt
http://www.ietf.org/internet-drafts/draft-uruena-xssp-00.txt
http://www.ietf.org/internet-drafts/draft-uruena-xstp-00.txt
http://www.ietf.org/internet-drafts/draft-uruena-xbe32-00.txt

The xsdf-overview draft resumes the whole thing in just 20 pages. 
If you are interested in a particular protocol, they are specified in
separate drafts, while xsdf-common contains the elements and procedures
shared by all of them. At last, the xbe32 one defines the binary
encoding for XSDF messages.

Thank you very much for your time !

Best regards,
--Manuel

-- 
Manuel Uruen~a - Universidad Carlos III de Madrid
GPG FP: 68A1 164B EE28 52C9 87CB  EBF9 616E 52B5 451A B6B2

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBAYyVVYW5StUUatrIRAo2+AJ9xGUPSRBqrqVHWQZAJV6KsLta4BwCgisbT
heHZw5PyDYEvBeq7odJnpo8=
=WyWn
-----END PGP SIGNATURE-----