rfc2814.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      managed segment, the client must pass the user_priority value in
      the TCLASS object to its local packet classifier. This will ensure
      that the data packets in the admitted RSVP flow that are
      subsequently forwarded over the outgoing interface will contain
      the appropriate value encoded in their frame header.





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


   *  When an L3 device receives a PATH or RESV message over a managed
      segment in one L2 domain and it needs to forward the PATH/RESV
      message over an interface outside that domain, the L3 device must
      remove the TCLASS object (along with LAN_NHOP, RSVP_HOP_L2, and
      LAN_LOOPBACK objects in the case of the PATH message) before
      forwarding the PATH/RESV message. If the outgoing interface is on
      a separate L2 domain, these objects may be regenerated according
      to the processing rules applicable to that interface.

5. Detailed Message Processing Rules

5.1. Additional Notes on Terminology

   *  An L2 device may have several interfaces with attached segments
      that are part of the same L2 domain. A switch in a L2 domain is an
      example of such a device. A device which has several interfaces
      may contain a SBM protocol entity that acts in different
      capacities on each interface. For example, a SBM protocol entity
      could act as a SBM on interface A, and act as a DSBM on interface
      B.

   *  A SBM protocol entity on a layer 3 device can be a DSBM client,
      and SBM, a DSBM, or none of the above (SBM transparent).  Non-
      transparent L3 devices can implement any combination of these
      roles simultaneously. DSBM clients always reside at L3 devices.

   *  A SBM protocol entity residing at a layer 2 device can be a SBM, a
      DSBM or none of the above (SBM transparent). A layer 2 device will
      never host a DSBM client.

5.2. Use Of Reserved IP Multicast Addresses

   As stated earlier, we require that the DSBM clients forward the RSVP
   PATH messages to their DSBMs in a L2 domain before they reach the
   next L3 hop in the path. RSVP PATH messages are addressed, according
   to RFC-2205, to their destination address (which can be either an IP
   unicast or multicast address).  When a L2 device hosts a DSBM, a
   simple-to-implement mechanism must be provided for the device to
   capture an incoming PATH message and hand it over to the local DSBM
   agent without requiring the L2 device to snoop for L3 RSVP messages.

   In addition, DSBM clients need to know how to address SBM messages to
   the DSBM. For the ease of operation and to allow dynamic DSBM-client
   binding, it should be possible to easily detect and address the
   existing DSBM on a managed segment.






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


   To facilitate dynamic DSBM-client binding as well as to enable easy
   detection and capture of PATH messages at L2 devices, we require that
   a DSBM be addressed using a logical address rather than a physical
   address. We make use of reserved IP multicast address(es) for the
   purpose of communication with a DSBM.  In particular, we require that
   when a DSBM client or a SBM forwards a PATH message over a managed
   segment, it is addressed to a reserved IP multicast address. Thus, a
   DSBM on a L2 device needs to be configured in a way to make it easy
   to intercept the PATH message and forward it to the local SBM
   protocol entity. For example, this may involve simply adding a static
   entry in the device's filtering database (FDB) for the corresponding
   MAC multicast address to ensure the PATH messages get intercepted and
   are not forwarded further without the DSBM intervention.

   Similarly, a DSBM always sends the PATH messages over a managed
   segment using a reserved IP multicast address and, thus, the SBMs or
   DSBM clients on the managed segments must simply be configured to
   intercept messages addressed to the reserved multicast address on the
   appropriate interfaces to easily receive PATH messages.

   RSVP RESV messages continue to be unicast to the previous hop address
   stored as part of the PATH state at each intermediate hop.

   We define use of two reserved IP multicast addresses. We call these
   the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen
   from the range of local multicast addresses, such that:

   *  They are not passed through layer 3 devices.

   *  They are passed transparently through layer 2 devices which are
      SBM transparent.

   *  They are configured in the permanent database of layer 2 devices
      which host SBMs or DSBMs, such that they are directed to the SBM
      management entity in these devices. This obviates the need for
      these devices to explicitly snoop for SBM related control packets.

   *  The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and
      224.0.0.17 (AllSBMAddress).

   These addresses are used as described in the following table:

   Type     DSBMLogicaladdress         AllSBMAddress

   DSBM     * Sends PATH messages      * Monitors this address to detect
   Client     to this address            the presence of a DSBM





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


                                       * Monitors this address to
                                         receive PATH messages
                                         forwarded by the DSBM

   SBM      * Sends PATH messages      * Monitors and sends on this
              to this address            address to participate in
                                         election of the DSBM
                                       * Monitors this address to
                                         receive PATH messages
                                         forwarded by the DSBM

   DSBM     * Monitors this address    * Monitors and sends on this
              for PATH messages          to participate in election
              directed to it             of the DSBM
                                       * Sends PATH messages to this
                                         address

   The L2 or MAC addresses corresponding to IP multicast addresses are
   computed algorithmically using a reserved L2 address block (the high
   order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700]
   gives additional details.

