1 / 5

IETF 57

IETF 57. Comparison of Protocols for Reliable Server Pooling <draft-ietf-rserpool-comp-06.txt> John Loughney. Changes. Updated CORBA section Updated DNS section Updated SLP section New L4/L7 Switching section Expanded ASAP & ENRP section. CORBA. Tightened text, in general.

jorden-park
Download Presentation

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