rfc2814.txt

RFC 的详细文档！

   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
   the egress node after processing the PATH message.  However, we
   expect the L2 devices (such as switches) to act as DSBMs on the path
   within the L2 domain and it may not be reasonable to expect these
   devices to have an ARP capability to determine the MAC address (we



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


   call it L2ADDR for Layer 2 address) corresponding to the IP address
   in the LAN_NHOP object.

   Therefore, we require that the LAN_NHOP information (generated by the
   L3 device) include both the IP address (LAN_NHOP_L3 address) and the
   corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop
   over the L2 domain.  The LAN_NHOP_L3 address is used by SBM protocol
   entities on L3 devices to forward the PATH message towards its
   destination whereas the L2 address is used by the SBM protocol
   entities on L2 devices to determine how to forward the PATH message
   towards the L3 NHOP (egress point from the L2 domain).  The exact
   format of the LAN_NHOP information and relevant objects is described
   later in Appendix B.

4.2.2.4 Similarities to Standard RSVP Message Processing

   -  When a DSBM receives a RSVP PATH message, it processes the PATH
      message according to the PATH processing rules described in the
      RSVP specification. In particular, the DSBM retrieves the IP
      address of the previous hop from the RSVP_HOP object in the PATH
      message and stores the PHOP address in its PATH state.  It then
      forwards the PATH message with the PHOP (RSVP_HOP) object modified
      to reflect its own IP address (RSVP_HOP_L3 address). Thus, the
      DSBM inserts itself as an intermediate hop in the chain of nodes
      in the path between two L3 nodes across the L2 domain.

   -  The PATH state in a DSBM is used for forwarding subsequent RESV
      messages as per the standard RSVP message processing rules.  When
      the DSBM receives a RESV message, it processes the message and
      forwards it to appropriate PHOP(s) based on its PATH state.

   -  Because a DSBM inserts itself as a hop between two RSVP nodes in
      the path of a RSVP flow, all RSVP related messages (such as PATH,
      PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow
      through the DSBM.  In particular, a PATH_TEAR message is routed
      exactly through the intermediate DSBM(s) as its corresponding PATH
      message and the local PATH state is first cleaned up at each
      intermediate hop before the PATH_TEAR message gets forwarded.

   -  So far, we have described how the PATH message propagates through
      the L2 domain establishing PATH state at each DSBM along the
      managed segments in the path. The layer 2 address (LAN_NHOP_L2
      address) in the LAN_NHOP object should be used by the L2 devices
      along the path to decide how to forward the PATH message toward
      the next L3 hop.  Such devices will apply the standard IEEE 802.1D
      forwarding rules (e.g., send it on a single port based on its
      filtering database, or flood it on all ports active in the
      spanning tree if the L2 address does not appear in the filtering



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


      database) to the LAN_NHOP_L2 address as are applied normally to
      data packets destined to the address.

4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP
        Objects

   In the conventional RSVP message processing, the PATH state
   established along the nodes on a path is used to route the RESV
   message from a receiver to a sender in an RSVP session. As each
   intermediate node builds the path state, it remembers the previous
   hop (stores the PHOP IP address available in the RSVP_HOP object of
   an incoming message) that sent it the PATH message and, when the RESV
   message arrives, the intermediate node simply uses the stored PHOP
   address to forward the RESV after processing it successfully.

   In our case, we expect the SBM entities residing at L2 devices to act
   as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain)
   along the path between a sender (PHOP) and receiver (NHOP). Thus,
   when a RESV message arrives at a DSBM, it must use the stored PHOP IP
   address to forward the RESV message to its previous hop. However, it
   may not be reasonable to expect the L2 devices to have an ARP cache
   or the ARP capability to map the PHOP IP address to its corresponding
   L2 address before forwarding the RESV message.

   To obviate the need for such address mapping at L2 devices, we use a
   RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object
   includes the Layer 2 address (L2ADDR) of the previous hop and
   complements the L3 address information included in the RSVP_HOP
   object (RSVP_HOP_L3 address).

   When a L3 device constructs and forwards a PATH message over a
   managed segment, it includes its IP address (IP address of the
   interface over which PATH is sent) in the RSVP_HOP object and adds a
   RSVP_HOP_L2 object that includes the corresponding L2 address for the
   interface.  When a device in the L2 domain receives such a PATH
   message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2
   objects in its PATH state and then overwrites the RSVP_HOP and
   RSVP_HOP_L2 objects with its own addresses before forwarding the PATH
   message over a managed segment.

   The exact format of RSVP_HOP_L2 object is specified in Appendix B.