5.3. Layer 3 to Layer 2 Address Mapping

   As stated earlier, DSBMs or DSBM clients residing at a L3 device must
   include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2
   devices along the path of a PATH message do not need to separately
   determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP
   object and its corresponding L2 address (for example, using ARP).

   For the purpose of such mapping at L3 devices, we assume a mapping
   function called "map_address" that performs the necessary mapping:

                 L2ADDR object = map_addr(L3Addr)

   We do not specify how the function is implemented; the implementation
   may simply involve access to the local ARP cache entry or may require
   performing an ARP function.  The function returns a L2ADDR object
   that need not be interpreted by an L3 device and can be treated as an
   opaque object.  The format of the L2ADDR object is specified in
   Appendix B.

5.4. Raw vs. UDP Encapsulation

   We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for
   encapsulating RSVP messages that are forwarded onto a L2 domain.
   Thus, when a SBM protocol entity on a L3 device forwards a RSVP
   message onto a L2 segment, it will only use RAW IP encapsulation.



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


5.5. The Forwarding Rules

   The message processing and forwarding rules will be described in the
   context of the sample network illustrated in Figure 2.

   Figure 2 - A sample network or L2 domain consisting of switched and
   shared L2 segments

 ..........
          .
+------+  .    +------+  seg A  +------+  seg C  +------+ seg D +------+
|  H1  |_______|  R1  |_________|  S1  |_________|  S2  |_______|  H2  |
|      |  .    |      |         |      |         |      |       |      |
+------+  .    +------+         +------+         +------+       +------+
          .                        |                /
1.0.0.0   .                        |               /
          .                        |___           /
          .                    seg B  |          / seg E
 ..........                           |         /
                     2.0.0.0          |        /
                                     +-----------+
                                     |    S3     |
                                     |           |
                                     +-----------+
                                          |
                                          |
                                          |
                                          |
                         seg F            |            .................
                 ------------------------------        .
                   |         |             |           .
                +------+  +------+        +------+     .      +------+
                |  H3  |  |  H4  |        |  R2  |____________|  H5  |
                |      |  |      |        |      |     .      |      |
                +------+  +------+        +------+     .      +------+
                                                       .
                                                       .     3.0.0.0
                                                       .................

   Figure 2 illustrates a sample network topology consisting of three IP
   subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two
   routers. The subnet 2.0.0.0 is an example of a L2 domain consisting
   of switches, hosts, and routers interconnected using switched
   segments and a shared L2 segment. The sample network contains the
   following devices:






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


   Device          Type                    SBM Type

   H1, H5      Host (layer 3)          SBM Transparent
   H2-H4       Host (layer 3)          DSBM Client
   R1          Router (layer 3)        SBM
   R2          Router (layer 3)        DSBM for segment F
   S1          Switch (layer 2)        DSBM for segments A, B
   S2          Switch (layer 2)        DSBM for segments C, D, E
   S3          Switch (layer 2)        SBM

   The following paragraphs describe the rules, which each of these
   devices should use to forward PATH messages (rules apply to PATH_TEAR
   messages as well). They are described in the context of the general
   network illustrated above. While the examples do not address every
   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: