1 / 14

IRIS and Application Transports

Andrew Newton <andy@hxr.us> CRISP Working Group 58 th IETF, Minneapolis, MN, USA November 12, 2003. IRIS and Application Transports. BEEP. IRIS currently specifies BEEP/TCP (RFC 3080/3081) as the “default” transport. Provides Framing, security framework, versioning, and much more...

ace
Download Presentation

IRIS and Application Transports

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. Andrew Newton <andy@hxr.us> CRISP Working Group 58th IETF, Minneapolis, MN, USA November 12, 2003 IRIS and Application Transports

  2. BEEP • IRIS currently specifies BEEP/TCP (RFC 3080/3081) as the “default” transport. • Provides • Framing, security framework, versioning, and much more... • The “full-service” application transport. • Explicitly specified by “iris.beep” URI scheme • Implicit for “iris” URI scheme as the fallback. • This presentation is NOT about replacing BEEP.

  3. The Open Door • Are we allowed to discuss other transports? • From our requirements: • “The protocol MUST define one or more congestion-aware transport mechanisms for mandatory implementation.”

  4. IRIS Transport Design • Iris-core specifically leaves room for more transports: • Nothing in or above the IRIS layer is “stateful” • Session state related to authentication/authorization is purposefully assigned to the application transport layer • Uses S-NAPTR • Specifies how to map additional URI schemes • Etc...

  5. A Survey of Possible Transports • Fast and Light UDP • Straight XML (iris-lwx) • GZIP compressed (iris-lwz) • Tokenized XML (iris-lwb) • Simple TCP-based • Straight XML (iris-tcp) • Secured with SSL/TLS (iris-tls) • HTTP-based • Layered directly on HTTP (iris-http) • SOAP (iris-soap)

  6. Fast and Light UDP • Fast and Light • But... • Does not lend itself towards long messages • Not good for stateful transactions (authorization) • No encryption/confidentiality/other security goodies • However, perfect for situations where no authentication is needed (anonymous access) and results are small.

  7. IRIS-LWZ • Compressed XML over UDP • XML -> GZIP -> UDP • Defines a simple XML wrapper • Profiles (similar to BEEP mechanism) • Client-specified UDP datagram sizes • See draft-newton-iris-lightweight

  8. A Sample IRIS-LWZ Request <lwzRequest • xmlns="urn:ietf:params:xml:ns:iris-lwz" • xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" • serverName="com" length="1280"> • <request xmlns="urn:ietf:params:xml:ns:iris1"> • <searchSet> • <dreg:findDomainsByContact • xmlns:dreg="urn:ietf:params:xml:ns:dreg1"> • <dreg:baseDomain>com</dreg:baseDomain> • <dreg:commonName> • <dreg:beginsWith> • The Cobbler Shoppe • </dreg:beginsWith> • </dreg:commonName> • <dreg:role>registrant</dreg:role> • </dreg:findDomainsByContact> • </searchSet> • </request> • </lwzRequest>

  9. A Sample IRIS-LWZ Response <lwzResponse • xmlns="urn:ietf:params:xml:ns:iris-lwz" • xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> • <response xmlns="urn:ietf:params:xml:ns:iris1"> • <resultSet> • <answer> • <domain • xmlns="urn:ietf:params:xml:ns:dreg1" • authority="com" registryType="dreg1" • entityClass="domain-handle" entityName="tcs-com-1" > • <domainName>thecobblershoppe.com</domainName> • <status> • <assignedAndActive denied="true" /> • </status> • </domain> • </answer> • </resultSet> • </response> • </lwzResponse>

  10. IRIS-LWX & IRIS-LWB • IRIS-LWX • Similar idea to IRIS-LWZ • XML -> UDP • IRIS-LWB • Instead of compression, XML is tokenized with WBXML. • XML Data -> WBXML -> UDP • WBXML can be faster than straight XML • But not namespace aware – simple wrapper may get bigger

  11. Simple TCP-based Transports • Straight layering of IRIS over TCP • XML -> TCP • Simple wrapping similar to iris-lwz • Will remind us of port 43 • Straight layering of IRIS over SSL/TLS • XML -> TLS -> TCP • The same as above, except inserts TLS • But no protocol advantages over BEEP

  12. HTTP-based • Issues with BCP 56 • Direct Layering over HTTP (iris-http) • Sounds simple but it is not • Using SOAP (iris-soap) • Technically not an app-transport • Issues with session semantics • But seemingly very popular • No protocol advantages over BEEP

  13. The Case for UDP • Advantages over BEEP when: • Access is anonymous • Result set can be squeezed into 512 to 1500 bytes • Do we have these situations today? • 95% of queries against whois.verisign-grs.com • 80% of queries against whois.arin.net • 80% of queries against whois.ripe.net • Average answer size of non-recursive answers for whois.nic.de is 1199 bytes

  14. The Case for UDP • Need for very fast domain name check • Many registries are deploying/planning deployment of very fast domain name check service • IRIS over UDP would be perfect for this • Either using 'dreg' • Or with a scaled-down version of 'dreg' like 'dchk'

More Related