rfc2209.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/4 页

        o    Insert TIME_VALUES object into the PATH message being
             built.  Compute the IP TTL for the PATH message as one less
             than the TTL value received in the message.  However, if
             the result is zero, return without sending the PATH
             message.

        o    Create a sender descriptor containing the SENDER_TEMPLATE,
             SENDER_TSPEC, and POLICY_DATA objects, if present in the
             PSB, and pack it into the PATH message being built.



Braden & Zhang               Informational                     [Page 19]

RFC 2209                RSVP-Message Processing           September 1997


        o    Send a copy of the PATH message to each interface OI in
             OutInterface_list.  Before sending each copy:

             1.   If the PSB has the E_Police flag on and if interface
                  OI is not capable of policing, turn the E_Police flag
                  on in the PATH message being built.

             2.   Pass the ADSPEC object and Non_RSVP flag present in
                  the PSB to the traffic control call TC_Advertise.
                  Insert the modified ADSPEC object that is returned
                  into the PATH message being built.

             3.   Insert into its PHOP object the interface address and
                  the LIH for the interface.

   RESV REFRESH

        This sequence sends a reservation refresh towards a particular
        previous hop with IP address PH.  This sequence may be entered
        by the expiration of a refresh timer, or invoked from the PATH
        MESSAGE ARRIVES, RESV MESSAGE ARRIVES, RTEAR MESSAGE ARRIVES, or
        RERR MESSAGE ARRIVES sequence.

        In general, this sequence considers each of the PSB's with PHOP
        address PH.  For a given PSB, it scans the TCSBs for matching
        reservations and merges the styles, FLOWSPECs and
        Filter_spec_list's appropriately.  It then builds a RESV message
        and sends it to PH.  The details depend upon the attributes of
        the style(s) included in the reservations.

        Initially the Need_Scope flag is off and the new_SCOPE object is
        empty.

        o    Create an output message containing INTEGRITY (if
             configured), SESSION, RSVP_HOP, and TIME_VALUES objects.

        o    Determine the style for these reservations from the first
             RSB for the session, and move the STYLE object into the
             proto-message.  (Note that the present set of styles are
             never themselves merged; if future styles can be merged,
             these rules will become more complex).

        o    If style is wildcard and if there are PSB's from more than
             one PHOP and if the multicast routing protocol does not use
             shared trees, set the Need_Scope flag on.






Braden & Zhang               Informational                     [Page 20]

RFC 2209                RSVP-Message Processing           September 1997


        o    Select each sender PSB whose PHOP has address PH.  Set the
             local flag B_Merge off and execute the following steps.

             1.   Select all TCSB's whose Filter_spec_list's match the
                  SENDER_TEMPLATE object in the PSB and whose OI appears
                  in the OutInterface_list of the PSB.

             2.   If the PSB is from the API, then:

                  -    If TCSB contains a CONFIRM object, then create
                       and send a RACK message containing the object and
                       delete the CONFIRM object from the TCSB.

                  -    Continue with next PSB.

             3.   If B_Merge flag is off then ignore a blockaded TCSB,
                  as follows.

                  -    Select BSB's that match this TCSB.  If a selected
                       BSB is expired, delete it.  If any of the
                       unexpired BSB's has a Qb that is not strictly
                       larger than TC_Flowspec, then continue processing
                       with the next TCSB.

                  However, if steps 1 and 2 result in finding that all
                  TCSB's matching this PSB are blockaded, then:

                  -    If this RESV REFRESH sequence was invoked from
                       RESV ERROR RECEIVED, then return to the latter.

                  -    Otherwise, turn on the B_Merge flag and restart
                       at step 1, immediately above.

             4.   Merge the flowspecs from this set of TCSB's, as
                  follows:

                  -    If B_Merge flag is off, compute the LUB over the
                       flowspec objects.  From each TCSB, use the
                       Fwd_Flowspec object if present, else use the
                       normal Flowspec object.











Braden & Zhang               Informational                     [Page 21]

