tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2814

Proposed STD
Pages: 60
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ISSLL

SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks

Part 1 of 3, p. 1 to 16
None       Next RFC Part


Top       Page 1 
Network Working Group                                        R. Yavatkar
Request for Comments: 2814                                         Intel
Category: Standards Track                                     D. Hoffman
                                                               Y. Bernet
                                                                F. Baker
                                                                M. Speer
                                                        Sun Microsystems
                                                                May 2000

                    SBM (Subnet Bandwidth Manager):
A Protocol for RSVP-based Admission Control over IEEE 802-style networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


   This document describes a signaling method and protocol for RSVP-
   based admission control over IEEE 802-style LANs.  The protocol is
   designed to work both with the current generation of IEEE 802 LANs as
   well as with the recent work completed by the IEEE 802.1 committee.

1. Introduction

   New extensions to the Internet architecture and service models have
   been defined for an integrated services Internet [RFC-1633, RFC-2205,
   RFC-2210] so that applications can request specific qualities or
   levels of service from an internetwork in addition to the current IP
   best-effort service.  These extensions include RSVP, a resource
   reservation setup protocol, and definition of new service classes to
   be supported by Integrated Services routers.  RSVP and service class
   definitions are largely independent of the underlying networking
   technologies and it is necessary to define the mapping of RSVP and
   Integrated Services specifications onto specific subnetwork
   technologies.  For example, a definition of service mappings and

