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-intserv-charac-02.txt < prev    next >
Text File  |  1996-11-26  |  38KB  |  823 lines
  1. Internet Engineering Task Force                   Integrated Services WG
  2. INTERNET-DRAFT                              S. Shenker and J. Wroclawski
  3. draft-ietf-intserv-charac-02.txt                      Xerox PARC/MIT LCS
  4.                                                            October, 1996
  5.                                                            Expires: 3/97
  6.  
  7.  
  8.                 General Characterization Parameters for
  9.                   Integrated Service Network Elements
  10.  
  11.  
  12. Status of this Memo
  13.  
  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),
  28.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  29.    ftp.isi.edu (US West Coast).
  30.  
  31.    This document is a product of the Integrated Services working group
  32.    of the Internet Engineering Task Force. Comments are solicited and
  33.    should be addressed to the working group's mailing list at int-
  34.    serv@isi.edu and/or the author(s).
  35.  
  36. Abstract
  37.  
  38.       This memo defines a set of general control and characterization
  39.       parameters for network elements supporting the IETF integrated
  40.       services QoS control framework. General parameters are those with
  41.       common, shared definitions across all QoS control services.
  42.  
  43. 1. Introduction
  44.  
  45.    This memo defines the set of general control and characterization
  46.    parameters used by network elements supporting the integrated
  47.    services framework.  "General" means that the parameter has a common
  48.    definition and shared meaning across all QoS control services.
  49.  
  50.  
  51.  
  52. Shenker/Wroclawski         Expires March, 1997                  [Page 1]
  53. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  54.  
  55.  
  56.    Control parameters are used by applications to provide information to
  57.    the network related to QoS control requests. An example is the
  58.    traffic specification (TSpec) generated by application senders and
  59.    receivers.
  60.  
  61.    Characterization parameters are used to discover or characterize the
  62.    QoS management environment along the path of a packet flow requesting
  63.    active end-to-end QoS control.  These characterizations may
  64.    eventually be used by the application requesting QoS control, or by
  65.    other network elements along the path. Examples include information
  66.    about which QoS control services are available along a network path
  67.    and estimates of the available path bandwidth.
  68.  
  69.    Individual QoS control service specifications may refer to these
  70.    parameter definitions as well as defining additional parameters
  71.    specific to the needs of that service.
  72.  
  73.    Parameters are assigned machine-oriented ID's using a method
  74.    described in [RFCTEMPLATE] and summarized here.  These ID's may be
  75.    used within protocol messages and management interfaces to describe
  76.    the parameter values present. Each parameter ID is composed from two
  77.    numbers, one identifying the service associated with the parameter
  78.    (the <service_number>), and the other (the <parameter_number>)
  79.    identifying the parameter itself. <parameter_number> values for the
  80.    parameters defined in this document are assigned from the "general
  81.    parameters" range (1 - 127). Numbers in this range indicate that the
  82.    parameter definition is shared by all QoS control services.
  83.  
  84.       NOTE: Parameters numbered 128 - 254 have definitions specific to a
  85.       particular QoS control service. In contrast to the general
  86.       parameters described here, the parameter's meaning depends on the
  87.       service_number portion of the parameter ID.
  88.  
  89.       Service number 1 is reserved for use as described in Section 2 of
  90.       this note. Service numbers 2 through 254 will be allocated to
  91.       individual QoS control services. Currently, Guaranteed service
  92.       [RFCG] is allocated number 2, and Controlled-load service [RFCCL]
  93.       is allocated number 5.
  94.  
  95.    In this note, the textual form
  96.  
  97.      <service_number, parameter_number>
  98.  
  99.    is used to write a service_number, parameter_number pair.  The range
  100.    of possible of service_number and parameter_number values specified
  101.    in [RFCTEMPLATE] allow the parameter ID to directly form the tail
  102.    portion of a MIB object ID representing the parameter. This
  103.    simplifies the task of making parameter values available to network
  104.  
  105.  
  106.  
  107. Shenker/Wroclawski         Expires March, 1997                  [Page 2]
  108. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  109.  
  110.  
  111.    management applications.
  112.  
  113.    The definition of each parameter used to characterize a path through
  114.    the network describes two types of values; local and composed.  Local
  115.    values reflect conditions at a single network element.  Composed
  116.    values reflect the running composition of local values along a path,
  117.    as specified by a composition rule.  Each parameter definition
  118.    specifies the composition rule for that parameter. The composition
  119.    rule describes how to combine the arriving composed value and the
  120.    local value, to give a new composed value which is passed to the next
  121.    network element in the path. Note that the composition may proceed
  122.    either downstream, toward the receiver(s), or upstream, toward the
  123.    sender. Each parameter may give only one definition for the local
  124.    value, but may give more than one definition for composition rules
  125.    and composed values. This is because it may be useful to compose the
  126.    same local value several times following different composition rules.
  127.  
  128.    Because characterization parameters are used to compute the
  129.    properties of a specific path through the internetwork, all
  130.    characterization parameter definitions are conceptually "per-next-
  131.    hop", as opposed to "per interface" or "per network element".  In
  132.    cases where the network element is (or is controlling) a shared media
  133.    or large-cloud subnet, the element may need to provide different
  134.    values for different next-hops.  In practice, it may be appropriate
  135.    for vendors to choose and document a tolerance range, such that if
  136.    all next-hop values are within the tolerance range only a single
  137.    value need be stored and provided.
  138.  
  139.    Local and composed characterization parameter values have distinct
  140.    ID's so that a network management entity can request the value of
  141.    either a local or path-composed parameter at any point within the
  142.    network.
  143.  
  144.    Each parameter definition includes a description of the minimal
  145.    properties, such as range and precision, required of any wire
  146.    representation of that parameter's values. Each definition also
  147.    includes an XDR [RFCXDR] description of the parameter, describing an
  148.    appropriate external (wire) data representation for the parameter's
  149.    values. This dual definition is intended to encourage a common wire
  150.    representation format whenever possible, while still allowing other
  151.    representations when required by the specific circumstances (e.g.,
  152.    ASN.1 within SNMP).
  153.  
  154.    The message formats specified in [RFCRSVPUSE] for use with the RSVP
  155.    setup protocol use the XDR data representation parameters.
  156.  
  157.    All of the parameters described in this note are mandatory, in the
  158.    sense that a network element claiming to support integrated service
  159.  
  160.  
  161.  
  162. Shenker/Wroclawski         Expires March, 1997                  [Page 3]
  163. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  164.  
  165.  
  166.    must recognize arriving values in setup and management protocol
  167.    messages, process them correctly, and export a reasonable value in
  168.    response. For certain parameters, it is required that the network
  169.    element compute and export an *accurate* local value. For other
  170.    parameters, it is acceptable for the network element to indicate that
  171.    it cannot compute and export an accurate local value. The definition
  172.    of these parameters provides a reserved value which indicates
  173.    "indeterminate" or "invalid". This value signals that an element
  174.    cannot process the parameter accurately, and consequently that the
  175.    result of the end-to-end composition is also questionable.
  176.  
  177.       NOTE (temporary): Previous versions of this and the RSVP use
  178.       document used both the reserved-value approach and a separate
  179.       INVALID flag to record this fact.  Now, the reserved-value
  180.       approach is used exclusively. This is so that any protocol which
  181.       retrieves a parameter value, including SNMP, can carry the invalid
  182.       indication without needing a separate flag. The INVALID flag
  183.       remains in the RSVP message format but is reserved for use only
  184.       with a possible future service-composition scheme.
  185.  
  186. 2. Default and Service-Specific Values for General Parameters
  187.  
  188.    General parameters have a common *definition* across all QoS control
  189.    services. Frequently, the same *value* of a general parameter will be
  190.    correct for all QoS control services supported at a network element.
  191.    In this circumstance, there is no need to export a separate copy of
  192.    the value for each QoS control service; instead the node can export
  193.    one copy which applies to all supported services.
  194.  
  195.    A general parameter value which applies to all services supported at
  196.    a network node is called a default or global value. For example, if
  197.    all of the QoS control services provided at a node support the same
  198.    maximum packet size, the node may export a single default value for
  199.    the PATH_MTU parameter described in Section 3, rather than providing
  200.    a separate copy of the value for each QoS control service. In the
  201.    common case, this reduces both message size and processing overhead
  202.    for the setup protocol.
  203.  
  204.    Occasionally an individual service needs to report a value differing
  205.    from the default value for a particular general parameter. For
  206.    example, if the implementation of Guaranteed Service [RFCG] at a
  207.    router is restricted by scheduler or hardware considerations to a
  208.    maximum packet size smaller than supported by the router's best-
  209.    effort forwarding path, the implementation may wish to export a
  210.    "service-specific" value of the PATH_MTU parameter so that
  211.    applications using the Guaranteed service will function correctly.
  212.    In the example above, the router might supply a value of 1500 for the
  213.    default PATH_MTU parameter, and a value of 250 for the PATH_MTU
  214.  
  215.  
  216.  
  217. Shenker/Wroclawski         Expires March, 1997                  [Page 4]
  218. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  219.  
  220.  
  221.    parameter applying to guaranteed service. In this case, the setup
  222.    protocol providing path characterization carries (and delivers to the
  223.    application) both a value for Guaranteed service and a value for
  224.    other services.
  225.  
  226.    The distinction between default and service-specific parameter values
  227.    makes no sense for non-general parameters (those defined by a
  228.    specific QoS control service, rather than this note), because both
  229.    the definition and value of the parameter are always specific to the
  230.    particular service.
  231.  
  232.    The distinction between default and service-specific values for
  233.    general parameters is reflected in the parameter ID name space.  This
  234.    allows network nodes, setup protocols, and network management tools
  235.    to distinguish default from service-specific values, and to determine
  236.    which service a service-specific parameter value is associated with.
  237.  
  238.    Service number 1 is used to indicate the default value. A parameter
  239.    value identified by the ID:
  240.  
  241.      <1, parameter_number>
  242.  
  243.    is a default value, which applies to all services unless it is
  244.    overridden by a service-specific value for the same parameter.
  245.  
  246.    A parameter value identified by the ID:
  247.  
  248.      <service_number, parameter_number>
  249.  
  250.    where service_number is not equal to 1, is a service-specific value.
  251.    It applies only to the service identified by service_number.
  252.  
  253.    These service-specific values are also called override values.  When
  254.    both service-specific and default values are present for a parameter,
  255.    the service-specific value overrides the default value (for the
  256.    service to which it applies). The rules for composing service-
  257.    specific and global general parameters support this override
  258.    capability.  The basic rule is to use the service-specific value if
  259.    it exists, and otherwise the global value.
  260.  
  261.    A complete summary of the characterization parameter composition
  262.    process is given below. In this summary, the "arriving value" is the
  263.    incompletely composed parameter value arriving from a neighbor node.
  264.    The "local value" is the (global or service-specific) value made
  265.    available by the local node. The "result" is the newly composed value
  266.    to be sent to the next node on the data path.
  267.  
  268.      1. Examine the <service_number, parameter_number> pair associated
  269.  
  270.  
  271.  
  272. Shenker/Wroclawski         Expires March, 1997                  [Page 5]
  273. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  274.  
  275.  
  276.      with the arriving value. This information is conveyed by the setup
  277.      protocol together with the arriving value.
  278.  
  279.      2. If the arriving value is for a parameter specific to a single
  280.      service (the parameter_number is larger than 128), compose the
  281.      arriving value with the locally value exported by the specified
  282.      service, and pass the result to the next hop.
  283.  
  284.      3. If the arriving value is a service-specific value for a general
  285.      parameter (the parameter_number is 127 or less, and the
  286.      service_number is other than 1), and the local implementation of
  287.      that service also exports a service-specific value for the
  288.      parameter, compose the service-specific arriving value and the
  289.      service-specific local value of the parameter, and pass the result
  290.      as a service-specific value to the next-hop node.
  291.  
  292.      4. If the arriving value is a service-specific value for a general
  293.      parameter (the parameter_number is 127 or less, and the
  294.      service_number is other than 1), and the local implementation of
  295.      that service does *not* export a service-specific value, compose
  296.      the service-specific arriving value with the global value for that
  297.      parameter exported by the local node, and pass the result as a
  298.      service-specific value to the next-hop node.
  299.  
  300.      5. If the arriving value is a global value for a general parameter
  301.      (parameter_number is 127 or less, and the service_number is 1), and
  302.      the local implementation of *any* service exports a service-
  303.      specific value for that general parameter, compose the arriving
  304.      (global) value with the service-specific value for that parameter
  305.      exported by the local service, and pass the result as a service-
  306.      specific value to the next-hop node. This will require adding a new
  307.      data field to the message passed to the next hop, to hold the newly
  308.      generated service-specific value. Repeat this process for each
  309.      service that exports a service-specific value for the parameter.
  310.  
  311.      6. If the arriving value is a global value for a general parameter
  312.      (the service_number is 1, and the parameter_number is 127 or less),
  313.      compose the arriving (global) value with the global parameter value
  314.      exported by the local node, and pass the result as a global
  315.      (service 1) value to the next-hop node. This step is performed
  316.      whether or not any service-specific values were generated and
  317.      exported in step 5.
  318.  
  319. 3. General Parameter Definitions
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327. Shenker/Wroclawski         Expires March, 1997                  [Page 6]
  328. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  329.  
  330.  
  331.  3.1 NON-IS_HOP flag parameter
  332.  
  333.    This parameter provides information about the presence of network
  334.    elements which do not implement QoS control services along the data
  335.    path.
  336.  
  337.    The local value of the parameter is 1 if the network element does not
  338.    implement the relevant QoS control service, or knows that there is a
  339.    break in the chain of elements which implement the service.  The
  340.    local parameter is 0 otherwise.  The local parameter is assigned
  341.    parameter_number 1.
  342.  
  343.    The composition rule for this parameter is the OR function. A
  344.    composed parameter value of 1 arriving at the endpoint of a path
  345.    indicates that at least one point along the path does not offer the
  346.    indicated QoS control service.  The parameter_number for the composed
  347.    quantity is 2.
  348.  
  349.    The global NON_IS_HOP flag parameter thus has the ID <1,2>. If this
  350.    flag is set, it indicates that one or more network elements along the
  351.    application's data path does not support the integrated services
  352.    framework at all. An example of such an element would be an IP router
  353.    offering only best-effort packet delivery and not supporting any
  354.    resource reservation requests.
  355.  
  356.    Obviously, a network element which does not support this
  357.    specification will not know to set this flag.  The actual
  358.    responsibility for determining that a network node does not support
  359.    integrated services may fall to the network element, the setup
  360.    protocol, or a manual configuration operation and is dependent on
  361.    implementation and usage.  This calculation must be conservative.
  362.    For example, a router sending packets into an IP tunnel must assume
  363.    that the tunneled packets will not receive QoS control services
  364.    unless it or the setup protocol can prove otherwise.
  365.  
  366.    Service-specific versions of the NON_IS_HOP flag indicate that one or
  367.    more network elements along a path don't support the particular
  368.    service. For example, the flag parameter identified by ID <2,2> being
  369.    set indicates that some network element along the path does not
  370.    support the Guaranteed service, though it might support another
  371.    service such as Controlled-Load.
  372.  
  373.    If the global NON_IS_HOP flag <1,2> is set for a path, the receiver
  374.    (network element or application) should consider the values of all
  375.    other parameters defined in this specification, including service-
  376.    specific NON_IS_HOP flags, as possibly inaccurate. If a service
  377.    specific NON_IS_HOP flag is set for a path, the receiver should
  378.    consider the values of all other parameters associated with that
  379.  
  380.  
  381.  
  382. Shenker/Wroclawski         Expires March, 1997                  [Page 7]
  383. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  384.  
  385.  
  386.    service as possibly inaccurate.
  387.  
  388.    The NON_IS_HOP parameter may be represented in any form which can
  389.    express boolean true and false. However, note that a network element
  390.    must set this flag precisely when it does *not* fully understand the
  391.    format or data representation of an arriving protocol message
  392.    (because it does not support the specified service). Therefore, the
  393.    data representation used for this parameter by setup and management
  394.    protocols must allow the parameter value to be read and set even if
  395.    the network element cannot otherwise parse the protocol message.
  396.  
  397.    An appropriate XDR description of this parameter is:
  398.  
  399.      bool NON_IS_HOP;
  400.  
  401.    However, the standard XDR data encoding for this description will not
  402.    meet the requirement described above unless other restrictions are
  403.    placed on message formats. An alternative data representation may be
  404.    more appropriate.
  405.  
  406.      NOTE: The message format described for RSVP in [RFCRSVPUSE] carries
  407.      this parameter as a single-bit flag, referred to as the "break
  408.      bit".
  409.  
  410.  3.2 NUMBER_OF_IS_HOPS
  411.  
  412.    IS stands for "integrated services aware".  An integrated services
  413.    aware network element is one that conforms to the various
  414.    requirements described in this and other referenced documents.  The
  415.    network element need not offer a specific service, but if it does it
  416.    must support and characterize the service in conformance with the
  417.    relevant specification, and if it does not it must correctly set the
  418.    NON_IS_HOP flag parameter for the service. For completeness, the
  419.    local parameter is assigned the parameter_number 3.
  420.  
  421.    The composition rule for this parameter is to increment the counter
  422.    by one at each IS-aware hop.  This quantity, when composed end-to-
  423.    end, informs the endpoint of the number of integrated-services aware
  424.    network elements traversed along the path.  The parameter_number for
  425.    this composed parameter is 4.
  426.  
  427.    Values of the composed parameter will range from 1 to 255, limited by
  428.    the bound on IP hop count.
  429.  
  430.    The XDR representation of this parameter is:
  431.  
  432.      unsigned int NUMBER_OF_IS_HOPS;
  433.  
  434.  
  435.  
  436.  
  437. Shenker/Wroclawski         Expires March, 1997                  [Page 8]
  438. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  439.  
  440.  
  441.  3.3. AVAILABLE_PATH_BANDWIDTH
  442.  
  443.    This parameter provides information about the bandwidth available
  444.    along the path followed by a data flow.  The local parameter is an
  445.    estimate of the bandwidth the network element has available for
  446.    packets following the path.  Computation of the value of this
  447.    parameter should take into account all information available to the
  448.    network element about the path, taking into consideration
  449.    administrative and policy controls on bandwidth, as well as physical
  450.    resources.
  451.  
  452.       NOTE: This parameter should reflect, as closely as possible, the
  453.       actual bandwidth available to packets following a path. However,
  454.       the bandwidth available may depend on a number of factors not
  455.       known to the network element until a specific QoS request is in
  456.       place, such as the destination(s) of the packet flow, the service
  457.       to be requested by the flow, or external policy information
  458.       associated with a reservation request.  Because the parameter must
  459.       in fact be provided before any specific QoS request is made, it is
  460.       frequently difficult to provide the parameter accurately. In
  461.       circumstances where the parameter cannot be provided accurately,
  462.       the network element should make the best attempt possible, but is
  463.       permitted to overestimate the available bandwidth by a significant
  464.       amount.
  465.  
  466.    The parameter_number for AVAILABLE_PATH_BANDWIDTH is 5. The global
  467.    parameter <1, 5> is an estimate of the bandwidth available to any
  468.    packet following the path, without consideration of which (if any)
  469.    QoS control service the packets may be subject to.
  470.  
  471.    In cases where a particular service is administratively or
  472.    implementationally restricted to a limited portion of the overall
  473.    available bandwidth, the service module may wish to export an
  474.    override parameter which specifies this smaller bandwidth value.
  475.  
  476.    The composition rule for this parameter is the MIN function. The
  477.    composed value is the minimum of the network element's value and the
  478.    previously composed value. This quantity, when composed end-to-end,
  479.    informs the endpoint of the minimal bandwidth link along the path
  480.    from sender to receiver.  The parameter_number for the composed
  481.    minimal bandwidth along the path is 6.
  482.  
  483.    Values of this parameter are measured in bytes per second.  The
  484.    representation must be able to express values ranging from 1 byte per
  485.    second to 40 terabytes per second, about what is believed to be the
  486.    maximum theoretical bandwidth of a single strand of fiber.
  487.    Particularly for large bandwidths, only the first few digits are
  488.    significant, so the use of a floating point representation, accurate
  489.  
  490.  
  491.  
  492. Shenker/Wroclawski         Expires March, 1997                  [Page 9]
  493. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  494.  
  495.  
  496.    to at least 0.1%, is encouraged.
  497.  
  498.    The XDR representation for this parameter is:
  499.  
  500.      float AVAILABLE_PATH_BANDWIDTH;
  501.  
  502.    For values of this parameter only valid non-negative floating point
  503.    numbers are allowed. Negative numbers (including "negative zero"),
  504.    infinities, and NAN's are not allowed.
  505.  
  506.       NOTE: An implementation which utilizes general-purpose hardware or
  507.       software IEEE floating-point support may wish to verify that
  508.       arriving parameter values meet these requirements before using the
  509.       values in floating-point computations, in order to avoid
  510.       unexpected exceptions or traps.
  511.  
  512.    If the network element cannot or wishes not to provide an estimate of
  513.    path bandwidth, it may export a local value of zero for this
  514.    parameter. A network element or application receiving a composed
  515.    value of zero for this parameter should assume that the actual
  516.    bandwidth available is unknown.
  517.  
  518.  3.4 MINIMUM_PATH_LATENCY
  519.  
  520.    The local parameter is the latency of the packet forwarding process
  521.    associated with the network element, where the latency is defined to
  522.    be the *minimal* possible packet delay added by the network element
  523.    This delay may result from speed-of-light propagation delay, from
  524.    packet processing limitations, or both. It does not include any
  525.    variable queuing delay which may be present.
  526.  
  527.    The purpose of this parameter is to provide a baseline minimal path
  528.    latency for use with services which provide estimates or bounds on
  529.    additional path delay, such as Guaranteed [RFCG].  In conjunction
  530.    with the queuing delay bound offered by Guaranteed and similar
  531.    services, this parameter gives the application knowledge of both the
  532.    minimum and maximum packet delivery delay.  Knowing both the minimum
  533.    and maximum latency experienced by data packets allows the receiving
  534.    application to accurately compute its de-jitter buffer requirements.
  535.  
  536.    Note that the quantity characterized by this parameter is the
  537.    absolute lower bound on the packet processing and transmission
  538.    latency of the network element. This value is the quantity required
  539.    to provide jitter bounding. The parameter does *not* provide the type
  540.    of upper-bound estimate on minimum latency which might be of interest
  541.    for best-effort traffic and QoS control services which do not
  542.    explicitly offer delay bounds. That is, the parameter will always
  543.    underestimate, rather than overestimate, latency, particularly in
  544.  
  545.  
  546.  
  547. Shenker/Wroclawski         Expires March, 1997                 [Page 10]
  548. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  549.  
  550.  
  551.    multicast and large cloud situations.
  552.  
  553.    When packets traversing a network element may experience different
  554.    minimal latencies, this parameter should ideally report an accurate
  555.    latency value for each path. For example, when an ATM point-
  556.    multipoint virtual circuit is used to implement IP multicast, the
  557.    mechanism used to implement this parameter would ideally compute a
  558.    separate value for each destination. Doing so may require cooperation
  559.    between the ingress and egress elements bounding the multi-path
  560.    communication cloud.  The method by which this cooperation is
  561.    achieved, and the choice of which IP-level network element actually
  562.    provides and composes the value, is technology-dependent.
  563.  
  564.    An alternative choice is to provide the same value of this parameter
  565.    for all paths through the cloud. The value reported must be the
  566.    smallest latency for any possible path. Note that in this situation,
  567.    QoS control services (e.g., Guaranteed) which provide an upper bound
  568.    on latency cannot simply add their queuing delay to the value
  569.    computed by this parameter; they must also compensate for path delays
  570.    above the minimum. In this case the range between the minimum and
  571.    maximum packet delays reported to the application will be larger,
  572.    because the application will be told about the minimum delay along
  573.    the shortest path and the maximum delay along the actual path.  This
  574.    is acceptable in many situations.
  575.  
  576.    A third alternative is to report the "indeterminate" value, as
  577.    specified below.  In this circumstance the client application may
  578.    either deduce a minimum path latency through measurement, or assume a
  579.    value of zero.
  580.  
  581.    The composition rule for this parameter is summation with a clamp of
  582.    (2**32 - 1) on the maximum value. This quantity, when composed end-
  583.    to-end, informs the endpoint of the minimal packet delay along the
  584.    path from sender to receiver. The parameter_number for the latency of
  585.    the network element's link is 7. The parameter_number for the
  586.    cumulative latency along the path is 8.
  587.  
  588.    The latencies are measured in units of one microsecond. An individual
  589.    element can advertise a latency value between 1 and 2**28 (somewhat
  590.    over two minutes) and the total latency added across all elements can
  591.    range as high as (2**32)-2. Should the sum of the different elements
  592.    delay exceed (2**32)-2, the end-to-end advertised delay should be
  593.    reported as indeterminate. This is described below.
  594.  
  595.    Note that while the granularity of measurement is microseconds, a
  596.    conforming element is free to measure delays more loosely. The
  597.    minimum requirement is that the element estimate its delay accurately
  598.    to the nearest 100 microsecond granularity. Elements that can measure
  599.  
  600.  
  601.  
  602. Shenker/Wroclawski         Expires March, 1997                 [Page 11]
  603. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  604.  
  605.  
  606.    more accurately are, of course, encouraged to do so.
  607.  
  608.       NOTE: Measuring in milliseconds is not acceptable, because if the
  609.       minimum delay value is a millisecond, a path with several hops
  610.       will lead to a composed delay of at least several milliseconds,
  611.       which is likely to be misleading.
  612.  
  613.    The XDR description of this parameter is:
  614.  
  615.      unsigned int MINIMUM_PATH_LATENCY;
  616.  
  617.    The distinguished value (2**32)-1 is taken to mean "indeterminate
  618.    latency". A network element which cannot accurately predict the
  619.    latency of packets it is processing should set its local parameter to
  620.    this value. Because the composition function limits the composed sum
  621.    to this value, receipt of this value at a network element or
  622.    application indicates that the true path latency is not known. This
  623.    may happen because one or more network elements could not supply a
  624.    value, or because the range of the composition calculation was
  625.    exceeded.
  626.  
  627.  3.5. PATH_MTU
  628.  
  629.    This parameter computes the maximum transmission unit (MTU) for
  630.    packets following a data path.  This value is required to invoke QoS
  631.    control services which require that IP packet size be strictly
  632.    limited to a specific MTU. Existing MTU discovery mechanisms cannot
  633.    be used because they provide information only to the sender and they
  634.    do not directly allow for QoS control services to specify MTU's
  635.    smaller than the physical MTU.
  636.  
  637.    The local characterization parameter is the IP MTU, where the MTU of
  638.    a network element is defined to be the maximum transmission unit the
  639.    network element can accommodate without fragmentation, including IP
  640.    and upper-layer protocol headers but not including link level
  641.    headers.  The composition rule is to take the minimum of the network
  642.    element's MTU and the previously composed value.  This quantity, when
  643.    composed end-to-end, informs the endpoint of the maximum transmission
  644.    unit that can traverse the path from sender to receiver without
  645.    fragmentation.  The parameter_number for the MTU of the network
  646.    element's link is 9.  The parameter_number for the composed MTU along
  647.    the path is 10.
  648.  
  649.    A correct and valid value of this parameter must be provided by all
  650.    IS-aware network elements.
  651.  
  652.    A specific service module may specify an MTU smaller than that of the
  653.    overall network element by overriding this parameter with one giving
  654.  
  655.  
  656.  
  657. Shenker/Wroclawski         Expires March, 1997                 [Page 12]
  658. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  659.  
  660.  
  661.    the service's MTU value. A service module may not specify an MTU
  662.    value larger than that given by the global parameter.
  663.  
  664.    Values of this parameter are measured in bytes.  The representation
  665.    must be able to express values ranging from 1 byte to 2**32-1 bytes.
  666.  
  667.    The XDR description of this parameter is:
  668.  
  669.      unsigned int PATH_MTU;
  670.  
  671.  3.6. TOKEN_BUCKET_TSPEC
  672.  
  673.    This parameter is used to describe data traffic parameters using a
  674.    simple token bucket filter. This parameter is used by data senders to
  675.    describe the traffic parameters of traffic it expects to generate,
  676.    and by QoS control services to describe the parameters of traffic for
  677.    which the reservation should apply. It is defined as a general rather
  678.    than service-specific parameter because the same traffic description
  679.    may be used by several QoS control services in some situations.
  680.  
  681.    The TOKEN_BUCKET_TSPEC parameter is assigned parameter_number 127.
  682.  
  683.    The TOKEN_BUCKET_TSPEC takes the form of a token bucket specification
  684.    plus a peak rate p, minimum policed unit m, and a maximum packet size
  685.    M.
  686.  
  687.    The token bucket specification includes an average or token rate r
  688.    and a bucket depth b.  Both r and b must be positive.
  689.  
  690.    The token rate r is measured in bytes of IP datagrams per second.
  691.    Values of this parameter may range from 1 byte per second to 40
  692.    terabytes per second. In practice, only the first few digits of the r
  693.    and p parameters are significant, so the use of floating point
  694.    representations, accurate to at least 0.1% is encouraged.
  695.  
  696.    The bucket depth, b, is measured in bytes. Values of this parameter
  697.    may range from 1 byte to 250 gigabytes. In practice, only the first
  698.    few digits of the b parameter are significant, so the use of floating
  699.    point representations, accurate to at least 0.1% is encouraged.
  700.  
  701.    The peak traffic rate p is measured in bytes of IP datagrams per
  702.    second. Values of this parameter may range from 1 byte per second to
  703.    40 terabytes per second. In practice, only the first few digits of
  704.    the r and p parameters are significant, so the use of floating point
  705.    representations, accurate to at least 0.1% is encouraged. The peak
  706.    rate value may be set to positive infinity, indicating that it is
  707.    unknown or unspecified.
  708.  
  709.  
  710.  
  711.  
  712. Shenker/Wroclawski         Expires March, 1997                 [Page 13]
  713. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  714.  
  715.  
  716.    The range of values allowed for these parameters is intentionally
  717.    large to allow for future network technologies. Any particular
  718.    network element is not expected to support the full range of values.
  719.  
  720.    The minimum policed unit, m, is an integer measured in bytes.  All IP
  721.    datagrams less than size m will be counted against the token bucket
  722.    as being of size m. The maximum packet size, M, is the biggest packet
  723.    that will conform to the traffic specification; it is also measured
  724.    in bytes.  Both m and M must be positive, and m must be less then or
  725.    equal to M.
  726.  
  727.    The XDR description of this parameter is:
  728.  
  729.      struct {
  730.        float r;
  731.        float b;
  732.        float p;
  733.        unsigned m;
  734.        unsigned M;
  735.      } TOKEN_BUCKET_TSPEC;
  736.  
  737.    For the fields r and b only valid non-negative floating point numbers
  738.    are allowed. Negative numbers (including "negative zero), infinities,
  739.    and NAN's are not allowed.
  740.  
  741.    For the field p, only valid non-negative floating point numbers or
  742.    positive infinity are allowed. Negative numbers (including "negative
  743.    zero), negative infinities, and NAN's are not allowed.
  744.  
  745.       NOTE: An implementation which utilizes general-purpose hardware or
  746.       software IEEE floating-point support may wish to verify that
  747.       arriving parameter values meet these requirements before using the
  748.       values in floating-point computations, in order to avoid
  749.       unexpected exceptions or traps.
  750.  
  751.  4. Security Considerations
  752.  
  753.    Security considerations are not discussed in this memo.
  754.  
  755. 5. References
  756.  
  757.    [RFCRSVP] B. Braden, et. al. "Resource Reservation Protocol (RSVP) -
  758.    Version 1 Functional Specification", Internet Draft, July 1996,
  759.    <draft-ietf-rsvp-spec-13.txt>
  760.  
  761.    [RFCRSVPUSE] J. Wroclawski. "The Use of RSVP with IETF Integrated
  762.    Services", Internet Draft, October, 1996, <draft-ietf-intserv-rsvp-
  763.    use-01.txt>
  764.  
  765.  
  766.  
  767. Shenker/Wroclawski         Expires March, 1997                 [Page 14]
  768. INTERNET-DRAFT      draft-ietf-intserv-charac-02.txt       October, 1996
  769.  
  770.  
  771.    [RFCTEMPLATE] S. Shenker and J. Wroclawski. "Network Element QoS
  772.    Control Service Specification Template". Internet Draft, October
  773.    1996, <draft-ietf-intserv-svc-template-03.txt>
  774.  
  775.    [RFCG] S. Shenker, C. Partridge, and R Guerin. "Specification of the
  776.    Guaranteed Quality of Service", Internet Draft, July 1996, <draft-
  777.    ietf-intserv-guaranteed-svc-06.txt>
  778.  
  779.    [RFCCL] J. Wroclawski. "Specification of the Controlled Load Quality
  780.    of Service", Internet Draft, July 1996, <draft-ietf-intserv-ctrl-
  781.    load-svc-03.txt>
  782.  
  783.    [RFCXDR] R. Srinivansan. "XDR: External Data Representation
  784.    Standard", RFC 1832, August 1995.
  785.  
  786. Author's Address:
  787.  
  788.    Scott Shenker
  789.    Xerox PARC
  790.    3333 Coyote Hill Road
  791.    Palo Alto, CA 94304-1314
  792.    shenker@parc.xerox.com
  793.    415-812-4840
  794.    415-812-4471 (FAX)
  795.  
  796.    John Wroclawski
  797.    MIT Laboratory for Computer Science
  798.    545 Technology Sq.
  799.    Cambridge, MA  02139
  800.    jtw@lcs.mit.edu
  801.    617-253-7885
  802.    617-253-2673 (FAX)
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822. Shenker/Wroclawski         Expires March, 1997                 [Page 15]
  823.