rfc2814.txt

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

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


   -  Managed L2 domain: An L2 domain consisting of managed segments is
      referred to as a managed L2 domain to distinguish it from a L2
      domain with no DSBMs present for exercising admission control over
      resources at segments in the L2 domain.

   -  DSBM clients: These are entities that transmit traffic onto a
      managed segment and use the services of a DSBM for the managed
      segment for admission control over a LAN segment. Only the layer 3
      or higher layer entities on L3 devices such as hosts and routers
      are expected to send traffic that requires resource reservations,
      and, therefore, DSBM clients are L3 entities.

   -  SBM transparent devices: A "SBM transparent" device is unaware of
      SBMs or DSBMs (though it may or may not be RSVP aware) and,
      therefore, does not participate in the SBM-based admission control
      procedure over a managed segment. Such a device uses standard
      forwarding rules appropriate for the device and is transparent
      with respect to SBM.  An example of such a L2 device is a legacy
      switch that does not participate in resource reservation.

   -  Layer 3 and layer 2 addresses: We refer to layer 3 addresses of
      L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2
      addresses". This convention will be used in the rest of the
      document to distinguish between Layer 3 and layer 2 addresses used
      to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices.
      For example, in conventional RSVP message processing, RSVP_HOP
      object in a PATH message carries the L3 address of the previous
      hop device. We will refer to the address contained in the RSVP_HOP
      object as the RSVP_HOP_L3 address and the corresponding MAC
      address of the previous hop device will be referred to as the
      RSVP_HOP_L2 address.

4.2. Overview of the SBM-based Admission Control Procedure

   A protocol entity called "Designated SBM" (DSBM) exists for each
   managed segment and is responsible for admission control over the
   resource reservation requests originating from the DSBM clients in
   that segment.  Given a segment, one or more SBMs may exist on the
   segment.  For example, many SBM-capable devices may be attached to a
   shared L2 segment whereas two SBM-capable switches may share a half-
   duplex switched segment. In that case, a single DSBM is elected for
   the segment. The procedure for dynamically electing the DSBM is
   described in Appendix A. The only other approved method for
   specifying a DSBM for a managed segment is static configuration at
   SBM-capable devices.






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


   The presence of a DSBM makes the segment a "managed segment".
   Sometimes, two or more L2 segments may be interconnected by SBM
   transparent devices. In that case, a single DSBM will manage the
   resources for those segments treating the collection of such segments
   as a single managed segment for the purpose of admission control.

4.2.1. Basic Algorithm

   Figure 1 - An Example of a Managed Segment.

       +-------+      +-----+     +------+    +-----+   +--------+
       |Router |      | Host|     | DSBM |    | Host|   | Router |
       | R2    |      | C   |     +------+    |  B  |   |  R3    |
       +-------+      +-----+     /           +-----+   +--------+
          |             |        /               |          |
          |             |       /                |          |
   ==============================================================LAN
                    |                                   |
                    |                                   |
                  +------+                          +-------+
                  | Host |                          | Router|
                  |  A   |                          |   R1  |
                  +------+                          +-------+

   Figure 1 shows an example of a managed segment in a L2 domain that
   interconnects a set of hosts and routers. For the purpose of this
   discussion, we ignore the actual physical topology of the L2 domain
   (assume it is a shared L2 segment and a single managed segment
   represents the entire L2 domain). A single SBM device is designated
   to be the DSBM for the managed segment. We will provide examples of
   operation of the DSBM over switched and shared segments later in the
   document.

   The basic DSBM-based admission control procedure works as follows:

   1.  DSBM Initialization:  As part of its initial configuration, DSBM
       obtains information such as the limits on fraction of available
       resources that can be reserved on each managed segment under its
       control. For instance, bandwidth is one such resource. Even
       though methods such as auto-negotiation of link speeds and
       knowledge of link topology allow discovery of link capacity, the
       configuration may be necessary to limit the fraction of link
       capacity that can be reserved on a link.  Configuration is likely
       to be static with the current L2/L3 devices. Future work may
       allow for dynamic discovery of this information. This document
       does not specify the configuration mechanism.





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


   2.  DSBM Client Initialization:  For each interface attached, a DSBM
       client determines whether a DSBM exists on the interface. The
       procedure for discovering and verifying the existence of the DSBM
       for an attached segment is described in Appendix A. If the client
       itself is capable of serving as the DSBM on the segment, it may
       choose to participate in the election to become the DSBM. At the
       start, a DSBM client first verifies that a DSBM exists in its L2
       domain so that it can communicate with the DSBM for admission
       control purposes.

       In the case of a full-duplex segment, an election may not be
       necessary as the SBM at each end will typically act as the DSBM
       for outgoing traffic in each direction.

   3.  DSBM-based Admission Control: To request reservation of resources
       (e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable
       L3 devices such as hosts and routers) follow the following steps:

      a) When a DSBM client sends or forwards a RSVP PATH message over
         an interface attached to a managed segment, it sends the PATH
         message to the segment's DSBM instead of sending it to the RSVP
         session destination address (as is done in conventional RSVP
         processing). After processing (and possibly updating an
         ADSPEC), the DSBM will forward the PATH message toward its
         destination address. As part of its processing, the DSBM builds
         and maintains a PATH state for the session and notes the
         previous L2/L3 hop that sent it the PATH message.

         Let us consider the managed segment in Figure 1. Assume that a
         sender to a RSVP session (session address specifies the IP
         address of host A on the managed segment in Figure 1) resides
         outside the L2 domain of the managed segment and sends a PATH
         message that arrives at router R1 which is on the path towards
         host A.

         DSBM client on Router R1 forwards the PATH message from the
         sender to the DSBM. The DSBM processes the PATH message and
         forwards the PATH message towards the RSVP receiver (Detailed
         message processing and forwarding rules are described in
         Section 5).  In the process, the DSBM builds the PATH state,
         remembers the router R1 (its L2 and l3 addresses) as the
         previous hop for the session, puts its own L2 and L3 addresses
         in the PHOP objects (see explanation later), and effectively
         inserts itself as an intermediate node between the sender (or
         R1 in Figure 1) and the receiver (host A) on the managed
         segment.





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


      b) When an application on host A wishes to make a reservation for
         the RSVP session, host A follows the standard RSVP message
         processing rules and sends a RSVP RESV message to the previous
         hop L2/L3 address (the DSBMs address) obtained from the PHOP
         object(s) in the previously received PATH message.

      c) The DSBM processes the RSVP RESV message based on the bandwidth
         available and returns an RESV_ERR message to the requester
         (host A) if the request cannot be granted. If sufficient
         resources are available and the reservation request is granted,
         the DSBM forwards the RESV message towards the PHOP(s) based on
         its local PATH state for the session. The DSBM merges
         reservation requests for the same session as and when possible
         using the rules similar to those used in the conventional RSVP
         processing (except for an additional criterion described in
         Section 5.8).

      d) If the L2 domain contains more than one managed segment, the
         requester (host A) and the forwarder (router R1) may be
         separated by more than one managed segment. In that case, the
         original PATH message would propagate through many DSBMs (one
         for each managed segment on the path from R1 to A) setting up
         PATH state at each DSBM. Therefore, the RESV message would
         propagate hop-by-hop in reverse through the intermediate DSBMs
         and eventually reach the original forwarder (router R1) on the
         L2 domain if admission control at all DSBMs succeeds.

4.2.2. Enhancements to the conventional RSVP operation

   (D)SBMs and DSBM clients implement minor additions to the standard
   RSVP protocol. These are summarized in this section. A detailed
   description of the message processing and forwarding rules follows in
   section 5.

4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment

   Normal RSVP forwarding rules apply at a DSBM client when it is not
   forwarding an outgoing PATH message over a managed segment. However,
   outgoing PATH messages on a managed segment are sent to the DSBM for
   the corresponding managed segment (Section 5.2 describes how the PATH
   messages are sent to the DSBM on a managed segment).

4.2.2.2 The LAN_NHOP Objects

   In conventional RSVP processing over point-to-point links, RSVP nodes
   (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep
   track of the next hop (downstream node in the path of data packets in
   a traffic flow) and the previous hop (upstream nodes with respect to



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


   the data flow) nodes on the path between a sender and a receiver.
   Routers along the path of a PATH message forward the message towards
   the destination address based on the L3 routing (packet forwarding)
   tables.

   For example, consider the L2 domain in Figure 1. Assume that both the
   sender (some host X) and the receiver (some host Y) in a RSVP session
   reside outside the L2 domain shown in the Figure, but PATH messages
   from the sender to its receiver pass through the routers in the L2
   domain using it as a transit subnet. Assume that the PATH message
   from the sender X arrives at the router R1. R1 uses its local routing
   information to decide which next hop router (either router R2 or
   router R3) to use to forward the PATH message towards host Y.
   However, when the path traverses a managed L2 domain, we require the
   PATH and RESV messages to go through a DSBM for each managed segment.
   Such a L2 domain may span many managed segments (and DSBMs) and,
   typically, SBM protocol entities on L2 devices (such as a switch)
   will serve as the DSBMs for the managed segments in a switched
   topology. When R1 forwards the PATH message to the DSBM (an L2
   device), the DSBM may not have the L3 routing information necessary
   to select the egress router (between R2 and R3) before forwarding the
   PATH message. To ensure correct operation and routing of RSVP
   messages, we must provide additional forwarding information to DSBMs.

   For this purpose, we introduce new RSVP objects called LAN_NHOP
   address objects that keep track of the next L3 hop as the PATH
   message traverses an L2 domain between two L3 entities (RSVP PHOP and
   NHOP nodes).

4.2.2.3 Including Both Layer-2 and Layer-3 Addresses in the LAN_NHOP

   When a DSBM client (a host or a router acting as the originator of a
   PATH message) sends out a PATH message to the DSBM, it must include
   LAN_NHOP information in the message. In the case of a unicast
   destination, the LAN_NHOP address specifies the destination address
   (if the destination is local to its L2 domain) or the address of the
   next hop router towards the destination. In our example of an RSVP
   session involving the sender X and receiver Y with L2 domain in
   Figure 1 acting as the transit subnet, R1 is the ingress node that
   receives the PATH message.  R1 first determines that R2 is the next
   hop router (or the egress node in the L2 domain for the session
   address) and then inserts a LAN_NHOP object that specifies R2's IP
   address. When a DSBM receives a PATH message, it can now look at the
   address in the LAN_NHOP object and forward the PATH message towards