MIPSHOP E. Hepworth Internet-Draft Siemens Roke Manor Research Expires: September 7, 2006 G. Daley Panasonic S. Sreemanthula S. Faccin Nokia Research Center G. Vivek Intel March 06, 2006 Media Independent Handovers: Problem Statement draft-hepworth-mipshop-mih-problem-statement-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract There are on-going activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous Hepworth, et al. Expires September 7, 2006 [Page 1] Internet-Draft MIH Problem March 2006 wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem which is within the scope of the IETF. This draft presents a problem statement for this core problem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. End-to-End Signalling and Transport over IP . . . . . . . 4 2.2. End-to-End Signalling and Partial Transport over IP . . . 4 2.3. End-to-End Signalling with a Proxy . . . . . . . . . . . . 5 3. Solution Components . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payload Formats and Extensibility Considerations . . . . . 8 4. Requirements on the Mobility Service Transport Layer . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Conclusions and Open Issues . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix B. Relationship to IEEE 802.21 . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Hepworth, et al. Expires September 7, 2006 [Page 2] Internet-Draft MIH Problem March 2006 1. Introduction This Internet Draft provides a problem statement for the exchange of information to support handover in heterogeneous link environments. This mobility support service allows more sophisticated handover operations by making available information about network characteristics, neighbouring networks and associated characteristics, indications that a handover should take place, and suggestions for suitable target networks to which to handover. The mobility support services work complementarily with IP mobility mechanisms to enhance the overall performance and usability perpception. There are two key attributes to the handover support service problem: 1. The Information and Information Exchange mechanism: this includes the information elements that describe the information, and any signalling exchanges that are required to support the transfer of these Information Elements. 2. The Underlying Transport: this supports the Information Exchange between devices in the network. The requirements on this transfer mechanism include transport issues, because of the volume of data to be sent, as well as security issues, as the signalling may cross administrative boundaries and is interdependent with AAA aspects. This draft has been motivated by on-going work within IEEE 802.21, but the following description intentionally describes the problem from a more general perspective. This document represents the views of the authors, and does not represent the official view of IEEE 802.21. The structure of this document is as follows. Section 2 provides a simple model for the entities involved in the signalling and their possible relationships. Section 3 describes a decomposition of the signalling problem into service specific parts and a generic transport part. Section 4 describes more detailed requirements for the transport component. Section 5 provides security considerations, and Section 6 summarises the conclusions and open issues. 2. Entities The following section provides an overview of the network entities that are expected to be involved in the signalling exchanges to support the handover operation. The following abbreviations are used in this section: Hepworth, et al. Expires September 7, 2006 [Page 3] Internet-Draft MIH Problem March 2006 o MN: mobile node o NN: network node, intended to represent some device in the network (the location of the node e.g. in the access network, home network is not specified, and for the moment it is assumed that they can reside anywhere). o EP: endpoint, intended to represent the terminating endpoints of the transport protocol used to support the signalling exchanges between nodes. The deployment sceanrios are outlined in the following sections. Note: while MN-to-MN signalling exchanges are theoretically possible, these are not currently being considered, and are out-of-scope. 2.1. End-to-End Signalling and Transport over IP In this case, the end-to-end signalling used to exchange the handover information elements (the Information Exchange) runs end-to-end between MN and NN. The underlying transport is also end-to-end +------+ +------+ | MN | | NN | | (EP) | | (EP) | +------+ +------+ Information Exchange <------------------------------------> /------------------------------------\ < Transport over IP > \------------------------------------/ Figure 1: End-to-end Signalling and Transport 2.2. End-to-End Signalling and Partial Transport over IP As before, the Information Exchange runs end-to-end between the MN and the second NN. However, in this scenario, some other transport means is used from the MN to the first NN, and the transport over IP is used only between NNs. This is analogous to the use of EAP end- to-end between Supplicant and Authentication Server, with a upper- layer multihop protocol such as RADIUS used as a backhaul transport protocol between an Access Point and the Authentication Server. Hepworth, et al. Expires September 7, 2006 [Page 4] Internet-Draft MIH Problem March 2006 +------+ +------+ +------+ | MN | | NN | | NN | | | | (EP) | | (EP) | +------+ +------+ +------+ Information Exchange <------------------------------------> (Transport over /------------------\ <--------------->< Transport over IP > e.g. L2) \------------------/ Figure 2: Partial Transport 2.3. End-to-End Signalling with a Proxy In the final case, a number of proxies are inserted along the path between the two transport endpoints. The use of proxies is possible in both cases 1 and 2 above, but distinguished here as there are a number of options as to how the proxy may behave with regard to the transport and end-to-end signalling exchange. o Information Exchange Approach In this case, the proxy performs some processing on the Information Exchange before forwarding the information on. This can be viewed as concatenating signalling exchanges between a number of EPs. +------+ +---------+ +------+ | MN | | ProxyNN | | NN | | (EP) | | (EP) | | (EP) | +------+ +---------+ +------+ Information Exchange ------------------> -------------------> <------------------- <------------------ /---------------\ /----------------\ < Transport > < Transport > \---------------/ \----------------/ Figure 3: Information Exchange Approack The Proxy NN processes all layers of the protocol suite in the same way as an ordinary EP. o Redirection Approach Hepworth, et al. Expires September 7, 2006 [Page 5] Internet-Draft MIH Problem March 2006 In this case, the redirection NN processes enough of the Information Exchange to forward the message to the correct ultimate NN for that MN and service type. Subsequent Information Exchanges take place between the MN and NN. +------+ +----------+ +------+ | MN | | Redirect | | NN | | (EP) | | NN | | (EP) | +------+ +----------+ +------+ Information Exchange ------------------> -------------------> [------Minimal Transport/Security------] Information Exchange <--------------------------------------> /--------------------------------------\ < Transport > \--------------------------------------/ Figure 4: Redirection Approach The initial messages are assumed to have minimal transport requirements. The main information exchange takes place directly between the endpoints. o Directory Approach In this scenario, the MN (EP) carries out an Information Exchange with a Directory node in the network to determine which NN should be used for subsequent Information Exchanges. +------+ +------------+ +------+ | MN | | Directory | | NN | | (EP) | | (EP) | | (EP) | +------+ +------------+ +------+ Information Exchange -------------------> <------------------- [Minimal Transport/Security] Information Exchange <-------------------------------------> /--------------------------------------\ < Transport > \--------------------------------------/ Figure 5: Directory Approach The Information Exchange with the Directory requires only minimal Hepworth, et al. Expires September 7, 2006 [Page 6] Internet-Draft MIH Problem March 2006 processing, just enough to determine the appropriate NN for the MN to use. Transport and security requirements for the lookup phase are typically very limited. This option provides one approach to supporting initial node discovery, where subsequent Information Exchanges are carried out directly between two peers. The question as to which of these proxy options should be considered is still open. 3. Solution Components Figure 6 shows a model where the Information Exchanges are implemented by a signalling protocol specific to a particular mobility service, and these are relayed over a generic transport layer (the Mobility Service Transport Layer). +----------------+ ^ |Mobility Support| | | Service 2 | | +----------------+ | (e.g. ES) | | Mobility Service |Mobility Support| +----------------+ | Signaling | Service 1 | +----------------+ | Layer | (e.g. IS) | |Mobility Support| | +----------------+ | Service 3 | | | (other) | | +----------------+ V ================================================ +---------------------------------------+ ^ Mobility Service | Mobility Service Transport Protocol | | Transport +---------------------------------------+ V Layer ================================================ +---------------------------------------+ | IP | +---------------------------------------+ Figure 6: Handover Services over IP The Mobility Service Transport Layer provides certain functionality (outlined in Section 4) to the higher layer mobility support services in order to support the exchange of information between communicating mobility service functions. The transport layer effectively provides a container capability to mobility support services, as well as any required discovery, transport and security operations required to provide communication. The Mobility Support Services themselves may also define certain protocol exchanges to support the exchange of service specific Hepworth, et al. Expires September 7, 2006 [Page 7] Internet-Draft MIH Problem March 2006 Information Elements. It is likely that the responsibility for defining the contents and significance of the Information Elements is the responsibility of other standards bodies other than the IETF. Example mobility services include the Media Independent Information Service [1], and the Media Independent Command and Event Services [2]. 3.1. Payload Formats and Extensibility Considerations The format of the Mobility Service Transport Protocol is as follows: +----------------+----------------------------------------+ |Mobility Service| Opaque Payload | |Transport Header| (Mobility Support Service) | +----------------+----------------------------------------+ Figure 7: Protocol Structure The opaque payload encompasses the Mobility Support Service information that is to be transported. The definition of the Mobility Service Trabsport Header is something that is best addressed within the IETF. The Mobility Support Service payload format also includes a header, which could vary depending on the definition of each Mobility Support Service. +----------------+-------------------------------+ Mobility Support | Header | Payload | Service 1 (IS) | |(Mobility Support Service Data)| +----------------+-------------------------------+ +--------+---------------------------------------+ Mobility Support | Header | Payload | Service 2 (other) | | (Mobility Support Service Data) | +--------+---------------------------------------+ Figure 8: Protocol Structure There are a number of issues with regard to the Mobility Support Service header and payload definition. These include: 1. Responsibility for defining the header: where should the contents of the Mobility Support Service header be defined, and should there be one or multiple header definitions (i.e. will a common header definition for all mobility support services be adequate?). Where there are commonalities, it may indicate that these aspects should actually be included in the Mobility Service Hepworth, et al. Expires September 7, 2006 [Page 8] Internet-Draft MIH Problem March 2006 Transport Header. 2. Payload Format: the format or the Mobility Support Service Data payload could be represented in a number of formats, e.g. TLV, ASN/1, XML or text. Ideally, a single payload representation should be defined, as support for multiple formats leads to unnecessary complexity. It is expected that a set of Data Objects will be defined for the Mobility Support Services to exchange. 3. Sharing of Data Objects: which refers to sharing the definitions of Data Objects between Mobility Support Services, e.g. if a Capabilities object is defined that is used by multiple Mobility Support Services, should the same definition be used by all of them. If this is the case, then a common identifier space is needed to identify the different Data Objects. There is a question about where the definition of Data Objects and the management of the identifier space should take place. The answers to some of the above issues may in part depend on how many standards groups are interested in defining their own Mobility Support Services. 4. Requirements on the Mobility Service Transport Layer The following section outlines some of the general transport requirements that should be supported by the Mobility Service Transport Protocol. Analysis within IEEE 802.21 has suggested that at least the following need to be taken into account: Discovery MNs need the ability to locate nodes that support particular mobility services in the network. There are no assumptions about the location of these mobility services within the network, therefore the discovery mechanism needs to operate across administrative boundaries. Issues such as speed of discovery, proetcion against spoofing, when discovery needs to take place, and the length of time over which the discovery information may remain valid all need to be considered. Approaches include: * Hard coding information into the MN, indicating either the IP address of the NN, or information about the NN that can be resolved onto an IP address. The configuration information could be managed dynamically, but assumes that the NN is independent of the access network to which the MN is currently attached. Hepworth, et al. Expires September 7, 2006 [Page 9] Internet-Draft MIH Problem March 2006 * Pushing information to the MN, where the information is delivered to the MN as part of other configuration operations, for example, in a Router Discovery exchange. The benefit of this approach is that no additional exchanges with the network would be required, but the limitations associated with modiftying these protocols may limit applicability of the solution. * MN dynamically requesting information about a service, which may require both MN and NN support for a particular service discovery mechanism. This may require additional support by the access network (e.g. multicast or anycast) even when it may not be supporting the service directly itself. Numerous directory and configuration services already exist, and reuse of these mechanisms may be appropriate. There is an open question about whether mulitple methods of discovery would be needed, and whether NNs would also need to discover other NNs. The definition of a service also needs to be determined, including the granularity of the decsription (for example, should the MN look for an "IS" service, or "IS-local information", and "IS-home network information" services. Information from a trusted source: The MN uses the Mobility Service information to make decisions about what steps to take next. It is essential that there is some way to ensure that the information received is from a trustworthy source. This includes cases where trusted proxies along the path have access to, and may modify, parts of the Mobility Service information. This requirement should reuse trust relationships that have already been established in the network, for example, on the relationships established by the AAA infrastructure after a mutual authentication, or on the certificate infrastructure required to support SEND. Low latency: Some of the Mobility Services generate time sensitive information. Therefore, there is a need to deliver the information over quite short timescales, and the required lifetime of a connection might be quite short lived. For reliable delivery, short-lived connections could be set up as and when needed, although there is a connection setup latency associated with this approach. Alternatively, a long-lived connection could be used, but this requires advanced warning of being needed and some way to maintain the state associated with the connection. It also assumes that the relationships between devices supporting the mobility service are fairly stable. Another alternative is connectionless operation, but this has interactions with other requirements such as reliable delivery. Hepworth, et al. Expires September 7, 2006 [Page 10] Internet-Draft MIH Problem March 2006 Reliability: Reliable delivery for some of the mobility services may be essential, but it is difficult to trade this off against the low latency requirement. It is also quite difficult to design a robust, high performance mechanism that can operate in heterogeneous environments, especially one where the link characteristics can vary quite dramatically. There are two main approaches that could be adopted: 1. Assume the transport cannot be guaranteed to support reliable delivery. In this case, the Mobility Support Service itself will have to provide some sort of reliability mechanism to allow communicating endpoints to acknowledge receipt of information. 2. Assume the underlying transport will deal with most error situations, and provide a very basic acknowledgement mechanism that (if no acknowledgement is received) will indicate that something more serious has occurred than a packet drop (since these other types of error conditions are dealt with at the transport layer). Option 1 has a number of diasadvantges associated with it, namely that ultimately the protocol design ends up re-inventing a lot of the functionality already avaialble in lower layers at a higher layer where access to information about what is going on in the network is restricted. For example, how will the higher layer determine the cause of the error, if a message is lost due to network congestion, it is pointless sending the message again. It also adds to the complexity of the higher layer protocol, and makes successful deployment less certain (the protocol will have to be trialled in a number of network situations instead of re- using a protocol that has already been tested). Congestion Control: A Mobility Service may wish to transfer large amounts of data, placing a requirement for congestion control in the transport. There is an interaction between this requirement and that of the requirement for low latency since ways to deal with timely delivery of smaller asynchronous messages around the larger datagrams is required (mitigation of head of line blocking etc.). Secure delivery: The Mobility Service information must be delivered securely between trusted peers, where the transport may pass though untrusted intermediate nodes and networks. Design considerations include whether session based or host based security associations are required along the chain of NNs, and what the rate limitation requirements of requests/responses might be. Hepworth, et al. Expires September 7, 2006 [Page 11] Internet-Draft MIH Problem March 2006 Multiplexing: The transport service needs to be able to support different mobility services. This may require multiplexing and the ability to manage multiple discovery operations and peering relationships in parallel. Multihoming: For some information services exchanged with the MN, there is a possibility that the request and response messages can be carried over two different links e.g. a handover command request is on the current link while the response could be delivered on the new link. Depending on the IP mobility mechanism, there is some impact on the transport option for the mobility information services. This may potentially have some associated latency and security issues, for example, if the transport is over IP there is some transparency but Mobile IP may introduce additional delay and both TCP and UDP must use the permanent address of the MN. In addition to the above, it may be necessary for the transport to support multiple applications (or modes of operation) to support the particular requirements of the Information Exchange being carried out between nodes. This may require the ability to multiplex multiple information exchanges into a single transport exchange. Further information about transport requirements related to specific Mobility Services can be found in [1] and [2]. 5. Security Considerations Network supported mobility services aim at improving decision making and management of dynamically connected hosts. The control and maintenance of mobile nodes becomes challenging where authentication and authorization credentials used to access a network are unavailable for the purpose of bootstrapping a security association for handover services. Information Services may not require authorization of the client, but both event and command services must authenticate message sources, particularly if they are mobile. Network side service entities will typically need to provide proof of authority to serve visiting devices. Where signalling or radio operations can result from received messages, significant disruption may result from processing bogus or modified messages. The effect of processing bogus messages depends largely upon the content of the message payload, which is handled by the handover services application. Regardless of the variation in effect, message delivery mechanisms need to provide protection against tampering, and spoofing. Hepworth, et al. Expires September 7, 2006 [Page 12] Internet-Draft MIH Problem March 2006 Sensitive and identifying information about a mobile device may be exchanged during handover service message exchange. Since handover decisions are to be made based upon message exchanges, it may be possible to trace a user's movement between cells, or predict future movements, by inspecting handover service messages. In order to prevent such tracking, message confidentiality should be available. This is particularly important since many mobile devices are associated with only one user, as divulgence of such information may violate the user's privacy. Additionally, identifying information may be exchanged during security association construction. As this information may be used to trace users across cell boundaries, identity protection should be available if possible, when establishing SAs. In addition, the user should not have to disclose its identity to the network (any more than it needed to during authentication) in order to access the Mobility Support Services. For example, if the local network is just aware that an anonymous user with a subscription to operatorXYX.com is accessing the network, the user should not have to divulge their true identity in order to access the Mobility Support Services available locally. Finally, the network nodes themselves will potentially be subject to denial of service attacks from MNs and these problems will be exacerbated if operation of the mobility service protocols imposes a heavy computational load on the NNs. The overall design has to consider at what stage (e.g. discovery, transport layer establishment, service specific protocol exchange) denial of service prevention or mitigation should be built in. 6. Conclusions and Open Issues This Internet draft outlined a broad problem statement for the signalling of information elements across a network to support media independent handover services. In order to enable this type of signalling service, a need for a generic transport solution with certain transport and security properties was outlined. Whilst the motivation for considering this problem has come form work within IEEE 802.21, a desirable goal is to ensure that solutions to this problem are applicable to a wider range of mobility services. One important open issue is the question of how much Mobility Service specific functionality (with respect to the structure shown in []) should be seen as part of the common problem within IETF scope. One option is that the problem scope is limited strictly to message transport requirements, the other extreme is that the full mobility service protocols should be defined. An intermediate stage would be Hepworth, et al. Expires September 7, 2006 [Page 13] Internet-Draft MIH Problem March 2006 to consider message sequences and use cases for different mobility services but leave the details of Information Elements by other bodies, but potentially including IETF working groups. It would be valuable to establish realistic performance goals for the solution to this common problem (i.e. transport and security aspects) using experience from previous IETF work in this area and knowledge about feasible deployment scenarios. This information could then be used as an input to other standards bodies in assisting them to design mobility services with feasible performance requirements. Much of the functionality required for this problem is available from existing IETF protocols or combination thereof. This document takes no position on whether an existing protocol can be adapted for the solution or whether new protocol development is required. In either case, we believe that the appropriate skills for development of protocols in this area lies in the IETF. 7. References [1] Faccin, S., "Some Requirements for a Handover Information Service", draft-faccin-mih-infoserv-01 (work in progress), October 2005. [2] Sreemanthula, S., "A Problem Statement for Event Services and Command Services for Media Independent Handovers", draft-sreemanthula-es-cs-problem-statement-00 (work in progress), October 2005. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Appendix A. Acknowledgements Thanks to Robert Hancock, Andrew McDonald and Jari Arkko for their inputs. Appendix B. Relationship to IEEE 802.21 The following Appendix provides some further information on the relationship of this problem statement to the work being carried out by IEEE 802.21. IEEE 802.21 has identified three Mobility Support Services to enable better inter-technology handover decisions. These are: Hepworth, et al. Expires September 7, 2006 [Page 14] Internet-Draft MIH Problem March 2006 1. the Event Service (ES) which provides indications from lower layers about changes in the connectivity state. This is particularly relevant to wireless interfaces. 2. the Command Service (CS) which provides a mechanism for controlling handovers. This includes the establishment, redirection, or removal of state in either the network or the mobile terminal, so that handovers occur smoothly. 3. the Information Service (IS) which provides additional handover- related information. This allows the network or host to make informed decisions of which handover operations to undertake either in response to an event, or when planning controlled or commanded handovers. Together, these services provide information about the various networks in range of an MN to support inter-technology handover decisions either in the MN or by the network. Handover commands to the MN can be delivered via the CS. Hepworth, et al. Expires September 7, 2006 [Page 15] Internet-Draft MIH Problem March 2006 Authors' Addresses Eleanor Hepworth Siemens Roke Manor Research Roke Manor Romsey, SO51 5RE UK Email: eleanor.hepworth@roke.co.uk Greg Daley Panasonic Digital Networking Laboratory 2 Research Way Princeton, New Jersey 08540 USA Phone: +1 609 734 7334 Email: greg.daley@research.panasonic.com Srivinas Sreemanthula Nokia Research Center 6000 Connection Dr. Irving, TX 75028 USA Email: srinivas.sreemanthula@nokia.com Stefano Faccin Nokia Research Center 6000 Connection Dr. Irving, TX 75229 USA Email: stefano.faccin@nokia.com Vivek Gupta Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 712 1754 Email: vivek.g.gupta@intel.com Hepworth, et al. Expires September 7, 2006 [Page 16] Internet-Draft MIH Problem March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hepworth, et al. Expires September 7, 2006 [Page 17]