home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-issll-is802-sbm-04.txt < prev    next >
Text File  |  1997-07-25  |  129KB  |  3,306 lines
  1.  
  2.   Internet Engineering Task Force               Raj Yavatkar, Intel
  3.   INTERNET-DRAFT                                Don Hoffman, Sun Microsystems
  4.                                                 Yoram Bernet, Microsoft
  5.                                                 Fred Baker, Cisco
  6.  
  7.                                                 July 20, 1997
  8.                                                 Expires: January 30, 1998
  9.  
  10.                       SBM (Subnet Bandwidth Manager):
  11.        A Proposal for Admission Control over IEEE 802-style networks
  12.  
  13.                             Status of this Memo
  14.  
  15.   This document is an Internet-Draft.  Internet-Drafts are working
  16.   documents of the Internet Engineering Task Force (IETF), its areas,
  17.   and its working groups.  Note that other groups may also distribute
  18.   working documents as Internet-Drafts.
  19.  
  20.   Internet-Drafts are draft documents valid for a maximum of six months
  21.   and may be updated, replaced, or obsoleted by other documents at any
  22.   time.  It is inappropriate to use Internet-Drafts as reference
  23.   material or to cite them other than as ``work in progress.''
  24.  
  25.   To learn the current status of any Internet-Draft, please check the
  26.   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  27.   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
  28.   (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
  29.   Coast).
  30.  
  31.   This document is a product of the ISSLL (IS802) subgroup of the Integrated
  32.   Services working group of the Internet Engineering Task Force.  Comments are
  33.   solicited and should be addressed to the working group's mailing list at
  34.   issll@mercury.lcs.mit.edu, and/or the author(s).
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.   draft-ietf-issll-is802-sbm-04.txt                               [Page 1]
  54.  
  55.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  56.  
  57.  
  58.                                   Abstract
  59.  
  60.   This document outlines a signaling method and protocol for RSVP-based
  61.   admission control over IEEE 802-style LANs.  The proposed method is designed
  62.   to work both with the current generation of IEEE 802 LANs and new work being
  63.   defined within the IEEE 802 committee.
  64.  
  65.  
  66.  
  67.  
  68.                                What's Changed
  69.  
  70.   *    This draft obsoletes its previous version, draft-yavatkar-sbm-
  71.        ethernet-03.txt.
  72.  
  73.   *    Incorporated detailed message processing rules in to this document.
  74.  
  75.   *    Added additional MAC-level information in several SBM-specific
  76.        objects to facilitate efficient implementation in switches.
  77.  
  78.   *    Defined well-known multicast addresses for SBM-encapsulated PATH
  79.        messages.
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.   draft-ietf-issll-is802-sbm-04.txt                               [Page 2]
  110.  
  111.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  112.  
  113.  
  114.   1. Introduction
  115.  
  116.  
  117.   The IETF working groups such as Integrated Services and RSVP have been
  118.   chartered to develop extensions to the IP architecture and service model
  119.   which allow applications to request specific qualities or levels  of
  120.   service from an internetwork in addition to the current IP best-effort
  121.   service. The work at these working groups has led to the definition of
  122.   RSVP (ReSource reServation Protocol), a new resource reservation setup
  123.   protocol, and definition of new service classes to be supported by
  124.   Integrated Services routers. The specifications produced by these work-
  125.   ing groups are largely independent of underlying networking technolo-
  126.   gies.
  127.  
  128.   A separate working group, ISSLL (Integrated Services over Specific Link
  129.   Layers), is chartered to define the mapping of RSVP and Integrated Ser-
  130.   vices specifications onto specific subnetwork technologies. For example,
  131.   a definition of service mappings and reservation setup protocols is
  132.   needed for specific link-layer technologies such as shared and switched
  133.   IEEE-802-style LAN technologies.
  134.  
  135.   In particular, the IS802 subgroup of the ISSLL working group has
  136.   addressed the following three aspects of mapping the RSVP and Integrated
  137.   Services specifications over IEEE-802-style LAN technologies:
  138.  
  139.  
  140.   *    Specification of a framework [9] for providing Integrated Services
  141.        over shared and switched IEEE-802-style LAN technologies.
  142.  
  143.   *    Definition of service mappings [10] that describes the limitations
  144.        and ways of supporting Controlled Load [4] and Guaranteed Services
  145.        [5] using the inherent capabilities of the relevant IEEE 802 LAN
  146.        technologies.
  147.  
  148.   *    Specification of a signaling mechanism to map an internet-level
  149.        setup protocol such as RSVP onto IEEE 802 LAN technologies.
  150.  
  151.  
  152.   This document deals with the third of these aspects, and describes a
  153.   signaling method which uses the existing RSVP protocol to allow admis-
  154.   sion control over IEEE 802-style LANs.  In particular, it describes the
  155.   operation of RSVP-enabled hosts/routers and link layer devices
  156.   (switches, bridges) to support reservation of LAN resources for RSVP-
  157.   enabled data flows.
  158.  
  159.  
  160.  
  161.   2. Goals and Assumptions
  162.  
  163.  
  164.  
  165.   draft-ietf-issll-is802-sbm-04.txt                               [Page 3]
  166.  
  167.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  168.  
  169.  
  170.   Our proposal is  based on the following architectural goals and assump-
  171.   tions:
  172.  
  173.  
  174.  
  175.   I.   Even though the current trend is towards increased use of switched
  176.        LAN topologies consisting of newer switches that support the prior-
  177.        ity queuing mechanisms specified by IEEE 802.1p, we assume that the
  178.        LAN technologies will continue to be a mix of legacy shared/
  179.        switched LAN segments and newer switched segments based on IEEE
  180.        802.1p specification.  Therefore, our proposal specifies a signal-
  181.        ing mechanism for managing bandwidth over both legacy and newer LAN
  182.        topologies and takes advantage of the additional functionality
  183.        (such as an explicit support for different traffic classes or
  184.        integrated service classes) as it becomes available in the new gen-
  185.        eration of  switches, hubs, or bridges. As a result, our proposal
  186.        would allow for a range of LAN bandwidth management solutions that
  187.        vary from one that exercises purely administrative control (over
  188.        the  amount of bandwidth consumed by RSVP-enabled traffic flows) to
  189.        one that requires cooperation (and enforcement) from all the end-
  190.        systems or switches in a IEEE 802 LAN.
  191.  
  192.  
  193.   II.  This document specifies only a signaling method and protocol for
  194.        LAN-based admission control over RSVP flows.  We assume that the
  195.        IEEE 802 working groups will specify and standardize the traffic
  196.        control mechanisms needed at the link layer. In addition, we assume
  197.        that the Layer 3 end-systems (e.g., a host or a router) will exer-
  198.        cise traffic control by policing Integrated Services traffic flows
  199.        to ensure that each flow stays within its traffic specifications
  200.        stipulated in an earlier reservation request submitted for admis-
  201.        sion control.
  202.  
  203.        We believe that the LAN-based admission control when combined with
  204.        per-flow policing  at end-systems and traffic control and priority
  205.        queuing at link layer should realize some approximation of Con-
  206.        trolled Load (and even Guaranteed) services  over IEEE 802-style
  207.        LANs.
  208.  
  209.  
  210.   III. In the absence of any link-layer traffic control or priority queu-
  211.        ing mechanisms in the underlying LAN (such as a shared LAN seg-
  212.        ment), the proposed mechanism only limits the total amount of
  213.        traffic load imposed by RSVP-enabled flows on a shared LAN.  In
  214.        such an environment, no traffic flow separation mechanism exists to
  215.        protect the RSVP-enabled flows from the best-effort traffic on the
  216.        same shared media and that raises the question of the utility of
  217.        such a mechanism outside a topology consisting only of 802.1p-
  218.  
  219.  
  220.  
  221.   draft-ietf-issll-is802-sbm-04.txt                               [Page 4]
  222.  
  223.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  224.  
  225.  
  226.        compliant switches. However, we assume that the proposed signaling
  227.        mechanism will still serve a useful purpose in a legacy, shared LAN
  228.        topology for two reasons. First, assuming that all the nodes that
  229.        generate Integrated Services traffic flows utilize the proposed
  230.        admission control procedure to request reservation of resources
  231.        before sending any traffic, the proposed mechanism will restrict
  232.        the total amount of traffic generated by Integrated Services flows
  233.        within the bounds desired by a LAN administrator. Second, the
  234.        best-effort traffic generated by the TCP/IP-based traffic sources
  235.        is generally rate-adaptive (using a TCP-style "slow start" conges-
  236.        tion avoidance mechanism or a feedback-based rate adaptation
  237.        mechanism used by audio/video streams based on RTP/RTCP protocols)
  238.        and adapts to stay within the available network bandwidth. Thus,
  239.        the combination of admission control and rate adaptation should
  240.        avoid persistent traffic congestion. This does not, however,
  241.        guarantee that non-Integrated-Services traffic will not interfere
  242.        with the Integrated Services traffic in the absence of traffic con-
  243.        trol support in the underlying LAN infrastructure.
  244.  
  245.  
  246.  
  247.  
  248.  
  249.   3. Organization of the rest of this document
  250.  
  251.  
  252.   The rest of this document provides a detailed description of the SBM-
  253.   based admission control procedure(s) for IEEE 802 LAN technologies. The
  254.   document is organized as follows:
  255.  
  256.  
  257.   *    Section 4 first defines the various terms used in the document and
  258.        then provides an overview of the admission control procedure with
  259.        an example of its application to a sample network.
  260.  
  261.  
  262.   *    Section 5  describes the rules for processing and forwarding PATH
  263.        (and PATH_TEAR) messages at DSBMs, SBMs, and DSBM clients.
  264.  
  265.  
  266.   *    Section 6 addresses the inter-operability issues when a DSBM may
  267.        operate in the absence of RSVP signaling at Layer 3 or when another
  268.        signaling protocol (such as SNMP) to reserve resources on a LAN
  269.        segment.
  270.  
  271.  
  272.  
  273.   *    Appendix A describes the details of the DSBM election algorithm
  274.  
  275.  
  276.  
  277.   draft-ietf-issll-is802-sbm-04.txt                               [Page 5]
  278.  
  279.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  280.  
  281.  
  282.        used for electing a designated SBM on a LAN segment when more than
  283.        one SBM is present.  It also describes how DSBM clients discover
  284.        the presence of a DSBM on a managed segment.
  285.  
  286.  
  287.   *    Appendix B specifies the formats of SBM-specific messages used and
  288.        the formats of new RSVP objects needed for the SBM operation.
  289.  
  290.  
  291.  
  292.   4. Overview
  293.  
  294.  
  295.   4.1. Definitions
  296.  
  297.  
  298.   -    Link Layer/Layer 2 or L2: We refer to link layer technologies such
  299.        as IEEE 802.3/Ethernet as L2 or layer 2.
  300.  
  301.   -    Layer 2 or L2 domain: An L2 domain is a set of nodes and links
  302.        interconnected without passing through a L3 (Layer 3 or IP) for-
  303.        warding function. An IP subnet corresponds to a L2 domain.
  304.  
  305.   -    Layer2 or L2 devices: We refer to devices that only implement
  306.        Layer2 functionality as Layer2 or L2 devices and these include
  307.        802.1D bridges or switches.
  308.  
  309.  
  310.   -    Layer 3 or L3 devices: these include hosts and routers that use L3
  311.        and higher layer protocols or application programs that need to
  312.        make resource reservations.
  313.  
  314.  
  315.   -    Segment: A L2 segment that is shared by one or more senders. Thus,
  316.        a segment includes a "yellow" wire (the term "yellow wire" is used
  317.        to refer to a physical segment shared by many L2 or L3 devices.
  318.        Such devices typically resolve contention for media access using
  319.        CSMA or token passing), a switched half duplex link, or a switched
  320.        full-duplex link.
  321.  
  322.  
  323.   -    DSBM: Designated SBM (DSBM) is a L2 or L3 device that manages
  324.        resources on a L2 segment. At most one DSBM exists for each L2 seg-
  325.        ment.
  326.  
  327.  
  328.   -    SBM: the SBM is a L2 or L3 device that is capable of managing
  329.        resources on a segment. As an SBM, it is not actually managing
  330.  
  331.  
  332.  
  333.   draft-ietf-issll-is802-sbm-04.txt                               [Page 6]
  334.  
  335.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  336.  
  337.  
  338.        resources. When more than one SBM exists on a segment, one of the
  339.        SBMs is elected to be a DSBM.
  340.  
  341.  
  342.   -    Managed segment: A managed segment is a segment with a DSBM present
  343.        and responsible for exercising admission control over requests for
  344.        resource reservation. A managed segment includes those intercon-
  345.        nected parts of a shared LAN that are not separated by DSBMs.
  346.  
  347.  
  348.   -    Extended segment: An extended segment includes those parts of a
  349.        network which are members of the same IP subnet and therefore are
  350.        not separated by any layer 3 devices. Several managed segments,
  351.        interconnected by layer 2 devices, constitute an extended segment.
  352.  
  353.  
  354.  
  355.   -    DSBM clients: These are devices that transmit traffic onto a
  356.        managed segment and use the services of a DSBM for the managed seg-
  357.        ment for admission control over a LAN segment. Only the L3 devices
  358.        such as hosts and routers are expected to act as sources of traffic
  359.        that requires resource reservations, and, therefore, DSBM clients
  360.        are L3 devices.
  361.  
  362.  
  363.   -    SBM transparent devices: An "SBM transparent" device is unaware of
  364.        SBMs or DSBMs (though it may or may not be RSVP aware) and, there-
  365.        fore, does not participate in the SBM-based admission control pro-
  366.        cedure over a managed segment. Such a device uses standard forward-
  367.        ing rules appropriate for the device and is  transparent with
  368.        respect to SBM.  An example of such a L2 device is a legacy switch
  369.        that does not participate in resource reservation. In addition, an
  370.        L3 device may also be SBM transparent. For example, such an L3 dev-
  371.        ice may participate in a L3 resource reservation protocol (RSVP)
  372.        and use standard forwarding rules for RSVP messages appropriate for
  373.        the device and is, thus, transparent with respect to the SBM pro-
  374.        cedures.
  375.  
  376.  
  377.   -    Layer 3 and layer 2 addresses: We refer to layer 3 addresses of
  378.        L3/L2 devices as "L3 addresses" and layer2 addresses as "L2
  379.        addresses". This convention will be used in the rest of the docu-
  380.        ment to distinguish between Layer 3 and layer 2 addresses used to
  381.        refer to RSVP next hop (NHOP) and previous hop (PHOP) devices. For
  382.        example, in conventional RSVP message processing RSVP_HOP object in
  383.        a PATH message carries the L3 address of the previous hop device
  384.        and we will refer to the address contained in the RSVP_HOP object
  385.        as the RSVP_HOP_L3 address and the corresponding MAC address of the
  386.  
  387.  
  388.  
  389.   draft-ietf-issll-is802-sbm-04.txt                               [Page 7]
  390.  
  391.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  392.  
  393.  
  394.        previous hop device will be referred to as the RSVP_HOP_L2 address.
  395.  
  396.  
  397.  
  398.   4.2. Outline of the SBM-based Admission Control Procedure
  399.  
  400.  
  401.   We assume that a Designated SBM (DSBM) exists for each managed segment
  402.   and is responsible for admission control over the resource reservation
  403.   requests originating from the DSBM clients in that segment.  Given a
  404.   segment, one  or more SBMs may exist on the segment. For example, many
  405.   SBM-capable devices may be attached to a yellow wire whereas two SBM-
  406.   capable switches may share a half-duplex switched segment. In that case,
  407.   a single DSBM is elected for the segment. A fail-safe procedure for
  408.   dynamically electing the DSBM is described in Appendix A.  The presence
  409.   of a DSBM makes the segment a "managed segment". Sometimes, two or more
  410.   L2 segments may be interconnected  by SBM transparent devices. In that
  411.   case, a single DSBM will manage the resources for those segments treat-
  412.   ing the collection of such segments as a single managed segment for the
  413.   purpose of admission control.
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.   draft-ietf-issll-is802-sbm-04.txt                               [Page 8]
  446.  
  447.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  448.  
  449.  
  450.   4.2.1. Basic Algorithm
  451.  
  452.  
  453.   Figure 1 - An Example of a Managed Segment.
  454.  
  455.  
  456.          +-------+      +-----+     +------+    +-----+   +--------+
  457.          |Router |      | Host|     | DSBM |    | Host|   | Router |
  458.          | R2    |      | C   |     +------+    |  B  |   |  R3    |
  459.          +-------+      +-----+     /           +-----+   +--------+
  460.             |             |        /               |          |
  461.             |             |       /                |          |
  462.      ==============================================================LAN
  463.                       |                                   |
  464.                       |                                   |
  465.                     +------+                          +-------+
  466.                     | Host |                          | Router|
  467.                     |  A   |                          |   R1  |
  468.                     +------+                          +-------+
  469.  
  470.  
  471.   Figure 1 shows an example of a managed segment in a L2 domain that
  472.   interconnects a set of hosts and routers. For the purpose of this dis-
  473.   cussion, we ignore the actual physical topology of the L2 domain (assume
  474.   it is a yellow wire and a single managed segment represents the entire
  475.   L2 domain). A single SBM device is designated  to be the DSBM for the
  476.   managed segment. We will provide examples of operation of the DSBM over
  477.   switched and shared segments later in the document.
  478.  
  479.  
  480.   The basic DSBM-based admission control procedure works as follows:
  481.  
  482.  
  483.   1.   DSBM Initialization: As part of its initial configuration, DSBM
  484.        obtains information such as the maximum bandwidth that can be
  485.        reserved on each managed segment under its control. Configuration
  486.        is likely to be static with the current L2/L3 devices. Future work
  487.        may allow for dynamic discovery of this information. This document
  488.        does not specify the configuration mechanism.
  489.  
  490.  
  491.   2.   DSBM Client Initialization: For each interface attached, a DSBM
  492.        client determines whether a DSBM exists on the interface. The pro-
  493.        cedure for discovering and verifying the existence of the DSBM for
  494.        an attached segment is described in Appendix A. If the client
  495.        itself is capable of serving as the DSBM on the segment, it may
  496.        choose to participate in the election to become the DSBM. At the
  497.        start, a DSBM client first verifies that a DSBM exists in its L2
  498.  
  499.  
  500.  
  501.   draft-ietf-issll-is802-sbm-04.txt                               [Page 9]
  502.  
  503.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  504.  
  505.  
  506.        domain  so that it can communicate with the DSBM for admission con-
  507.        trol purposes.
  508.  
  509.  
  510.  
  511.   3.   DSBM-based Admission Control: To request reservation of resources
  512.        (LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable L3 dev-
  513.        ices such as  hosts and routers) follow the following steps:
  514.  
  515.  
  516.     a)   When a DSBM client  sends or forwards a PATH message over an
  517.          interface attached to a  managed segment, it sends the PATH mes-
  518.          sage to its DSBM instead of sending it to the RSVP session desti-
  519.          nation address (as is done in conventional RSVP processing).
  520.          After processing (and possibly updating an ADSPEC), the DSBM will
  521.          forward the PATH message toward its destination address. As part
  522.          of its processing, the DSBM builds and maintains a PATH state for
  523.          the session and notes the previous hop that sent it the PATH mes-
  524.          sage.
  525.  
  526.          Let us consider the managed segment in Figure 1. Assume that a
  527.          sender to a RSVP session (session address specifies the IP
  528.          address of host A on the managed segment in Figure 1) resides
  529.          outside the L2 domain of the managed segment and sends a PATH
  530.          message that arrives at router R1 which is on the path towards
  531.          host A.
  532.  
  533.          Router R1, which is a DSBM client, forwards the  PATH message
  534.          from the sender to its DSBM. The DSBM processes the PATH message
  535.          and forwards the PATH message towards the RSVP session address
  536.          (Detailed message processing and forwarding rules are described
  537.          in Section 5).  In the process, the DSBM builds the PATH state,
  538.          remembers the router R1 as the previous hop for the session, puts
  539.          its own IP address in the PHOP (RSVP_HOP) object, and effectively
  540.          inserts itself as an intermediate node between the sender (or R1
  541.          in Figure 1) and the  receiver (host A) on the managed segment.
  542.  
  543.     b)   When an application on host A wishes to make a reservation for
  544.          the RSVP session, host A follows the standard RSVP message pro-
  545.          cessing rules and sends a RSVP RESV message to the previous hop
  546.          address (the DSBMs address) obtained from the PHOP object in the
  547.          previously received PATH message.
  548.  
  549.  
  550.     c)   The DSBM processes the RSVP RESV message based on the bandwidth
  551.          available and returns an ResvErr message to the requester (host
  552.          A) if the request cannot be granted. The admission control algo-
  553.          rithm at DSBM ensures that sufficient bandwidth is available on
  554.  
  555.  
  556.  
  557.   draft-ietf-issll-is802-sbm-04.txt                              [Page 10]
  558.  
  559.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  560.  
  561.  
  562.          managed segments  between the NHOP (requester) and the PHOP
  563.          (sender/router) before accepting a request. If sufficient
  564.          resources are available and the reservation request is granted,
  565.          the DSBM forwards the RESV message towards the PHOP(s) based on
  566.          its local PATH state for the session. The DSBM merges reservation
  567.          requests for the same session as and when possible using the
  568.          rules similar to the conventional RSVP processing.
  569.  
  570.  
  571.     d)   If the L2 domain contains more than one managed segment, the
  572.          requester (host A) and the forwarder (router R1) may be separated
  573.          by more than one managed segment. In that case, the original PATH
  574.          message would propagate through many DSBMs (one for each managed
  575.          segment on the path from R1 to A) setting up PATH state at each
  576.          DSBM. Therefore, the RESV message would propagate hop-by-hop in
  577.          reverse through the intermediate DSBMs and eventually reach the
  578.          original forwarder (router R1) on the L2 domain if admission con-
  579.          trol at all DSBMs succeeds.
  580.  
  581.  
  582.  
  583.  
  584.   4.2.2. Enhancements  to the conventional RSVP operation
  585.  
  586.  
  587.   The addition of a DSBM for admission control over managed segments
  588.   results in some additions to the RSVP message processing rules at a DSBM
  589.   client. In the following, we first motivate and summarize the additions
  590.   and a detailed description of the message processing and forwarding
  591.   rules at (D)SBMs and DSBM clients is provided in Section 5:
  592.  
  593.  
  594.   -    Normal RSVP forwarding rules  apply at a DSBM client when it is not
  595.        forwarding an outgoing PATH message over a managed segment. How-
  596.        ever, outgoing PATH messages on a managed segment are sent to the
  597.        DSBM for the corresponding managed segment.
  598.  
  599.  
  600.   -    In conventional RSVP processing over point-to-point links, RSVP
  601.        nodes (hosts/routers) use NHOP and PHOP objects to keep track of
  602.        the next hop (downstream node in the path of data packets in a
  603.        traffic flow) and the previous hop (upstream nodes with respect to
  604.        the data flow) nodes on the path between a sender and a receiver.
  605.        Routers along the path of a PATH message forward the message
  606.        towards the destination address based on the L3 routing (packet
  607.        forwarding) tables.
  608.  
  609.        For example, consider the L2 domain in Figure 1. Assume that both
  610.  
  611.  
  612.  
  613.   draft-ietf-issll-is802-sbm-04.txt                              [Page 11]
  614.  
  615.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  616.  
  617.  
  618.        the sender (some host X) and the receiver (some host Y) in a RSVP
  619.        session reside outside the L2 domain shown in the Figure, but PATH
  620.        messages from the sender to its receiver pass through the routers
  621.        in the L2 domain using it as a transit subnet. Assume that the PATH
  622.        message from the sender X arrives at the router R1. R1 uses its
  623.        local routing information to decide which next hop router (either
  624.        router R2 or router R3) to use to forward the PATH message towards
  625.        host Y. However, when the path traverses a L2 domain consisting of
  626.        segments using IEEE 802 LAN technologies, we require the PATH and
  627.        RESV messages to go through a DSBM for each managed segment. Such a
  628.        L2 domain may span many managed segments (and DSBMs) and, typi-
  629.        cally, L2 devices (such as a switch) will serve as the DSBM for the
  630.        managed segments in a  switched topology. When R1 forwards the PATH
  631.        message to its DSBM (an L2 device), the DSBM will not have the L3
  632.        routing information necessary to select the egress router (between
  633.        R2 and R3) before forwarding the PATH message.  To ensure correct
  634.        operation and routing of RSVP messages, we must provide additional
  635.        forwarding information to DSBMs.
  636.  
  637.        For this purpose, we introduce new RSVP objects called LAN_NHOP
  638.        address objects  that keep track of the next L3 hop as the PATH
  639.        message traverses an L2 domain between two L3 entities (RSVP PHOP
  640.        and NHOP nodes).
  641.  
  642.  
  643.  
  644.   -    When a DSBM client (a host or a router acting as the originator of
  645.        a PATH message) sends out a PATH message to its DSBM, it must
  646.        include LAN_NHOP information in the message. In the case of a uni-
  647.        cast destination, the LAN_NHOP address specifies the destination
  648.        address (if the destination exists within the L2 domain) or the
  649.        address of the next hop router towards the destination. In our
  650.        example of an RSVP session involving the sender X and receiver Y
  651.        with L2 domain in Figure 1 acting as the transit subnet, R1 is the
  652.        ingress node that receives the PATH message.  R1 first determines
  653.        that R2 is the next hop router (or the egress node in the L2 domain
  654.        for the session address) and then inserts a LAN_NHOP object that
  655.        specifies R2's IP address. When a DSBM receives a PATH message, it
  656.        can now look at the address in the LAN_NHOP object and forward the
  657.        PATH message towards the egress node after processing the PATH mes-
  658.        sage.  However, we expect the L2 devices (such as switches) to act
  659.        as DSBMs on the path within the L2 domain and it may not be reason-
  660.        able to expect these devices to have an ARP capability to determine
  661.        the  MAC address (we call it L2ADDR for Layer 2 address)
  662.        corresponding to  the IP address in the LAN_NHOP object.
  663.  
  664.        Therefore, we require that the LAN_NHOP information (generated by
  665.        the L3 device) include both the IP address (LAN_NHOP_L3 address)
  666.  
  667.  
  668.  
  669.   draft-ietf-issll-is802-sbm-04.txt                              [Page 12]
  670.  
  671.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  672.  
  673.  
  674.        and the corresponding MAC address (LAN_NHOP_L2 address ) for the
  675.        next L3 hop over the L2 domain. The exact format of the LAN_NHOP
  676.        information and relevant objects is described later in Appendix B.
  677.  
  678.  
  679.   -    When a DSBM receives a RSVP PATH message, it processes the PATH
  680.        message  according to the PATH processing rules described in the
  681.        RSVP specification. In particular, the DSBM retrieves the IP
  682.        address of the previous hop from the RSVP_HOP object in the PATH
  683.        message and stores the PHOP address in its PATH state.  It then
  684.        forwards the PATH message with the PHOP (RSVP_HOP) object modified
  685.        to reflect its own IP address (RSVP_HOP_L3 address). Thus, the DSBM
  686.        inserts itself as an intermediate hop in the chain of nodes in the
  687.        path between two L3 nodes across the L2 domain.
  688.  
  689.  
  690.   -    The PATH state in a DSBM is used for forwarding subsequent RESV
  691.        messages as per the standard RSVP message processing rules.  When
  692.        the DSBM receives a RESV message, it processes the message and for-
  693.        wards it to appropriate PHOP(s) based on its PATH state.
  694.  
  695.  
  696.   -    Because a DSBM inserts itself as a hop between two RSVP nodes in
  697.        the path of a RSVP flow, all RSVP related messages (such as PATH,
  698.        PATH_TEAR, RESV, RESV_CONFM, RESV_TEAR, and RESV_ERR) now flow
  699.        through the DSBM.  In particular, a PATH_TEAR message is routed
  700.        exactly through the intermediate DSBM(s) as its corresponding PATH
  701.        message and the local PATH state is first cleaned up at each inter-
  702.        mediate hop before the PATH_TEAR message gets forwarded.
  703.  
  704.  
  705.  
  706.   -    So far, we have described how the PATH message propagates through
  707.        the L2 domain establishing PATH state at each DSBM along the
  708.        managed segments in the path. The layer 2 address (LAN_NHOP_L2
  709.        address) in the LAN_NHOP object helps the L2 devices along the path
  710.        in forwarding the PATH message toward the next L3 hop.
  711.  
  712.        In the conventional RSVP message processing, the PATH state esta-
  713.        blished along the nodes on a path is used to route the RESV message
  714.        from a receiver to a sender in an RSVP session. As each intermedi-
  715.        ate node builds the path state, it remembers the previous hop
  716.        (stores the PHOP IP address available in the RSVP_HOP object of an
  717.        incoming message) that sent it the PATH message and, when the RESV
  718.        message arrives, the intermediate node simply uses the stored PHOP
  719.        address to forward the RESV after processing it successfully.
  720.  
  721.        In our case, we expect the L2 devices to act as DSBMs (and,
  722.  
  723.  
  724.  
  725.   draft-ietf-issll-is802-sbm-04.txt                              [Page 13]
  726.  
  727.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  728.  
  729.  
  730.        therefore, intermediate hops in an L2 domain) along the path
  731.        between a sender (PHOP) and receiver (NHOP). Thus, when a RESV mes-
  732.        sage arrives at a DSBM, it must use the stored PHOP IP address to
  733.        forward the RESV message to its previous hop. However, it may not
  734.        be reasonable to expect the L2 devices to have an ARP cache or the
  735.        ARP capability to map the PHOP IP address to its corresponding L2
  736.        address before forwarding the RESV message.
  737.  
  738.        To obviate the need for such address mapping at L2 devices, we use
  739.        a RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object
  740.        includes  the  Layer 2 address (L2ADDR) of the previous hop and
  741.        complements the L3 address information included in the RSVP_HOP
  742.        object (RSVP_HOP_L3 address).
  743.  
  744.        When a L3 device constructs and forwards a PATH message over a
  745.        managed segment, it  includes its IP address (IP address of the
  746.        interface over which PATH is sent) in the RSVP_HOP object and add a
  747.        RSVP_HOP_L2 object that includes the corresponding L2 address for
  748.        the interface. When a device in the L2 domain receives such a PATH
  749.        message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2
  750.        objects in its PATH state and then overwrites the RSVP_HOP and
  751.        RSVP_HOP_L2 objects with its own addresses before forwarding the
  752.        PATH message over a managed segment.
  753.  
  754.        The exact format of RSVP_HOP_L2 object is specified in APPENDIX B.
  755.  
  756.  
  757.   -    When an RSVP session address is a multicast address and an SBM,
  758.        DSBM, and DSBM clients share the same yellow wire, it is possible
  759.        for an SBM or a DSBM client to receive one or more copies of a PATH
  760.        message that it forwarded earlier when a DSBM on the same wire for-
  761.        wards it (See Section 5.8 for an example of such a case). To facil-
  762.        itate detection of such loops, we use a new RSVP object called the
  763.        LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs
  764.        reflecting a PATH message onto the interface over which it arrived
  765.        earlier) must overwrite (or add if the PATH message does NOT
  766.        already include  a LAN_LOOPBACK object) the LAN_LOOPBACK object in
  767.        the PATH message with their own unicast IP address.
  768.  
  769.        Now, a SBM or a DSBM client can easily detect and discard the
  770.        duplicates by checking the contents of the LAN_LOOPBACK object (a
  771.        duplicate PATH message will list a device's own interface address
  772.        in the LAN_LOOPBACK object). Appendix B specifies the exact format
  773.        of the LAN_LOOPBACK object.
  774.  
  775.  
  776.   -    The model proposed by the Integrated Services working group
  777.        requires isolation of traffic flows from each other during their
  778.  
  779.  
  780.  
  781.   draft-ietf-issll-is802-sbm-04.txt                              [Page 14]
  782.  
  783.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  784.  
  785.  
  786.        transit across a network. The motivation for traffic flow separa-
  787.        tion is to provide Integrated Services flows protection from mis-
  788.        behaving flows and other best-effort traffic that share the same
  789.        path. The basic IEEE 802.3/Ethernet networks do not provide any
  790.        notion of traffic classes to discriminate among different flows
  791.        that request different service classes. However, IEEE 802.1p
  792.        defines (see [10, 11] for further details) a way of assigning dif-
  793.        ferent "user priority" values to packets from different flows so
  794.        that packets in different service classes can be discriminated by
  795.        L2 devices. The priority value assigned to each packet will be car-
  796.        ried in the frame header using the new, extended frame format
  797.        defined by IEEE 802.1Q [12]. IEEE, however, makes no recommenda-
  798.        tions about how a sender or network should use the priority values.
  799.        The IS802 subgroup of the ISSLL working group makes recommendations
  800.        on the usage of the user priority values as described in [10].
  801.  
  802.        Under the Integrated Services model, L3 devices that transmit
  803.        traffic flows onto a IEEE 802 segment are expected to perform per-
  804.        flow policing to ensure that the flows do not exceed their traffic
  805.        specification as specified during admission control. In addition,
  806.        L3 devices may label the frames in such flows with a user-priority
  807.        value to identify their service class.
  808.  
  809.        For the purpose of this discussion, we will refer to the priority
  810.        value carried in the extended frame header as a "traffic class" of
  811.        a packet. Under the ISSLL model, the L3 devices, that send traffic
  812.        and that use the SBM protocol, are not expected to select the
  813.        traffic class of outgoing packets. Instead, we assume that once a
  814.        sender sends a  PATH message, downstream switches (L2 devices) will
  815.        insert a new traffic class object (TCLASS object) in the PATH mes-
  816.        sage that travels to the next L3 device (L3 NHOP for the PATH mes-
  817.        sage). The L3 device that receives the PATH message is expected to
  818.        remove and store the TCLASS object as part of its PATH state for
  819.        the session. Later, when the same L3 device needs to forward a RSVP
  820.        RESV message towards the original sender, it must include the
  821.        TCLASS object in the RESV message. When the RESV message arrives at
  822.        the original sender, it is expected to pass the user_priority value
  823.        in the TCLASS object to its local packet classifier (traffic con-
  824.        trol)  so that subsequent, outgoing data packets for this RSVP flow
  825.        will have the user priority value included in the extended MAC
  826.        header.
  827.  
  828.        The format of the TCLASS object is specified in Appendix B.  In
  829.        summary, use of TCLASS objects requires following additions to the
  830.        conventional RSVP message processing at DSBMs, SBMs, and DSBM
  831.        clients:
  832.  
  833.  
  834.  
  835.  
  836.  
  837.   draft-ietf-issll-is802-sbm-04.txt                              [Page 15]
  838.  
  839.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  840.  
  841.  
  842.     *    If an SBM receives a PATH or RESV message with a TCLASS object
  843.          over a managed segment in a L2 domain and needs to forward it
  844.          over a managed segment in the same L2 domain, it should forward
  845.          the message without changing the contents of the TCLASS object.
  846.  
  847.  
  848.     *    When a DSBM client (an L3 device such as a host or an edge
  849.          router) receives the TCLASS object in a PATH message that it
  850.          accepts over an interface, it should store the TCLASS object as
  851.          part of its PATH state for the interface. Later, when the client
  852.          forwards a RESV message for the same session on the interface,
  853.          the client must include the TCLASS message in the RESV message it
  854.          forwards over the interface.
  855.  
  856.  
  857.     *    When a DSBM client receives a TCLASS object in an incoming RESV
  858.          message over a managed segment and local admission control
  859.          succeeds for the session for the outgoing interface over the
  860.          managed segment, the client must pass the user_priority value in
  861.          the TCLASS object to its local packet classifier so that outgoing
  862.          data packets sent subsequently over the interface will contain
  863.          the appropriate value in their MAC-layer frame header.
  864.  
  865.  
  866.     *    When a DSBM receives a PATH message with a  TCLASS object, it
  867.          must forward it unchanged. When a DSBM receives a  RESV message
  868.          with a TCLASS object, it may use the traffic class information
  869.          for its own admission control for the managed segment. If admis-
  870.          sion control succeeds, it must forward the TCLASS object in the
  871.          RESV message.
  872.  
  873.  
  874.  
  875.     *    When an L3 device receives a PATH message over a managed segment
  876.          in one L2 domain and it needs to forward the PATH message over an
  877.          interface outside that domain, the L3 device must remove the
  878.          TCLASS object (along with LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK
  879.          objects) before forwarding the PATH message.  If the outgoing
  880.          interface is on a separate L2 domain, these objects may be regen-
  881.          erated according to the processing rules applicable to that
  882.          interface.
  883.  
  884.  
  885.  
  886.  
  887.   5. Detailed Message Processing Rules
  888.  
  889.  
  890.  
  891.  
  892.  
  893.   draft-ietf-issll-is802-sbm-04.txt                              [Page 16]
  894.  
  895.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  896.  
  897.  
  898.   5.1. Additional Notes on Terminology
  899.  
  900.  
  901.  
  902.   *    An L2 device may have several interfaces with attached segments
  903.        that are part of the same L2 domain. A switch in a L2 domain is an
  904.        example of such a device. A device which has several interfaces may
  905.        act in different capacities on each interface. For example, a dev-
  906.        ice could be an SBM on interface A, and a DSBM on interface B.
  907.  
  908.  
  909.   *    The SBMs functionality is a superset of the DSBM Client's func-
  910.        tionality. Further, the DSBMs functionality is a superset of the
  911.        SBM's functionality. For the purpose of this discussion, we iden-
  912.        tify a device by its highest level of functionality. So - even
  913.        though an SBM includes the functionality of a DSBM Client, it is
  914.        referred to as an SBM only (not as an SBM and a DSBM Client).
  915.  
  916.  
  917.   *    Layer 3 devices can be DSBM clients, SBMs, DSBMs or none of the
  918.        above ("SBM transparent"). DSBM clients are always L3 devices.
  919.  
  920.  
  921.   *    Layer 2 devices can be SBMs,  DSBMs or none of the above (SBM tran-
  922.        sparent). There is no marginal value in a layer 2 device being a
  923.        DSBM client vs. SBM transparent. Therefore, layer 2 devices will
  924.        never be DSBM clients.
  925.  
  926.  
  927.        5.2. Use Of a Reserved IP Multicast Address
  928.  
  929.  
  930.   As stated earlier, we require that the DSBM clients forward the RSVP
  931.   PATH messages to their DSBMs in a L2 domain before they reach the next
  932.   L3 hop in the path. The RSVP PATH messages are typically addressed to
  933.   their destination address (RSVP session address which can be either an
  934.   IP unicast or multicast address). However, in the case of a managed seg-
  935.   ment, the RSVP PATH messages are sent to the DSBM's unicast IP address
  936.   (we refer to this address as the "DSBMAddress").  When a L2 device acts
  937.   as the DSBM, the device is expected to receive the PATH message and hand
  938.   it over to the local DSBM agent (Since the PATH message is directed to
  939.   the L2 device, there is no need for the L2 device to snoop for L3 RSVP
  940.   messages).
  941.  
  942.   DSBM clients discover the unicast IP address of the DSBM using a method
  943.   described as part of the election algorithm discussed in APPENDIX A.  To
  944.   facilitate an  election of a DSBM and to allow dynamic DSBM-client bind-
  945.   ing, the election algorithm relies on a reserved IP multicast address.
  946.  
  947.  
  948.  
  949.   draft-ietf-issll-is802-sbm-04.txt                              [Page 17]
  950.  
  951.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  952.  
  953.  
  954.   In addition, the reserved multicast address is also used for easy for-
  955.   warding of PATH messages from a DSBM to its clients.
  956.  
  957.   For example, when a DSBM forwards a PATH message towards the next hop,
  958.   it need not be aware of the identity of multiple DSBM clients or SBMs on
  959.   the path towards the L3 NHOP. In addition, L2 devices (SBMs) on the path
  960.   should be able to easily detect and capture PATH messages without
  961.   requiring any snooping for RSVP messages. To facilitate forwarding of
  962.   PATH messages from a DSBM to other SBMs and DSBM clients as well as to
  963.   enable easy detection and capture of PATH messages at L2 devices, we
  964.   require that a PATH message forwarded by a DSBM be addressed using a
  965.   logical address rather than a physical address.
  966.  
  967.   We make use of a reserved IP multicast address for this purpose.  We
  968.   require that the PATH messages forwarded from a DSBM to its clients or
  969.   to other SBMs be addressed using a reserved IP multicast address. Thus,
  970.   SBMs  on a L2 device can simply subscribe to the reserved IP multicast
  971.   address on the interfaces corresponding to managed segments to easily
  972.   receive PATH messages.
  973.  
  974.   On the other hand, RSVP Resv messages need not be multicast as they are
  975.   expected to be unicast to the previous hop address stored as part of the
  976.   PATH state at each intermediate hop.
  977.  
  978.  
  979.  
  980.   We define use of one reserved IP multicast address called the "AllSBM
  981.   Address". The address is chosen from the range of local multicast
  982.   addresses, such that:
  983.  
  984.  
  985.   *    It is not passed through layer 3 devices.
  986.  
  987.  
  988.   *    It is passed transparently through layer 2 devices which are SBM
  989.        transparent.
  990.  
  991.  
  992.   *    It is configured in the permanent database of layer 2 devices which
  993.        are SBMs or DSBMs, such that messages directed to this address are
  994.        forwarded to the SBM management entity in these devices. This obvi-
  995.        ates the need for these devices to explicitly snoop for SBM related
  996.        control packets.
  997.  
  998.  
  999.   *    The reserved address is 224.0.1.59 (AllSBMAddress).
  1000.  
  1001.   The two addresses, AllSBMAddress and DSBMAddress, are used as described
  1002.  
  1003.  
  1004.  
  1005.   draft-ietf-issll-is802-sbm-04.txt                              [Page 18]
  1006.  
  1007.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1008.  
  1009.  
  1010.   in the following table:
  1011.  
  1012.  
  1013.   Type        DSBMAddress                             AllSBM Address
  1014.               (Unicast IP addr of DSBM)         (reserved IP mcast addr)
  1015.  
  1016.   DSBM        * Sends PATH messages           * Monitors this address to
  1017.   Client        to this address                 detect the presence of DSBM
  1018.                                               * Monitors this address to
  1019.                                                 receive PATH messages
  1020.                                                 forwarded by the DSBM
  1021.  
  1022.   SBM         * Sends PATH messages           * Monitors and sends on this
  1023.                 to this address                 address to participate in
  1024.                                                 election of the DSBM
  1025.                                               * Monitors this address to
  1026.                                                 receive PATH messages
  1027.                                                 forwarded by the DSBM
  1028.  
  1029.   DSBM        * Monitors this address         * Monitors and sends on this
  1030.                 address for PATH messages       to participate in election
  1031.                 directed to it                  of the DSBM
  1032.                                               * Sends PATH messages to this
  1033.                                                   address
  1034.  
  1035.  
  1036.   The L2 or MAC addresses corresponding to IP multicast addresses are com-
  1037.   puted algorithmically using a reserved L2 address block (the high order
  1038.   24-bits are 00:00:5e). The Assigned Numbers RFC [RFC 1700] gives addi-
  1039.   tional details.
  1040.  
  1041.   5.3. Layer 3 to Layer 2 Address Mapping
  1042.  
  1043.  
  1044.   As stated earlier, L3 devices that act as DSBMs or DSBM clients must
  1045.   include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2
  1046.   devices along the path of a PATH message do not need to separately
  1047.   determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP
  1048.   object and its corresponding L2 address (for example, using ARP).
  1049.  
  1050.   For the purpose of such mapping at L3 devices, we assume a mapping
  1051.   function called "map_address" that performs the necessary mapping:
  1052.  
  1053.                   L2ADDR object = map_addr(L3Addr)
  1054.  
  1055.   We do not specify how the function is implemented; the implementation
  1056.   may simply involve access to the local ARP cache entry or may require
  1057.   performing an ARP function.  The function returns a L2ADDR object that
  1058.  
  1059.  
  1060.  
  1061.   draft-ietf-issll-is802-sbm-04.txt                              [Page 19]
  1062.  
  1063.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1064.  
  1065.  
  1066.   need not be interpreted by an L3 device and can be treated as an opaque
  1067.   object.  The format of the L2ADDR object is specified in Appendix B.
  1068.  
  1069.  
  1070.   5.5. Raw vs. UDP Encapsulation
  1071.  
  1072.  
  1073.   We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for
  1074.   encapsulating RSVP messages that are forwarded onto a L2 domain.  Thus,
  1075.   when a L3 device forwards a RSVP message onto a L2 domain based on the
  1076.   IEEE 802 LAN technology, it will only use RAW IP encapsulation.
  1077.  
  1078.   (NOTE -- THIS IS SUBJECT TO VERIFICATION THAT RSVP V1 WILL DROP UDP
  1079.   ENCAP.  Otherwise, we have an inter-operability issue here.)
  1080.  
  1081.  
  1082.   5.6. The Forwarding Rules
  1083.  
  1084.  
  1085.   The message processing and forwarding rules will be described in the
  1086.   context of the sample network illustrated in Figure 2.
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.   draft-ietf-issll-is802-sbm-04.txt                              [Page 20]
  1118.  
  1119.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1120.  
  1121.  
  1122.   Figure 2 - A sample network or L2 domain consisting of switched and
  1123.   shared L2 segments
  1124.  
  1125.    ..........
  1126.             .
  1127.   +------+  .    +------+  seg A  +------+  seg C  +------+  seg D  +------+
  1128.   |  H1  |_______|  R1  |_________|  S1  |_________|  S2  |_________|  H2  |
  1129.   |      |  .    |      |         |      |         |      |         |      |
  1130.   +------+  .    +------+         +------+         +------+         +------+
  1131.             .                        |                /
  1132.   1.0.0.0   .                        |               /
  1133.             .                        |___           /
  1134.             .                    seg B  |          / seg E
  1135.    ..........                           |         /
  1136.                        2.0.0.0          |        /
  1137.                                        +-----------+
  1138.                                        |    S3     |
  1139.                                        |           |
  1140.                                        +-----------+
  1141.                                             |
  1142.                                             |
  1143.                                             |
  1144.                                             |
  1145.                            seg F            |            .................
  1146.                    ------------------------------        .
  1147.                      |         |             |           .
  1148.                   +------+  +------+        +------+     .      +------+
  1149.                   |  H3  |  |  H4  |        |  R2  |____________|  H5  |
  1150.                   |      |  |      |        |      |     .      |      |
  1151.                   +------+  +------+        +------+     .      +------+
  1152.                                                          .
  1153.                                                          .     3.0.0.0
  1154.                                                          .................
  1155.  
  1156.  
  1157.   Figure 2 illustrates a sample network topology consisting of three IP
  1158.   subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two
  1159.   routers. The subnet 2.0.0.0 is an example of a L2 domain consisting of
  1160.   switches, hosts, and routers interconnected using switched segments and
  1161.   a yellow wire (shared segment). The sample network contains the follow-
  1162.   ing devices:
  1163.  
  1164.   Device          Type                    SBM Type
  1165.  
  1166.   H1, H5      Host (layer 3)          SBM Transparent
  1167.   H2-H4       Host  (layer 3)         DSBM Client
  1168.   R1          Router (layer 3)        SBM
  1169.   R2          Router (layer 3)        DSBM for segment F
  1170.  
  1171.  
  1172.  
  1173.   draft-ietf-issll-is802-sbm-04.txt                              [Page 21]
  1174.  
  1175.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1176.  
  1177.  
  1178.   S1          Switch (layer 2)        DSBM for segments A, B
  1179.   S2          Switch (layer 2)        DSBM for segments C, D, E
  1180.   S3          Switch (layer 2)        SBM
  1181.  
  1182.  
  1183.   The following paragraphs describe the rules, which each of these devices
  1184.   should use to forward PATH messages (rules apply to PATH_TEAR messages
  1185.   as well). They are described in the context of the general network
  1186.   illustrated above. While the examples do not address every scenario,
  1187.   they do address most of the interesting scenarios.  Exceptions can be
  1188.   discussed separately.
  1189.  
  1190.   The forwarding rules are applied to received PATH messages (routers and
  1191.   switches) or originating PATH messages (hosts), as follows:
  1192.  
  1193.  
  1194.   1.   Determine the interface(s) on which to forward the PATH message
  1195.        using standard forwarding rules:
  1196.  
  1197.  
  1198.   *    If there is a LAN_LOOPBACK object in the PATH message, and it car-
  1199.        ries the address of this device, silently discard the message. (see
  1200.        multicast exception discussion below).
  1201.  
  1202.  
  1203.   *    Layer 3 devices use the RSVP session address and perform a routing
  1204.        lookup to determine the forwarding interface(s).
  1205.  
  1206.  
  1207.   *    Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP infor-
  1208.        mation and MAC forwarding tables to determine the forwarding
  1209.        interface(s).  (see multicast exception discussion below).
  1210.  
  1211.  
  1212.   2.   For each forwarding interface:
  1213.  
  1214.     *    If the device is a layer 3 device, determine whether the inter-
  1215.          face is on a managed segment managed by a DSBM, based on the
  1216.          presence or absence of I_AM_DSBM messages. If the interface is
  1217.          not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
  1218.          LAN_LOOPBACK objects (if present), and forward to the standard
  1219.          unicast or multicast destination.  All layer 2 device's inter-
  1220.          faces are considered to be on managed segments.
  1221.  
  1222.          (Please note that the RSVP Class Numbers for these new objects
  1223.          are chosen so that if an RSVP message includes these objects, the
  1224.          nodes that are not aware of SBM will ignore and silently discard
  1225.          such objects.)
  1226.  
  1227.  
  1228.  
  1229.   draft-ietf-issll-is802-sbm-04.txt                              [Page 22]
  1230.  
  1231.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1232.  
  1233.  
  1234.     *    If the device is a layer 2 device or it is a layer 3 device *and*
  1235.          the interface is on a managed segment, proceed to rule #3.
  1236.  
  1237.  
  1238.   3.   Forward the PATH message onto the managed segment:
  1239.  
  1240.  
  1241.     *    If the device is a layer 3 device, insert LAN_NHOP address
  1242.          objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH
  1243.          message. The LAN_NHOP objects carry the LAN_NHOP_L3 and
  1244.          LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2
  1245.          object carries the device's own L2 address, and the LAN_LOOPBACK
  1246.          object contains the IP address of the outgoing interface.
  1247.  
  1248.          An L3 device is expected to use the map_addr() function described
  1249.          earlier to obtain an L2 address corresponding to an IP address.
  1250.  
  1251.  
  1252.     *    If the device is the DSBM for the segment to which the forwarding
  1253.          interface is attached, retrieve the PHOP information from the
  1254.          standard RSVP HOP object in the PATH message, and store it. This
  1255.          will be used to route RESV messages back through the L2 network.
  1256.          If the PATH message arrived over a managed segment, it will also
  1257.          contain the RSVP_HOP_L2 object; then retrieve and store also the
  1258.          previous hop's L2 address in the PATH state.
  1259.  
  1260.          If the device is the DSBM for the segment to which the forwarding
  1261.          interface is attached, copy the IP address of the forwarding
  1262.          interface (layer 2 devices must also have IP addresses) into the
  1263.          standard RSVP HOP object and the L2 address of the forwarding
  1264.          interface into the RSVP_HOP_L2 object.
  1265.  
  1266.  
  1267.     *    If the device is a layer 3 device and an SBM for the segment to
  1268.          which the forwarding interface is attached, it *is required* to
  1269.          retrieve and store the PHOP info.
  1270.  
  1271.          If the device is a layer 2 device and an SBM for the segment to
  1272.          which the forwarding interface is attached, it is *not* required
  1273.          to retrieve and store the PHOP info. If it does not do so, it
  1274.          must leave the standard RSVP HOP object and the RSVP_HOP_L2
  1275.          objects in the PATH message intact and it will not receive RESV
  1276.          messages.
  1277.  
  1278.          If the L2 device (which is a SBM) chooses to overwrite the RSVP
  1279.          HOP and RSVP_HOP_L2 objects with the IP and L2 addresses of  its
  1280.          forwarding interface, it will receive RESV messages. In this
  1281.          case, it must store the PHOP address info received in the
  1282.  
  1283.  
  1284.  
  1285.   draft-ietf-issll-is802-sbm-04.txt                              [Page 23]
  1286.  
  1287.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1288.  
  1289.  
  1290.          standard RSVP_HOP field and RSVP_HOP_L2 objects  of the incident
  1291.          PATH message.
  1292.  
  1293.  
  1294.     *    Copy the IP address of the forwarding interface into the
  1295.          LAN_LOOPBACK object, unless the device is a DSBM reflecting a
  1296.          PATH message for a multicast session, back onto the incident
  1297.          interface. (See multicast exception discussion below).
  1298.  
  1299.  
  1300.     *    If the device is the DSBM for the segment to which the forwarding
  1301.          interface is attached, send the PATH message to the AllSBMAd-
  1302.          dress.
  1303.  
  1304.  
  1305.     *    If the device is an SBM or a DSBM Client on the segment to which
  1306.          the forwarding interface is attached, send the PATH message to
  1307.          the DSBMAddress.
  1308.  
  1309.  
  1310.  
  1311.       5.6.1. Multicast Exception
  1312.  
  1313.       Rule #1 states that standard forwarding rules should be used to
  1314.       determine the interfaces on which the PATH message should be for-
  1315.       warded.  In the case of multicast messages, standard forwarding
  1316.       rules dictate that the message should not be forwarded on the inter-
  1317.       face from which it was received. However, in the case of a  DSBM
  1318.       that receives a PATH message over a managed segment, the following
  1319.       exception applies.  If there are members of the multicast group
  1320.       address (specified by the addresses in the LAN_NHOP object), on the
  1321.       segment from which the message was received, the message should be
  1322.       forwarded back onto the interface from which it was received. The
  1323.       message is reflected back onto the incoming interface, using the
  1324.       AllSBMAddress.
  1325.  
  1326.       Since it is possible for a DSBM to reflect a multicast message back
  1327.       onto the interface from which it was received, precautions must be
  1328.       taken to avoid looping these messages indefinitely.  The
  1329.       LAN_LOOPBACK object addresses this issue. All devices (except DSBMs
  1330.       reflecting a multicast PATH message) overwrite the LAN_LOOPBACK
  1331.       object in the PATH message with the IP address of the outgoing
  1332.       interface. DSBMs which are reflecting a multicast PATH message,
  1333.       leave the LAN_LOOPBACK object unchanged.  Thus, devices will always
  1334.       be able to recognize a reflected multicast message by the presence
  1335.       of their own address in the LAN_LOOPBACK object. These messages
  1336.       should be silently discarded.
  1337.  
  1338.  
  1339.  
  1340.  
  1341.   draft-ietf-issll-is802-sbm-04.txt                              [Page 24]
  1342.  
  1343.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1344.  
  1345.  
  1346.       5.7. Applying the Rules -- Unicast Session
  1347.  
  1348.  
  1349.       Let's see how the rules are applied in the general network illus-
  1350.       trated previously (see Figure 2).
  1351.  
  1352.  
  1353.       Assume that H1 is sending a PATH for a unicast session for which H5
  1354.       is the receiver. The following PATH message is composed by H1:
  1355.  
  1356.                                  RSVP Contents
  1357.       RSVP session IP address     IP address of H5 (3.0.0.35)
  1358.       Sender Template             IP address of H1 (1.0.0.11)
  1359.       PHOP                        IP address of H1 (1.0.0.11)
  1360.       RSVP_HOP_L2                 n/a  (H1 is not sending onto a managed
  1361.                                       segment)
  1362.       LAN_NHOP                    n/a  (H1 is not sending onto a managed
  1363.                                       segment)
  1364.       LAN_LOOPBACK                n/a  (H1 is not sending onto a managed
  1365.                                       segment)
  1366.  
  1367.                                    IP Header
  1368.       Source address              IP address of H1 (1.0.0.11)
  1369.       Destn address               IP addr of H5 (3.0.0.35, assuming raw mode &
  1370.                                    router alert)
  1371.  
  1372.                                    MAC Header
  1373.       Destn address               The L2 addr corresponding to R1 (determined
  1374.                                    by map_addr() and routing tables at H1)
  1375.  
  1376.       Since H1 is not sending onto a managed segment, the PATH message is
  1377.       composed and forwarded according to standard RSVP processing rules.
  1378.  
  1379.       Upon receipt of the PATH message, R1 composes and forwards a PATH
  1380.       message as follows:
  1381.  
  1382.  
  1383.                                  RSVP Contents
  1384.       RSVP session IP address     IP address of H5
  1385.       Sender Template             IP address of H1
  1386.       PHOP                        IP address of R1 (2.0.0.1)
  1387.                                   (seed the return path for RESV messages)
  1388.       RSVP_HOP_L2                 L2 address of R1
  1389.       LAN_NHOP                    LAN_NHOP_L3 (2.0.0.2) and
  1390.                                   LAN_NHOP_L2 address of R2 (L2ADDR)
  1391.                                   (this is the next layer 3 hop)
  1392.       LAN_LOOPBACK                IP address of R1 (2.0.0.1)
  1393.  
  1394.  
  1395.  
  1396.  
  1397.   draft-ietf-issll-is802-sbm-04.txt                              [Page 25]
  1398.  
  1399.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1400.  
  1401.  
  1402.                                    IP Header
  1403.       Source address              IP address of H1
  1404.       Destn address               DSBM's IP address (S1's IP address)
  1405.  
  1406.                                    MAC Header
  1407.       Destn address               DSBM (S1's) MAC address over segment A
  1408.  
  1409.  
  1410.  
  1411.       *    R1 does a routing lookup on the RSVP session address, to deter-
  1412.            mine the IP address of the next layer 3 hop, R2.
  1413.  
  1414.  
  1415.       *    It determines that R2 is accessible via seg A and that seg A is
  1416.            managed by a DSBM, S1.
  1417.  
  1418.  
  1419.       *    Therefore, it concludes that it is sending onto a managed seg-
  1420.            ment, and composes LAN_NHOP objects to carry the layer 3 and
  1421.            layer 2 next hop addresses. To compose the LAN_NHOP L2ADDR
  1422.            object, it invokes the L3L2 address mapping function
  1423.            ("map_address") to find out the MAC address for the  next hop
  1424.            L3 device, and then inserts a LAN_NHOP_L2ADDR object (that car-
  1425.            ries the MAC address) in the message.
  1426.  
  1427.  
  1428.       *    Since R1 is not the DSBM for seg A, it sends the PATH message
  1429.            to the DSBM's (S1's)  IP Address.
  1430.  
  1431.  
  1432.  
  1433.       Upon receipt of the PATH message, S1 composes and forwards a PATH
  1434.       message as follows:
  1435.  
  1436.  
  1437.                                  RSVP Contents
  1438.       RSVP session IP address     IP address of H5
  1439.       Sender Template             IP address of H1
  1440.       PHOP                        IP addr of S1 (seed the return path for RESV
  1441.                                   messages)
  1442.       RSVP_HOP_L2                 L2 address of S1
  1443.       LAN_NHOP                    LAN_NHOP_L3 (IP)  and LAN_NHOP_L2
  1444.                                       address of R2
  1445.                                   (layer 2 devices do not modify the LAN_NHOP)
  1446.       LAN_LOOPBACK                IP addr of S1
  1447.  
  1448.                                    IP Header
  1449.       Source address              IP address of H1
  1450.  
  1451.  
  1452.  
  1453.   draft-ietf-issll-is802-sbm-04.txt                              [Page 26]
  1454.  
  1455.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1456.  
  1457.  
  1458.       Destn address               AllSBMIPaddr (224.0.1.59, since S1 is the
  1459.                                   DSBM for seg B).
  1460.  
  1461.                                    MAC Header
  1462.       Destn address               All SBM MAC address (since S1 is the DSBM for
  1463.                                   seg B).
  1464.  
  1465.  
  1466.  
  1467.       *    S1 looks at the LAN_NHOP address information to determine the
  1468.            L2 address towards which it should forward the PATH message.
  1469.  
  1470.  
  1471.       *    From the bridge forwarding tables, it determines that the L2
  1472.            address is reachable via seg B.
  1473.  
  1474.  
  1475.       *    Since S1 is the DSBM for seg B, it inserts the RSVP_HOP_L2
  1476.            object and overwrites the RSVP HOP object (PHOP) with its own
  1477.            addresses.
  1478.  
  1479.  
  1480.       *    Since S1 is the DSBM for seg B, it addresses the PATH message
  1481.            to the AllSBMAddress.
  1482.  
  1483.            Upon receipt of the PATH message,  S3 composes and forwards a
  1484.            PATH message as follows:
  1485.  
  1486.  
  1487.  
  1488.                                  RSVP Contents
  1489.       RSVP session IP addr            IP address of H5
  1490.       Sender Template                 IP address of H1
  1491.       PHOP                            IP addr of S3 (seed the return
  1492.                                           path for RESV messages)
  1493.       RSVP_HOP_L2                     L2 address of S3
  1494.       LAN_NHOP                        LAN_NHOP_L3 (IP) and
  1495.                                       LAN_NHOP_L2 (MAC) address of R2
  1496.                                       (L2 devices don't modify  LAN_NHOP)
  1497.       LAN_LOOPBACK                    IP address of S3
  1498.  
  1499.                                    IP Header
  1500.       Source address                  IP address of H1
  1501.       Destn address                   DSBM address (R2's IP address on F)
  1502.  
  1503.                                    MAC Header
  1504.       Destn address                   DSBM (R2's) MAC address
  1505.  
  1506.  
  1507.  
  1508.  
  1509.   draft-ietf-issll-is802-sbm-04.txt                              [Page 27]
  1510.  
  1511.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1512.  
  1513.  
  1514.       *    S3 looks at the LAN_NHOP address information to determine the
  1515.            L2 address towards which it should forward the PATH message.
  1516.  
  1517.  
  1518.       *    From the bridge forwarding tables, it determines that the L2
  1519.            address is reachable via segment F.
  1520.  
  1521.  
  1522.       *    It has discovered that R2 is the DSBM for segment F. It there-
  1523.            fore sends the PATH message to R2's IP address on segment F.
  1524.  
  1525.  
  1526.       *    Note that S3 may or may not choose to overwrite the PHOP
  1527.            objects with its own IP  and L2 addresses. If it does so, it
  1528.            will receive RESV messages. In this case, it must also store
  1529.            the PHOP info  received in the incident PATH message such that
  1530.            it is able to forward the RESV messages on the correct path.
  1531.  
  1532.  
  1533.  
  1534.       Upon receipt of the PATH message, R2 composes and forwards a PATH
  1535.       message as follows:
  1536.  
  1537.                                  RSVP Contents
  1538.       RSVP session IP addr    IP address of H5
  1539.       Sender Template         IP address of H1
  1540.       PHOP                    IP addr of R2 (seed the return path for RESV
  1541.                               messages)
  1542.       RSVP_HOP_L2             Removed by R2  (R2 is not sending onto a
  1543.                                   managed segment)
  1544.       LAN_NHOP                Removed by R2  (R2 is not sending onto a
  1545.                               managed segment)
  1546.  
  1547.                                    IP Header
  1548.       Source address          IP address of H1
  1549.       Destn address           IP address of H5, the RSVP session address
  1550.  
  1551.                                    MAC Header
  1552.       Destn address           L2 addr corresponding to H5, the next
  1553.                                   layer 3 hop
  1554.  
  1555.  
  1556.       *    R2 does a routing lookup on the RSVP session address, to deter-
  1557.            mine the IP address of the next layer 3 hop, H5.
  1558.  
  1559.  
  1560.       *    It determines that H5 is accessible via a segment for which
  1561.            there is no DSBM (not a managed segment).
  1562.  
  1563.  
  1564.  
  1565.   draft-ietf-issll-is802-sbm-04.txt                              [Page 28]
  1566.  
  1567.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1568.  
  1569.  
  1570.       *    Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects and
  1571.            places the RSVP session address in the destination address of
  1572.            the IP header. It places the L2 address of the next layer 3
  1573.            hop, into the destination address of the MAC header and for-
  1574.            wards the PATH message to H5.
  1575.  
  1576.  
  1577.  
  1578.  
  1579.       5.8. Applying the Rules - Multicast Session
  1580.  
  1581.  
  1582.       The rules described above also apply to multicast (m/c) sessions.
  1583.       For the purpose of this discussion, it is assumed that layer 2 dev-
  1584.       ices track multicast group membership on each port individually.
  1585.       Layer 2 devices which do not do so, will merely generate extra mul-
  1586.       ticast traffic. This is the case for L2 devices which do not imple-
  1587.       ment multicast filtering or GARP/GMRP capability.
  1588.  
  1589.       Assume that H1 is sending a PATH for an m/c session for which H3 and
  1590.       H5 are the receivers. The rules are applied as they are in the uni-
  1591.       cast case described previously, until the PATH message reaches R2,
  1592.       with the following exception. The RSVP session address and the
  1593.       LAN_NHOP carry the destination m/c addresses rather than the unicast
  1594.       addresses carried in the unicast example.
  1595.  
  1596.       Now let's look at the processing applied by R2 upon receipt of the
  1597.       PATH message. Recall that R2 is the DSBM for segment F. Therefore,
  1598.       S3 will have forwarded its PATH message to the DSBMAddress (R2's IP
  1599.       address), to be picked up by R2. The PATH message will not have been
  1600.       seen by H3 (one of the m/c receivers), since the PATH message was
  1601.       directly sent to the DSBMAddress. We rely on R2 to reflect the PATH
  1602.       message back onto seg f, and to forward it to H5. R2 forwards the
  1603.       following PATH message onto seg f:
  1604.  
  1605.                                  RSVP Contents
  1606.       RSVP session addr       m/c session address
  1607.       Sender Template         IP address of H1
  1608.       PHOP                    IP addr of R2 (seed the return path for
  1609.                               RESV messages)
  1610.       RSVP_HOP_L2             L2 addr of  R2
  1611.       LAN_NHOP                m/c session address and corresponding L2 address
  1612.       LAN_LOOPBACK            IP addr of S3 (DSBMs reflecting a PATH
  1613.                               message don't modify this object)
  1614.  
  1615.                                    IP Header
  1616.       Source address          IP address of H1
  1617.       Destn address           AllSBMIP address (since R2 is the DSBM for seg F)
  1618.  
  1619.  
  1620.  
  1621.   draft-ietf-issll-is802-sbm-04.txt                              [Page 29]
  1622.  
  1623.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1624.  
  1625.  
  1626.                                    MAC Header
  1627.       Destn address           AllSBMMAC address (since R2 is the
  1628.                                   DSBM for seg F)
  1629.  
  1630.  
  1631.       Since H3 is monitoring the All SBM Address, it will receive the PATH
  1632.       message reflected by R2. Note that R2 violated the standard forward-
  1633.       ing rules here by sending a multicast  message back onto the inter-
  1634.       face from which it was received.  It protected against loops by
  1635.       leaving S3's address in the LAN_LOOPBACK object unchanged.
  1636.  
  1637.       R2 forwards the following PATH message on to H5:
  1638.  
  1639.                                  RSVP Contents
  1640.       RSVP session addr       m/c session address
  1641.       Sender Template         IP address of H1
  1642.       PHOP                    IP addr of R2 (seed the return path for RESV
  1643.                               messages)
  1644.       RSVP_HOP_L2             Removed by R2  (R2 is not sending onto a
  1645.                               managed segment)
  1646.       LAN_NHOP                Removed by R2  (R2 is not sending onto a
  1647.                               managed segment)
  1648.       LAN_LOOPBACK            Removed by R2  (R2 is not sending onto a
  1649.                               managed segment)
  1650.  
  1651.                                    IP Header
  1652.       Source address          IP address of H1
  1653.       Destn address           m/c session address
  1654.  
  1655.                                    MAC Header
  1656.       Destn address           MAC addr corresponding to the m/c
  1657.                               session address
  1658.  
  1659.  
  1660.       *    R2 determines that there is an m/c receiver accessible via a
  1661.            segment for which there is no DSBM. Therefore, it removes the
  1662.            LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
  1663.            address in the destination address of the IP header. It places
  1664.            the corresponding L2 address into the destination address of
  1665.            the MAC header and multicasts the message towards H5.
  1666.  
  1667.  
  1668.  
  1669.       5.9. Merging Traffic Class objects
  1670.  
  1671.  
  1672.       When an L3 device receives TCLASS objects from different senders
  1673.       (different PATH messages) in the same RSVP session and needs to
  1674.  
  1675.  
  1676.  
  1677.   draft-ietf-issll-is802-sbm-04.txt                              [Page 30]
  1678.  
  1679.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1680.  
  1681.  
  1682.       combine them for sending back a single RESV message (as in a wild-
  1683.       card style reservation), the device should use the lowest priority
  1684.       value among the values received in TCLASS objects of the PATH mes-
  1685.       sages.
  1686.  
  1687.       Similarly, when a L2 device needs to merge RESVs from different next
  1688.       hops at a merge point, it should merge the TCLASS values in the
  1689.       incoming RESVs to the lowest priority value among those received.
  1690.  
  1691.  
  1692.       5.10. Operation of SBM Transparent Devices
  1693.  
  1694.       We previously defined SBM Transparent Devices. Since no SBM tran-
  1695.       sparent devices were illustrated in the example provided, we will
  1696.       describe the operation of these in the following paragraph.
  1697.  
  1698.       SBM transparent devices are unaware of the entire SBM/DSBM protocol.
  1699.       They do not intercept messages addressed to the ALLSBMAddress, but
  1700.       instead, pass them through. As a result, they do not divide the DSBM
  1701.       election scope, they do not explicitly participate in routing of
  1702.       PATH or RESV messages, and they do not participate in admission con-
  1703.       trol. They are entirely transparent with respect to SBM operation.
  1704.  
  1705.       According to the definitions provided, physical segments intercon-
  1706.       nected by SBM transparent devices are considered a single managed
  1707.       segment. Therefore, DSBMs must perform admission control on such
  1708.       managed segments, with no knowledge of the segment's topology. In
  1709.       this case, the network administrator is expected to configure the
  1710.       DSBM for the managed segment, with some reasonable approximation of
  1711.       the segment's capacity.  A conservative policy would configure the
  1712.       DSBM for the lowest capacity route through the managed segment. A
  1713.       liberal policy would configure the DSBM for the highest capacity
  1714.       route through the managed segment. A network administrator will
  1715.       likely choose some value between the two, based on the level of
  1716.       guarantee required and some knowledge of likely traffic patterns.
  1717.  
  1718.       This document does not specify the configuration mechanism or the
  1719.       choice of a policy.
  1720.  
  1721.  
  1722.       5.11. Operation of SBMs Which are NOT DSBMs
  1723.  
  1724.  
  1725.       In the example illustrated, S3 is an SBM, but did not win the elec-
  1726.       tion to act as DSBM on any segment. One might ask what purpose such
  1727.       a device serves. SBMs actually provide the important service of
  1728.       dividing the election scope and reducing the size and complexity of
  1729.       managed segments. For example, if S3 were SBM transparent, seg B and
  1730.  
  1731.  
  1732.  
  1733.   draft-ietf-issll-is802-sbm-04.txt                              [Page 31]
  1734.  
  1735.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1736.  
  1737.  
  1738.       seg F would not be separate segments. Instead, they would constitute
  1739.       a single managed segment, managed by a single DSBM. As it is, seg B
  1740.       and seg F are each managed by separate DSBMs.  Each of these seg-
  1741.       ments have a trivial topology and a well defined capacity. As a
  1742.       result, the DSBMs for these segments do not need to perform admis-
  1743.       sion control based on approximations (as would be the case if S3
  1744.       were SBM transparent).
  1745.  
  1746.       Note that,  SBM devices which are not DSBMs, are not required to
  1747.       overwrite the PHOP in incident PATH messages with their own address.
  1748.       This is because it is not necessary for RESV messages to be routed
  1749.       through these devices. RESV messages are only required to be routed
  1750.       through the correct sequence of DSBMs. SBMs are not expected to pro-
  1751.       cess RESV messages that do pass through them, other than to forward
  1752.       them towards their destination address, using standard forwarding
  1753.       rules.
  1754.  
  1755.       SBM devices which are not DSBMs are required to overwrite the
  1756.       address in the LAN_LOOPBACK object with their own address, in order
  1757.       to avoid looping multicast messages. However, no state need be
  1758.       stored.
  1759.  
  1760.  
  1761.       6. Inter-Operability Considerations
  1762.  
  1763.  
  1764.       There are a few interesting inter-operability issues related to the
  1765.       deployment of a DSBM-based admission control method in an environ-
  1766.       ment consisting of network nodes with and without RSVP capability.
  1767.       In the following, we list some of these scenarios and explain how
  1768.       SBM-aware clients and nodes can operate in those scenarios:
  1769.  
  1770.       6.1. An L2 domain with no RSVP capability.
  1771.  
  1772.  
  1773.       It is possible to envisage L2 domains that do not use RSVP signaling
  1774.       for requesting resource reservations, but, instead, use some other
  1775.       (e.g., SNMP or static configuration) mechanism  to reserve bandwidth
  1776.       at a particular  network device such as a router. In that case, the
  1777.       question is how does a DSBM-based admission control method work and
  1778.       interoperate with the non-RSVP mechanism.  This proposal does not
  1779.       attempt to provide an admission control solution for such an
  1780.       environment. We believe that the SBM-based approach is part of an
  1781.       end2end signaling approach to establish resource reservations and
  1782.       does not attempt to provide a solution for SNMP-based configuration
  1783.       scenario.
  1784.  
  1785.       As stated earlier, the SBM-based approach can, however, co-exist
  1786.  
  1787.  
  1788.  
  1789.   draft-ietf-issll-is802-sbm-04.txt                              [Page 32]
  1790.  
  1791.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1792.  
  1793.  
  1794.       with any other, non-RSVP bandwidth allocation mechanism as long as
  1795.       resources being reserved are either partitioned statically between
  1796.       the different mechanisms or are resolved dynamically through a com-
  1797.       mon bandwidth allocator so that there is no over-commitment of the
  1798.       same resource.
  1799.  
  1800.       6.2. An L2 domain with SBM-transparent L2 Devices.
  1801.  
  1802.  
  1803.       This scenario has been addressed earlier in the document. The SBM-
  1804.       based method is designed to operate in such an environment. When
  1805.       SBM-transparent L2 devices interconnect SBM-aware devices, the
  1806.       resulting managed segment is  a combination of one or more physical
  1807.       segments and the DSBM for the managed segment may not be as effi-
  1808.       cient in allocating resources as it would if all L2 devices were
  1809.       SBM-aware.
  1810.  
  1811.  
  1812.  
  1813.       6.3. An L2 domain on which some senders are not DSBM clients.
  1814.  
  1815.       We believe that all senders that are sending RSVP/int-serv based
  1816.       traffic flows onto a managed segment must be SBM-aware and partici-
  1817.       pate in the SBM protocol. As stated above, those senders that rely
  1818.       on another reservation mechanism must avoid over-commitment of
  1819.       resources through a shared bandwidth allocator or static partition-
  1820.       ing of resources. All other senders (senders that are not sending
  1821.       streams subject to admission control) must be elastic applications
  1822.       that send best-effort traffic and use TCP-like congestion avoidance
  1823.       mechanism.
  1824.  
  1825.       All  DSBMs, SBMs, or DSBM clients on a managed segment (a segment
  1826.       with a currently active DSBM) must not accept PATH messages from
  1827.       senders that are not SBM-aware. PATH messages from such devices can
  1828.       be easily detected by SBMs and DSBM clients as they would not be
  1829.       multicast to the ALLSBMAddress. Also, such devices will not be aware
  1830.       of DSBMs and will, therefore, not address them directly.
  1831.  
  1832.  
  1833.       6.4. A non-SBM router that interconnects two DSBM-managed L2
  1834.       domains.
  1835.  
  1836.  
  1837.       This is not a problem as SBM-messages have local scope and do not
  1838.       pass between the two domains.
  1839.  
  1840.  
  1841.       7. Guidelines for Implementors
  1842.  
  1843.  
  1844.  
  1845.   draft-ietf-issll-is802-sbm-04.txt                              [Page 33]
  1846.  
  1847.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1848.  
  1849.  
  1850.       In the following, we provide guidelines for implementors on dif-
  1851.       ferent aspects of the implementation of the SBM-based admission con-
  1852.       trol procedure including suggestions for DSBM initialization, etc.
  1853.  
  1854.       7.1. DSBM Initialization
  1855.  
  1856.  
  1857.       As stated earlier, DSBM initialization includes configuration of
  1858.       maximum bandwidth that can be reserved on a managed segment under
  1859.       its control.  We suggest the following guideline.
  1860.  
  1861.       In the case of a managed segment consisting of L2 devices intercon-
  1862.       nected by a single standard, legacy 10 Mbps or 100 Mbps hub ("yellow
  1863.       wire"), DSBM devices should assume the default - the bandwidth of
  1864.       their interface, as the total allocatable bandwidth. In the case of
  1865.       L2 devices interconnected by a more modern, but still blocking, sin-
  1866.       gle switch, the DSBM should be configured with an estimate of the
  1867.       switch's backplane capacity.   Given the total allocatable
  1868.       bandwidth, the DSBM may be further configured to limit the maximum
  1869.       amount of bandwidth for RSVP-enabled flows to ensure spare capacity
  1870.       for best-effort traffic.
  1871.  
  1872.       7.2. Operation of DSBMs in Different L2 Topologies
  1873.  
  1874.  
  1875.       Depending on a L2 topology, a DSBM may be called upon to manage
  1876.       resources for one or more physical segments and the implementors
  1877.       must bear in mind efficiency implications of the use DSBM in dif-
  1878.       ferent L2 topologies. Trivial L2 topologies consist of a single
  1879.       'physical segment'. In this case, the  'managed segment' is
  1880.       equivalent to a single segment. Complex L2 topologies may consist of
  1881.       a number of 'physical segments', separated by L2 devices. Such an L2
  1882.       network is still a single 'segment' and can be collectively managed
  1883.       by a single DSBM. In this case, the configuration compromises the
  1884.       efficiency with which the DSBM can allocate resources. This is
  1885.       because the single DSBM is required to make admission control deci-
  1886.       sions for all reservation requests within the L2 topology, with no
  1887.       knowledge of the actual physical segments affected by the reserva-
  1888.       tion.
  1889.  
  1890.       We can realize improvements in the efficiency of resource allocation
  1891.       by subdividing the complex segment into a number of managed seg-
  1892.       ments, each managed by their own DSBM. In this case, each DSBM
  1893.       manages a managed segment having a relatively simple topology.
  1894.       Since managed segments are simpler, the DSBM can be configured with
  1895.       a more accurate estimate of the resources available for all reserva-
  1896.       tions in the managed segment. In the ultimate configuration, each
  1897.       physical segment is a managed segment and is managed by its own
  1898.  
  1899.  
  1900.  
  1901.   draft-ietf-issll-is802-sbm-04.txt                              [Page 34]
  1902.  
  1903.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1904.  
  1905.  
  1906.       DSBM. We make no assumption about the number of managed segments but
  1907.       state, simply, that in complex L2 topologies, the efficiency of
  1908.       resource allocation improves as the granularity of managed segments
  1909.       increases.
  1910.  
  1911.       8. Security Considerations
  1912.  
  1913.  
  1914.       The message formatting and usage rules described in this note raise
  1915.       some security issues, but they are no different than the ones raised
  1916.       by use of RSVP and Integrated Services; the need to control and
  1917.       authenticate access to enhanced qualities of service.  This require-
  1918.       ment is discussed further in [1], [4], and [5]. [2] describes the
  1919.       mechanism used to protect the integrity of RSVP messages carrying
  1920.       the information described here.
  1921.  
  1922.       In the case of the DSBM election over a segment shared by two or
  1923.       more entities, it is also necessary to authenticate DSBM candidates
  1924.       and a mechanism based on a shared secret among the DSBM candidates
  1925.       may be used.
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.   draft-ietf-issll-is802-sbm-04.txt                              [Page 35]
  1958.  
  1959.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  1960.  
  1961.  
  1962.       9. References
  1963.  
  1964.       [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
  1965.       ReSerVation Protocol (RSVP) -- Version 1 Functional Specification ",
  1966.       Internet Draft <draft-ietf-rsvp-spec-16{.txt,.ps}>, June 1997.
  1967.  
  1968.       [2] F. Baker., "RSVP Cryptographic Authentication", Internet Draft
  1969.       <draft-ietf-rsvp-md5-02.txt>, June 1996.
  1970.  
  1971.       [3] F. Baker, J. Krawczyk, "RSVP Management Information Base",
  1972.       Internet Draft <draft-ietf-rsvp-mib-08.txt>, June 1997.
  1973.  
  1974.       [4] J. Wroclawski, "Specification of the Controlled-Load Network
  1975.       Element Service", Internet Draft <draft-ietf-intserv-ctrl-load-svc-
  1976.       05.txt>, May 1997.
  1977.  
  1978.       [5] S. Shenker, C. Partridge, R. Guerin, "Specification of
  1979.       Guaranteed Quality of Service", Internet Draft <draft-ietf-intserv-
  1980.       guaranteed-svc-08.txt>, July 1997
  1981.  
  1982.       [6] S. Shenker, J. Wroclawski, "General Characterization Parameters
  1983.       for Integrated Service Network Elements", Internet Draft <draft-
  1984.       ietf-intserv-charac-03.txt>, July 1997.
  1985.  
  1986.       [7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services",
  1987.       Internet Draft <draft-ietf-intserv-rsvp-use-02.txt>, July 1997.
  1988.  
  1989.       [8] F. Baker, J. Krawczyk, "Integrated Services Management Informa-
  1990.       tion Base", Internet Draft <draft-ietf-intserv-mib-07.txt>, June
  1991.       1997.
  1992.  
  1993.       [9] A. Ghanwani, W. Pace, V. Srinivasan, "A Framework for Providing
  1994.       Integrated Services Over Shared and Switched LAN Technologies",
  1995.       Internet Draft <draft-ietf-issll-is802-framework-02.txt>, May 1997.
  1996.  
  1997.       [10] M. Seaman, A. Smith, E. Crawley, "Integrated Services over IEEE
  1998.       802.1D/802.1p Networks", Internet Draft <draft-ietf-issll-802-
  1999.       01.txt>, June 1997.
  2000.  
  2001.       [11] "Supplement to MAC Bridges: Traffic Class Expediting and
  2002.       Dynamic Multicast Filtering",  May 1997, IEEE P802.1p/D6
  2003.  
  2004.       [12] "Draft Standard for Virtual Bridged Local Area Networks", May
  2005.       1997, IEEE P802.1Q/D6
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.   draft-ietf-issll-is802-sbm-04.txt                              [Page 36]
  2014.  
  2015.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2016.  
  2017.  
  2018.                                    APPENDIX A
  2019.                             DSBM Election Algorithm
  2020.  
  2021.  
  2022.       A.1. Introduction
  2023.  
  2024.  
  2025.  
  2026.       To simplify the rest of this discussion, we will assume that there
  2027.       is a single DSBM for the entire L2 domain (i.e., assume a yellow
  2028.       wire for the entire L2 domain). Later, we will discuss how a DSBM is
  2029.       elected for a half-duplex or full-duplex switched segment.
  2030.  
  2031.       To allow for quick recovery from the failure of a DSBM, we assume
  2032.       that additional SBMs may be active in a L2 domain for fault toler-
  2033.       ance. When more than one SBM is active in a L2 domain, the SBMs use
  2034.       an election algorithm to elect a DSBM for the L2 domain. After the
  2035.       DSBM is elected and is operational, other SBMs remain passive in the
  2036.       background to step in to elect a new DSBM when necessary. The proto-
  2037.       col for electing and discovering DSBM is called the "DSBM election
  2038.       protocol" and is described in the rest of this document.
  2039.  
  2040.       A.1.1. How a DSBM Client Detects a Managed Segment
  2041.  
  2042.       Once elected, a DSBM periodically multicasts an I_AM_DSBM message on
  2043.       the AllSBMAddress to indicate its presence. The message is sent
  2044.       every period (e.g., every 5 seconds) according to the DSBMRefreshIn-
  2045.       terval timer value (a configuration parameter).  Absence of such a
  2046.       message over a certain time interval (called "DSBMDeadInterval";
  2047.       another configuration parameter typically set to a multiple of
  2048.       RefreshInterval) indicates that the DSBM has failed or terminated
  2049.       and triggers another round of the DSBM election. The DSBM clients
  2050.       always listen for periodic DSBM advertisements. The advertisement
  2051.       includes the unicast IP address of the DSBM (DSBMAddress) and DSBM
  2052.       clients send their PATH/RESV (or other) messages to the DSBM. When a
  2053.       DSBM client detects the failure of a DSBM, it waits for a subsequent
  2054.       I_AM_DSBM advertisement before resuming any communication with its
  2055.       DSBM. During the period when a DSBM is not present, a DSBM client
  2056.       may forward outgoing PATH messages using the standard RSVP forward-
  2057.       ing rules.
  2058.  
  2059.       The exact message formats and addresses used for communication with
  2060.       (and among) SBM(s) are described in Appendix B.
  2061.  
  2062.  
  2063.  
  2064.       A.2. Overview of the DSBM Election Procedure
  2065.  
  2066.  
  2067.  
  2068.  
  2069.   draft-ietf-issll-is802-sbm-04.txt                              [Page 37]
  2070.  
  2071.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2072.  
  2073.  
  2074.       When an SBM first starts up, it listens for incoming DSBM advertise-
  2075.       ments for some period to check whether a DSBM already exists in its
  2076.       L2 domain. If one already exists (and no new election is in pro-
  2077.       gress), the new SBM stays quiet in the background until an election
  2078.       of DSBM is necessary. All messages related to the DSBM election and
  2079.       DSBM advertisements are always sent to the AllSBMAddress.
  2080.  
  2081.       If no DSBM exists, the SBM initiates the election of a DSBM by send-
  2082.       ing out a DSBM_WILLING message that lists its IP address as a candi-
  2083.       date DSBM and its "SBM priority". Each SBM is assigned a priority
  2084.       to determine its relative precedence. When more than one SBM candi-
  2085.       date exists, the SBM priority determines who gets to be the DSBM
  2086.       based on the relative priority of candidates. If there is a tie
  2087.       based on the priority value, the tie is  broken using the IP
  2088.       addresses of tied candidates (one with the higher IP address in the
  2089.       lexicographic order wins). The details of the election protocol
  2090.       start in Section A.4.
  2091.  
  2092.  
  2093.       A.2.1 Summary of the Election Algorithm
  2094.  
  2095.  
  2096.  
  2097.       For the purpose of the algorithm, an SBM is in one of the four
  2098.       states (SteadyState, DetectDSBM, ElectDSBM, I_AM_DSBM).
  2099.  
  2100.       An SBM (call it X) starts up in the DetectDSBM state and waits for a
  2101.       ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or
  2102.       DSBM_WILLING messages. If an I_AM_DSBM advertisement is received
  2103.       during this state, the SBM notes the current DSBM (its IP address
  2104.       and priority) and enters the SteadyState state. If a DSBM_WILLING
  2105.       message is received from another SBM (call it Y) during this state,
  2106.       then X enters the ElectDSBM state. Before entering the new state, X
  2107.       first checks to see whether it itself is a better candidate than Y
  2108.       and, if so, sends out a DSBM_WILLING message and then enters the
  2109.       ElectDSBM state.
  2110.  
  2111.       When an SBM (call it X) enters the ElectDSBM state, it sets a timer
  2112.       (called ElectionIntervalTimer that is typically set to a value at
  2113.       least equal to the DeadIntervalTimer value) to wait for the election
  2114.       to finish and to discover who is the best candidate. In this state,
  2115.       X keeps track of the best (or better) candidate seen so far (includ-
  2116.       ing itself). Whenever it receives another DSBM_WILLING message, it
  2117.       updates its notion of the best (or better) candidate based on the
  2118.       priority (and tie-breaking) criterion.  During the ElectionInterval,
  2119.       X sends out a DSBM_WILLING message every RefreshInterval to
  2120.       (re)assert its candidacy.
  2121.  
  2122.  
  2123.  
  2124.  
  2125.   draft-ietf-issll-is802-sbm-04.txt                              [Page 38]
  2126.  
  2127.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2128.  
  2129.  
  2130.       At the end of the ElectionInterval, X checks whether it is the best
  2131.       candidate so far. If so, it declares itself to be the DSBM (by send-
  2132.       ing out the I_AM_DSBM advertisement) and enters the I_AM_DSBM state;
  2133.       otherwise, it decides to wait for the best candidate to declare
  2134.       itself the winner. To wait, X re-initializes its ElectDSBM state and
  2135.       continues to wait for another round of election (each round lasts
  2136.       for an ElectionTimerInterval duration).
  2137.  
  2138.       An SBM is in SteadyState state when no election is in progress and
  2139.       the DSBM is already elected (and happens to be someone else).  In
  2140.       this state, it listens  for incoming I_AM_DSBM advertisements and
  2141.       uses a DSBMDeadInterval timer to detect the failure of DSBM. Every
  2142.       time the advertisement is received, the timer is restarted. If the
  2143.       timer fires, the SBM goes into the DetectDSBM state to prepare to
  2144.       elect the new DSBM. If an SBM receives a DSBM_WILLING message from
  2145.       the current DSBM in this state, the SBM enters the ElectDSBM state
  2146.       after sending  out a DSBM_WILLING message (to announce its own can-
  2147.       didacy).
  2148.  
  2149.       In the I_AM_DSBM state, the DSBM sends out I_AM_DSBM advertisements
  2150.       every refresh interval. If the DSBM wishes to shut down (gracefully
  2151.       terminate), it sends out a DSBM_WILLING message (with SBM priority
  2152.       value set to zero) to initiate the election procedure. The priority
  2153.       value zero effectively removes the outgoing DSBM from the election
  2154.       procedure and makes way for the election of a different DSBM.
  2155.  
  2156.  
  2157.  
  2158.       A.3. Recovering from DSBM Failure
  2159.  
  2160.  
  2161.       When a DSBM fails (DSBMDeadInterval timer fires), all the SBMs enter
  2162.       the ElectDSBM state and start the election process.
  2163.  
  2164.       At the end of the ElectionInterval, the elected DSBM sends out
  2165.       I_AM_DSBM advertisement and the DSBM is then operational.
  2166.  
  2167.  
  2168.       A.4. DSBM Advertisements
  2169.  
  2170.  
  2171.  
  2172.       The I_AM_DSBM advertisement contains the following information:
  2173.  
  2174.  
  2175.       1.   DSBM address information -- contains the IP address of the DSBM
  2176.            and its SBM priority (a configuration parameter -- priority
  2177.            specified by a network administrator). The priority value is
  2178.  
  2179.  
  2180.  
  2181.   draft-ietf-issll-is802-sbm-04.txt                              [Page 39]
  2182.  
  2183.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2184.  
  2185.  
  2186.            used to choose among candidate SBMs during the election algo-
  2187.            rithm. Higher integer values indicate higher priority and the
  2188.            value is in the range 0..255. The value zero indicates that the
  2189.            SBM is not eligible to be the DSBM.
  2190.  
  2191.  
  2192.       2.   refresh interval -- contains the value of the refresh interval
  2193.            in seconds.  Value zero indicates the parameter has been omit-
  2194.            ted in the message.  Receivers may substitute their own default
  2195.            value in this case.
  2196.  
  2197.  
  2198.       3.   SBMDeadInterval -- contains the value of the SBMDeadInterval in
  2199.            seconds. If the value is omitted (or value zero is specified),
  2200.            a default value (from initial configuration) should be used.
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.       A.5. DSBM_WILLING Messages
  2207.  
  2208.  
  2209.       When an SBM wishes to declare its candidacy to be the DSBM  during
  2210.       an election phase, it sends out a DSBM_WILLING message. The
  2211.       DSBM_WILLING message contains the following information:
  2212.  
  2213.  
  2214.  
  2215.       1.   DSBM address information -- Contains the SBM's own address, if
  2216.            it wishes to be the DSBM. Also, contains the  priority of the
  2217.            SBM whose address is given above.
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.       A.6. SBM State Variables
  2224.  
  2225.  
  2226.       For each network interface, an SBM maintains the following state
  2227.       variables related to the election of the DSBM for the L2 domain on
  2228.       that interface:
  2229.  
  2230.  
  2231.            a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
  2232.            0.0.0.0) and priority. All IP addresses are assumed to be in
  2233.            network byte order.
  2234.  
  2235.  
  2236.  
  2237.   draft-ietf-issll-is802-sbm-04.txt                              [Page 40]
  2238.  
  2239.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2240.  
  2241.  
  2242.            b) OwnAddrInfo -- SBM's own IP address for the interface and
  2243.            its own priority (a configuration parameter).
  2244.  
  2245.  
  2246.            c) DSBM RefreshInterval in seconds. When the DSBM is not yet
  2247.            elected, it is set to a default value specified as a configura-
  2248.            tion parameter.
  2249.  
  2250.  
  2251.  
  2252.            d) DSBMDeadInterval in seconds. When the DSBM is not yet
  2253.            elected, it is initially set to  a default value specified as a
  2254.            configuration parameter.
  2255.  
  2256.  
  2257.            f) ListenInterval in seconds -- a configuration parameter that
  2258.            decides how long an SBM spends in the DetectDSBM state (see
  2259.            below).
  2260.  
  2261.  
  2262.            g) ElectionInterval in seconds -- a configuration parameter
  2263.            that decides how long an SBM spends in the ElectDSBM state when
  2264.            it has declared its candidacy.
  2265.  
  2266.  
  2267.       Figure 3 shows the state transition diagram for the election proto-
  2268.       col and the various states are described below. A complete descrip-
  2269.       tion of the state machine is provided in Section A.10.
  2270.  
  2271.  
  2272.       A.7. DSBM Election States
  2273.  
  2274.  
  2275.            DOWN -- SBM is not operational.
  2276.  
  2277.  
  2278.            DetectDSBM -- typically, the initial state of an SBM when it
  2279.            starts up. In this state, it checks to see whether a DSBM
  2280.            already exists in its domain.
  2281.  
  2282.  
  2283.  
  2284.            SteadyState -- SBM is in this state when no election is in pro-
  2285.            gress and it is not the DSBM. In this state, SBM passively mon-
  2286.            itors the state of the DSBM.
  2287.  
  2288.  
  2289.            ElectDSBM -- SBM is in this state when a DSBM election is in
  2290.  
  2291.  
  2292.  
  2293.   draft-ietf-issll-is802-sbm-04.txt                              [Page 41]
  2294.  
  2295.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2296.  
  2297.  
  2298.            progress.
  2299.  
  2300.  
  2301.            IAMDSBM -- SBM is in this state when it is the DSBM for the L2
  2302.            domain.
  2303.  
  2304.  
  2305.  
  2306.       A.8. Events that cause state changes
  2307.  
  2308.  
  2309.            StartUp -- SBM starts operation.
  2310.  
  2311.  
  2312.            ListenInterval Timeout -- The ListenInterval timer has fired.
  2313.            This means that the SBM has monitored its domain to check for
  2314.            an existing DSBM or to check whether there are candidates
  2315.            (other than itself) willing to be the DSBM.
  2316.  
  2317.  
  2318.            DSBM_WILLING message received -- This means that the SBM
  2319.            received a DSBM_WILLING message from some other SBM. Such a
  2320.            message is sent when an SBM wishes to declare its candidacy to
  2321.            be the DSBM.
  2322.  
  2323.  
  2324.            I_AM_DSBM message received -- SBM received a DSBM advertisement
  2325.            from the DSBM in its L2 domain.
  2326.  
  2327.  
  2328.            SBMDeadInterval Timeout -- The SBMDeadInterval timer has fired.
  2329.            This means that the SBM did not receive even one DSBM adver-
  2330.            tisement during this period and indicates possible failure of
  2331.            the DSBM.
  2332.  
  2333.  
  2334.            RefreshInterval Timeout -- The RefreshInterval timer has fired.
  2335.            In the I_AM_DSBM state, this means it is the time for sending
  2336.            out the next DSBM advertisement. In the ElectDSBM state, the
  2337.            event means that it is the time to send out another
  2338.            DSBM_WILLING message.
  2339.  
  2340.  
  2341.            ElectionInterval Timeout -- The ElectionInterval timer has
  2342.            fired. This means that the SBM has waited long enough after
  2343.            declaring its candidacy to determine whether or not it suc-
  2344.            ceeded.
  2345.  
  2346.  
  2347.  
  2348.  
  2349.   draft-ietf-issll-is802-sbm-04.txt                              [Page 42]
  2350.  
  2351.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2352.  
  2353.  
  2354.                              CONTINUED ON NEXT PAGE
  2355.  
  2356.  
  2357.  
  2358.  
  2359.  
  2360.  
  2361.  
  2362.  
  2363.  
  2364.  
  2365.  
  2366.  
  2367.  
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.  
  2381.  
  2382.  
  2383.  
  2384.  
  2385.  
  2386.  
  2387.  
  2388.  
  2389.  
  2390.  
  2391.  
  2392.  
  2393.  
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404.  
  2405.   draft-ietf-issll-is802-sbm-04.txt                              [Page 43]
  2406.  
  2407.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2408.  
  2409.  
  2410.       A.9. State Transition Diagram (Figure 3)
  2411.  
  2412.  
  2413.                                    +-----------+
  2414.                +--<--------------<-|DetectDSBM |---->------+
  2415.                |                   +-----------+           |
  2416.                |                                           |
  2417.                |                                           |
  2418.                |                                           |
  2419.                |     +-------------+       +---------+     |
  2420.                +->---| SteadyState |--<>---|ElectDSBM|--<--+
  2421.                      +-------------+       +---------+
  2422.                           |                        |
  2423.                           |                        |
  2424.                           |                        |
  2425.                           |        +-----------+   |
  2426.                           +<<- +---|  IAMDSBM  |-<-+
  2427.                                |   +-----------+
  2428.                                |
  2429.                                |   +-----------+
  2430.                                +>>-| SHUTDOWN  |
  2431.                                    +-----------+
  2432.  
  2433.  
  2434.       A.10. Election State Machine
  2435.  
  2436.  
  2437.       Based on the events and states described above, the state changes at
  2438.       an SBM are described below. Each state change is triggered by an
  2439.       event and is typically accompanied by a sequence of actions.  The
  2440.       state machine is described assuming a single threaded implementation
  2441.       (to avoid race conditions between state changes and timer events)
  2442.       with no timer events occurring during the execution of the state
  2443.       machine.
  2444.  
  2445.       The following routines will be frequently used in the description of
  2446.       the state machine:
  2447.  
  2448.       ComparePrio(FirstAddrInfo, SecondAddrInfo)
  2449.         -- determines whether the entity represented by the first parameter
  2450.           is better than the second entity using the priority information
  2451.           and the address information. If any address is zero, that entity
  2452.           automatically loses; then first priorities are compared; higher
  2453.           priority candidate wins. If there is a tie based on
  2454.           the priority value, the tie is  broken using the IP
  2455.           addresses of tied candidates (one with the higher IP address in the
  2456.           lexicographic order wins). Returns TRUE if first entity is a better
  2457.           choice. FALSE otherwise.
  2458.  
  2459.  
  2460.  
  2461.   draft-ietf-issll-is802-sbm-04.txt                              [Page 44]
  2462.  
  2463.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2464.  
  2465.  
  2466.       SendDSBMWilling Message()
  2467.       Begin
  2468.           Send out DSBM_WILLING message listing myself as a candidate for
  2469.           DSBM (copy OwnAddr and priority into appropriate fields)
  2470.           start RefreshIntervalTimer
  2471.           goto ElectDSBM state
  2472.       End
  2473.  
  2474.       AmIBetterDSBM(OtherAddrInfo)
  2475.       Begin
  2476.           if (ComparePrio(OwnAddrInfo, OtherAddrInfo))
  2477.               return TRUE
  2478.  
  2479.           change LocalDSBMInfo = OtherDSBMAddrInfo
  2480.           return FALSE
  2481.       End
  2482.  
  2483.       UpdateDSBMInfo()
  2484.       /* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
  2485.       Begin
  2486.           update LocalDSBMInfo such as  IP addr, DSBM priority,
  2487.           RefreshIntervalTimer, DSBMDeadIntervalTimer
  2488.       End
  2489.  
  2490.  
  2491.  
  2492.       A.10.1 State Changes
  2493.  
  2494.  
  2495.  
  2496.       In the following, the action "continue" or "continue in current
  2497.       state" means an "exit" from the current action sequence without a
  2498.       state transition.
  2499.  
  2500.       State:      DOWN
  2501.       Event:      StartUp
  2502.       New State:  DetectDSBM
  2503.       Action:     Initialize the local state variables (LocalDSBMADDR and
  2504.                   LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
  2505.  
  2506.       State:      DetectDSBM
  2507.       New State:  SteadyState
  2508.       Event:      I_AM_DSBM message received
  2509.       Action:     set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
  2510.                   start DeadDSBMInterval timer
  2511.                   goto SteadyState
  2512.  
  2513.       State:      DetectDSBM
  2514.  
  2515.  
  2516.  
  2517.   draft-ietf-issll-is802-sbm-04.txt                              [Page 45]
  2518.  
  2519.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2520.  
  2521.  
  2522.       Event:      ListenIntervalTimer fired
  2523.       New State:  ElectDSBM
  2524.       Action:     Start ElectionIntervalTimer
  2525.                   SendDSBMWillingMessage();
  2526.  
  2527.       State:      DetectDSBM
  2528.       Event:      DSBM_WILLING message received
  2529.       New State:  ElectDSBM
  2530.       Action:     Cancel any active timers
  2531.  
  2532.                   Start ElectionIntervalTimer
  2533.                   /* am I a better choice than this dude? */
  2534.                   If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) {
  2535.                       /* I am better */
  2536.                       SendDSBMWillingMessage()
  2537.                   } else {
  2538.                       Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
  2539.                       goto ElectDSBM state
  2540.                   }
  2541.  
  2542.       State:      SteadyState
  2543.       Event:      SBMDeadInterval timer fired.
  2544.       New State:  ElectDSBM
  2545.       Action:     start ElectionIntervalTimer
  2546.                   set LocalDSBMAddrInfo = OwnAddrInfo
  2547.                   SendDSBMWiliingMessage()
  2548.  
  2549.       State:      SteadyState
  2550.       Event:      I_AM_DSBM message received.
  2551.       New State:  SteadyState
  2552.       Action:     /* first check whether anything has changed */
  2553.                   if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
  2554.                       change LocalDSBMAddrInfo to reflect new info
  2555.                   endif
  2556.                   restart DSBMDeadIntervalTimer;
  2557.                   continue in current state;
  2558.  
  2559.       State:      SteadyState
  2560.       Event:      DSBM_WILLING Message is received
  2561.       New State:  Depends on action (ElectDSBM or SteadyState)
  2562.       Action:     /* check whether it is from the DSBM itself (shutdown) */
  2563.                   if (IncomingDSBMAddr == LocalDSBMAddr) {
  2564.                       cancel active timers
  2565.                       Set LocalDSBMAddrInfo = OwnAddrInfo
  2566.                       Start ElectionIntervalTimer
  2567.                       SendDSBMWillingMessage() /* goto ElectDSBM state */
  2568.                   }
  2569.                   /* else, ignore it */
  2570.  
  2571.  
  2572.  
  2573.   draft-ietf-issll-is802-sbm-04.txt                              [Page 46]
  2574.  
  2575.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2576.  
  2577.  
  2578.                   continue in current state
  2579.  
  2580.       State:      ElectDSBM
  2581.       Event:      ElectionIntervalTimer Fired
  2582.       New State:  depends on action (I_AM_DSBM or SteadyState)
  2583.       Action:     If (LocalDSBMAddrInfo == OwnAddrInfo) {
  2584.                       /* I won */
  2585.                       send I_AM_DSBM message
  2586.                       start RefreshIntervalTimer
  2587.                       goto I_AM_DSBM state
  2588.                   } else {   /* someone else won, so wait for it to declare
  2589.                                itself to be the DSBM */
  2590.                       set LocalDSBMAddressInfo = OwnAddrInfo
  2591.                       start ElectionIntervalTimer
  2592.                       continue in current state
  2593.                   }
  2594.  
  2595.       State:      ElectDSBM
  2596.       Event:      I_AM_DSBM message received
  2597.       New State:  SteadyState
  2598.       Action:     set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
  2599.                   Cancel any active timers
  2600.                   start DeadDSBMInterval timer
  2601.                   goto SteadyState
  2602.  
  2603.       State:      ElectDSBM
  2604.       Event:      DSBM_WILLING message received
  2605.       New State:  ElectDSBM
  2606.       Action:     Check whether it's a loopback and if so, discard, continue;
  2607.                   if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
  2608.                       Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
  2609.                   }
  2610.                   continue in current state
  2611.  
  2612.       State:      ElectDSBM
  2613.       Event:      RefreshIntervalTimer fired
  2614.       New State:  ElectDSBM
  2615.       Action:     SendDSBMWillingMessage()
  2616.  
  2617.       State:      I_AM_DSBM
  2618.       Event:      DSBM_WILLING message received
  2619.       New State:  I_AM_DSBM
  2620.       Action:     send I_AM_DSBM message  /* reassert myself */
  2621.                   restart RefreshIntervalTimer
  2622.  
  2623.       State:      I_AM_DSBM
  2624.       Event:      RefreshIntervalTimer fired
  2625.       New State:  I_AM_DSBM
  2626.  
  2627.  
  2628.  
  2629.   draft-ietf-issll-is802-sbm-04.txt                              [Page 47]
  2630.  
  2631.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2632.  
  2633.  
  2634.       Action:     send I_AM_DSBM message
  2635.                   restart RefreshIntervalTimer
  2636.  
  2637.       State:      I_AM_DSBM
  2638.       Event:      I_AM_DSBM message received
  2639.       New State:  depends on action (I_AM_DSBM or SteadyState)
  2640.       Action:     /* check whether other guy is better */
  2641.                   If (ComparePrio(OwnAddrInfo, IncomingAddrInfo))  {
  2642.                       /* I am better */
  2643.                       send I_AM_DSBM message
  2644.                       restart RefreshIntervalTimer
  2645.                       continue in current state
  2646.                  } else {
  2647.                       Set LocalDSBMAddrInfo = IncomingAddrInfo
  2648.                       cancel active timers
  2649.                       start DSBMDeadInterval timer
  2650.                       goto SteadyState
  2651.                 }
  2652.  
  2653.       State:      I_AM_DSBM
  2654.       Event:      Want to shut myself down
  2655.       New State:  DOWN
  2656.       Action:     send DSBM_WILLING message with My address filled in, but
  2657.                   priority set to zero
  2658.                   goto Down State
  2659.  
  2660.  
  2661.       A.10.2 Suggested Values of Interval Timers
  2662.  
  2663.  
  2664.       To avoid DSBM outages for long period, to ensure quick recovery from
  2665.       DSBM failures, and to avoid timeout of PATH and RESV state at the
  2666.       edge devices, we suggest  the following values for various timers.
  2667.  
  2668.       Assuming that the RSVP implementations use a 30 second timeout for
  2669.       PATH and RESV refreshes, we suggest that the RefreshIntervalTimer
  2670.       should be set to about 5 seconds with DSBMDeadIntervalTimer set to
  2671.       15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be
  2672.       set to a random value between (DeadIntervalTimer, 2*DeadIntervalTi-
  2673.       mer). The ElectionIntervalTimer should be set at least to the value
  2674.       of DeadIntervalTimer to ensure that each SBM has a chance to have
  2675.       its DSBM_WILLING message (sent every RefreshInterval in ElectDSBM
  2676.       state) delivered to others.
  2677.  
  2678.  
  2679.       A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
  2680.  
  2681.  
  2682.  
  2683.  
  2684.  
  2685.   draft-ietf-issll-is802-sbm-04.txt                              [Page 48]
  2686.  
  2687.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2688.  
  2689.  
  2690.       Network administrators are expected to configure each SBM-capable
  2691.       device with its "SBM priority" for each of the interfaces attached
  2692.       to a managed segment.  SBM_PRIORITY is an 8-bit, unsigned integer
  2693.       value (in the range 0-255) with higher integer values denoting
  2694.       higher priority. The value zero indicates that the device is not
  2695.       eligible to be a DSBM.
  2696.  
  2697.       A separate range of values is reserved for each type of SBM-capable
  2698.       device to reflect the relative priority among different classes of
  2699.       L2/L3 devices. L2 devices get higher priority followed by routers
  2700.       followed by hosts. The priority values in the range of 128..255 are
  2701.       reserved for L2 devices, the values in the range of 64..127 are
  2702.       reserved for routers, and values in the range of 1..63 are reserved
  2703.       for hosts.
  2704.  
  2705.  
  2706.       A.11. DSBM Election over switched links
  2707.  
  2708.  
  2709.  
  2710.       The election algorithm works as described before in this case except
  2711.       each SBM-capable L2 device restricts the scope of the election to
  2712.       its local segment. As described in Section B.1 below, all messages
  2713.       related to the DSBM election are sent to a special multicast address
  2714.       (AllSBMAddress). AllSBMAddress (its corresponding MAC multicast
  2715.       address) is configured in the permanent database of SBM-capable,
  2716.       layer 2 devices so that all frames with AllSBMAddress as the desti-
  2717.       nation address are not forwarded and instead directed to the SBM
  2718.       management entity in those devices. Thus, a DSBM can be elected
  2719.       separately on each point-to-point segment in  a switched topology.
  2720.       For example, in Figure 2, DSBM for "segment A" will be elected using
  2721.       the election algorithm between R1 and S1 and none of the election-
  2722.       related messages on this segment will be forwarded by S1 beyond
  2723.       "segment A". Similarly, a separate election will take place on each
  2724.       segment in this topology.
  2725.  
  2726.       When a switched segment is a half-duplex segment, two senders (one
  2727.       sender at each end of the link) share the link. In this case, one of
  2728.       the two senders will win the DSBM election and will be responsible
  2729.       for managing the segment.
  2730.  
  2731.       If a switched segment is full-duplex, exactly one sender sends on
  2732.       the link in each direction. In this case, either one or two DSBMs
  2733.       can exist on such a managed segment. If a sender at each end wishes
  2734.       to serve as a DSBM for that end, it can declare itself to be the
  2735.       DSBM by sending out an I_AM_DSBM advertisement and start managing
  2736.       the resources for the outgoing traffic over the segment. If one of
  2737.       the two senders does not wish itself to be the DSBM, then the other
  2738.  
  2739.  
  2740.  
  2741.   draft-ietf-issll-is802-sbm-04.txt                              [Page 49]
  2742.  
  2743.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2744.  
  2745.  
  2746.       DSBM will not receive any DSBM advertisement from its peer and
  2747.       assume itself to be the DSBM for traffic traversing in both direc-
  2748.       tions over the managed segment.
  2749.  
  2750.  
  2751.  
  2752.  
  2753.  
  2754.  
  2755.  
  2756.  
  2757.  
  2758.  
  2759.  
  2760.  
  2761.  
  2762.  
  2763.  
  2764.  
  2765.  
  2766.  
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.  
  2777.  
  2778.  
  2779.  
  2780.  
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796.  
  2797.   draft-ietf-issll-is802-sbm-04.txt                              [Page 50]
  2798.  
  2799.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2800.  
  2801.  
  2802.                                    APPENDIX B
  2803.                        Message Encapsulation and Formats
  2804.  
  2805.  
  2806.       To minimize changes to existing RSVP implementations and to ensure
  2807.       quick deployment of an SBM in conjunction with RSVP, all communica-
  2808.       tion to and from a DSBM will be performed using messages constructed
  2809.       using the current rules for RSVP message formats and raw IP encapsu-
  2810.       lation. For more details on the RSVP message formats, refer to the
  2811.       RSVP specification (draft-ietf-rsvp-spec-15.ps).  No changes to the
  2812.       RSVP message formats are proposed, but new message types  and new
  2813.       L2-specific objects are added to the RSVP message formats to accom-
  2814.       modate DSBM-related messages. These additions are described below.
  2815.  
  2816.  
  2817.       B.1 Message Addressing
  2818.  
  2819.  
  2820.       For the purpose of DSBM election and detection, AllSBMAddress is
  2821.       used as the destination address while sending out both DSBM_WILLING
  2822.       and I_AM_DSBM messages. A DSBM client first detects a managed seg-
  2823.       ment by listening to I_AM_DSBM advertisements and records the
  2824.       DSBMAddress (unicast IP address of the DSBM) for the purpose of com-
  2825.       munication with the DSBM over the managed segment.
  2826.  
  2827.       B.2. Message Sizes
  2828.  
  2829.  
  2830.       Each message must occupy exactly one IP datagram. If it exceeds the
  2831.       MTU, such a datagram will be fragmented by IP and reassembled at the
  2832.       recipient node. This has a consequence that a single message may not
  2833.       exceed the maximum IP datagram size, approximately 64K bytes.
  2834.  
  2835.  
  2836.       B.3. RSVP-related Message Formats
  2837.  
  2838.  
  2839.  
  2840.       All RSVP messages directed to and from a DSBM may contain various
  2841.       RSVP objects defined in the RSVP specification and messages continue
  2842.       to follow the formatting rules specified in the RSVP specification.
  2843.       In addition, an RSVP implementation must also recognize new object
  2844.       classes that are described below.
  2845.  
  2846.       B.3.1. Object Formats
  2847.  
  2848.  
  2849.       All objects are defined using the format specified in the RSVP
  2850.  
  2851.  
  2852.  
  2853.   draft-ietf-issll-is802-sbm-04.txt                              [Page 51]
  2854.  
  2855.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2856.  
  2857.  
  2858.       specification. Each object has a 32-bit header that contains length
  2859.       (of the object in bytes including the object header), the object
  2860.       class number, and a C-Type.  All unused fields should be set to zero
  2861.       and ignored on receipt.
  2862.  
  2863.       B.3.2. LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK Objects
  2864.  
  2865.  
  2866.       LAN_NHOP, LAN_LOOPBACK,  and RSVP_HOP_L2 objects are identified as
  2867.       separate object classes and the value of Class_Num for the objects
  2868.       is chosen so that non-SBM aware RSVP nodes will ignore the objects
  2869.       without forwarding them or generating an error message.
  2870.  
  2871.  
  2872.       B.3.3. IEEE 802 Canonical Address Format
  2873.  
  2874.       The 48-bit MAC Addresses used by IEEE 802 were originally defined in
  2875.       terms of wire order transmission of bits in the source and destina-
  2876.       tion MAC address fields. The same wire order applied to both Ether-
  2877.       net and Token Ring. Since the bit transmission order of Ethernet and
  2878.       Token Ring data differ - Ethernet octets are transmitted least sig-
  2879.       nificant bit first, Token Ring most significant first - the numeric
  2880.       values naturally associated with the same address on different 802
  2881.       media differ. To facilitate the communication of address values in
  2882.       higher layer protocols which might span both token ring and Ethernet
  2883.       attached systems connected by bridges, it was necessary to define
  2884.       one reference format - the so called canonical format for these
  2885.       addresses. Formally the canonical format defines the value of the
  2886.       address, separate from the encoding rules used for transmission. It
  2887.       comprises a sequence of octets derived from the original wire order
  2888.       transmission bit order as follows. The least significant bit of the
  2889.       first octet is the first bit transmitted, the next least significant
  2890.       bit the second bit, and so on to the most significant bit of the
  2891.       first octet being the 8th bit transmitted; the least significant bit
  2892.       of the second octet is the 9th bit transmitted, and so on to the
  2893.       most significant bit of the sixth octet of the canonical format
  2894.       being the last bit of the address transmitted.
  2895.  
  2896.       This canonical format corresponds to the natural value of the
  2897.       address octets for Ethernet. The actual transmission order or formal
  2898.       encoding rules for addresses on media which do not transmit bit
  2899.       serially are derived from the canonical format octet values.
  2900.  
  2901.       This document requires that the MAC address for links based on the
  2902.       IEEE 802 LAN technologies be encoded in the canonical format as a
  2903.       sequence of 6 octets. In the following, we define the object formats
  2904.       for objects that contain L2 addresses that are based on the canoni-
  2905.       cal representation.
  2906.  
  2907.  
  2908.  
  2909.   draft-ietf-issll-is802-sbm-04.txt                              [Page 52]
  2910.  
  2911.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2912.  
  2913.  
  2914.       B.3.4. RSVP_HOP_L2 object
  2915.  
  2916.  
  2917.       RSVP_HOP_L2 object uses object class = 161; it contains the L2
  2918.       address of the previous hop L3 device in the IEEE Canonical address
  2919.       format discussed above.
  2920.  
  2921.       RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format
  2922.       used. In our case, CType=1 represents the IEEE Canonical Address
  2923.       format.
  2924.  
  2925.                0              1             2                 3
  2926.       +---------------+---------------+---------------+---------------+
  2927.       |       Length                  |   161         |CType(addrtype)|
  2928.       +---------------+---------------+---------------+---------------+
  2929.       |                  Variable length Opaque data                  |
  2930.       +---------------+---------------+---------------+---------------+
  2931.  
  2932.       CType = 1 (IEEE Canonical Address format)
  2933.  
  2934.       When CType=1, the object format is:
  2935.  
  2936.               0               1               2               3
  2937.       +---------------+---------------+---------------+---------------+
  2938.       |              12               |   161         |      1        |
  2939.       +---------------+---------------+---------------+---------------+
  2940.       |             Octets 0-3 of the MAC address                     |
  2941.       +---------------+---------------+---------------+---------------+
  2942.       |  Octets 4-5 of the MAC addr.  |   /////       |     ////      |
  2943.       +---------------+---------------+---------------+---------------+
  2944.  
  2945.       //// -- unused (set to zero)
  2946.  
  2947.  
  2948.       B.3.5. LAN_NHOP object
  2949.  
  2950.  
  2951.       LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
  2952.       object and LAN_NHOP_L2 address object.
  2953.            <LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
  2954.  
  2955.       LAN_NHOP_L2 address object uses object class = 162 and uses the same
  2956.       format (but different class number) as the RSVP_HOP_L2 object. It
  2957.       provides the L2 or MAC address of the next hop L3 device.
  2958.  
  2959.               0               1               2               3
  2960.       +---------------+---------------+---------------+---------------+
  2961.       |       Length                  |   162         |CType(addrtype)|
  2962.  
  2963.  
  2964.  
  2965.   draft-ietf-issll-is802-sbm-04.txt                              [Page 53]
  2966.  
  2967.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  2968.  
  2969.  
  2970.       +---------------+---------------+---------------+---------------+
  2971.       |                  Variable length Opaque data                  |
  2972.       +---------------+---------------+---------------+---------------+
  2973.  
  2974.       CType = 1 (IEEE 802 Canonical Address Format as defined below)
  2975.       See the RSVP_HOP_L2 address object for more details.
  2976.  
  2977.       LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP
  2978.       address of the next hop L3 device.
  2979.  
  2980.       LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address
  2981.       family used.
  2982.  
  2983.       IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
  2984.       +---------------+---------------+---------------+---------------+
  2985.       |       Length = 8              |   163         |       1       |
  2986.       +---------------+---------------+---------------+---------------+
  2987.       |               IPv4 NHOP address                               |
  2988.       +---------------------------------------------------------------+
  2989.  
  2990.  
  2991.       IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
  2992.       +---------------+---------------+---------------+---------------+
  2993.       |       Length = 20             |   163         |       2       |
  2994.       +---------------+---------------+---------------+---------------+
  2995.       //              IPv6 NHOP address (16 bytes)                    |
  2996.       +---------------------------------------------------------------+
  2997.  
  2998.  
  2999.       B.3.6. LAN_LOOPBACK Object
  3000.  
  3001.  
  3002.       The LAN_LOOPBACK object gives the IP address of the outgoing inter-
  3003.       face for a PATH message and uses object class=164; both IPv4 and
  3004.       IPv6 formats are specified.
  3005.  
  3006.       IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
  3007.  
  3008.               0               1               2               3
  3009.       +---------------+---------------+---------------+---------------+
  3010.       |       Length                  |   164         |       1       |
  3011.       +---------------+---------------+---------------+---------------+
  3012.       |                  IPV4 address of an interface                 |
  3013.       +---------------+---------------+---------------+---------------+
  3014.  
  3015.       IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
  3016.  
  3017.       +---------------+---------------+---------------+---------------+
  3018.  
  3019.  
  3020.  
  3021.   draft-ietf-issll-is802-sbm-04.txt                              [Page 54]
  3022.  
  3023.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  3024.  
  3025.  
  3026.       |       Length                  |   164         |       2       |
  3027.       +---------------+---------------+---------------+---------------+
  3028.       |                                                               |
  3029.       +                                                               +
  3030.       |                                                               |
  3031.       +                  IPV6 address of an interface                 +
  3032.       |                                                               |
  3033.       +                                                               +
  3034.       |                                                               |
  3035.       +---------------+---------------+---------------+---------------+
  3036.  
  3037.  
  3038.       B.3.7. TCLASS Object
  3039.  
  3040.  
  3041.       TCLASS object (traffic class based on IEEE 802.1p) uses  object
  3042.       class = 165.
  3043.  
  3044.                0              1               2               3
  3045.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3046.       |         Length                |   165         |       1       |
  3047.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3048.       |    ///        |    ///        |  ////         | ////    | PV  |
  3049.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3050.  
  3051.       Only  3 bits in data contain the user-priority value (PV).
  3052.  
  3053.  
  3054.       B.4. RSVP PATH Message Format
  3055.  
  3056.  
  3057.       As specified in the RSVP specification, an RSVP_PATH message con-
  3058.       tains the RSVP Common Header and the relevant RSVP objects. For the
  3059.       RSVP Common Header, refer to the RSVP specification (draft-ietf-
  3060.       rsvp-spec-15.ps). Enhancements to an RSVP_PATH message include addi-
  3061.       tional objects as specified below.
  3062.  
  3063.       <RSVP_PATH> ::= <RSVP Common Header> [<INTEGRITY>]
  3064.                       <RSVP_HOP_L2> <LAN_NHOP>
  3065.                       <LAN_LOOPBACK> [<TCLASS>]  <SESSION><RSVP_HOP>
  3066.                       <TIME_VALUES> [<POLICY DATA>] <sender descriptor>
  3067.  
  3068.       If the INTEGRITY object is present, it must immediately follow the
  3069.       RSVP common header. L2-specific objects must always precede the SES-
  3070.       SION object.
  3071.  
  3072.       B.5. RSVP RESV Message Format
  3073.  
  3074.  
  3075.  
  3076.  
  3077.   draft-ietf-issll-is802-sbm-04.txt                              [Page 55]
  3078.  
  3079.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  3080.  
  3081.  
  3082.       As specified in the RSVP specification, an RSVP_RESV message con-
  3083.       tains the RSVP Common Header and relevant RSVP objects. In addition,
  3084.       it may contain an optional TCLASS object as described earlier.
  3085.  
  3086.  
  3087.       B.6. Additional RSVP message types to handle SBM interactions
  3088.  
  3089.  
  3090.       New RSVP message types are introduced to allow interactions between
  3091.       a DSBM and an RSVP node (host/router) for the purpose of discovering
  3092.       and binding to a DSBM. New RSVP message types needed are as follows:
  3093.  
  3094.       RSVP Msg Type (8 bits)      Value
  3095.       DSBM_WILLING                66
  3096.       I_AM_DSBM                   67
  3097.  
  3098.  
  3099.       All SBM-specific messages are formatted as RSVP messages with an
  3100.       RSVP common header followed by SBM-specific objects.
  3101.  
  3102.       <SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
  3103.  
  3104.       where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
  3105.  
  3106.  
  3107.       For each SBM message type, there is a set of rules for the permissi-
  3108.       ble choice of object types. These rules are specified using Backus-
  3109.       Naur Form (BNF) augmented with square brackets surrounding optional
  3110.       sub-sequences. The BNF implies an order for the objects in a mes-
  3111.       sage. However, in many (but not all) cases, object order makes no
  3112.       logical difference. An implementation should create messages with
  3113.       the objects in the order shown here, but accept the objects in any
  3114.       permissible order. Any exceptions to this rule will be pointed out
  3115.       in the specific message formats.
  3116.  
  3117.  
  3118.       DSBM_WILLING Message
  3119.  
  3120.  
  3121.       <DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
  3122.                                  <SBM PRIORITY>
  3123.  
  3124.  
  3125.       I_AM_DSBM Message
  3126.  
  3127.  
  3128.       <I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS>
  3129.                                  <SBM PRIORITY> <DSBM Timer Intervals>
  3130.  
  3131.  
  3132.  
  3133.   draft-ietf-issll-is802-sbm-04.txt                              [Page 56]
  3134.  
  3135.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  3136.  
  3137.  
  3138.       All I_AM_DSBM messages are multicast to the well known DSBM_GROUP
  3139.       address.  The default priority of an SBM is 1 and higher priority
  3140.       values represent higher precedence. The priority value zero indi-
  3141.       cates that the SBM is not eligible to be the DSBM.
  3142.  
  3143.  
  3144.       Relevant Objects
  3145.  
  3146.  
  3147.       DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS
  3148.       object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object
  3149.       uses <Class=42, C-Type=2>.
  3150.  
  3151.       IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
  3152.               0               1               2               3
  3153.       +---------------+---------------+---------------+---------------+
  3154.       |                       IPv4 DSBM IP Address                    |
  3155.       +---------------+---------------+---------------+---------------+
  3156.  
  3157.       IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2
  3158.       +---------------+---------------+---------------+---------------+
  3159.       |                                                               |
  3160.       +                                                               +
  3161.       |                                                               |
  3162.       +                       IPv6 DSBM IP Address                    +
  3163.       |                                                               |
  3164.       +                                                               +
  3165.       |                                                               |
  3166.       +---------------+---------------+---------------+---------------+
  3167.  
  3168.       SBM_PRIORITY Object: class = 43, C-Type =1
  3169.  
  3170.               0               1               2               3
  3171.       +---------------+---------------+---------------+---------------+
  3172.       |   ////        |   ////        | ////          | SBM priority  |
  3173.       +---------------+---------------+---------------+---------------+
  3174.  
  3175.  
  3176.       TIMER INTERVAL VALUES.
  3177.  
  3178.       The two timer intervals, namely, DSBM Dead Interval and DSBM Refresh
  3179.       Interval, are specified as integer values each  in the range of
  3180.       0..255 seconds. Both values are included in a  single "DSBM Timer
  3181.       Intervals" object described below.
  3182.  
  3183.       DSBM Timer Intervals Object: class = 44, C-Type =1
  3184.  
  3185.       +---------------+---------------+---------------+----------------+
  3186.  
  3187.  
  3188.  
  3189.   draft-ietf-issll-is802-sbm-04.txt                              [Page 57]
  3190.  
  3191.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  3192.  
  3193.  
  3194.       |   ////        |   ////        | DeadInterval  |Refresh Interval|
  3195.       +---------------+---------------+---------------+----------------+
  3196.  
  3197.  
  3198.  
  3199.  
  3200.  
  3201.  
  3202.  
  3203.  
  3204.  
  3205.  
  3206.  
  3207.  
  3208.  
  3209.  
  3210.  
  3211.  
  3212.  
  3213.  
  3214.  
  3215.  
  3216.  
  3217.  
  3218.  
  3219.  
  3220.  
  3221.  
  3222.  
  3223.  
  3224.  
  3225.  
  3226.  
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244.  
  3245.   draft-ietf-issll-is802-sbm-04.txt                              [Page 58]
  3246.  
  3247.   INTERNET-DRAFT       SBM (Subnet Bandwidth Manager)           July, 1997
  3248.  
  3249.  
  3250.                                 ACKNOWLEDGEMENTS
  3251.  
  3252.       Authors are grateful to Ramesh Pabbati (Microsoft), Mick Seaman
  3253.       (3COM), Andrew Smith (Extreme Networks) for their constructive com-
  3254.       ments on the SBM design and the earlier versions of this draft.
  3255.  
  3256.       6. Authors` Addresses
  3257.  
  3258.               Raj Yavatkar
  3259.               Intel Corporation
  3260.               2111 N.E. 25th Avenue,
  3261.               Hillsboro, OR 97124
  3262.               USA
  3263.               phone: +1 503-264-9077
  3264.               email: yavatkar@ibeam.intel.com
  3265.  
  3266.               Don Hoffman
  3267.               Sun Microsystems, Inc.
  3268.               2550 Garcia Avenue
  3269.               Mountain View, California 94043-1100
  3270.               USA
  3271.               phone: +1 503-297-1580
  3272.               email: don.hoffman@eng.sun.com
  3273.  
  3274.               Yoram Bernet
  3275.               Microsoft
  3276.               1 Microsoft Way
  3277.               Redmond, WA 98052
  3278.               USA
  3279.               phone: +1 206 936 9568
  3280.               email: yoramb@microsoft.com
  3281.  
  3282.               Fred Baker
  3283.               Cisco Systems
  3284.               519 Lado Drive
  3285.               Santa Barbara, California 93111
  3286.               USA
  3287.               phone: +1 408 526 4257
  3288.               email: fred@cisco.com
  3289.  
  3290.  
  3291.  
  3292.  
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.   draft-ietf-issll-is802-sbm-04.txt                              [Page 59]
  3302.  
  3303.  
  3304.  
  3305.  
  3306.