An implementation of RSVP has been made by the University of Southern California Information Sciences Institute (ISI), which has a leading role2.4 in the development of RSVP. The last version (release 4.2a3) implements the RFC 2205 [#!RFC2205!#] except (mainly) traffic control, support of policy objects, complete integrity checks, multicast tunnelling. It is a 30,000 line C implementation.
It is obvious that I did not have time to implement the whole RSVP protocol. I therefore had to do some simplifications.
Some features could not be implemented. Until now, there is no implementation supporting policy object processing, because the IETF is still working on this field (although the Internet Draft defining policy control [#!RSVP_policy!#] pointed out by RFC 2205 [#!RFC2205!#] has not been updated and has now expired, it has been decided on 12 June 1998 to consider the creation of a new IETF working group called ``Policy Framework''). The checking of integrity objects would have also been too time consuming.
Implementing multicast would have been too long for several reason: multicast routing is much more complicated than unicast routing. Then the decisions that have to be taken during message processing are more complex as well. As my knowledge in multicasting is limited, I would not have had time to implement it.
As only IPv4 is used nowadays, IPv6 was not in the design goals, even if more and more systems already support it. However, an objective was to endeavour to use processing means suitable for IPv4 as well as IPv6.
No other simplification had been planned. As I might run short of time, I decided to first implement core functions in order to get a control architecture supporting the main features of RSVP as soon as possible.