home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rsvp-partial-service-00.txt < prev    next >
Text File  |  1997-04-25  |  16KB  |  422 lines
  1.  
  2.  
  3. Internet Engineering Task Force                                  RSVP WG
  4. INTERNET-DRAFT                                     L. Breslau/S. Shenker
  5. draft-ietf-rsvp-partial-service-00.txt                        Xerox PARC
  6.                                                           April 23, 1997
  7.                                                        Expires: 10/23/97
  8.  
  9.  
  10.  
  11.    Partial Service Deployment in the Integrated Services Architecture
  12.  
  13.  
  14. Status of this Memo
  15.  
  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 months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time.  It is inappropriate to use Internet-Drafts as reference
  25.    material or to cite them other than as "work in progress."
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.  
  34. Abstract
  35.  
  36.  
  37.    Specifications for providing enhanced qualities of service in the
  38.    Internet have been defined in [2,4].  Technical and administrative
  39.    concerns may prevent a network element from offering one or more of
  40.    these services.  In this document, we present a mechanism for dealing
  41.    with heterogeneity in the set of services offered by different
  42.    network elements.  This approach enables end-to-end service to be
  43.    composed of different per-hop services while not requiring end
  44.    systems to be aware of the details of the service provided at each
  45.    hop.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Breslau/Shenker             Expires 10/23/97                    [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61. INTERNET-DRAFT   draft-ietf-rsvp-partial-service-00.txt   April 23, 1997
  62.  
  63.  
  64. Introduction
  65.  
  66.  
  67.    The Integrated Services Working Group has produced specifications for
  68.    new types of service[2,4].  These services will provide enhanced
  69.    qualities of service to applications that use them.  Such services
  70.    will be most useful when they are provided at all network elements
  71.    along a data distribution path.  However, because these services
  72.    impose stricter requirements on the network elements than traditional
  73.    best-effort service, it may not be practical to provide these
  74.    services on some subnet technologies.  Furthermore, the ultimate
  75.    decision to implement and deploy a particular service belongs to
  76.    vendors and network service providers, respectively.  A vendor may
  77.    choose not to implement a service, or network service provider may
  78.    choose not to offer a service (e.g., for administrative reasons),
  79.    even if the underlying technology is able to support the service.
  80.    Therefore, newly defined services will not always be available end-
  81.    to-end along a data distribution path.  In this document we describe
  82.    a strategy for coping with this heterogeneity in the set of services
  83.    offered in a network.
  84.  
  85.  
  86.  
  87. Replacement Services
  88.  
  89.  
  90.    The mechanism for addressing the problem of service heterogeneity is
  91.    built on the concept of "replacement" services. When a network
  92.    element does not offer a service, it can offer a replacement service
  93.    for it.  Under circumstances described below, when a network element
  94.    receives a request for a service it does not offer, it treats the
  95.    request as if it were for the replacement service.  A replacement
  96.    service can be one of the other real-time services, best-effort
  97.    service, or a non-compliant implementation of the original service.
  98.    Decisions about the use of replacement services are a local matter.
  99.  
  100.    Replacement services are characterized as either "reliable" or
  101.    "unreliable".  A reliable replacement is one that is expected to meet
  102.    the requirements of the service being replaced a large majority of
  103.    the time (e.g., over 95%).  No assurance is given about the resulting
  104.    quality of an unreliable replacement.  Since best effort service
  105.    qualifies as an unreliable replacement in all circumstances, network
  106.    elements are always able to at least offer unreliable replacements
  107.    for every service.
  108.  
  109.    When a network element offers a reliable replacement it MUST also
  110.    export meaningful values for any characterization parameters required
  111.    by the original service.  (See [1] and [3] for a discussion of
  112.  
  113.  
  114.  
  115. Breslau/Shenker             Expires 10/23/97                    [Page 2]
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122. INTERNET-DRAFT   draft-ietf-rsvp-partial-service-00.txt   April 23, 1997
  123.  
  124.  
  125.    characterization parameters.) These parameters must accurately
  126.    characterize the replacement service, and when composed end-to-end
  127.    with parameters from other network elements they must provide
  128.    applications with a valid characterization of the end-to-end service.
  129.    When a network element offers an unreliable replacement it MAY export
  130.    values for any characterization parameters of the original service if
  131.    it is able to accurately characterize the service.  However, given
  132.    that an unreliable replacement may be arbitrarily bad, the network
  133.    element may instead set the value of all characterization parameters
  134.    to the "invalid" values defined for those parameters.
  135.  
  136.    We provide the following guidelines for determining whether a network
  137.    element offers an actual service, a reliable replacement, or an
  138.    unreliable replacement.
  139.  
  140.    Offered Service:  In order to claim to offer a service, a network
  141.    element's implementation of the service must conform to the service
  142.    specification. Specific conformance requirements are included in the
  143.    service specification documents (e.g., [2,4]).  Some knowledge about
  144.    the environment in which an implementation is deployed can be used in
  145.    making this determination.  For example, an implementation of
  146.    Controlled-Load in a router attached to an ethernet may be compliant
  147.    if all routers and hosts attached to the network participate in a
  148.    distributed admission control process to reserve resources on the
  149.    ethernet.  However, the same implementation may not be compliant if
  150.    there are hosts attached to the ethernet that do not participate in
  151.    the bandwidth allocation procedure.  Knowledge of link bandwidth can
  152.    also be used to determine service compliance.  For example, a router
  153.    may be able to offer a service on an interface using FIFO scheduling
  154.    and no admission control if the bandwidth on the link exceeds the sum
  155.    of the input bandwidths on all other links.  On the other hand,
  156.    knowledge about average levels of offered load cannot be used to
  157.    claim compliance with the currently defined service specifications;
  158.    the offered service must comply with the service specifications
  159.    independent of ambient loading.
  160.  
  161.    Reliable Replacement:  A network element can claim to offer a
  162.    reliable replacement if it does not offer the actual service but the
  163.    service it provides is expected to adhere to the specification of the
  164.    original service a large majority of the time.  This determination
  165.    can take local conditions, including expected load, into account.
  166.    However, since the semantics of a reliable replacement are that it
  167.    emulates very closely the actual service, applications using reliable
  168.    replacements will expect to receive service that is in general not
  169.    significantly different than the original service.  Therefore, the
  170.    reliable replacement label should be applied to service replacements
  171.    with caution.  Furthermore, since a reliable replacement will often
  172.    depend on local conditions, and conditions may change over time,
  173.  
  174.  
  175.  
  176. Breslau/Shenker             Expires 10/23/97                    [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183. INTERNET-DRAFT   draft-ietf-rsvp-partial-service-00.txt   April 23, 1997
  184.  
  185.  
  186.    network operators should monitor these conditions and continually
  187.    reassess the suitability of reliable replacements. Finally, note that
  188.    the ability to provide a reliable replacement may also depend on the
  189.    availability of appropriate invocation parameters for the replacement
  190.    service.
  191.  
  192.    We offer two examples of reliable replacements.  First, a router on a
  193.    vastly underutilized point-to-point link, which rarely experiences
  194.    persistent congestion, may offer best effort service as a reliable
  195.    replacement for Controlled Load service.  Second, a router attached
  196.    to an ethernet that has an otherwise compliant implementation of
  197.    Controlled Load but has no means to control the load generated by
  198.    other stations attached to the ethernet may claim to offer a reliable
  199.    replacement for Controlled Load if the ethernet is not in general
  200.    highly loaded.
  201.  
  202.    Unreliable Replacement:  Since unreliable replacements make no
  203.    assurances about the service they provide, any service qualifies as
  204.    an unreliable replacement for any other service.  Hence, when the
  205.    actual service or a reliable replacement is not offered, an
  206.    unreliable replacement can always be offered.  For example, best
  207.    effort service on a congested link qualifies as an unreliable
  208.    replacement for any real-time service.  Applications should have no
  209.    expectations about the resulting service when they use an unreliable
  210.    replacement.  Finally, additional real-time services may be defined
  211.    after a particular implementation is deployed.  Hence, a network
  212.    element may not even know about a requested service, so it cannot
  213.    make an informed decision about the suitability of its offered
  214.    services (other than best effort) to act as replacements.  In such
  215.    cases, the router can always use best effort as an unreliable
  216.    replacement.
  217.  
  218.  
  219. Characterizing Service Offerings
  220.  
  221.  
  222.    Each network element must export characterization parameters
  223.    describing the various services and replacements that it offers.  An
  224.    example format and composition rules for these characterization
  225.    parameters are described in the Appendix to this document.
  226.  
  227.  
  228. Service Handling Flags
  229.  
  230.  
  231.    When characterization parameters are provided end-to-end by a setup
  232.    protocol, an application will know before issuing a service request
  233.    whether any replacement services will be substituted for its request.
  234.  
  235.  
  236.  
  237. Breslau/Shenker             Expires 10/23/97                    [Page 4]
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244. INTERNET-DRAFT   draft-ietf-rsvp-partial-service-00.txt   April 23, 1997
  245.  
  246.  
  247.    Applications that would be dissatisfied with the level of assurance
  248.    provided by the resulting service should refrain from issuing service
  249.    requests when such substitutions would be made.
  250.  
  251.    The Integrated Services architecture is intended to allow services to
  252.    be invoked by more than one setup protocol or by network management
  253.    functions.  Therefore, we cannot assume that end-to-end
  254.    characterizations of service offerings will always be available to
  255.    the applications.  When they are not, mechanisms are needed so that
  256.    applications can express to the network elements their willingness to
  257.    accept replacement services.
  258.  
  259.    We propose that application preferences be expressed in a new object
  260.    that we refer to as the Service Handling Flags, which is optionally
  261.    included in service requests.  These flags are associated with
  262.    service requests in general, and not with specific services, so they
  263.    are associated with service_name 0 (just like general
  264.    characterization parameters).  The parameter is a 16-bit value.  The
  265.    most significant bit is set to 1 if service replacements are *not*
  266.    allowed and 0 if replacements are allowed.  The remaining 15 bits are
  267.    currently unused.
  268.  
  269.    Hence, the default router action is to perform replacements when a
  270.    requested service is not available.  In environments where end-to-end
  271.    characterizations are available (e.g., as with RSVP) the Service
  272.    Handling Flags are not needed.  When end-to-end characterizations are
  273.    not available, an end system must include the Service Handling Flags
  274.    with the most significant bit set in order to prevent the use of
  275.    replacement services.
  276.  
  277.  
  278. Security Considerations
  279.  
  280.  
  281.    Security considerations are not discussed in this memo.
  282.  
  283.  
  284. Appendix -- Service Availability Characterization Parameters
  285.  
  286.  
  287.    The following is an example format for characterization parameters
  288.    describing service availability.
  289.  
  290.    An integrated services aware router exports a general
  291.    characterization parameter for each service that it knows about
  292.    indicating whether it offers the service, a reliable replacement for
  293.    the service, or an unreliable replacement for the service.  These
  294.    parameters, when composed end-to-end, inform the endpoints about the
  295.  
  296.  
  297.  
  298. Breslau/Shenker             Expires 10/23/97                    [Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305. INTERNET-DRAFT   draft-ietf-rsvp-partial-service-00.txt   April 23, 1997
  306.  
  307.  
  308.    end-to-end availability of services.
  309.  
  310.    The parameter_name for the local parameter is N.  A single router can
  311.    export multiple characterization parameters with parameter_name N,
  312.    each corresponding to a different service.  The specific service
  313.    referenced by a particular parameter is identified by a field within
  314.    the parameter itself.
  315.  
  316.    Each local parameter is represented by a sequence of 4 16-bit
  317.    unsigned integers in network byte order.  The first is the
  318.    service_name for the service referenced by the parameter.  The
  319.    service_name is defined within the service specification for each
  320.    service (e.g., see [2,4]).  The second has the value 1 if the router
  321.    offers the indicated service and 0 if the router does not offer the
  322.    service.  The third field has the value 1 if the router offers a
  323.    reliable replacement for the service and 0 if the router does not
  324.    offer a reliable replacement for the service.  The fourth field has
  325.    the value 1 if the router offers an unreliable replacement for the
  326.    service and 0 if the router does not offer an unreliable replacement
  327.    for the service.  A router must assign a value of 1 to exactly one of
  328.    the latter three fields.  Guidelines for offering reliable
  329.    replacements and unreliable replacements are specified earlier in
  330.    this document.
  331.  
  332.    The parameter_name for the composed end-to-end parameter is N+1.  The
  333.    specific service referenced by a particular parameter is specified by
  334.    a field inside the parameter itself.
  335.  
  336.    Each composed parameter is represented by a sequence of 4 16-bit
  337.    unsigned integers in network byte order.  The first is the
  338.    service_name for the service characterized by the parameter.  The
  339.    second is the number of routers that offer the service.  The third is
  340.    the number of routers that offer reliable replacements for the
  341.    service.  The fourth is the number of routers that offer unreliable
  342.    replacements for the service.
  343.  
  344.    The composition rule for composing a local parameter with a composed
  345.    parameter is to add the i_th value of the local parameter to the i_th
  346.    value of the composed parameter, for i = {2,3,4}.  Two parameters can
  347.    be composed only if the first field in each parameter (the
  348.    service_name) is the same.
  349.  
  350.  
  351.  
  352. References
  353.  
  354.  
  355.    [1] S. Shenker and J. Wroclawski.  "Specification of General
  356.  
  357.  
  358.  
  359. Breslau/Shenker             Expires 10/23/97                    [Page 6]
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366. INTERNET-DRAFT   draft-ietf-rsvp-partial-service-00.txt   April 23, 1997
  367.  
  368.  
  369.    Characterization Parameters", Internet Draft, October 1996, <draft-
  370.    ietf-intserv-charac-02.txt>.
  371.  
  372.    [2] S. Shenker, C. Partridge and R. Guerin. "Specification of
  373.    Guaranteed Quality of Service", Internet Draft, February 1997,
  374.    <draft-ietf-intserv-guaranteed-svc-07.txt>.
  375.  
  376.    [3] S. Shenker and J. Wroclawski.  "Network Element Service
  377.    Specification Template", Internet Draft, November 1996, <draft-ietf-
  378.    intserv-svc-template-03.txt>.
  379.  
  380.    [4] J. Wroclawski.  "Specification of Controlled-Load Network Element
  381.    Service", Internet Draft, November 1996, <draft-ietf-intserv-ctrl-
  382.    load-svc-04.txt>.
  383.  
  384.  
  385.  
  386. Authors' Addresses:
  387.  
  388.  
  389.    Lee Breslau
  390.    Xerox PARC
  391.    3333 Coyote Hill Road
  392.    Palo Alto, CA  94304-1314
  393.    breslau@parc.xerox.com
  394.    415-812-4402
  395.    415-812-4471 (FAX)
  396.  
  397.    Scott Shenker
  398.    Xerox PARC
  399.    3333 Coyote Hill Road
  400.    Palo Alto, CA  94304-1314
  401.    shenker@parc.xerox.com
  402.    415-812-4840
  403.    415-812-4471 (FAX)
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420. Breslau/Shenker             Expires 10/23/97                    [Page 7]
  421.  
  422.