blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
3.11.4 RSVP/Routing Interface Connected: An Internet Encyclopedia
3.11.4 RSVP/Routing Interface

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2205
Up: 3. RSVP Functional Specification
Up: 3.11 RSVP Interfaces
Prev: 3.11.3 RSVP/Policy Control Interface
Next: 3.11.5 RSVP/Packet I/O Interface

3.11.4 RSVP/Routing Interface

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).


Next: 3.11.5 RSVP/Packet I/O Interface

Connected: An Internet Encyclopedia
3.11.4 RSVP/Routing Interface

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609