1 / 5

Comparison of Protocols for Reliable Server Pooling: Insights and Updates from IETF 57

This document provides a comprehensive comparison of various protocols used for Reliable Server Pooling (RSerPool), detailing key updates and changes from the IETF 57 meeting. It covers advancements in the CORBA, DNS, SLP, and ASAP/ENRP sections, emphasizing CORBA's role as an application service in high-availability middleware. The document also discusses new insights on L4/L7 switching, identifying the need for standard protocols for switch communications, enhanced registration services, and the limitations of proprietary technologies in supporting robust, scalable, and transparent clustering solutions.

jorden-park
Télécharger la présentation

Comparison of Protocols for Reliable Server Pooling: Insights and Updates from IETF 57

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 57 Comparison of Protocols for Reliable Server Pooling <draft-ietf-rserpool-comp-06.txt> John Loughney

  2. Changes • Updated CORBA section • Updated DNS section • Updated SLP section • New L4/L7 Switching section • Expanded ASAP & ENRP section

  3. CORBA • Tightened text, in general. • Added text about CORBA being an application service in an HA middleware stack and not a communications service. • In a conceptual model of a middleware stack for highly available clustering, CORBA is considered an application service and not a messaging or clustering service. A distributed application may utilize a CORBA ORB for location transparency at the application layer, and the ORB may in turn utilized RSerPool for its communications layer.

  4. DNS / SLP / ASAP / ENRP • Minor changes: • DNS – more text about needs in RserPool for handle to address resolution. • SLP – improved text • Updated ASAP / ENRP sections

  5. L4/L7 Switching • Got feedback from many sources that RserPool should consider this. • Summary: • Inadequate support for naming, as well as registration and deregistration services. • Need to define a standard protocol to allow the switches to communicate amongst themselves and, perhaps, implement a co-resident name server on the switch. • Deploy middle boxes as opposed to end-devices / peer-to-peer model. • Usually requires specialized hardware. • Lacks the ability to provide a robust framework for location transparent clustering capable of scaling in size and performance. • Proprietary technology. • Often service specific.

More Related