blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
3.1.4 Resv Messages Connected: An Internet Encyclopedia
3.1.4 Resv Messages

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2205
Up: 3. RSVP Functional Specification
Up: 3.1 RSVP Message Formats
Prev: 3.1.3 Path Messages
Next: 3.1.5 Path Teardown Messages

3.1.4 Resv Messages

3.1.4 Resv Messages

Resv messages carry reservation requests hop-by-hop from receivers to senders, along the reverse paths of data flows for the session. The IP destination address of a Resv message is the unicast address of a previous-hop node, obtained from the path state. The IP source address is an address of the node that sent the message. The Resv message format is as follows:

           <Resv Message> ::= <Common Header> [ <INTEGRITY> ]

                                   <SESSION>  <RSVP_HOP>

                                   <TIME_VALUES>

                                   [ <RESV_CONFIRM> ]  [ <SCOPE> ]

                                   [ <POLICY_DATA> ... ]

                                   <STYLE> <flow descriptor list>

           <flow descriptor list> ::=  <empty> |

                            <flow descriptor list> <flow descriptor>

If the INTEGRITY object is present, it must immediately follow the common header. The STYLE object followed by the flow descriptor list must occur at the end of the message, and objects within the flow descriptor list must follow the BNF given below. There are no other requirements on transmission order, although the above order is recommended.

The NHOP (i.e., the RSVP_HOP) object contains the IP address of the interface through which the Resv message was sent and the LIH for the logical interface on which the reservation is required.

The appearance of a RESV_CONFIRM object signals a request for a reservation confirmation and carries the IP address of the receiver to which the ResvConf should be sent. Any number of POLICY_DATA objects may appear.

The BNF above defines a flow descriptor list as simply a list of flow descriptors. The following style-dependent rules specify in more detail the composition of a valid flow descriptor list for each of the reservation styles.

  • WF Style:

                    <flow descriptor list> ::=  <WF flow descriptor>
    
                    <WF flow descriptor> ::= <FLOWSPEC>
    

  • FF style:

                    <flow descriptor list> ::=
    
                              <FLOWSPEC>  <FILTER_SPEC>  |
    
                              <flow descriptor list> <FF flow descriptor>
    
                    <FF flow descriptor> ::=
    
                              [ <FLOWSPEC> ] <FILTER_SPEC>
    

    Each elementary FF style request is defined by a single (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests may be packed into the flow descriptor list of a single Resv message. A FLOWSPEC object can be omitted if it is identical to the most recent such object that appeared in the list; the first FF flow descriptor must contain a FLOWSPEC.

  • SE style:

                    <flow descriptor list> ::= <SE flow descriptor>
    
                    <SE flow descriptor> ::=
    
                                           <FLOWSPEC> <filter spec list>
    
                    <filter spec list> ::=  <FILTER_SPEC>
    
                                      |  <filter spec list> <FILTER_SPEC>
    

The reservation scope, i.e., the set of senders towards which a particular reservation is to be forwarded (after merging), is determined as follows:

  • Explicit sender selection

    The reservation is forwarded to all senders whose SENDER_TEMPLATE objects recorded in the path state match a FILTER_SPEC object in the reservation. This match must follow the rules of Section 3.2.

  • Wildcard sender selection

    A request with wildcard sender selection will match all senders that route to the given outgoing interface.

    Whenever a Resv message with wildcard sender selection is forwarded to more than one previous hop, a SCOPE object must be included in the message (see Section 3.4 below); in this case, the scope for forwarding the reservation is constrained to just the sender IP addresses explicitly listed in the SCOPE object.

    A Resv message that is forwarded by a node is generally the result of merging a set of incoming Resv messages (that are not blockaded; see Section 3.5). If one of these merged messages contains a RESV_CONFIRM object and has a FLOWSPEC larger than the FLOWSPECs of the other merged reservation requests, then this RESV_CONFIRM object is forwarded in the outgoing Resv message. A RESV_CONFIRM object in one of the other merged requests (whose flowspecs are equal to, smaller than, or incomparable to, the merged flowspec, and which is not blockaded) will trigger the generation of an ResvConf message containing the RESV_CONFIRM. A RESV_CONFIRM object in a request that is blockaded will be neither forwarded nor returned; it will be dropped in the current node.


Next: 3.1.5 Path Teardown Messages

Connected: An Internet Encyclopedia
3.1.4 Resv Messages

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 Elephant1999, 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