rfc2814.txt

RFC 的详细文档！

   scenario, they do address most of the interesting scenarios.
   Exceptions can be discussed separately.

   The forwarding rules are applied to received PATH messages (routers
   and switches) or originating PATH messages (hosts), as follows:

   1. Determine the interface(s) on which to forward the PATH message
      using standard forwarding rules:

      *  If there is a LAN_LOOPBACK object in the PATH message, and it
         carries the address of this device, silently discard the
         message.  (See the section below on "Additional notes on
         forwarding the PATH message onto a managed segment).

      *  Layer 3 devices use the RSVP session address and perform a
         routing lookup to determine the forwarding interface(s).

      *  Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP
         information and MAC forwarding tables to determine the
         forwarding interface(s). (See the section below on "Additional
         notes on forwarding the PATH message onto a managed segment")

   2. For each forwarding interface:

      *  If the device is a layer 3 device, determine whether the
         interface is on a managed segment managed by a DSBM, based on
         the presence or absence of I_AM_DSBM messages. If the interface
         is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
         LAN_LOOPBACK, and TCLASS objects (if present), and forward to
         the unicast or multicast destination.







Yavatkar, et al.            Standards Track                    [Page 20]

RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000


         (Note that the RSVP Class Numbers for these new objects are
         chosen so that if an RSVP message includes these objects, the
         nodes that are RSVP-aware, but do not participate in the SBM
         protocol, will ignore and silently discard such objects.)

      *  If the device is a layer 2 device or it is a layer 3 device
         *and* the interface is on a managed segment, proceed to rule
         #3.

   3. Forward the PATH message onto the managed segment:

      *  If the device is a layer 3 device, insert LAN_NHOP address
         objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH
         message. The LAN_NHOP objects carry the LAN_NHOP_L3 and
         LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2
         object carries the device's own L2 address, and the
         LAN_LOOPBACK object contains the IP address of the outgoing
         interface.

         An L3 device should use the map_addr() function described
         earlier to obtain an L2 address corresponding to an IP address.

      * If the device hosts the DSBM for the segment to which the
         forwarding interface is attached, do the following:

         - Retrieve the PHOP information from the standard RSVP HOP
           object in the PATH message, and store it. This will be used
           to route RESV messages back through the L2 network. If the
           PATH message arrived over a managed segment, it will also
           contain the RSVP_HOP_L2 object; then retrieve and store also
           the previous hop's L2 address in the PATH state.

         - Copy the IP address of the forwarding interface (layer 2
           devices must also have IP addresses) into the standard RSVP
           HOP object and the L2 address of the forwarding interface
           into the RSVP_HOP_L2 object.

         - If the PATH message received does not contain the TCLASS
           object, insert a TCLASS object. The user_priority value
           inserted in the TCLASS object is based on service mappings
           internal to the device that are configured according to the
           guidelines listed in [RFC-MAP]. If the message already
           contains the TCLASS object, the user_priority value may be
           changed based again on the service mappings internal to the
           device.






Yavatkar, et al.            Standards Track                    [Page 21]

RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000


      *  If the device is a layer 3 device and hosts a SBM for the
         segment to which the forwarding interface is attached, it *is
         required* to retrieve and store the PHOP info.

         If the device is a layer 2 device and hosts a SBM for the
         segment to which the forwarding interface is attached, it is
         *not* required to retrieve and store the PHOP info. If it does
         not do so, the SBM must leave the standard RSVP HOP object and
         the RSVP_HOP_L2 objects in the PATH message intact and it will
         not receive RESV messages.

         If the SBM on a L2 device chooses to overwrite the RSVP HOP and
         RSVP_HOP_L2 objects with the IP and L2 addresses of its
         forwarding interface, it will receive RESV messages. In this
         case, it must store the PHOP address info received in the
         standard RSVP_HOP field and RSVP_HOP_L2 objects of the incident
         PATH message.

         In both the cases mentioned above (L2 or L3 devices), the SBM
         must forward the TCLASS object in the received PATH message
         unchanged.

      *  Copy the IP address of the forwarding interface into the
         LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM
         reflecting a PATH message back onto the incident interface.
         (See the section below on "Additional notes on forwarding a
         PATH message onto a managed segment").

      *  If the SBM protocol entity is the DSBM for the segment to which
         the forwarding interface is attached, it must send the PATH
         message to the AllSBMAddress.

      *  If the SBM protocol entity is a SBM or a DSBM Client on the
         segment to which the forwarding interface is attached, it must
         send the PATH message to the DSBMLogicalAddress.

5.5.1. Additional notes on forwarding a PATH message onto a managed
       segment

   Rule #1 states that normal IEEE 802.1D forwarding rules should be
   used to determine the interfaces on which the PATH message should be
   forwarded. In the case of data packets, standard forwarding rules at
   a L2 device dictate that the packet should not be forwarded on the
   interface from which it was received. However, in the case of a DSBM
   that receives a PATH message over a managed segment, the following
   exception applies:





Yavatkar, et al.            Standards Track                    [Page 22]

RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000


      E1. If the address in the LAN_NHOP object is a unicast address,
          consult the filtering database (FDB) to determine whether the
          destination address is listed on the same interface over which
          the message was received. If yes, follow the rule below on
          "reflecting a PATH message back onto an interface" described
          below; otherwise, proceed with the rest of the message
          processing as usual.

      E2. If there are members of the multicast group address (specified
          by the addresses in the LAN_NHOP object), on the segment from
          which the message was received, the message should be
          forwarded back onto the interface from which it was received
          and follow the rule on "reflecting a PATH message back onto an
          interface" described below.

   *** Reflecting a PATH message back onto an interface ***

      Under the circumstances described above, when a DSBM reflects the
      PATH message back onto an interface over which it was received, it
      must address it using the AllSBMAddress.

      Since it is possible for a DSBM to reflect a PATH message back
      onto the interface from which it was received, precautions must be
      taken to avoid looping these messages indefinitely. The
      LAN_LOOPBACK object addresses this issue. All SBM protocol
      entities (except DSBMs reflecting a PATH message) overwrite the
      LAN_LOOPBACK object in the PATH message with the IP address of the
      outgoing interface. DSBMs which are reflecting a PATH message,
      leave the LAN_LOOPBACK object unchanged. Thus, SBM protocol
      entities will always be able to recognize a reflected multicast
      message by the presence of their own address in the LAN_LOOPBACK
      object. These messages should be silently discarded.

5.6. Applying the Rules -- Unicast Session

   Let's see how the rules are applied in the general network
   illustrated previously (see Figure 2).

   Assume that H1 is sending a PATH for a unicast session for which H5
   is the receiver. The following PATH message is composed by H1:

                             RSVP Contents
   RSVP session IP address   IP address of H5 (3.0.0.35)
   Sender Template           IP address of H1 (1.0.0.11)
   PHOP                      IP address of H1 (1.0.0.11)
   RSVP_HOP_L2               n/a  (H1 is not sending onto a managed
                                 segment)
   LAN_NHOP                  n/a  (H1 is not sending onto a managed



Yavatkar, et al.            Standards Track                    [Page 23]

RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000


                                 segment)
   LAN_LOOPBACK              n/a  (H1 is not sending onto a managed
                                 segment)

                             IP Header
   Source address            IP address of H1 (1.0.0.11)
   Destn address             IP addr of H5 (3.0.0.35, assuming raw mode
                              & router alert)

                             MAC Header
   Destn address             The L2 addr corresponding to R1 (determined
                              by map_addr() and routing tables at H1)

   Since H1 is not sending onto a managed segment, the PATH message is
   composed and forwarded according to standard RSVP processing rules.

   Upon receipt of the PATH message, R1 composes and forwards a PATH
   message as follows:

                             RSVP Contents
   RSVP session IP address   IP address of H5
   Sender Template           IP address of H1
   PHOP                      IP address of R1 (2.0.0.1)
                             (seed the return path for RESV messages)
   RSVP_HOP_L2               L2 address of R1
   LAN_NHOP                  LAN_NHOP_L3 (2.0.0.2) and
                             LAN_NHOP_L2 address of R2 (L2ADDR)
                             (this is the next layer 3 hop)
   LAN_LOOPBACK              IP address of R1 (2.0.0.1)

                             IP Header
   Source address            IP address of H1
   Destn address             DSBMLogical IP address (224.0.0.16)

                             MAC Header
   Destn address             DSBMLogical MAC address

   *  R1 does a routing lookup on the RSVP session address, to
      determine the IP address of the next layer 3 hop, R2.

   *  It determines that R2 is accessible via seg A and that seg A
      is managed by a DSBM, S1.

   *  Therefore, it concludes that it is sending onto a managed
      segment, and composes LAN_NHOP objects to carry the layer 3
      and layer 2 next hop addresses. To compose the LAN_NHOP
      L2ADDR object, it invokes the L3 to L2 address mapping function




Yavatkar, et al.            Standards Track                    [Page 24]

RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000


      ("map_address") to find out the MAC address for the next hop
      L3 device, and the