1 / 7

Update on Native HIP API Status and Future Work Plans

This document provides an overview of the current status of the Native HIP API, noting that there are no major changes but several minor corrections pending. It outlines the need for feedback on future work, including the potential of supporting addresses beyond IP in the API and the utility of the Enhanced Data (ED). The discussion touches on the API architecture, the value of moving current work to a Working Group (WG), and proposed research ideas for further development. Feedback on the usefulness of these ideas to prioritize next steps is welcomed.

dominy
Télécharger la présentation

Update on Native HIP API Status and Future Work Plans

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. Miika Komu <miika@iki.fi> Andrei Gurtov gurtov@cs.helsinki.fi Native HIP API

  2. Current Status • No major changes • Some minor corrections pending • Future work planned • We need some feedback before continuing

  3. Feedback Summary • Consider supporting also other addresses than IP in the API • The API architecture and Application Specified Host Identities seem to be interesting • Is the ED actually useful? Just use HITs? • This should not be in the RG (move to WG?)

  4. How to Proceed from Here? • Do you think that this work is useful? • Plain engineering: move to WG? • Some research ideas on the next slide… • Which of the ideas on the following slide do you find useful to proceed on? Feedback, please 

  5. How to Proceed: New Ideas • Opportunistic HIP may be difficult to implement using a standard sockets API • The EDs of the Native HIP API can make it easier • Alternatively, use Berkeley OCALA architecture (caveat: dependency to i3?) • Consider integration to Session or Service Layer identifiers? • Crazy idea: communicate EDs on-the-wire to support semantics similar to sctp_peeloff()?

  6. References • draft-mkomu-hip-native-api-00.txt • Applying a Cryptographic Namespace to Applications [Komu et al] • Application Programming Interfaces for Host Identity Protocol [Komu] • draft-henderson-hip-applications-01

  7. Questions / Feedback Miika Komu <miika@iki.fi> or <infrahip@hiit.fi>

More Related