Some NSIS messages have to be addressed end-to-end but
intercepted at intermediate routers, and this imposes some
special constraints on how they can be encapsulated.  RSVPv1
[9] primarily uses raw IP with a specific protocol number
(46); a UDP encapsulation is also possible for hosts unable
to perform raw network i/o.  RSVP aggregation [15] uses an
additional protocol number (134) to bypass certain interior
   nodes.  

The critical requirements for the encapsulation at this
level are that routers should be able to identify signaling
packets for processing, and that they should not
mis-identify packets for 'normal' end-to-end user data flows
as signaling packets.  The current assumption is that UDP
encapsulation can be used for such messages, by allocating
appropriate (new) value codes for the router alert option
(RAO) [1][4] to identify NSIS messages.  Specific open
issues about how to allocate such values are discussed in
Section 9.4.

An alternative approach would be to use raw IP with the RSVP
protocol numbers and a new RSVP version number.  Although
this would provide some more commonality with existing RSVP
implementations, the NAT traversal problems for such an
encapsulation seem much harder to solve.  Specifically, any
unmodified NAT (which performed address sharing) would be
unable to process any such traffic since they need to
understand a higher-layer field (such as TCP or UDP port) to
use as a demultiplexer.