rfc2209.txt

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

Network Working Group                                          R. Braden
Request For Comments: 2209                                           ISI
Category: Informational                                         L. Zhang
                                                                    UCLA
                                                          September 1997

                Resource ReSerVation Protocol (RSVP) --
                   Version 1 Message Processing Rules

Status of this Memo


   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This memo contains an algorithmic description of the rules used by an
   RSVP implementation for processing messages.  It is intended to
   clarify the version 1 RSVP protocol specification.

   This memo provides a generic description of the rules for the
   operation of Version 1 of RSVP [RFC 2205].  It is intended to outline
   a set of algorithms that will accomplish the needed function,
   omitting many details.

1. GENERIC DATA STRUCTURES

   This memo assumes the generic interface calls defined in [RFC 2005]
   and the following data structures.  An actual implementation may use
   additional or different data structures and interfaces.  The data
   structure fields that are shown are required unless they are
   explicitly labelled as optional.

   o    PSB -- Path State Block

        Each PSB holds path state for a particular (session, sender)
        pair, defined by SESSION and SENDER_TEMPLATE objects,
        respectively, received in a PATH message.











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


        PSB contents include the following values from a PATH message:

        -    Session

        -    Sender_Template

        -    Sender_Tspec

        -    The previous hop IP address and the Logical Interface
             Handle (LIH) from a PHOP object

        -    The remaining IP TTL

        -    POLICY_DATA and/or ADSPEC objects (optional)

        -    Non_RSVP flag

        -    E_Police flag

        -    Local_Only flag

        In addition, the PSB contains the following information provided
        by routing: OutInterface_list, which is the list of outgoing
        interfaces for this (sender, destination), and IncInterface,
        which is the expected incoming interface.  For a unicast
        destination, OutInterface_list contains one entry and
        IncInterface is undefined.

        Note that there may be more than one PSB for the same (session,
        sender) pair but different incoming interfaces.  At most one of
        these, which will have the Local_Only flag off, will be the PSB
        used for forwarding PATH messages downstream; we will refer to
        it as the "forwarding PSB" in the following.  The other PSB's
        will have the Local_Only flag on and an empty
        OutInterface_list.h The Local_Only flag is needed to correctly
        match PSB's against RSB's, by the rules of [RFC 2205].

   o    RSB -- Reservation State Block

        Each RSB holds a reservation request that arrived in a
        particular RESV message, corresponding to the triple:  (session,
        next hop, Filter_spec_list).  Here "Filter_spec_list" may be a
        list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
        style), or empty (WF style).  We define the virtual object type
        "FILTER_SPEC*" for such a data structure.






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


        RSB contents include:

        -    Session specification

        -    Next hop IP address

        -    Filter_spec_list

        -    The outgoing (logical) interface OI on which the
             reservation is to be made or has been made.

        -    Style

        -    Flowspec

        -    A SCOPE object (optional, depending upon style)

        -    RESV_CONFIRM object that was received (optional)

   o    TCSB -- Traffic Control State Block

        Each TCSB holds the reservation specification that has been
        handed to traffic control for a specific outgoing interface.  In
        general, TCSB information is derived from RSB's for the same
        outgoing interface.  Each TCSB defines a single reservation for
        a particular triple: (session, OI, Filter_spec_list).   TCSB
        contents include:

        -    Session

        -    OI (Outgoing Interface)

        -    Filter_spec_list

        -    TC_Flowspec, the effective flowspec, i.e., the LUB over the
             corresponding FLOWSPEC values from matching RSB's.
             TC_Flowspec is passed to traffic control to make the actual
             reservation.

         -   Fwd_Flowspec, the updated object to be forwarded
             after merging.

        -    TC_Tspec, equal to Path_Te, the effective sender Tspec.

        -    Police Flags

             The flags are E_Police_Flag, M_Police_Flag, and
             B_Police_Flag.



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


        -    Rhandle, F_Handle_list

             Handles returned by the traffic control interface,
             corresponding to a flowspec and perhaps a list of filter
             specs.

        -    A RESV_CONFIRM object to be forwarded.

   o    BSB -- Blockade State Block

        Each BSB contains an element of blockade state.  Depending upon
        the reservation style in use, the BSB's may be per (session,
        sender_template) pair or per (session, PHOP) pair.  In practice,
        an implementation might embed a BSB within a PSB; however, for
        clarity we describe BSB's independently.

        The contents of a BSB include:

        -    Session

        -    Sender_Template (which is also a filter spec)

        -    PHOP

        -    FLOWSPEC Qb

        -    Blockade timer Tb

        The following Boolean Flag variables are used in this section:
        Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
        Need_Scope, B_Merge, and NeworMod.  Refresh_PHOP_list is a
        variable-length list of PHOPs to be refreshed.

