Network Working Group H. Vatiainen Internet-Draft Tampere University of Technology Expires: December 18, 2003 R. Lehtonen J. Soini Sonera Corporation June 19, 2003 Multicast Control Protocol (MCOP) over COPS draft-vatiainen-mcop-cops-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on December 18, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a COPS Client-Type for Multicast Control Protocol (MCOP) and the encapsulation for transmitting MCOP messages over COPS. The document also defines message formats when MCOP over COPS is used for MCOP operation for first hop routers [1]. Vatiainen, et al. Expires December 18, 2003 [Page 1] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MCOP Object Formats . . . . . . . . . . . . . . . . . . . . . 4 2.1 Multicast Parameter Object . . . . . . . . . . . . . . . . . . 4 2.2 Group Range Object . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Group Member Object . . . . . . . . . . . . . . . . . . . . . 7 3. Creating the COPS Messages . . . . . . . . . . . . . . . . . . 10 3.1 Establishing COPS Connection . . . . . . . . . . . . . . . . . 10 3.2 MCOP Initialization . . . . . . . . . . . . . . . . . . . . . 10 3.3 MCOP Validation . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Removing Multicast Group Member Information . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Vatiainen, et al. Expires December 18, 2003 [Page 2] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 1. Introduction The MCOP functionality is specified in [1]. This document specifies the protocol between Multicast Control Client (MCCs) and Multicast Control Servers (MCSs) over COPS [2]. The COPS protocol uses a client/server model in which the servers are called Policy Decision Points (PDPs) and clients Policy Enforcement Points (PEPs). When mapping these terms to MCOP entities, the MCOP MCS is PDP and MCOP MCC is PEP. COPS specification discusses two different scenarios: the outsourcing scenario and the configuration scenario. MCOP uses the outsourcing scenario in which the PEPs (MCCs) ask PDP (MCS) for information about multicast senders and receivers. The MCOP functionality is similar to what is described in the COPS specification [2], section 1.1 Basic Model. The outsourcing model is described in section 4.4. COPS provides the basic protocol containing security, connection keepalive tracking and extensibility and was thus chosen to carry the messages between MCCs and MCS. Vatiainen, et al. Expires December 18, 2003 [Page 3] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 2. MCOP Object Formats All MCOP messages sent over COPS follow the same object format in which each object begins with a four-octet header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length (octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... Object contents ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8 bits o Type field identifies the object class contained in the object. This document specifies the object formats for MCOP operation for first hop routers. Later documents can specify additional types for future uses of MCOP over COPS. The Type values defined in this document are: 1 = Multicast Parameter, 2 = Group Range and 3 = Group Member Subtype: 8 bits o Subtype identifies the subtype of the information contained in the object. Length: 16 bits o The length field is a two-octet value that describes the number of octets (including the object header) that compose the object. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary. 2.1 Multicast Parameter Object The Multicast Parameter object contains Parameter Blocks that carry parameters used by MCC for multicast control purposes. The parameters are intended to be used for all multicast groups and channels (not just for MCOP controlled groups and channels). Type = 1, Vatiainen, et al. Expires December 18, 2003 [Page 4] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 Subtype = 0 (IPv4) or Subtype = 1 (IPv6) o The Parameter Blocks list the MCC's directly connected networks that have multicast capable hosts. This information is used by MCS to send the correct network specific multicast parameters back to the MCC. Sent by MCC to MCS. Subtype = 2 (IPv4) or Subtype = 3 (IPv6) o The Parameter Blocks contain network specific parameters that are applied to multicast receivers. Sent by MCS to MCC. Subtype = 4 (IPv4) or Subtype = 5 (IPv6) o The Parameter Blocks contain network specific parameters that are applied to multicast sources. Sent by MCS to MCC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or More Parameter Blocks | . . . . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter Block (IPv4): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Number of Groups per Host | Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Allowed Multicast Rate (kbits/s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For Subtypes 0 and 1 the Number of Groups per Host field and Maximum Allowed Multicast Rate MUST be set to zero by MCC and ignored on reception by MCS. IP Address: 32 bits (IPv4) or 128 bits (IPv6) and Mask Length: 8 bits o For Subtypes 0 and 1 IP Address and Mask Length specify the networks that have multicast capable hosts. For other Subtypes they specify the network for which the parameters apply. Vatiainen, et al. Expires December 18, 2003 [Page 5] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 Maximum Number of Groups per Host: 24 bits o Maximum Number of Groups per Host field specifies for receivers the maximum number of groups that can be joined by a single host. For senders it defines the maximum number of groups that can be sent traffic to (within Source Timer). The meaning depends on the subtype in question. Maximum Number of Groups per Host field maximum value of 0xFFFFFF is interpreted as Infinity. Maximum Allowed Multicast Rate: 32 bits o Maximum Allowed Multicast Rate is used for controlling multicast sources as specified in [1]. Maximum Allowed Multicast Rate field maximum value of 0xFFFFFF is interpreted as Infinity. 2.2 Group Range Object The Group Range object contains the MCOP controlled multicast addresses in zero or more Group Address Blocks. The MCS uses this object type to inform MCC to which multicast groups and SSM channels MCOP control applies to. Sent by MCS to MCC. Type = 2, Subtype = 0 (IPv4) or Subtype = 1 (IPv6) o Specifies the multicast address ranges and SSM channel ranges for the indicated protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MCOP Connection Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MCOP Cache Entry Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero or More Group Address Blocks | . . . . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vatiainen, et al. Expires December 18, 2003 [Page 6] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 Group Address Block (IPv4): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S| Reserved | Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MCOP Connection Holdtime: 32 bits o Specifies the holdtime of MCOP controlled multicast addresses and MCOP controlled group and channel information in case the connection to MCS is disconnected. MCOP Cache Entry Lifetime: 32 bits o Specifies the lifetime of MCOP controlled multicast addresses and MCOP controlled group and channel information. Group Address: 32 bits (IPv4) or 128 bits (IPv6) and Mask Length: 8 bits o Group Address and Mask Length specify the MCOP controlled multicast address or SSM group ranges. For a single any-source multicast group or SSM channel the mask length is 32 (IPv4) or 128 (IPv6). R: 1 bit o If Receiver bit is set, information in this Group Address Block applies to multicast receivers. S: 1 bit o If Source bit is set, information in this Group Address Block applies to multicast sources. Reserved: 22 bits o Reserved bits MUST be set zero on transmission and ignored on reception. 2.3 Group Member Object The Group Member object contains information about receivers and sources for one MCOP controlled group or channel. The object can be Vatiainen, et al. Expires December 18, 2003 [Page 7] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 used to validate either single hosts or entire subnets. Sent by MCC to MCS when requesting information and by MCS to MCC when providing information. Type = 3, Subtype = 0 (IPv4) or Subtype = 1 (IPv6) o Specifies the protocol for which control information is requested. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address for Source-Specific Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero or More Address Blocks | . . . . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Block (IPv4): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S| Reserved | Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multicast Group Address: 32 bits (IPv4) or 128 bits (IPv6) o Multicast Address of the multicast group G. The address MUST belong to the MCOP controlled multicast addresses which were previously specified with Group Range object. Source Address for Source-Specific Group: 32 bits (IPv4) or 128 bits (IPv6) o The IP address of the source for source-specific group. The field is used only with source-specific multicast channels which are identified by the multicast group address field. Together with Vatiainen, et al. Expires December 18, 2003 [Page 8] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 the multicast group address it specifies a source-specific multicast [3] channel. If the multicast group address does not belong to the SSM address range, the field MUST be set to 0. IP Address: 32 bits (IPv4) or 128 bits (IPv6) and Mask Length: 8 bits o IP Address and Mask Length specify the IP network for which the Address Block contains MCOP information. For a single host the mask length is 32 (IPv4) or 128 (IPv6). R: 1 bit o When Receiver bit is set, it indicates valid receiver. S: 1 bit o When Source bit is set, it indicates valid source. Reserved: 22 bits o The reserved bits MUST be set zero on transmission and ignored on reception. Vatiainen, et al. Expires December 18, 2003 [Page 9] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 3. Creating the COPS Messages All MCOP objects in COPS Requests are encapsulated within COPS Client Specific Information Objects (ClientSI), C-Num = 9 with C-Type = 1, Signaled ClientSI. All MCOP objects in COPS Decisions are encapsulated in Decision Objects, C-Num = 6, C-Type = 4, Client Specific Decision Data. 3.1 Establishing COPS Connection The MCC creates a COPS connection to the selected MCS using the Client-type specified in Section 5. The PEPID COPS object in the COPS Client-Open (OPN) message specifies the PEP Identification configured to the client. 3.2 MCOP Initialization Once the COPS Client-Accept (CAT) message is received the MCC will send a COPS Request (REQ) specifying a new Client-Handle, Context Object with R-Type 0x08 (Configuration request) and M-Type 0x0. The Request must also contain ClientSI object with C-Type 1 (Signaled ClientSI). The ClientSI object contains the MCOP Multicast Parameter object in which the MCC lists all connected networks that have directly connected hosts. The format of COPS message from MCC to MCS is ::= [] MCS responds with COPS Decision (DEC) message specifying the Client-Handle, Context Object with R-Type 0x08 (Configuration Request) and M-Type 0x0. The Decision must also contain ClientSI object with C-Type 1 (Signaled ClientSI). The ClientSI contains MCOP Group Range object which lists all MCOP controlled multicast addresses. MCS also informs MCCs whether the control must be applied to multicast receivers, multicast sources or both. The ClientSI also contains MCOP Multicast Parameter object which contains general multicast parameters. The format of COPS message from MCS to MCC is Vatiainen, et al. Expires December 18, 2003 [Page 10] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 ::= | [] ::= The values for MCOP Connection Holdtime and MCOP Cache Entry Lifetime are obtained from locally configured values which may depend on the requesting MCC. The bits in the Group Address Block are interpreted as follows: o R=1, S=0 indicate that network and address mask is part of the MCOP controlled multicast addresses, but applies to multicast receivers only. o R=0, S=1 indicate that network and address mask is part of the MCOP controlled multicast addresses, but applies to multicast sources only. o R=1, S=1 indicate that network and address mask is part of the MCOP controlled multicast addresses and applies to both receivers and sources. o R=0, S=0 indicate that network and address mask is not part of the MCOP controlled multicast addresses. MCS may send unsolicited COPS Decisions to the MCC using an existing Client Handle if the address space for MCOP controlled multicast addresses or general multicast parameters change. In that case the Decision updates the current information in MCC. Decision ClientSI MUST NOT contain Group Member objects. 3.3 MCOP Validation When MCC receives new multicast traffic sent to a MCOP controlled group or channel, the MCC initiates the validating procedure before it passes any traffic up the protocol stack. When a MCC receives an IGMP/MLD Report from a new host wishing to join a MCOP controlled group or channel, the MCC initiates the validating procedure before it passes the packet to IGMP/MLD processing. Vatiainen, et al. Expires December 18, 2003 [Page 11] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 If the MCC does not know about the MCOP controlled group's or channel's valid receivers and sources already, it MUST retrieve this information from MCS using the Group Member object. For sending MCOP Validate messages the MCC creates a COPS Request (REQ) message with Context object R-Type set to 0x01, Incoming-Message/Admission Control Request. The MCOP Validate message is enacapsulated in COPS ClientSI object. As required by COPS the MCC must create a new Client Handle for the new request state. The format of COPS message from MCC to MCS is ::= [] The Group Member object is defined as follows: o Multicast Group Address specifies the multicast group that is validated with this Group Member object. o Source Address for Source-Specific Group identifies the IP address of the source if the multicast group is source-specific. If the address does not identify a source-specific multicast group, it is set to 0. o The address of the directly connected network of MCC, where the multicast traffic or IGMP Report was received from. The MCC can validate one or more subnets by listing them in Address Blocks. The R and S bits MUST be cleared and ignored on reception at MCS. MCS uses Group Member object to inform MCCs about the current status of multicast sources and receivers. To reduce the number of messages, the status of both receivers and sources for the subnet is returned with the same message. If necessary, the decision from MCS may contain individual host entries. If a new source or receiver becomes active for the same MCOP controlled group or channel, the MCC already has the control information stored locally. If the group status changes, MCS MUST send unsolicited MCOP Result message to MCCs that have checked the group status earlier. Those unsolicited MCOP Result messages are treated as an update to the multicast group status. Vatiainen, et al. Expires December 18, 2003 [Page 12] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 For sending MCOP Result messages the MCS creates a COPS Decision (DEC) message. The Decision Command-Code must be set to 1, Install. The Group Member object is encapsulated in COPS ClientSI object. As required by COPS the MCS must use the Client Handle for mapping the decision to the corresponding request. The Solicited Message Flag Bit in the COPS Common Header must be set if the Decision was solicited by MCC. The format of COPS message from MCS to MCC is ::= | [] ::= The Group Member object for the MCOP Result message is defined as follows: o Multicast Address specifies the multicast group in this Group Member object. o Source Address for Source-Specific Group identifies the IP address of the source if the multicast group is source-specific. o Address Blocks contain the network addresses and mask lengths for senders or receivers. For source-specific groups a valid source must be explicitly mentioned in the Address Block. Address Block can contain individual host entries (mask length = 32 or 128). The following network addresses and masks can be used to refer to whole multicast group: 0.0.0.0/0 indicate all IPv4 networks and ::/0 indicate all IPv6 networks. o R and S bits describe the validity or non-validity of a network or a host in question. If the MCS does not have information about the group or channel in question, it MUST set the network or host as non-valid. The individual bits are interpreted as follows: * R=1, S=0 indicate valid receiver. * R=0, S=1 indicate valid source. * R=1, S=1 indicate valid receiver and valid source. Vatiainen, et al. Expires December 18, 2003 [Page 13] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 * R=0, S=0 indicate non-valid receiver and non-valid source. 3.4 Removing Multicast Group Member Information For removing multicast group member information, the MCC creates a COPS Delete Request State (DRQ) message using the appropriate Client Handle to specify the request state that is removed. The format of COPS message from MCC to MCS is ::= [] Vatiainen, et al. Expires December 18, 2003 [Page 14] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 4. Security Considerations This document relies in the security measures of COPS. Vatiainen, et al. Expires December 18, 2003 [Page 15] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 5. IANA Considerations The IANA should assign a COPS Client-type value for Multicast Control Protocol (MCOP). FIXME: Should IANA also keep track of Type and Subtype values in the MCOP object common header? Vatiainen, et al. Expires December 18, 2003 [Page 16] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 Normative References [1] Lehtonen, R., Soini, J., Majalainen, J., Vatiainen, H. and M. Tammi, "MCOP operation for first hop routers", work in progress, June 2003. [2] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [3] Bhattacharyya, S., Diot, C., Giuliano, L., Rockell, R., Meylor, J., Meyer, D., Shepherd, G. and B. Haberman, "An Overview of Source-Specific Multicast (SSM)", work in progress, November 2002. Authors' Addresses Heikki Vatiainen Tampere University of Technology Korkeakoulunkatu 1 Tampere 33720 Finland EMail: hessu@cs.tut.fi Rami Lehtonen Sonera Corporation Hatanpaan valtatie 20 Tampere 33100 Finland EMail: rami.lehtonen@teliasonera.com Jyrki Soini Sonera Corporation Kumpulantie 3 Sonera 00051 Finland EMail: jyrki.soini@teliasonera.com Vatiainen, et al. Expires December 18, 2003 [Page 17] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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 Vatiainen, et al. Expires December 18, 2003 [Page 18] Internet-Draft Multicast Control Protocol (MCOP) over COPS June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vatiainen, et al. Expires December 18, 2003 [Page 19]