Top       Page 2 
   reservation setup protocols is needed for specific link-layer
   technologies such as shared and switched IEEE-802-style LAN

   This document defines SBM, a signaling protocol for RSVP-based
   admission control over IEEE 802-style networks.  SBM provides a
   method for mapping an internet-level setup protocol such as RSVP onto
   IEEE 802 style networks.  In particular, it describes the operation
   of RSVP-enabled hosts/routers and link layer devices (switches,
   bridges) to support reservation of LAN resources for RSVP-enabled
   data flows.  A framework for providing Integrated Services over
   shared and switched IEEE-802-style LAN technologies and a definition
   of service mappings have been described in separate documents [RFC-

2. Goals and Assumptions

   The SBM (Subnet Bandwidth Manager) protocol and its use for admission
   control and bandwidth management in IEEE 802 level-2 networks is
   based on the following architectural goals and assumptions:

      I. Even though the current trend is towards increased use of
      switched LAN topologies consisting of newer switches that support
      the priority queuing mechanisms specified by IEEE 802.1p, we
      assume that the LAN technologies will continue to be a mix of
      legacy shared/ switched LAN segments and newer switched segments
      based on IEEE 802.1p specification.  Therefore, we specify a
      signaling protocol for managing bandwidth over both legacy and
      newer LAN topologies and that takes advantage of the additional
      functionality (such as an explicit support for different traffic
      classes or integrated service classes) as it becomes available in
      the new generation of switches, hubs, or bridges.  As a result,
      the SBM protocol would allow for a range of LAN bandwidth
      management solutions that vary from one that exercises purely
      administrative control (over the amount of bandwidth consumed by
      RSVP-enabled traffic flows) to one that requires cooperation (and
      enforcement) from all the end-systems or switches in a IEEE 802

      II. This document specifies only a signaling method and protocol
      for LAN-based admission control over RSVP flows.  We do not define
      here any traffic control mechanisms for the link layer; the
      protocol is designed to use any such mechanisms defined by IEEE
      802.  In addition, we assume that the Layer 3 end-systems (e.g., a
      host or a router) will exercise traffic control by policing
      Integrated Services traffic flows to ensure that each flow stays
      within its traffic specifications stipulated in an earlier
      reservation request submitted for admission control.  This then

Top       Page 3 
      allows a system using SBM admission control combined with per flow
      shaping at end systems and IEEE-defined traffic control at link
      layer to realize some approximation of Controlled Load (and even
      Guaranteed) services over IEEE 802-style LANs.

      III. In the absence of any link-layer traffic control or priority
      queuing mechanisms in the underlying LAN (such as a shared LAN
      segment), the SBM-based admission control mechanism only limits
      the total amount of traffic load imposed by RSVP-enabled flows on
      a shared LAN. In such an environment, no traffic flow separation
      mechanism exists to protect the RSVP-enabled flows from the best-
      effort traffic on the same shared media and that raises the
      question of the utility of such a mechanism outside a topology
      consisting only of 802.1p-compliant switches.  However, we assume
      that the SBM-based admission control mechanism will still serve a
      useful purpose in a legacy, shared LAN topology for two reasons.
      First, assuming that all the nodes that generate Integrated
      Services traffic flows utilize the SBM-based admission control
      procedure to request reservation of resources before sending any
      traffic, the mechanism will restrict the total amount of traffic
      generated by Integrated Services flows within the bounds desired
      by a LAN administrator (see discussion of the NonResvSendLimit
      parameter in Appendix C).  Second, the best-effort traffic
      generated by the TCP/IP-based traffic sources is generally rate
      adaptive (using a TCP-style "slow start" congestion avoidance
      mechanism or a feedback-based rate adaptation mechanism used by
      audio/video streams based on RTP/RTCP protocols) and adapts to
      stay within the available network bandwidth.  Thus, the
      combination of admission control and rate adaptation should avoid
      persistent traffic congestion.  This does not, however, guarantee
      that non-Integrated-Services traffic will not interfere with the
      Integrated Services traffic in the absence of traffic control
      support in the underlying LAN infrastructure.

3. Organization of the rest of this document

   The rest of this document provides a detailed description of the
   SBM-based admission control procedure(s) for IEEE 802 LAN
   technologies. The document is organized as follows:

   *  Section 4 first defines the various terms used in the document and
      then provides an overview of the admission control procedure with
      an example of its application to a sample network.

   *  Section 5 describes the rules for processing and forwarding PATH
      (and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth
      Managers), SBMs, and DSBM clients.

Top       Page 4 
   *  Section 6 addresses the inter-operability issues when a DSBM may
      operate in the absence of RSVP signaling at Layer 3 or when
      another signaling protocol (such as SNMP) is used to reserve
      resources on a LAN segment.

   *  Appendix A describes the details of the DSBM election algorithm
      used for electing a designated SBM on a LAN segment when more than
      one SBM is present.  It also describes how DSBM clients discover
      the presence of a DSBM on a managed segment.

   *  Appendix B specifies the formats of SBM-specific messages used and
      the formats of new RSVP objects needed for the SBM operation.

   *  Appendix C describes usage of the DSBM to distribute configuration
      information to senders on a managed segment.

4. Overview

4.1. Definitions

   -  Link Layer or Layer 2 or L2: We refer to data-link layer
      technologies such as IEEE 802.3/Ethernet as L2 or layer 2.

   -  Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes
      and links interconnected without passing through a L3 forwarding
      function. One or more IP subnets can be overlaid on a L2 domain.

   -  Layer 2 or L2 devices: We refer to devices that only implement
      Layer 2 functionality as Layer 2 or L2 devices. These include
      802.1D bridges or switches.

   -  Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer
      model. This document is primarily concerned with networks that use
      the Internet Protocol (IP) at this layer.

   -  Layer 3 Device or L3 Device or End-Station: these include hosts
      and routers that use L3 and higher layer protocols or application
      programs that need to make resource reservations.

   -  Segment: A L2 physical segment that is shared by one or more
      senders. Examples of segments include (a) a shared Ethernet or
      Token-Ring wire resolving contention for media access using CSMA
      or token passing ("shared L2 segment"), (b) a half duplex link
      between two stations or switches, (c) one direction of a switched
      full-duplex link.

Top       Page 5 
   -  Managed segment: A managed segment is a segment with a DSBM
      present and responsible for exercising admission control over
      requests for resource reservation. A managed segment includes
      those interconnected parts of a shared LAN that are not separated
      by DSBMs.

   -  Traffic Class: An aggregation of data flows which are given
      similar service within a switched network.

   -  User_priority: User_priority is a value associated with the
      transmission and reception of all frames in the IEEE 802 service
      model: it is supplied by the sender that is using the MAC service.
      It is provided along with the data to a receiver using the MAC
      service. It may or may not be actually carried over the network:
      Token-Ring/802.5 carries this value (encoded in its FC octet),
      basic Ethernet/802.3 does not, 802.12 may or may not depending on
      the frame format in use. 802.1p defines a consistent way to carry
      this value over the bridged network on Ethernet, Token Ring,
      Demand-Priority, FDDI or other MAC-layer media using an extended
      frame format. The usage of user_priority is fully described in
      section 2.5 of 802.1D [IEEE8021D] and 802.1p [IEEE8021P] "Support
      of the Internal Layer Service by Specific MAC Procedures".

   -  Subnet: used in this memo to indicate a group of L3 devices
      sharing a common L3 network address prefix along with the set of
      segments making up the L2 domain in which they are located.

   -  Bridge/Switch: a layer 2 forwarding device as defined by IEEE
      802.1D. The terms bridge and switch are used synonymously in this

   -  DSBM: Designated SBM (DSBM) is a protocol entity that resides in a
      L2 or L3 device and manages resources on a L2 segment. At most one
      DSBM exists for each L2 segment.

   -  SBM: the SBM is a protocol entity that resides in a L2 or L3
      device and is capable of managing resources on a segment. However,
      only a DSBM manages the resources for a managed segment. When more
      than one SBM exists on a segment, one of the SBMs is elected to be
      the DSBM.

   -  Extended segment: An extended segment includes those parts of a
      network which are members of the same IP subnet and therefore are
      not separated by any layer 3 devices. Several managed segments,
      interconnected by layer 2 devices, constitute an extended segment.

Top       Page 6 
   -  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.

Top       Page 7 
   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    |
       +-------+      +-----+     /           +-----+   +--------+
          |             |        /               |          |
          |             |       /                |          |
                    |                                   |
                    |                                   |
                  +------+                          +-------+
                  | 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

   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.

Top       Page 8 
   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

Top       Page 9 
      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. 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). 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

Top       Page 10 
   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)

   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). 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
   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

Top       Page 11 
   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. 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,
      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

Top       Page 12 
      database) to the LAN_NHOP_L2 address as are applied normally to
      data packets destined to the address. Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP

   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. 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

Top       Page 13 
   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. 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

Top       Page 14 
   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. Processing the TCLASS Object

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

   *  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.

Top       Page 15 
      [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
      check its path state and check whether it has stored a TCLASS
      value. If so, it should include the TCLASS object in the outgoing
      RESV message after performing its own admission control. If no
      TCLASS value is stored, it must forward the RESV message without
      inserting a TCLASS object.

   *  When a DSBM client (residing at an L3 device such as a host or an
      edge router) receives the TCLASS object in a PATH message that it
      accepts over an interface, it should store the TCLASS object as
      part of its PATH state for the interface. Later, when the client
      forwards a RESV message for the same session on the interface, the
      client must include the TCLASS object (unchanged from what was
      received in the previous PATH message) in the RESV message it
      forwards over the interface.

   *  When a DSBM client receives a TCLASS object in an incoming RESV
      message over a managed segment and local admission control
      succeeds for the session for the outgoing interface over the
      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.

Top       Page 16 
   *  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.

(page 16 continued on part 2)

Next RFC Part