3.11.4 RSVP/Routing Interface

An RSVP implementation needs the following support from the routing mechanisms of the node.

• Route Query

  To forward Path and PathTear messages, an RSVP process must be able to query the routing process(s) for routes.

                   Ucast_Route_Query( [ SrcAddress, ] DestAddress,
  
                                       Notify_flag ) -> OutInterface
  
                   Mcast_Route_Query( [ SrcAddress, ] DestAddress,
  
                                       Notify_flag )
  
                                   -> [ IncInterface, ] OutInterface_list
  

  Depending upon the routing protocol, the query may or may not depend upon SrcAddress, i.e., upon the sender host IP address, which is also the IP source address of the message. Here IncInterface is the interface through which the packet is expected to arrive; some multicast routing protocols may not provide it. If the Notify_flag is True, routing will save state necessary to issue unsolicited route change notification callbacks (see below) whenever the specified route changes.

  A multicast route query may return an empty OutInterface_list if there are no receivers downstream of a particular router. A route query may also return a `No such route' error, probably as a result of a transient inconsistency in the routing (since a Path or PathTear message for the requested route did arrive at this node). In either case, the local state should be updated as requested by the message, which cannot be forwarded further. Updating local state will make path state available immediately for a new local receiver, or it will tear down path state immediately.

• Route Change Notification

  If requested by a route query with the Notify_flag True, the routing process may provide an asynchronous callback to the RSVP process that a specified route has changed.

                   Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
  
                                                  OutInterface
  
                   Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
  
                                 [ IncInterface, ] OutInterface_list
  

• Interface List Discovery

  RSVP must be able to learn what real and virtual interfaces are active, with their IP addresses.

  It should be possible to logically disable an interface for RSVP. When an interface is disabled for RSVP, a Path message should never be forwarded out that interface, and if an RSVP message is received on that interface, the message should be silently discarded (perhaps with local logging).