2. PROCESSING RULES

   MESSAGE ARRIVES

   Verify version number and RSVP checksum, and discard message if any
   mismatch is found.

   If the message type is not PATH or PTEAR or RACK and if the IP
   destination address does not match any of the addresses of the local
   interfaces, then forward the message to IP destination address and
   return.

   Parse the sequence of objects in the message.  If any required
   objects are missing or the length field of the common header does not
   match an object boundary, discard the message and return.



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


   Verify the INTEGRITY object, if any.  If the check fails, discard the
   message and return.

   Verify the consistent use of port fields.  If the DstPort in the
   SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
   FILTER_SPEC object is non-zero, then the message has a "conflicting
   source port" error; silently discard the message and return.

   Processing of POLICY_DATA objects will be specified in the future.

   Further processing depends upon message type.

   PATH MESSAGE ARRIVES

   Assume the PATH message arrives on interface InIf.

   Process the sender descriptor object sequence in the message as
   follows.  The Path_Refresh_Needed and Resv_Refresh_Needed flags are
   initially off.

   o    Search for a path state block (PSB) whose (session,
        sender_template) pair matches the corresponding objects in the
        message, and whose IncInterface matches InIf.

             During this search:

             1.   If a PSB is found whose session matches the
                  DestAddress and Protocol Id fields of the received
                  SESSION object, but the DstPorts differ and one is
                  zero, then build and send a "Conflicting Dst Port"
                  PERR message, drop the PATH message, and return.

             2.   If a PSB is found with a matching sender host but the
                  Src Ports differ and one of the SrcPorts is zero, then
                  build and send an "Ambiguous Path" PERR message, drop
                  the PATH message, and return.

             3.   If a forwarding PSB is found, i.e., a PSB that matches
                  the (session, sender_template) pair and whose
                  Local_Only flag is off, save a pointer to it in the
                  variable fPSB.  If none is found, set fPSB to NULL.

        o    If there was no matching PSB, then:

             1.   Create a new PSB.

             2.   Copy contents of the SESSION, SENDER_TEMPLATE,
                  SENDER_TSPEC, and PHOP (IP address and LIH) objects



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


                  into the PSB.

             3.   If the sender is from the local API, set
                  OutInterface_List to the single interface whose
                  address matches the sender address, and make
                  IncInterface undefined.  Otherwise, turn on the
                  Local_Only flag.

             4.   Turn on the Path_Refresh_Needed flag.

        o    Otherwise (there is a matching PSB):

             -    If the PHOP IP address, the LIH, or Sender_Tspec
                  differs between the message and the PSB, copy the new
                  value into the PSB and turn on the Path_Refresh_Needed
                  flag.  If the PHOP IP address or the LIH differ, also
                  turn on the Resv_Refresh_Needed flag.

        o    Call the resulting PSB the "current PSB" (cPSB).  Update
             the cPSB, as follows:

             -    Start or Restart the cleanup timer for the PSB.

             -    If the message contains an ADSPEC object, copy it into
                  the PSB.

             -    Copy E_Police flag from SESSION object into PSB.

             -    Store the received TTL into the PSB.
                  If the received TTL differs from Send_TTL in the RSVP
                  common header, set the Non_RSVP flag on in the PSB.

        o    If the PSB is new or if there is no route change
             notification in place, then perform the following routing
             manipulations, but not if the cPSB is from the local API.

             1.   Invoke the appropriate Route_Query routine using
                  DestAddress from SESSION and (for multicast routing)
                  SrcAddress from Sender_Template.

                  Call the results (Rt_OutL, Rt_InIf).

             2.   If the destination is multicast and Rt_InIf differs
                  from IncInterface in the cPSB, but fPSB points to the
                  cPSB, then do the following.

                  -    Turn on the Local_Only flag and clear the
                       OutInterface_list of the fPSB.  Set the fPSB



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


                       pointer to NULL.

                  -    Search for a PSB for the same (session,
                       sender_template) pair whose IncInterface matches
                       Rt_InIf.  If one is found, set fPSB to point to
                       it.

             3.   If the destination is multicast and Rt_InIf is the
                  same as IncInterface in the cPSB, but fPSB does not