4.2.2.6 Loop Detection

   When an RSVP session address is a multicast address and a SBM, DSBM,
   and DSBM clients share the same L2 segment (a shared segment), it is
   possible for a SBM or a DSBM client to receive one or more copies of
   a PATH message that it forwarded earlier when a DSBM on the same wire



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


   forwards it (See Section 5.7 for an example of such a case). To
   facilitate detection of such loops, we use a new RSVP object called
   the LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs
   reflecting a PATH message onto the interface over which it arrived
   earlier) must overwrite (or add if the PATH message does NOT already
   include a LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH
   message with their own unicast IP address.

   Now, a SBM or a DSBM client can easily detect and discard the
   duplicates by checking the contents of the LAN_LOOPBACK object (a
   duplicate PATH message will list a device's own interface address in
   the LAN_LOOPBACK object). Appendix B specifies the exact format of
   the LAN_LOOPBACK object.

4.2.2.7 802.1p, User Priority and TCLASS

   The model proposed by the Integrated Services working group requires
   isolation of traffic flows from each other during their transit
   across a network. The motivation for traffic flow separation is to
   provide Integrated Services flows protection from misbehaving flows
   and other best-effort traffic that share the same path. The basic
   IEEE 802.3/Ethernet networks do not provide any notion of traffic
   classes to discriminate among different flows that request different
   services.  However, IEEE 802.1p defines a way for switches to
   differentiate among several "user_priority" values encoded in packets
   representing different traffic classes (see [IEEE802Q, IEEE8021p] for
   further details). The user_priority values can be encoded either in
   native LAN packets (e.g., in IEEE 802.5's FC octet) or by using an
   encapsulation above the MAC layer (e.g., in the case of Ethernet, the
   user_priority value assigned to each packet will be carried in the
   frame header using the new, extended frame format defined by IEEE
   802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations about how
   a sender or network should use the user_priority values. An
   accompanying document makes recommendations on the usage of the
   user_priority values (see [RFC-MAP] for details).

   Under the Integrated Services model, L3 (or higher) entities that
   transmit traffic flows onto a L2 segment should perform per-flow
   policing to ensure that the flows do not exceed their traffic
   specification as specified during admission control. In addition, L3
   devices may label the frames in such flows with a user_priority value
   to identify their service class.

   For the purpose of this discussion, we will refer to the
   user_priority value carried in the extended frame header as the
   "traffic class" of a packet. Under the ISSLL model, the L3 entities,
   that send traffic and that use the SBM protocol, may select the
   appropriate traffic class of outgoing packets [RFC-MAP]. This



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


   selection may be overridden by DSBM devices, in the following manner.
   once a sender sends a PATH message, downstream DSBMs will insert a
   new traffic class object (TCLASS object) in the PATH message that
   travels to the next L3 device (L3 NHOP for the PATH message). To some
   extent, the TCLASS object contents are treated like the ADSPEC object
   in the RSVP PATH messages.  The L3 device that receives the PATH
   message must remove and store the TCLASS object as part of its PATH
   state for the session. Later, when the same L3 device needs to
   forward a RSVP RESV message towards the original sender, it must
   include the TCLASS object in the RESV message. When the RESV message
   arrives at the original sender, the sender must use the user_priority
   value from the TCLASS object to override its selection for the
   traffic class marked in outgoing packets.

   The format of the TCLASS object is specified in Appendix B.  Note
   that TCLASS and other SBM-specific objects are carried in a RSVP
   message in addition to all the other, normal RSVP objects per RFC
   2205.

4.2.2.8 Processing the TCLASS Object

   In summary, use of TCLASS objects requires following additions to the
   conventional RSVP message processing at DSBMs, SBMs, and DSBM
   clients:

   *  When a DSBM receives a PATH message over a managed segment and the
      PATH message does not include a TCLASS object, the DSBM MAY add a
      TCLASS object to the PATH message before forwarding it.  The DSBM
      determines the appropriate user_priority value for the TCLASS
      object. A mechanism for selecting the appropriate user_priority
      value is described in an accompanying document [RFC-MAP].

   *  When SBM or DSBM receives a PATH message with a TCLASS object over
      a managed segment in a L2 domain and needs to forward it over a
      managed segment in the same L2 domain, it will store it in its
      path state and typically forward the message without changing the
      contents of the TCLASS object.  However, if the DSBM/SBM cannot
      support the service class represented by the user_priority value
      specified by the TCLASS object in the PATH message, it may change
      the priority value in the TCLASS to a semantically "lower" service
      value to reflect its capability and store the changed TCLASS value
      in its path state.









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


      [NOTE: An accompanying document defines the int-serv mappings over
      IEEE 802 networks [RFC-MAP] provides a precise definition of
      user_priority values and describes how the user_priority values
      are compared to determine "lower" of the two values or the
      "lowest" among all the user_priority values.]

   *  When a DSBM receives a RESV message with a TCLASS object, it may
      use the traffic class information (in addition to the usual
      flowspec information in the RSVP message) for its own admission
      control for the managed segment.

      Note that this document does not specify the actual algorithm or
      policy used for admission control. At one extreme, a DSBM may use
      per-flow reservation request as specified by the flowspec for a
      fine grain admission control. At the other extreme, a DSBM may
      only consider the traffic class information for a very coarse-
      grain admission control based on some static allocation of link
      capacity for each traffic class. Any combination of the options
      represented by these two extremes may also be used.

   *  When a DSBM (at an L2 or L3) device receives a RESV message
      without a TCLASS object and it needs to forward the RESV message
      over a managed segment within the same L2 domain, it should first