NSIS Working Group Internet Draft Cornelia Kappler Document: draft-kappler-nsis-qosmodel- Siemens AG controlledload-00.txt Expires: August 2004 February 2004 A QoS Model for Signaling IntServ Controlled-Load Service with NSIS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a validation of QoS-NSLP by adapting an existing QoS model, controlled-load service from IntServ, for signaling with QoS-NSLP. It describes how to signal for controlled- load service with QoS-NSLP, and clarifies the features necessary for a QoS model description. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Table of Contents 1. Introduction...................................................2 2. QoS NSLP Overview..............................................3 3. What is a QoS Model............................................3 Kappler Expires - August 2004 [Page 1] QoS Model for IntServ Controlled-Load Service February 2004 4. IntServ Controlled Load Service Overview.......................4 5. NSIS QoS Model for IntServ Controlled Load Service.............5 5.1 Role of QNEs...............................................6 5.2 Control Information........................................6 5.3 Content of QSpec, Including Resource Description...........6 5.4 Objects to be Carried in QUERY and RESPONSE................7 5.5 Processing Rules in QNEs...................................7 5.6 Usage of QoS-NSLP Messages.................................9 6. Feedback to QoS-NSLP and Open Issues..........................10 Security Considerations..........................................11 References.......................................................11 Acknowledgment...................................................13 Author's Address.................................................13 1. Introduction The QoS NSIS Signaling Layer Protocol, QoS-NSLP [qos-nslp] defines how to signal for QoS reservations in the Internet. The protocol is not bound to a specific mechanism for achieving QoS, such as IntServ or DiffServ. Rather, the actual QoS information is carried opaquely in the protocol. A mechanism for achieving QoS is called QoS model in [qos-nslp]. It is expected that a number of QoS models will be developed for QoS-NSLP. The purpose of this document is to validate QoS-NSLP by adapting an existing QoS model for signaling with QoS-NSLP, and analyze what exactly a QoS model needs to be doing. The QoS model described here is based on the controlled-load service of IntServ [RFC2211]. [RFC2210] specifies how to signal for controlled-load service with RSVP. This document describes how to signal for the same service with QoS-NSLP. The controlled-load service is rather minimal both in terms of information that is signaled - basically bandwidth in the form of a token bucket û and in terms of prescribed realization of the service in the network. It is therefore suited for a wide range of realizations, such as reserving resources per-flow per-network node [RFC1633], achieving QoS in appropriately engineered DiffServ networks with admission control [RFC2998], or sending traffic via MPLS Label Switched Paths (LSPs) with reserved bandwidths and admission control [RFC3031][RFC2746]. In this document (unless explicitly referring to [qos-nslp]), the term ôQoS modelö is defined in more detail than in [qos-nslp] as ôa mechanism for achieving QoS, and a description of how to use QoS-NSLP for signaling itö. In this sense, the ômechanismö for controlled-load service is already defined in [RFC2211]. This document contains the Kappler Expires - August 2004 [Page 2] QoS Model for IntServ Controlled-Load Service February 2004 description of how to use QoS-NSLP for signaling it, and can hence be considered the analogue of [RFC2210]. The document is structured as follows: It gives a brief overview of QoS-NSLP, and the content and features of a QoS model as foreseen in [qos-nslp]. It then gives a brief overview of the controlled-load service of IntServ. Subsequently, the actual QoS model for controlled-load service is described. It turns out a QoS model needs more details in order to be useful for QoS-NSLP than outlined in [qos-nslp]. The additions and open issues are summarized in the last section. 2. QoS NSLP Overview QoS NSLP [qos-nslp] is an NSIS signaling layer protocol for signaling QoS reservations in the Internet. Together with NTLP [ntlp] [nsis- fw], it provides functionality similar to RSVP and extends it, e.g. by supporting both sender-initiated and receiver-initiated reservations. QoS-NSLP however does not support multicast. QoS NSLP establishes and maintains reservation state in QoS-NSLP aware nodes, called QNEs, along the path of a data flow. The number or frequency of QNEs is not prescribed. The node initiating a reservation request is called QNI, the node terminating the request is called QNR. QNI and QNR are also QNEs, and are not necessarily the actual sender and receiver of the data flow they are signaling for as they may also be proxying for them. QoS-NSLP defines four message types, RESERVE, QUERY, RESPONSE and NOTIFY. The message type identifies whether a message manipulates state (e.g. RESERVE) or not (e.g. QUERY, RESPONSE). The RESERVE message is used to create, refresh, modify or remove reservation state in QNEs. The QUERY message is used to request information about the data path without making a reservation. This functionality can be used to æprobeÆ the path for certain characteristics. The RESPONSE message is used to provide information about the results of a previous RESERVE or QUERY message, e.g. confirmation of a successful reservation, error, or for transferring results of a QUERY back towards the querying node. The NOTIFY message is not important in the context of this memo. 3. What is a QoS Model QoS NSLP is a QoS signaling protocol that is independent of the so- called QoS model, just as RSVP [RFC2205] is independent of IntServ [RFC1633]. According to [qos-nslp], a QoS model is a defined mechanism for achieving QoS. The specification of a QoS model includes a description of its QoS parameter information, as well as Kappler Expires - August 2004 [Page 3] QoS Model for IntServ Controlled-Load Service February 2004 how that information should be treated or interpreted in the network. A QoS model could also describe underlying assumptions, conditions and/or specific provisioning mechanisms. It is expected that a number of QoS models will be developed for QoS-NSLP. IntServ and DiffServ [RFC2475] are given as examples that could provide the basis of NSIS QoS models. In a QoS-NSLP RESERVE message, a description of the actual resources that are requested is carried in an Object, the QSpec. The QSpec is opaque to QoS-NSLP and similar in purpose to the TSpec, RSpec and AdSpec specified in [RFC2205],[RFC2210]. Thereby the TSpec is a description of the data flow generated by the sender for which resources are to be reserved, containing e.g. peek bandwidth and token bucket parameters, RSpec contains additional parameters necessary to invoke a service, and AdSpec carries information generated in or modified by the network, e.g. maximum currently available bandwidth, which is used for making reservation decisions. The QSpec is specific to the QoS model. The QoS model provides the parameters to be carried in the QSpec, and restricts their values. In [qos-nslp], also a strawman QSpec template is provided. The RESERVE message may additionally contain QoS model specific control information used by the QoS modelÆs processing. Control information may qualify or restrict the action a QNE may perform on the QoS message. At each QNE, QSpec and corresponding control information are interpreted by the resident resource management function for the purposes of policy control and traffic control, including admission control and configuration of the packet classifier and scheduler. The QoS model may also define specific objects to be carried in the QUERY message, in order to gather resource specific information on the data path without making a reservation. It is assumed in this memo that also the RESPONSE message may carry QoS model specific objects in order to distribute the queried information to interested nodes [This is not said in [qos-nslp] but seems to be understood]. As described in the Introduction, this document explicitly includes in the term ôQoS modelö the description of how to use QoS-NSLP to signal for the envisaged QoS mechanism. 4. IntServ Controlled Load Service Overview As specified in [RFC2211], the controlled-load service defined for IntServ supports applications which are highly sensitive to overload conditions, e.g. real-time applications. The controlled-load service provides to an application approximately the end-to-end service of an unloaded best-effort network. ôUnloadedö thereby is used in the sense Kappler Expires - August 2004 [Page 4] QoS Model for IntServ Controlled-Load Service February 2004 of ônot heavily loaded or congestedö rather than in the sense of ôno other network traffic whatsoeverö. The definition of controlled-load service is intentionally imprecise. It implies a very high percentage of transmitted packets will be successfully delivered to the end nodes. Furthermore, the transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transmit delay experienced by any successfully delivered packet. In other words, a short disruption of the service is viewed as statistical effect which may occur in normal operation. Events of longer duration are indicative of failure to allocate sufficient resources to the controlled-load flow. In order to ensure that the conditions on controlled-load service are met, clients requesting the service provide network elements on the data path with an estimation of the data traffic they are going to generate. When signaling with RSVP, the object carrying this estimation is called TSpec. In return, the service ensures that in each network element on the data path, resources adequate to process traffic falling within this descriptive envelope will be available to the client. This must be accomplished by admission control. The controlled-load service is implemented per-flow in each network element on the data-path. Thereby, a network element may be an individual node such as a router. However, a network element can also be a subnet, e.g. a DiffServ cloud within a larger IntServ network [RFC2998]. In this case, the per-flow traffic description (e.g. carried in the RSVP TSpec) together with the DiffServ Code Point (carried e.g. in the DCLASS object [RFC2996] of RSVP) is used for admission control into the DiffServ cloud. The DiffServ cloud must ensure it provides controlled-load service. It is also possible to operate controlled-load service over logical links such as IP tunnels [RFC2746] or MPLS LSPs [RFC3031]. The per-flow traffic descriptor is in this case used for admission control into the tunnel /LSP. 5. NSIS QoS Model for IntServ Controlled Load Service As described above, according to [qos-nslp], a QoS model needs to define - a description of resources to be reserved, carried in the QSpec, - control information associated with the QSpec, - objects to be carried in QUERY and RESPONSE, - processing rules for packet treatment in network elements, e.g. regarding admission control, packet scheduling and policy control. However, during this validation exercise, it became apparent that additional information seems necessary for fully specifying a QoS model. This document therefore also provides information on Kappler Expires - August 2004 [Page 5] QoS Model for IntServ Controlled-Load Service February 2004 - The role of QNEs: how do QNEs map onto controlled-load service network elements, - Usage of QoS-NSLP messages in the QoS model: what QoS-NSLP messages to use for signaling controlled-load service. - information carried in the QSpec beyond a description of resources to be reserved, such as QoS model identification, and AdSpec like information such as local availability of QoS model. 5.1 Role of QNEs Controlled-load service network elements can be individual routers or subnets. I.e. it is not necessary for each network node on the data path to interpret the signaling for the service. Rather, dedicated nodes may interpret signaling information and take on responsibility that the subnet they represent delivers adequate service. In fact, this setting maps nicely onto QoS-NSLP û and the NSIS protocol suite in general. In NSIS, QNEs are just required to be located on the data path. However there are no prescriptions regarding their number or frequency. This is in contrast to RSVP, where each router on the data path is expected to be RSVP-capable. Hence, in the controlled-load QoS model, there must be (at least) one QNE acting on behalf of every network element. E.g. all ingress routers to a DiffServ cloud could be QNEs, performing admission control (Note for this usage it would be necessary to also carry the DiffServ Code Point in the QoS_NSLP message, analogously to the DCLASS Object in RSVP [RFC2996]. A more detailed discussion will be provided in future versions of this document). If there is more than one QNE per network element, they must be coordinated among themselves to ensure the network element delivers controlled-load service. 5.2 Control Information No specific control information is necessary. 5.3 Content of QSpec, Including Resource Description The controlled-load service uses a token bucket specification plus a peak rate (p), a minimum policed unit (m) and a maximum packet size (M) to describe a data flow's required resources. The token bucket specification includes a bucket rate r and a bucket depth b. The minimum policed unit m is an integer measured in bytes. All IP data grams of size less than m are counted against the token bucket as being of size m. For more details, including value ranges of the parameters see [RFC2210]. It seems feasible to reuse the TOKEN_BUCKET_TSPEC defined for IntServ in [RFC2215] in the QSpec. The XDR description of this set of parameters is reproduced here: struct { float r; Kappler Expires - August 2004 [Page 6] QoS Model for IntServ Controlled-Load Service February 2004 float b; float p; unsigned m; unsigned M; } TOKEN_BUCKET_TSPEC; The controlled-load service has no required characterization parameters the QNI needs to be informed about, i.e. current measurement and monitoring information need not be exported by QNEs, although individual implementations may do so if they wish. In RSVP one would say the service-specific data fragment in the AdSpec carries no prescribed information except whether the service is implemented in each network element. If an implementation wishes to export information, appropriate fields in the QSpec would need to be defined. The information can be fed-back to the QNI by means of a RESPONSE message. It may be useful for the controlled-load service QSpec to contain AdSpec-like fields that are updated by each QNE, such as minimum MTU and maximum currently available bandwidth. In fact such fields are already foreseen in the strawman proposal QSpec template in [qos- nslp]. For usage of these parameters see Sec 5.6. Additionally, the QSpec should contain a QoS model (or QSpec) ID, also foreseen in the strawman QSpec template. Later versions of this document will give the precise Object format. 5.4 Objects to be Carried in QUERY and RESPONSE For sender-initiated reservations, the QUERY message is not used (except see discussion in Sec. 5.6). The RESPONSE needs to carry generic ôreservation successfulö and ôQoS Object not understoodö information which should be defined in another document ([qos-nslp] and/or a QoS Model template). Additionally, the RESPONSE needs to carry more precise information why a reservation failed, such as ôMTU too large, permissible MTU size isà), see also Sec. 5.6. The corresponding object will be defined in a later version of this document. 5.5 Processing Rules in QNEs - Admission Control For controlled-load service, QNEs are required to perform admission control. All resources important to the operation of the network element must be considered when admitting a request. Common examples of such resources include link bandwidth, router or switch port Kappler Expires - August 2004 [Page 7] QoS Model for IntServ Controlled-Load Service February 2004 buffer space, and computational capacity of the packet forwarding engine. It is not prescribed how a QNE determines adequate resources are available. It is however required that they make bandwidth greater than the token rate available to the flow in certain situations in order to account for fluctuations. E.g. statistical methods may be used to determine how much bandwidth is necessary. There are no target values for other parameters, e.g. delay or loss, other than providing a service closely equivalent to that provided to best-effort traffic under lightly loaded conditions. QNEs must reject a service request (by returning an admission control error) if the maximum packet size M is bigger than the MTU of the segment of the path managed by this QNE. Resource requests for new flows are accepted if capacity is available. Reservation modifications are accepted if the new TOKEN_BUCKET_TSPEC is strictly smaller than the old one (for rules for ordering TOKEN_BUCKET_TSPECs see [RFC2211]). Otherwise they are treated like new reservations from an admission control perspective. - Packet Scheduling No specific scheduling mechanism is prescribed, as long as admitted flows receive appropriate service. - Policy Control The controlled-load service is provided to a flow on the basis that the flow's traffic conforms to the traffic parameters signaled at flow setup time. Packets arriving when no tokens are available, or arriving with a rate greater than the peek rate, are considered non- conformant. QNEs are allowed to somewhat delay packets for making them conformant (i.e. to reshape the flow). Links are not permitted to fragment packets which receive the controlled-load service. Packets larger than the MTU of the link must be treated as non-conformant. Nonconformant packets should be forwarded on a best-effort basis, as long as the contracted QoS of other flows is not compromised, and as long as best-effort traffic is not impacted unfairly. The mechanism for implementing this policy is not prescribed. E.g. it would be possible to degrade the service delivered to the entire flow which originated the nonconformant packets, or to just degrade or even drop nonconformant packets (such as packets larger than the MTU). Note each QNE MUST independently ensure other flows are not impacted by non-conforming packets. Kappler Expires - August 2004 [Page 8] QoS Model for IntServ Controlled-Load Service February 2004 5.6 Usage of QoS-NSLP Messages QoS-NSLP allows for both sender-initiated and receiver-initiated reservations. So far however, only message flows for receiver- initiated reservations are defined in [qos-nslp]. Therefore this document at this point also only describes sender-initiated reservations for controlled-load service. In order to reserve controlled-load service, the sender initiates a RESERVE message containing a QSpec with the traffic description detailed in Sec. 5.3. If the request is admitted, a corresponding RESPONSE may be returned, as described in [qos-nslp]. The case of failing admission is more interesting. Admission may fail either because the MTU advertised in the traffic description is too large for at least one link, or because at least one QNE doesnÆt have the resources available to accommodate the advertised traffic. It would be helpful for the initiator of the RESERVE message, the QNI, to know what MTU or what resources would be feasible in order to be able to make another reservation attempt if so desired. In RSVP, the actual reservation is always made by the receiver. The initiator however triggers the reservation action by sending a PATH message containing the traffic description in the TSpec, and an AdSpec object, updated at each network element, which collects information on path properties, such as MTU and currently available bandwidth. The receiver can use the information in the AdSpec to make an appropriate reservation request. With a sender-initiated reservation as discussed here, collecting information from network elements for use in the reservation is not as straightforward. For signaling controlled-load service with QoS- NSLP the following possibilities exist: * The QNI obtains information on the appropriate MTU not via QoS-NSLP but differently (out-of-band). This way failing admission because of oversized MTU is avoided. Admission may however still fail for lack of resources. * The QNI issues a QUERY and awaits the RESPONSE before sending the actual RESERVE. While serving the purpose, this procedure adds another round-trip time and thus defeats the point (or at least one point) of sender-initiated reservations. * The QNE failing admission returns a RESPONSE to the QNI, giving the reason and a suitable value for MTU / bandwidth ([qos-nslp] does not specify yet which QNE informs the QNI a reservation failed: e.g. the QNE at which the reservation failed, or the QNR). For another reservation attempt at this QNE, success would be guaranteed (in case Kappler Expires - August 2004 [Page 9] QoS Model for IntServ Controlled-Load Service February 2004 of failing because of MTU) or at least be more likely (in case of failing because of lack of resources). However, a QNE further down the path towards the receiver may still deny admission. * The QNI adds an AdSpec-like Object (or appropriate fields in the QSpec) in the RESERVE, containing a proposal for MTU and for bandwidth. The QNE failing admission sets a ôdeniedö bit in the RESERVE (not defined yet) or QSpec / AdSpec, and updates the AdSpec- like object (henceforth called AdSpec for simplicityÆs sake) with permissible values. Then it continues to forward the RESERVE towards the QNR. Each QNE on the path continues to update the AdSpec if local MTU and bandwidth are even smaller than the values currently contained in the AdSpec. The QNR returns the AdSpec with a RESPONSE message saying ôfailureö to the QNI. This method allows for efficient adaptation of failed reservations, but adds overhead regarding bandwidth and processing. In case of a failed first attempt, it adds half a roundtrip time latency compared to receiver-initiated reservation. 6. Feedback to QoS-NSLP and Open Issues When elaborating the present QoS model, a number of requirements and suggestions for clarification came up that should be considered for QoS-NSLP, the strawmanÆs proposal for a QSpec template, and QoS models in general: - A feedback mechanism should be provided to inform QNIs when the desired QoS model is not known to a QNE that is supposed to interpret it. In RSVP a ôbreak bitö is set in the AdSpec. Such a break bit however is delivered to the QNR (in the case of QoS-NSLP). An alternative is for the QNE to issue an error RESPONSE message back to the QNI. - Information that is generated in or modified by the network (AdSpec-like information) may travel both in RESERVE and QUERY. When it is traveling in the RESERVE, is it an additional object, independent of the QSpec? This may make sense if it then can be reused as-is as object in QUERY. Also, just as in RSVP, the information carried in a RESERVE would be logically separated in a mutable and an immutable part. Mutable information in the RESERVE implies (not yet mentioned explicitly in [qos-nslp]) QNEs may manipulate information contained in RESERVE Objects. - [qos-nslp] provides a staw manÆs proposal for a QSpec template. It is suggested to extend this template to a QoS model template, similar to the network element service specification template for IntServ in [RFC2216]. Kappler Expires - August 2004 [Page 10] QoS Model for IntServ Controlled-Load Service February 2004 - Regarding content of the QSpec template in [qos-nslp], the QoS model presented here needs the fields for QoS Model (QSpec) ID, Traffic Envelope and traffic conformance and, possibly, Monitoring Requirements (namely minimum MTU and maximum currently available bandwidth). The other fields foreseen in the template are not necessary for this QoS Model. One could however picture a slight extension of the QoS model in which Excess Treatment (what happens to non-conforming traffic) and Service Schedule (giving a time for which the service is requested) are also used. This QoS model does not require additional fields not yet listed in the QSpec template. It may however be useful if the template allows for ôfree fieldsö in which e.g. implementation specific information can be exported by QNEs (see Sec. 5.3). - Would it make sense to define standard objects for QUERY and RESPONSE as well? And, already detailed above: - A QoS model should include a description of both the mechanism to provide QoS and the usage of QoS-NSLP to signal for this mechanism (cf. Sec. 1). Particularly, a QoS model should include, beyond what is already listed in [qos-nslp], a description of (cf. Sec. 5) * the role of QNEs * usage of QoS-NSLP messages in the QoS model * a full specification of the QSpec including, but not limited to, a resource description - Should QoS-NSLP or the QoS model define what QNE returns an error RESPONSE upon failed reservations(cf. Sec. 5.6)? - What is the most efficient way of providing feedback to the QNI for sender-initiated reservations (cf. Sec. 5.6)? Does the feedback mechanisms need to be described or could an implementation pick the one it finds the most useful? Later versions of this document will contain the precise QSpec Object and RESPONSE object formats, and a description of how to do receiver- initiated reservations. Security Considerations This Internet Draft raises no security issues. References Kappler Expires - August 2004 [Page 11] QoS Model for IntServ Controlled-Load Service February 2004 [nsis-fw] Hancock, R. and et al., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-05 (work in progress), October 2003. [ntlp] Schulzrinne, H. and Hancock, R., "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-00 (work in progress), Oct. 2003. [RFC1633] Braden, B., Clark, D. and Shenker, S., ôIntegrated Services in the Internet Architecture: An Overviewö, RFC 1633, June 1994. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, Sep 1997. [RFC2210] Wroclawski, J., ôThe Use of RSVP with IETF Integrated Servicesö, RFC 2210, September 1997. [RFC2211] Wroclawski, J., ôSpecification of the Controlled-Load Network Element Serviceö, RFC 2211, September 1997. [RFC2215] Shenker, S. and Wroclawski, J., ôGeneral Characterization Parameters for Integrated Service Network Elementsö, RFC 2215, September 1997. [RFC2216] Shenker, S. and Wroclawski, J., ôNetwork Element Service Specification Templateö, RFC 2216, September 1997. [RFC2475] Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2746] Terzis, A., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B. and J. Wroclawski, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [RFC3031] Rosen, E., Viswanathan, A., Callon, R., ôMultiprotocol Label Switching Architectureö, RFC 3031, January 2001. [qos-nslp] Van den Bosch, S., Karagiannis, G. And McDonald, A., "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-01 (work in progress), October 2003. Kappler Expires - August 2004 [Page 12] QoS Model for IntServ Controlled-Load Service February 2004 Acknowledgment The author would like to thank Andrew McDonald for providing helpful feedback. Author's Address Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany Email: cornelia.kappler@siemens.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kappler Expires - August 2004 [Page 13]