RFC 2209                RSVP-Message Processing           September 1997


                       While computing the LUB, check for a RESV_CONFIRM
                       object in each TCSB.  If a RESV_CONFIRM object is
                       found:

                       -    If the flowspec (Fwd_Flowspec or Flowspec)
                            in that TCSB is larger than all other (non-
                            blockaded) flowspecs being compared, then
                            save this RESV_CONFIRM object for forwarding
                            and delete from the TCSB.

                       -    Otherwise (the corresponding flowspec is not
                            the largest), create and send a RACK message
                            to the address in the RESV_CONFIRM object.
                            Include the RESV_CONFIRM object in the RACK
                            message.  The RACK message should also
                            include an ERROR_SPEC object whose
                            Error_Node parameter is IP address of OI
                            from the TCSB and specifying "No Error".

                       -    Delete the RESV_CONFIRM object from the
                            TCSB.

                  -    Otherwise (B_Merge flag is on), compute the GLB
                       over the Flowspec objects of this set of TCSB's.

                  While computing the GLB, delete any RESV_CONFIRM
                  object object in any of these TCSB's.

             5.   (All matching TCSB's have been processed).  The next
                  step depends upon the style attributes.

                  Distinct reservation (FF) style

                       Use the Sender_Template as the merged
                       FILTER_SPEC.  Pack the merged (FLOWSPEC,
                       FILTER_SPEC, F_POLICY_DATA) triplet into the
                       message as a flow descriptor.

                  Shared wildcard reservation (WF) style

                       There is no merged FILTER_SPEC.  Merge (compute
                       the LUB of) the merged FLOWSPECS from the TCSB's,
                       across all PSB's for PH.








Braden & Zhang               Informational                     [Page 22]

RFC 2209                RSVP-Message Processing           September 1997


                  Shared distinct reservation (SE) style

                       Using the Sender_Template as the merged
                       FILTER_SPEC, form the union of the FILTER_SPECS
                       obtained from the TCSB's.  Merge (compute the LUB
                       of) the merged FLOWSPECS from the TCSB's, across
                       all PSB's for PH.

             6.   If the Need_Scope flag is on and the sender specified
                  by the PSB is not the local API:

                  -    Find each RSB that matches this PSB, i.e., whose
                       Filter_spec_list matches Sender_Template in the
                       PSB and whose OI is included in
                       OutInterface_list.

                  -    If the RSB either has no SCOPE list or its SCOPE
                       list includes the sender IP address from the PSB,
                       insert the sender IP address into new_SCOPE.

        o    (All PSB's for PH have been processed).  Finish the RESV
             message.

             1.   If Need_Scope flag is on but new_SCOPE is empty, no
                  RESV message should be sent; return.  Otherwise, if
                  Need_Scope is on, move new_SCOPE into the message.

             2.   If a shared reservation style is being built, move the
                  final merged FLOWSPEC object and filter spec list into
                  the message.

             3.   If a RESV_CONFIRM object was saved earlier, move it
                  into the new RESV message.

             4.   Set the RSVP_HOP object in the message to contain the
                  IncInterface address through which it will be sent and
                  the LIH from (one of) the PSB's.

        o    Send the message to the address PH.

   ROUTE CHANGE NOTIFICATION

        This sequence is triggered when routing sends a route change
        notification to RSVP.

        o    Each PSB is located whose SESSION matches the destination
             address and whose SENDER_TEMPLATE matches the source
             address (for multicast).



Braden & Zhang               Informational                     [Page 23]

RFC 2209                RSVP-Message Processing           September 1997


             1.   If the OutInterface_list from the notification differs
                  from that in the PSB, execute the PATH LOCAL REPAIR
                  sequence.

             2.   If the IncInterface from the notification differs from
                  that in the PSB, update the PSB.

   PATH LOCAL REPAIR

        The sequence is entered to effect local repair after a route
        change for a given PSB.

        o    Wait for a delay time of W seconds.

        o    Execute the PATH REFRESH event sequence (above) for the
             PSB.

References

   [Baker96]  Baker, F., "RSVP Cryptographic Authentication", Work in
        Progress.


   [RFC 2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
        S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
        FunctionalSpecification", RFC 2205, September 1997.

   [RFC 2207]  Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
        IPv4 Data Flows", RFC 2207, September 1997.

   [RSVP93]  Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
        Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE
        Network, September 1993.

Security Considerations

   Processing the RSVP INTEGRITY object [Baker96] is only mentioned in
   this memo, because the processing rules are described here only in
   general terms.  The RSVP support for IPSEC [RFC 2207] will imply
   modifications that have not yet been incorporated into these
   processing rules.










Braden & Zhang               Informational                     [Page 24]

RFC 2209                RSVP-Message Processing           September 1997


Authors' Addresses

   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]
   EMail: [e-mail]


   Lixia Zhang
   UCLA Computer Science Department
   4531G Boelter Hall
   Los Angeles, CA 90095-1596 USA

   Phone: [phone]
   EMail: [e-mail]

































Braden & Zhang               Informational                     [Page 25]