An incomplete implementation

Because the complete RSVP protocol was too long to be implemented completely during this project, I had to choose how to reduce the implementation in a sensible way. That is why I decided to do several simplifications from the beginning (see section ).

I implemented the processing of the messages and the different states little by little, only when I needed to use them. As I did not want to support multicast addresses, I was not forced to implement all the styles, and therefore this would reduce considerably the implementation of Resv and Resv Teardown messages.

However, I wanted the implementation to be in such a state that it would be easy to complete it, either by me if I had extra time at the end of the project or by another person.

Although FF style support would have been sufficient for unicast sessions, adding support for WF and SE styles afterwards would have forced to rewrite a large part of the code. That is why I chose to process the different messages in the most general way, implementing from the beginning support the the three different styles and merging capabilities.

The code missing in the message processing routines are hence the parts of code calling multicast routing methods and explicit multicast addresses processing.

Still pursuing this goal, I endeavoured to write methods independent from the length of IP addresses, in such a way that adapting the code to run RSVP using IPv6 addresses would not be very painful.

Finally, I precisely documented all the code, using javadoc's format, so that anybody wanting to understand how the RSVP process works could do so.

Unfortunately, implementing a well-documented generic code for all the reservation styles did not leave me any time to implement the blockade state related operations, and therefore the processing of Resv Error messages. I did not have time to deal with the sending of Confirmation messages either.