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-framework-00.txt < prev    next >
Text File  |  1997-02-21  |  40KB  |  953 lines
  1.  
  2. Internet Engineering Task Force                              A. Ghanwani
  3. INTERNET DRAFT                                                J. W. Pace
  4.                                                            V. Srinivasan
  5.                                                                      IBM
  6.                                                            February 1997
  7.  
  8.  
  9.              A Framework for Providing Integrated Services
  10.                Over Shared and Switched LAN Technologies
  11.  
  12.                 draft-ietf-issll-is802-framework-00.txt
  13.  
  14.  
  15. Status of This Memo
  16.  
  17.    This document is an Internet-Draft.  Internet Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of six
  23.    months, and may be updated, replaced, or obsoleted by other documents
  24.    at any time.  It is not appropriate to use Internet Drafts as
  25.    reference material, or to cite them other than as a ``working draft''
  26.    or ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check
  29.    the ``1id-abstracts.txt'' listing contained in the internet-drafts
  30.    Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
  31.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  32.    Rim).
  33.  
  34.  
  35. Abstract
  36.  
  37.    Traditionally, LAN technologies such as ethernet and token ring have
  38.    been required to handle best effort services only.  No standard
  39.    mechanism exists for providing bandwidth or delay guarantees on these
  40.    media.  It is therefore not possible to provide guaranteed quality
  41.    of service as will be required by emerging and future multimedia
  42.    applications.  The anticipated demand for real-time applications
  43.    on the Internet has led to the development of RSVP, a signaling
  44.    mechanism for performing resource reservation in the Internet.
  45.    Concurrently, the Integrated Services working group within the
  46.    IETF has been working on the definition of service classes called
  47.    "Integrated Services" which are expected to make use of RSVP.
  48.    Applications will use these service classes in order to obtain the
  49.    desired quality of service from the network.  LAN technologies
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page i]
  57.  
  58. Internet Draft        Integrated Services Over LANs        February 1997
  59.  
  60.  
  61.    such as token ring and ethernet typically constitute the last hop
  62.    in Internet connections.  There is therefore a need to enhance
  63.    these technologies so that they are able to support the Integrated
  64.    Services.  In order to enable such services, it is necessary to
  65.    provide a resource management functions.  This memo describes a
  66.    framework for providing the necessary functionality on shared and
  67.    switched LAN technologies.
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  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.  
  110.  
  111.  
  112. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page ii]
  113.  
  114. Internet Draft        Integrated Services Over LANs        February 1997
  115.  
  116.  
  117. 1. Introduction
  118.  
  119.    The Internet has traditionally provided support for best effort
  120.    traffic only.  However, with the recent advances in link layer
  121.    technology, and with numerous emerging real-time applications such
  122.    as video conferencing, Internet telephony, etc, there has been much
  123.    interest for supporting real-time services over the Internet.  These
  124.    new requirements have led to the development of RSVP [3], a signaling
  125.    mechanism for providing resource reservation on the Internet.  The
  126.    protocol is currently being standardized by the IETF. Simultaneously,
  127.    the Integrated Services working group of the IETF has been working on
  128.    the specification of various service classes.  Each of these service
  129.    classes is designed to provide certain Quality of Service (QoS)
  130.    guarantees to traffic conforming to a specified set of parameters.
  131.    Applications are expected to use one of these classes depending on
  132.    their QoS requirements.
  133.  
  134.    Legacy LAN technologies such as ethernet and token ring currently
  135.    lack the necessary functionality to support real-time traffic.  They,
  136.    however, typically constitute the last mile between users and the
  137.    Internet backbone of campus networks.  Furthermore, the development
  138.    of standards for high speed LANs such as gigabit ethernet favors the
  139.    likelihood that these technologies will eventually be deployed in the
  140.    backbone.  It is therefore necessary to enhance these technologies so
  141.    that they are able to support end-to-end service guarantees such as
  142.    those defined by the Integrated Services.
  143.  
  144.    In order to support real-time services, there must be some mechanism
  145.    for resource management at the link level.  The ISSLL (Integrated
  146.    Services over Specific Link Layers) working group was chartered with
  147.    the purpose of exploring such mechanisms for various link layer
  148.    technologies.  Resource management in this context encompasses the
  149.    functions of admission control, scheduling, traffic policing, path
  150.    selection, etc.
  151.  
  152.    This document is concerned with specifying a framework for providing
  153.    Integrated Services over LAN technologies such as ethernet and
  154.    token ring.  We begin by defining the scope of the solution to be
  155.    developed.  A taxonomy of Layer 2 topologies is discussed with an
  156.    emphasis on the capabilities of each which can be leveraged for
  157.    enabling integrated services over these topologies.  Next, the
  158.    requirements and goals for a resource management mechanism capable of
  159.    providing Integrated Services in a subnet are listed and discussed.
  160.    These functions will be provided by an entity which is referred to
  161.    as the Bandwidth Manager.  We then discuss the various components
  162.    of the Bandwidth Manager.  No assumptions have been made about the
  163.    technology or topology at the link layer.  The framework is intended
  164.    to be as exhaustive as possible; this means that it is possible that
  165.  
  166.  
  167.  
  168. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 1]
  169.  
  170. Internet Draft        Integrated Services Over LANs        February 1997
  171.  
  172.  
  173.    all the functions discussed may not be supportable by a particular
  174.    topology/technology, but this should not preclude the usage of this
  175.    model for the technology.
  176.  
  177.  
  178. 2. Supporting Integrated Services Within a Subnet:  Requirements and
  179.    Goals
  180.  
  181.    This section discusses the requirements and goals which should drive
  182.    the design of an architecture for supporting Integrated Services
  183.    over legacy LAN technologies.  The requirements refer to functions
  184.    and features which must be supported, while goals refer to functions
  185.    and features which are desirable, but are not an absolute necessity.
  186.    Many of the requirements and goals are driven by the functionality
  187.    supported by RSVP.
  188.  
  189.  
  190. 2.1. Requirements
  191.  
  192.     -  Resource Reservation:  The mechanism must be capable of reserving
  193.        resources on a single segment or multiple segments and at
  194.        bridges/switches connecting them.  It must be able to provide
  195.        reservations for both unicast and multicast sessions.  It should
  196.        be possible to change the level of reservation while the session
  197.        is in progress.
  198.  
  199.     -  Admission Control:  The mechanism must be able to estimate the
  200.        level of resources necessary to meet the QoS for a session based
  201.        on the existing reservations in order to decide whether or not
  202.        the session can be admitted.  It should also be possible for a
  203.        host to query about the availability of resources.  It must be
  204.        able to provide different types of QoS such as guaranteed delay,
  205.        guaranteed bandwidth, etc.
  206.  
  207.     -  Flow Separation and Scheduling:  It is necessary to provide a
  208.        mechanism for traffic flow separation so that real-time flows can
  209.        be given preferential treatment over best effort flows.  Packets
  210.        of real-time flows can then be isolated and scheduled according
  211.        to their service requirements.  Scheduling algorithms can range
  212.        from simple static priority queueing to more complex algorithms
  213.        such as weighted fair queueing.
  214.  
  215.     -  Policing:  Traffic policing must be performed in order to ensure
  216.        that sources adhere to their negotiated traffic specifications.
  217.        Policing must be implemented at the sources and must ensure
  218.        that violating traffic is either dropped or transmitted as best
  219.        effort.
  220.  
  221.  
  222.  
  223.  
  224. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 2]
  225.  
  226. Internet Draft        Integrated Services Over LANs        February 1997
  227.  
  228.  
  229.     -  Fault Tolerance and Recovery:  The mechanism must be able to
  230.        function in the presence of failures; i.e.  there should not be a
  231.        single point of failure.  Back-up and failure recovery mechanisms
  232.        must be provided.
  233.  
  234.     -  Synchronization:  There should be some mechanism for resolving
  235.        synchronization and deadlock issues.  For instance, the case
  236.        where multiple sessions simultaneously request resources on a
  237.        common part of the network must be correctly handled.
  238.  
  239.     -  Soft state reservations:  The mechanism must maintain soft-state
  240.        information about the reservations.  This means that reservations
  241.        must be periodically refreshed if the reservation is to be
  242.        maintained; otherwise the reservation will expire after some
  243.        pre-specified interval.
  244.  
  245.     -  Centralized or distributed implementation:  In the case of a
  246.        centralized implementation, a single entity manages the resources
  247.        of the entire subnet.  This approach avoids synchronization and
  248.        deadlock problems but will not scale to subnets with a large
  249.        number of hosts.  In a fully distributed implementation, each
  250.        segment will have a separate entity managing its resources.  This
  251.        approach is scalable, but requires synchronization.  Ideally,
  252.        implementation should be flexible; i.e.  a centralized approach
  253.        may be used for small subnets and distributed approach, where
  254.        one or more segments is managed by a single entity, can be used
  255.        for larger subnets.  Examples of centralized and distributed
  256.        implementations are discussed in Section 4.
  257.  
  258.     -  Network Management:  The MIBs supported must be specified.
  259.  
  260.     -  Interaction with Existing Resource Management Controls:  The
  261.        interaction with existing infrastructure would need to be
  262.        specified.  For instance, FDDI has resource management with
  263.        its "Synchronous Bandwidth Manager".  The BM for FDDI must be
  264.        designed so that it takes advantage of this.
  265.  
  266.  
  267. 2.2. Goals
  268.  
  269.     -  Independence from higher layer protocols:  The mechanism should
  270.        be independent of higher layer protocols such as RSVP and IP.
  271.        Independence from RSVP is desirable so that it can interwork with
  272.        other reservation protocols such as STII. Independence from IP is
  273.        desirable so that it can interwork with protocols such as IPX,
  274.        NetBIOS, etc.
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 3]
  281.  
  282. Internet Draft        Integrated Services Over LANs        February 1997
  283.  
  284.  
  285.     -  Receiver heterogeneity:  The mechanism should support
  286.        heterogeneous receiver groups; i.e.  the level of reservation may
  287.        be different for different receivers of a multicast group.
  288.  
  289.     -  Support for different filter styles:  It is desirable to provide
  290.        support for the different filter as defined by RSVP such as fixed
  291.        filter, shared explicit and shared wildcard.
  292.  
  293.     -  Scalability:  The mechanism and protocols should have a low
  294.        overhead and should scale to large receiver groups.
  295.  
  296.     -  Path Selection:  In a bridged or switched LAN, it may be
  297.        worthwhile to do path selection, where possible, for a given
  298.        source-destination in order to utilize resources in an efficient
  299.        manner.  Along with other mechanisms, such as source routing in
  300.        token ring networks and bridge filtering, path selection can
  301.        ensure optimum utilization of network resources.  Frames will
  302.        appear only on those segments on which there are designated
  303.        receivers, or when the segment is on the path between the sender
  304.        and receiver.
  305.  
  306.  
  307. 3. Legacy LAN Topologies and Their Features
  308.  
  309.    We are concerned with specifying a framework for Integrated
  310.    Services over legacy LAN technologies.  These technologies include
  311.    ethernet/IEEE 802.3, token ring/IEEE 802.5 and FDDI. The extent to
  312.    which real-time services can be supported on a network depend to a
  313.    large degree on the available functions for providing priority media
  314.    access as well as the ability to identify packets of real-time flows
  315.    so that they can be given preferential treatment.  This section
  316.    discusses some of the capabilities of these LAN technologies and
  317.    provides a taxonomy of topologies.
  318.  
  319.    The basic topology of a legacy LAN network may be shared, switched
  320.    half duplex or switched full duplex.  In the shared topology,
  321.    multiple stations may be connected to a single segment.  Contention
  322.    for media access is resolved using protocols such as CSMA/CD in
  323.    ethernet and token passing in token ring and FDDI. Switched half
  324.    duplex, is essentially a shared topology with the restriction that
  325.    only a single station is attached per bridge/switch port, i.e.  there
  326.    are only two stations contending for resources on any segment.
  327.    This topology is fast becoming popular with the need for increased
  328.    bandwidth.  Finally, in a switched full duplex topology, there is a
  329.    single station per switch port and the media allows for full duplex
  330.    operation.  Therefore, in this topology, there is no access control
  331.    such as CSMA/CD or token passing.
  332.  
  333.  
  334.  
  335.  
  336. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 4]
  337.  
  338. Internet Draft        Integrated Services Over LANs        February 1997
  339.  
  340.  
  341.    Another important element in the discussion of topologies is the
  342.    ability to support priority handling of traffic.  Priority provides
  343.    a coarse method for isolation between flows and allows opens the
  344.    possibility to easily support scheduling algorithms which give
  345.    preferential treatment to high priority flows.  These functions are
  346.    key requirements as pointed out in Section 2.  Native ethernet/802.3
  347.    does not include support for priority.  Token ring/802.5 and FDDI on
  348.    the other hand support up to eight levels of priority.  Three bits
  349.    of the frame control field are used for carrying the frame priority.
  350.    Equally important in token ring networks are the notions of reserved
  351.    priority and access priority.  Reserved priority relates to the value
  352.    of priority which a station uses to reserve the token for the next
  353.    transmission on the ring.  When a free token is circulating, only
  354.    those stations having an access priority greater than or equal to the
  355.    reserved priority in the token will be allowed to seize the token
  356.    for transmission.  More recently, the IEEE 802.1 Standards Committee
  357.    has been working on the standards for expedited traffic classes in
  358.    bridges/switches [1].  The proposed standard requires a new frame
  359.    format for ethernet which carry three bits to indicate the frame
  360.    priority.  This allows for the support of eight traffic classes.
  361.    The standard does not specify scheduling algorithms between traffic
  362.    classes, and indeed, a bridge/switch need not implement separate
  363.    queues for each traffic class.
  364.  
  365.    Depending on the basic topology used and the ability to support
  366.    priority, there are six possible scenarios as follows:
  367.  
  368.     1. Shared topology without priority:  This category includes pure
  369.        shared media such as ethernet and legacy 802.3 networks which
  370.        are multi-access technologies with no support for priority media
  371.        access.  A special case of this topology is one where only a
  372.        single device is attached to the port in the network.  Shared
  373.        topology without priority offers no capability for isolation
  374.        between reserved/unreserved flows.  No service guarantees can be
  375.        provided for this scenario.
  376.  
  377.     2. Shared topology with priority:  This category includes
  378.        ethernet/802.3 networks which implement the emerging IEEE 802.1p
  379.        standard, token ring/802.5 networks and FDDI networks.  However,
  380.        shared ethernet with frame priority may offer limited support
  381.        for priority access because of the CSMA/CD protocol; at best
  382.        loose statistical service guarantees may be possible.  On the
  383.        other hand, deterministic guarantees can be provided for token
  384.        ring media if the frame priority, reserved priority and access
  385.        priority are used in conjunction with appropriate hardware.
  386.  
  387.     3. Switched half duplex topology without priority:  This scenario
  388.        is a special case of shared topology without priority where
  389.  
  390.  
  391.  
  392. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 5]
  393.  
  394. Internet Draft        Integrated Services Over LANs        February 1997
  395.  
  396.  
  397.        there are only two device per segment (an end station and a
  398.        bridge/switch or two bridges/switches).  This allows for higher
  399.        bandwidth per station.  Due to the absence of priority and
  400.        the CSMA/CD protocol, little can be done to isolate flows for
  401.        scheduling.
  402.  
  403.     4. Switched half duplex topology with priority:  This scenario is
  404.        a special case of shared topology with priority but there are
  405.        now only two devices per segment.  This reduces the contention
  406.        for resources.  Ethernet/802.3 with this topology will likely
  407.        be able to support some statistical service guarantees.  More
  408.        deterministic guarantees will be possible for token ring/802.5
  409.        media.
  410.  
  411.     5. Switched full duplex topology without priority:  This scenario
  412.        includes switched ethernet where the CSMA/CD protocol is no
  413.        longer used and full duplex operation is possible.  Because
  414.        priority is not available, again, it is not possible to provide
  415.        flow isolation between best effort and reserved flows.
  416.  
  417.     6. Switched full duplex topology with priority:  This category is
  418.        similar to the above, but frame priority is also available This
  419.        topology provides best capabilities for priority access and, at
  420.        the very least, enables a coarse level of flow separation based
  421.        on frame priority and static priority scheduling.
  422.  
  423.    There is also the possibility of hybrid topologies where two or more
  424.    of the above coexist.  For instance, it is possible that within a
  425.    single subnet, there are some bridges/switches which support priority
  426.    and some which do not.  If the flow in question traverses both kinds
  427.    of bridges/switches in the network, the least common denominator
  428.    will prevail.  In other words, for that flow, the network will be
  429.    considered to be of the less capable of the topologies.
  430.  
  431.  
  432. 4. Architecture for Integrated Services in Legacy LANs
  433.  
  434.    The functional requirements described in Section 2 will be performed
  435.    by an entity which we refer to as the Bandwidth Manager (BM). The BM
  436.    is responsible for providing mechanisms for an application (1) to
  437.    request QoS from the network.  The major components of the BM are
  438.    discussed below.
  439.  
  440. ----------------------------
  441. 1. We use "application" to indicate any higher layer protocol or
  442.    application
  443.  
  444.  
  445.  
  446.  
  447.  
  448. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 6]
  449.  
  450. Internet Draft        Integrated Services Over LANs        February 1997
  451.  
  452.  
  453. 4.1. Requester Module
  454.  
  455.    The requester module (RM) provides an interface between higher layer
  456.    protocols (such as RSVP, STII, etc.)  and the bandwidth manager.  It
  457.    provides a set of primitives which define the mechanism by which the
  458.    various services of the BM are invoked.  For instance, the higher
  459.    layer protocol will initiate the resource reservation at layer 2 by
  460.    providing the RM with the traffic descriptors and desired quality
  461.    of service.  The RM then communicates with the other components of
  462.    the BM to perform admission control.  The function of the RM must be
  463.    provided in every device (e.g.  host, router) which might need to
  464.    initiate the resource reservation at the link layer.
  465.  
  466.  
  467. 4.2. Bandwidth Allocator
  468.  
  469.    The bandwidth allocator (BA) is responsible for performing admission
  470.    control and tracking the allocation of resources in the subnet.  A
  471.    host can request various services, e.g.  bandwidth reservation,
  472.    changes in reservation, queries about resource availability, etc.
  473.    The communication between the host and the BA will take place
  474.    through the RM. The location of the BA will depend largely on the
  475.    implementation method.  In a centralized implementation, the BA
  476.    may reside on a single station in the subnet.  In a distributed
  477.    implementation, the functions of the BA may be provided in all the
  478.    hosts and bridges/switches as necessary.
  479.  
  480.  
  481. 4.3. Communication Protocols and Primitives
  482.  
  483.    The protocols and primitives for communication between the various
  484.    components of the BM must be specified.  These include the following:
  485.  
  486.     -  Communication between the higher layer protocols and the RM:
  487.        The BM must define primitives for the application to initiate
  488.        reservations, query the BA about available resources, and
  489.        change or delete reservations, etc.  These primitives could be
  490.        implemented as an API for an application to invoke functions of
  491.        the BM via the RM.
  492.  
  493.     -  Communication between the RM and the BA: A protocol must be
  494.        defined for the communication between the RM and the BA. This
  495.        protocol will specify the messages which must be exchanged
  496.        between the RM and the BA in order to service various requests
  497.        by the application.  Additionally, the protocol must specify a
  498.        method by which a RM can send a query message which will trigger
  499.        a response from its BA.
  500.  
  501.  
  502.  
  503.  
  504. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 7]
  505.  
  506. Internet Draft        Integrated Services Over LANs        February 1997
  507.  
  508.  
  509.     -  Communication between peer BAs:  If there is more than one BA in
  510.        the subnet, a means must be specified for inter-BA communication.
  511.        Specifically, the BAs must be able to decide among themselves
  512.        about which BA would be responsible for which segments and
  513.        bridges or switches.  Further, if a request is made for resource
  514.        reservation along the domain of multiple BAs, the BAs must be
  515.        able to handle such a scenario correctly.  Inter-BA communication
  516.        will also be required to handle failures.  When a BA fails,
  517.        another BA should assume its responsibility.
  518.  
  519.  
  520. 4.4. Implementation Scenarios
  521.  
  522.    Example scenarios are provided below showing the location of the
  523.    the components of the bandwidth manager in centralized and fully
  524.    distributed implementations.  Note that in either case, the RM
  525.    must be present on all end-stations/hosts which desire to make
  526.    reservations.  Essentially, centralized or distributed refers to the
  527.    implementation of the BA, the component responsible for resource
  528.    reservation and admission control.  In the figures below, "App"
  529.    refers to the application making use of the BM. It could either be a
  530.    user application, or a higher layer protocol process such as RSVP.
  531.  
  532.                                +---------+
  533.                            .-->|  BA     |<--.
  534.                           /    +---------+    \
  535.                          / .-->| Layer 2 |<--. \
  536.                         / /    +---------+    \ \
  537.                        / /                     \ \
  538.                       / /                       \ \
  539.   +---------+        / /                         \ \       +---------+
  540.   |  App    |<----- /-/---------------------------\-\----->|  App    |
  541.   +---------+      / /                             \ \     +---------+
  542.   |  RM     |<----. /                               \ .--->|  RM     |
  543.   +---------+      / +---------+        +---------+  \     +---------+
  544.   | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
  545.   +---------+        +---------+        +---------+        +---------+
  546.  
  547.   RSVP Host/         Intermediate       Intermediate       RSVP Host/
  548.      Router          Bridge/Switch      Bridge/Switch         Router
  549.  
  550.    Figure 1:  Bandwidth Manager with a centralized Bandwidth Allocator
  551.  
  552.    Figure 1 shows a centralized implementation.  Each host would contain
  553.    an RM. Intermediate bridges and switches in the network need not have
  554.    any functions of the BM since they will not be actively participating
  555.    in admission control.  The RM at the station requesting a reservation
  556.    initiates communication with its BA. With this approach, the end
  557.  
  558.  
  559.  
  560. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 8]
  561.  
  562. Internet Draft        Integrated Services Over LANs        February 1997
  563.  
  564.  
  565.    host must be able to identify its BA. For larger subnets, a single
  566.    BA may not be able to handle the reservations for the entire subnet.
  567.    In that case it would be necessary to deploy multiple BAs, each
  568.    managing the resources of a non-overlapping subset of segments.  In a
  569.    centralized implementation, the BA must maintain topology information
  570.    in order to be able to reserve resources on appropriate segments.
  571.  
  572.  
  573.   +---------+                                              +---------+
  574.   |  App    |<-------------------------------------------->|  App    |
  575.   +---------+        +---------+        +---------+        +---------+
  576.   |  RM/BA  |<------>|  BA     |<------>|  BA     |<------>|  RM/BA  |
  577.   +---------+        +---------+        +---------+        +---------+
  578.   | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
  579.   +---------+        +---------+        +---------+        +---------+
  580.  
  581.   RSVP Host/         Intermediate       Intermediate       RSVP Host/
  582.      Router          Bridge/Switch      Bridge/Switch         Router
  583.  
  584.    Figure 2:  Bandwidth Manager with a fully distributed Bandwidth
  585.    Allocator
  586.  
  587.    Figure 2 depicts the scenario of a fully distributed bandwidth
  588.    manager.  In this case, all devices in the subnet must have some BM
  589.    functionality.  All the end hosts are still required to have an RM.
  590.    In addition, all bridges and switches must participate in admission
  591.    control, but there is the possibility of relying on the link layer
  592.    for the maintenance of topology information.
  593.  
  594.    Note that in the figures above, the arrows between peer layers are
  595.    used to indicate logical connectivity.
  596.  
  597.  
  598. 4.5. Logical Operation of the BM in Hosts/Routers and Layer 2 Domain
  599.  
  600.    The figure below shows the location and logical operation of the
  601.    BM in hosts/routers and the Layer 2 domain.  It is not possible to
  602.    provide an explicit example because of the inherent differences that
  603.    arise in centralized and distributed implementations discussed in
  604.    Section 4.4.
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616. Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 9]
  617.  
  618. Internet Draft        Integrated Services Over LANs        February 1997
  619.  
  620.  
  621.     +-------------------------+
  622.     |  +--------+   +------+  |
  623.     |  |Appli-  <--->  RM  |  |
  624.     |  | cation |   +--^---+  |
  625.     |  +--------+      |      |     +-------------------------+
  626.     |    ||         +--V---+  |     |               +------+  |
  627.     |    ||  +------|  BA  <------------------------>  BA  |  |
  628.     |    ||  |      +------+  |     |  +----------+ +-^-^|-+  |
  629.     |    ||  |         |      |     |  |Forwarding|   | ||    |
  630.     |    ||  |         |      |     |  |Process   <---+ ||    |
  631.     |    ||  |         |      |     |  +---|------+     ||    |
  632.     |    ||  |         |      |     |      |  +---------+|    |
  633.     |    \/  |         |      |     |      |  |          |    |
  634.     |  +-----V-+    +--V---+  |     |  +---V--V+    +----V-+  |
  635.     |  |Class- |    |Sched-|  |     |  |Class- |    |Sched-|  |
  636.     |  | ifier |===>| uler |==========>| ifier |===>| uler |====>
  637.     |  +-------+    +------+  |     |  +-------+    +------+  |
  638.     +-------------------------+     +-------------------------+
  639.  
  640.          Host/Router                      Layer 2 Domain
  641.  
  642.     ---->  Signaling/control
  643.     ====>  Data
  644.  
  645.    Figure 3:  The logical Operation of the BM in the hosts/routers and
  646.    the Layer 2 network.
  647.  
  648.    The application, which may be RSVP or some other higher layer
  649.    reservation protocol requests resources by passing information to
  650.    the RM which includes the following:  (i) MAC addresses of the
  651.    source and destination, (ii) traffic descriptors for the flow, and
  652.    (iii) quality of service desired.  The RM then starts the process
  653.    of resource reservation at Layer 2 by contacting the local BA. The
  654.    local BA is responsible for admission control on the segment to which
  655.    the host/router is directly attached.  If the reservation succeeds,
  656.    the local BA sets up the classifier and scheduler as required so
  657.    that the appropriate priority is used for the flow.  The request
  658.    is then propagated to the the "remote" BA controlling the other
  659.    segments along the forwarding path.  In a centralized implementation,
  660.    the BA resides in a server within the subnet.  The classifier and
  661.    scheduler in the bridges/switches along the forwarding path are
  662.    implicitly set up by the priority carried in the data frames if the
  663.    reservation is successful.  On the other hand, in a fully distributed
  664.    implementation, the remote BA resides in every bridge/switch
  665.    and the process of resource reservation would be performed on a
  666.    hop-by-hop basis.  In this scenario, it would also be possible to use
  667.    sophisticated scheduling since the classifier can be explicitly set
  668.    up for each flow.
  669.  
  670.  
  671.  
  672. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 10]
  673.  
  674. Internet Draft        Integrated Services Over LANs        February 1997
  675.  
  676.  
  677. 5. Mapping Issues and Link Layer Support for IntServ Traffic Classes
  678.  
  679.    As stated earlier, the Integrated Services working group has defined
  680.    many service classes offering varying degrees of QoS guarantees.
  681.    Initial effort will concentrate on enabling the controlled load
  682.    and guaranteed service classes [4,5].  The controlled load service
  683.    provides a loose guarantee, informally stated as "better than
  684.    best effort".  The guaranteed service provides a delay bound which
  685.    the network guarantees will never be exceeded.  The extent to
  686.    which these services can be supported at the link layer will be
  687.    technology dependent and will depend on many factors.  Some of the
  688.    mapping issues in light of the emerging link layer standards are
  689.    discussed below.  Further, considering the limitations of some of the
  690.    topologies under consideration, it may not be possible to satisfy
  691.    all the requirements for Integrated Services.  In such cases, it is
  692.    to consider providing support for an approximation of the service
  693.    which may suffice in most practical instances.  For example, it
  694.    may not be feasible to provide policing/shaping at each network
  695.    element (bridge/switch) as is specified in the controlled load
  696.    specification [4].  But if this task is left to the routers/hosts, a
  697.    good approximation to the service can be obtained.
  698.  
  699.  
  700. 5.1. Mapping of Services to Link Level Priority
  701.  
  702.    The number of delay priorities and access methods of the technology
  703.    under consideration will determine how many and what services may be
  704.    supported.  Native token ring, for instance, supports eight priority
  705.    levels while ethernet has no support for priorities.  However, the
  706.    IEEE 802 standards committee is working on two new standards for
  707.    bridges related to multimedia traffic expediting, multicast filtering
  708.    and virtual LANs [1,2].  These standards allow for eight levels of
  709.    frame priority.  The frame priority is signaled on an end-to-end
  710.    basis, unless overridden by bridge/switch management.  Work is in
  711.    progress to address how each of these priorities will map to the
  712.    traffic classes supported by a bridge/switch; even though eight
  713.    levels of priority are allowed, a bridge/switch need not support
  714.    eight distinct service classes.
  715.  
  716.    The priority that is used by a flow should depend on the quality
  717.    of service desired and whether the reservation was successful or
  718.    not.  A flow, therefore should use the priority which best effort
  719.    traffic would use until told otherwise by the signaling mechanism.
  720.    The signaling mechanism will, upon successful completion of resource
  721.    reservation, specify the frame priority which the source must use.
  722.    More details on exact mapping of priorities to services is beyond
  723.    the scope of this document and will be a a part of another document
  724.    dedicated to addressing mapping issues.
  725.  
  726.  
  727.  
  728. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 11]
  729.  
  730. Internet Draft        Integrated Services Over LANs        February 1997
  731.  
  732.  
  733. 5.2. Supporting Receiver Heterogeneity
  734.  
  735.    Receiver heterogeneity means that receivers within a group can each
  736.    have different QoS requirements; i.e.  it is possible that, for a
  737.    given flow, some receivers make a reservation while others decide
  738.    to make use of best effort transport.  RSVP allows heterogeneous
  739.    receivers within a group.  However, handling the problem at layer
  740.    2 can be non-trivial.  Consider for instance, the scenario in the
  741.    figure below.
  742.  
  743.                    +-----+
  744.                    | R1  |
  745.                    +-----+
  746.                       |
  747.                       v
  748.       +-----+      +-----+      +-----+
  749.       | R2  |<-----| SW  |----->| R3  |
  750.       +-----+      +-----+      +-----+
  751.  
  752.    Figure 4:  An instance of receiver heterogeneity.  R1 is the source.
  753.    R2 is a receiver which makes a reservation, and R3 is a receiver
  754.    which is satisfied with best effort service.  SW is a Layer 2 device
  755.    (bridge/switch) participating in resource reservation.
  756.  
  757.    In the figure above, R1 is the upstream router/source and R2 and R3
  758.    are downstream routers/destinations.  R2 sends a RESV message to
  759.    reserve resources for the flow.  R3 would like to simply receive
  760.    the flow using best effort transport.  R1 sends PATH messages which
  761.    are multicast to both R2 and R3.  R2 sends a RESV message to R1
  762.    requesting the reservation of resources.  If the reservation is
  763.    successful at Layer 2, the frames addressed to the group will have a
  764.    high priority corresponding to the service requested by R3.  At SW,
  765.    there must be some mechanism which forwards the packet using high
  766.    priority at the interface to R3 while using the priority for best
  767.    effort traffic at the interface to R2.  This may involve changing the
  768.    contents of the frame itself, or ignoring the frame priority at the
  769.    interface to R2.  Another possibility for supporting heterogeneous
  770.    receivers would be to have separate groups, one for each class of
  771.    receivers.
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 12]
  785.  
  786. Internet Draft        Integrated Services Over LANs        February 1997
  787.  
  788.  
  789. 5.3. Support for Different Reservation Styles
  790.  
  791.               +-----+       +-----+       +-----+
  792.               | R1  |       | R2  |       | R3  |
  793.               +-----+       +-----+       +-----+
  794.                  |             |             |
  795.                  |             v             |
  796.                  |          +-----+          |
  797.                  +--------->| SW  |<---------+
  798.                             +-----+
  799.                                |
  800.                                v
  801.                             +-----+
  802.                             | R4  |
  803.                             +-----+
  804.  
  805.    Figure 5:  An illustration of filter styles.  R1, R2, R3 and R4 are
  806.    RSVP hosts/routers which are members of the same group.  SW is a
  807.    bridge/switch at Layer 2.
  808.  
  809.    In the figure above, R1, R2 and R3 are upstream routers/sources.  R4
  810.    is the downstream router/destination which is the receiver for all of
  811.    these flows.  RSVP allows receiver R4 to specify reservations which
  812.    can apply to:  (a) one specific sender only (fixed filter); (b) any
  813.    of two or more explicitly specified senders (shared explicit filter);
  814.    (c) any sender in the group (shared wildcard filter).  Support for
  815.    the fixed filter is relatively straightforward.  However, support for
  816.    the the other two styles has implications regarding policing; i.e.
  817.    the merged flows from the different sources should be policed so that
  818.    they conform to traffic parameters specified in the filter's Rspec.
  819.  
  820.  
  821. 6. Summary
  822.  
  823.    This document has specified a framework for providing Integrated
  824.    Services over shared and switched LAN technologies.  The ability to
  825.    provide QoS guarantees necessitates some form of admission control
  826.    and resource management.  The requirements and goals of a resource
  827.    management scheme for subnets have been identified and discussed.
  828.    We refer to the entire resource management scheme as a Bandwidth
  829.    Manager.  Architectural considerations were discussed and examples
  830.    were provided to illustrate possible implementations of a Bandwidth
  831.    Manager.  Some of the issues involved in mapping the services from
  832.    higher layers to Layer 2 were discussed.
  833.  
  834.  
  835. References
  836.  
  837.  
  838.  
  839.  
  840. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 13]
  841.  
  842. Internet Draft        Integrated Services Over LANs        February 1997
  843.  
  844.  
  845.  
  846. [1] IEEE Standards for Local and Metropolitan Area Networks:
  847.     Draft Standard for Traffic Class and Dynamic Multicast Filtering
  848.     Services in Bridged Local Area Networks (Draft Supplement to
  849.     802.1D), P802.1p/D4, September, 1996.
  850.  
  851. [2] IEEE Standards for Local and Metropolitan Area Networks:
  852.     Draft Standard for Virtual Bridged Local Area Networks,
  853.     P802.1Q/D4, January, 1997.
  854.  
  855. [3] B. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin,
  856.     "Resource Reservation Protocol (RSVP) - Version 1 Functional
  857.     Specification," Internet Draft, November 1996,
  858.     <draft-ietf-rsvp-spec-14.txt>
  859.  
  860. [4] J. Wroclawski, "Specification of the Controlled-Load Network
  861.     Element Service," Internet Draft, November 1996,
  862.     <draft-ietf-intserv-ctrl-load-svc-04.txt>
  863.  
  864. [5] S. Shenker, C. Partridge and R. Guerin, "Specification of
  865.     Guaranteed Quality of Service," Internet Draft, August 1996,
  866.     <draft-ietf-intserv-guaranteed-svc-06.txt>
  867.  
  868. [6] R. Braden, D. Clark and S. Shenker, "Integrated Services in the
  869.     Internet Architecture: An Overview,"  RFC 1633, June 1994.
  870.  
  871.  
  872. Acknowledgements
  873.  
  874.    Much of the work presented in this document has benefited greatly
  875.    from discussion held at the meetings of the Integrated Services over
  876.    Specific Link Layers (ISSLL) working group.  In particular we would
  877.    like to thank Eric Crawley, Don Hoffman, Mick Seaman, Andrew Smith
  878.    and Raj Yavatkar who have contributed to this effort via earlier
  879.    Internet drafts.
  880.  
  881.  
  882. Authors' Address
  883.  
  884.           Anoop Ghanwani
  885.           IBM Corporation
  886.           P. O. Box 12195
  887.           Research Triangle Park, NC 27709
  888.           Phone:   +1-919-254-0260
  889.           Fax:     +1-919-254-5410
  890.           Email:   anoop@raleigh.ibm.com
  891.  
  892.           Wayne Pace
  893.  
  894.  
  895.  
  896. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 14]
  897.  
  898. Internet Draft        Integrated Services Over LANs        February 1997
  899.  
  900.  
  901.           IBM Corporation
  902.           P. O. Box 12195
  903.           Research Triangle Park, NC 27709
  904.           Phone:   +1-919-254-4930
  905.           Fax:     +1-919-254-5410
  906.           Email:   pacew@raleigh.ibm.com
  907.  
  908.           Vijay Srinivasan
  909.           IBM Corporation
  910.           P. O. Box 12195
  911.           Research Triangle Park, NC 27709
  912.           Phone:   +1-919-254-2730
  913.           Fax:     +1-919-254-5410
  914.           Email:   vijay@raleigh.ibm.com
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952. Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 15]
  953.