Internet Engineering Task Force Mike Pierce Internet Draft Artel draft-pierce-tsvwg-assured-service-req-01.txt Don Choi October 20, 2004 DISA Expires April 20, 2005 Requirements for Assured Service Capabilities in Voice over IP draft-pierce-tsvwg-assured-service-req-01.txt Status of this memo By submitting this Internet-Draft, each author certifies 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 RFC 3668. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Copyright (C) Internet Society 2004. All rights reserved. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. Abstract Assured Service refers to the set of capabilities used to ensure that critical communications are established and remain connected. This memo describes the requirements for such capabilities in support of real-time communications for voice using specific networks such as those used by government agencies, but they could also be applied in commercial environments. Mike Pierce Expires April 20, 2005 [Page 1]
Internet Draft Requirements for Assured Service October 20, 2004 Table of Contents 0. History......................................................2 1. Introduction.................................................3 2. Background...................................................4 3. High Level Requirements......................................5 4. Functional Requirements......................................6 4.1. Precedence Level Marking................................6 4.2. Authentication/Authorization............................7 4.3. Preferential Treatments.................................7 4.3.1. Call Treatment...................................8 4.3.2. Packet Transfer Treatment........................8 4.3.3. Procedural Requirements..........................8 4.4. Diversion if Not Answered...............................9 4.5. Notifications...........................................9 4.6. Acknowledge by Preempted Party.........................10 4.7. Protection of Signaling/Routing Information from Disclosure.............................................10 4.8. Accounting.............................................11 4.9. Call Control Signaling Precedence......................11 4.10. Interworking..........................................11 5. Non-requirements............................................12 6. Security Considerations.....................................12 6.1. Authentication/authorization of User Access............12 6.2. Security of Signaling Information......................12 6.3. Security of Routing Data...............................13 6.4. Security of User Data..................................13 7. IANA Considerations.........................................13 8. References..................................................13 8.1. Normative References...................................13 8.2. Informative References.................................13 9. Acknowledgements............................................14 0. History Note: This section will be deleted before progressing as an RFC. This document has evolved through 3 different working groups: SIPPING, IEPREP, and TSVWG. This draft was originally submitted under SIPPING with 2 revisions and then in the IEPREP WG in order to ensure that the Assured Service requirements are considered along with those of the related IEPS discussions. It is not being submitted in TSVWG. (SIPPING) -00 Original draft (SIPPING) -01 Indicated informative material which would not be a part of final. Moved some to Annex. (SIPPING) -02 Removed material to draft-pierce-sipping-pref-treat- examples-00 and draft-pierce-sipping-assured-service-arch-00. Mike Pierce Expires April 20, 2005 [Page 2]
Internet Draft Requirements for Assured Service October 20, 2004 Added requirement to maintain records of use of service. (IEPREP) -00 - Updated references. - Added additional requirements related to preferential treatment in 4.3. - Added requirement in 4.8 for accounting records. - Added requirement in 4.9 that preferential treatment must be applied to call control signaling as well as to voice packets. - Added requirement in 4.10 for interworking between Assured Service and other priority schemes (e.g., IEPS) (IEPREP) -01 - Updated references - Moved informative material to Annex - Clarified requirement statements (IEPREP) -02 - clarified some text - made individual requirements into bulleted, named items instead of freeform text - moved additional informational material to a separate draft (TSVWG) -00 Resubmitted under TSVWG. - updated references - added requirement that preempted parties must not be notified of why and where preemption occurred - added new requirement that higher precedence call never be given lower preference treatment than lower precedence call. - added new section (5) on non-requirements to clarify the relationship of these requirements with complementary requirements for providing a specific QoS. (TSVWG) -01 - Minor editorial corrections. 1. Introduction Throughout many decades of evolution of the telephony network and its supporting protocols, there has been a need to provide preferential services and functionality to a limited subset of the users and calls within a network or domain in order to ensure completion of important calls that transit congested interconnections. Examples of this need have been in support of emergency traffic for natural disasters, network restoration traffic, and high priority traffic in a private networks. Provision of the required capabilities in the signaling protocols and within the switching systems has been defined in a number of national and international standards, most notably a service referred to as Multi-Level Precedence and Preemption (MLPP) as defined in an American National Standard [T1.619] in the US and in corresponding ITU-T Recommendations [I.255.3, Q.735.3, and Q.955.3]. In addition, a service called High Probability of Completion (HPC) was defined in Mike Pierce Expires April 20, 2005 [Page 3]
Internet Draft Requirements for Assured Service October 20, 2004 the US [T1.631] and, most recently, two ITU-T Recommendations define the requirements for the International Emergency Preference Scheme (IEPS) [E.106] and the International Preference Scheme for Multimedia Service in Support of Disaster Relief Operations [draft F.706]. Other drafts submitted to the IETF have addressed aspects of IEPS. Among these are the Framework for ETS for Telephony over IP [ETS]. MLPP was the solution for providing Assured Service capabilities within the circuit switched environment. It is essential that equivalent Assured Service capabilities are defined and implemented for the packet-based, connectionless environment of IP, and specifically SIP. Without these capabilities, SIP can not be used for those applications which require these capabilities. This memo builds on these references and identifies the specific requirements for Assured Service capabilities for Voice applications in support of these specific types of environments. Although this memo covers only Voice, there will be similar requirements for "Assured Service" capabilities for all other forms of communication. The term "Assured Service" is used to refer to the required capabilities, rather than the previous term of "MLPP" or the related but different terms of IEPS or ETS, since the envisioned set of capabilities and protocols to achieve them are not expected to be exactly the same as those other services. For example, IEPS/ETS may not have a requirement for preemption at any point in the SIP session, whereas Assured Service may have such a requirement at both the session endpoint and in networks between endpoints. Although these requirements are derived from previous government applications, many of the same requirements and capabilities may be applied for non-government networks, for example, in support of commercial network restoration efforts. A presentation in the TEWG during the August 2001 meeting demonstrated real-life situations from the past in which total network failures required extensive efforts, presumably including communication via other unaffected networks, to bring the affected network back on line. If one considered a situation in which the very network which had failed was needed to carry the network management traffic required to get it back on line, it would be hard to imagine how it could ever be brought back up in the face of overwhelming customer attempts. Capabilities would be required to give priority to the network management traffic, even to the extent of blocking all non-emergency traffic for a period of time. 2. Background In the circuit switched environment, specific circuits or channels are used for each call. These are typically 64 kbps channels which were normally part of a Time Division Multiplexed (TDM) transmission structure. These transmission channels are almost always Mike Pierce Expires April 20, 2005 [Page 4]
Internet Draft Requirements for Assured Service October 20, 2004 interconnected and switched by Time Division Switching technology (often referred to as "TDM switching"). More recent developments use packet/cell based transport instead of dedicated 64 kbps channels, often coupled with packet/cell-based switching, however, the effect is the same. There is still a dedicated transport capacity assigned for each call. Assured Service in the circuit switched environment may be provided by one or more of the following techniques. - Giving priority to return of dial tone (IEPS - note) - Marking of signaling messages for better handling, for example, being last to be dropped in case of congestion in the signaling network (HPC) - Extra routing possibilities for higher priority calls (IEPS - note) - Queuing for network resources (HPC) - Exemption from restrictive management controls such as hard-to- reach codes and code gapping (IEPS - note) - Reservation of specific facilities (trunks) for higher priority traffic (IEPS - note) - Higher priority calls may preempt existing lower priority calls, causing the network to release the lower priority call to free up resources for immediate reuse by the higher priority call (MLPP) (Note: Capabilities included within IEPS [E.106] are listed here for reference only but are not dealt with further in this document.) Identification of traffic authorized to use one or more of these techniques may be via the following or similar methods: - Calls placed from physical lines or devices authorized for signaling a higher priority for a call - Calls placed to specific telephone numbers or blocks of numbers - Entry of a special ID code and PIN from any telephone device to identify that this call should receive special service. - Use of a "smartcard" 3. High Level Requirements While the existing requirements and capabilities have been developed with the circuit switched environment in mind, many are directly Mike Pierce Expires April 20, 2005 [Page 5]
Internet Draft Requirements for Assured Service October 20, 2004 applicable to the packet environment and specifically the Voice over IP application being defined using SIP. Some of the capabilities need to be adapted or modified for application in the packet mode environment. In addition, there will likely be new techniques which can be defined specifically for the SIP case. At a high level, the Assured Service requirements can be stated as the need to ensure that mission critical voice-mode calls get set up and remain connected. As a result of this, calls designated as being at a lower precedence level are presumed to be less important and may be adversely affected by various techniques used to provide the preferential treatment to the important, mission-critical calls. For example, the lower precedence calls may temporarily experience reduced quality as their packets are discarded. This memo does not address issues related to incorrect assignment of the authority to use precedence levels or the incorrect use of levels, for example, if the user can not or does not specify a high enough precedence level for the nature of the call. (While this memo focuses on Voice over IP, there should be a consideration of the impact/solutions for other media flows which carry mission critical communication, for example, file transfers, video, and instant messaging. Most of the functional requirements can be equally applied to these other media.) 4. Functional Requirements While the functional requirements for Assured Service detailed here are specifically those needed to support the US government requirements for the Defense Switched Network (DSN), it is believed that at least a subset of those requirements are applicable to other government networks as well as some commercial (non-government) networks. This memo concentrates on those portions mentioned in Section 2 which are derived from the requirements for MLPP as defined in the American National Standard [T1.619]. The basic requirements are defined as follows; 4.1. Precedence Level Marking Each call within an Assured Service network is labeled with a precedence level as determined by the calling party at the beginning of the call. If not chosen by the caller, the default is to the lowest precedence level. The called party does not have any control over the precedence level for a call. To meet this general functional requirement, the following specific requirements apply: Mike Pierce Expires April 20, 2005 [Page 6]
Internet Draft Requirements for Assured Service October 20, 2004 Prec-1 It MUST be possible to assign each user the highest precedence level they are entitled to use. Prec-2 It MUST be possible for the originator of a call to select and signal one of the multiple precedence levels for the call, with the call defaulting to the lowest level if none is specified. The precedence of each call is independent, that is, it is selected for each call. Note: One current network for which this is intended uses five levels, but other numbers of levels are possible. In no case is it necessary to support more than 15 levels. Prec-3 It MUST be possible to carry this call associated precedence level unchanged though the IP network as a part of the Call Control Signaling (for example, in SIP). Prec-4 It MUST be possible to deliver the originally signaled precedence level to the called party. 4.2. Authentication/Authorization Not all users are allowed to signal higher precedence levels. Therefore, a means is necessary to determine and allow only the authorized users the ability to signal these higher precedence levels. The following specific requirements apply: A&A-1 It MUST be possible to verify that the calling party is authorized to use the Assured Service and the requested precedence level value if higher than the lowest. A&A-2 It MUST be possible to take the appropriate action if the calling party attempts to use a level which is higher than authorized. The preferred action is to reject the call, and send an indication of the reason to the caller. 4.3. Preferential Treatments Since it is expected that congestion may occur in various parts of a network, it is required that one or more preferential treatments can be applied to any call which is signaled with a higher precedence level relative to already existing calls if the packet flow for that call would cause congestion. This is required to manage the effects of congestion, for example, delay, delay variation, and loss, at key points. Pref-1 Under all circumstances, a higher precedence call MUST NOT be provided a lower level of preferential treatment for call setup and retention than a lower precedence call. In some cases it MAY be no better. The actual measures applied to provide preferential treatment depend on the situation, but support for the following are required: Mike Pierce Expires April 20, 2005 [Page 7]
Internet Draft Requirements for Assured Service October 20, 2004 4.3.1. Call Treatment Pref-2 It MUST be possible to block setup of a new call if that call would cause congestion. This is called Call Admission Control (CAC). ("Congestion" here means exceeding some engineered limit for traffic.) Pref-3 It MUST be possible to apply different limits for CAC for various call precedences, that is, in some cases, a higher precedence call may be allowed to be established while a lower precedence would not under the identical conditions. Pref-4 It MUST be possible for an endpoint to release an existing (lower precedence) call in favor of completing a new call signaled to it (at a higher precedence). Pref-5 It MUST be possible for a network node to release an existing network resource reservation in favor of a higher precedence call. This might involve releasing one or more reservations in the process of providing enough bandwidth for the new packet flow. Pref-6 Preferential treatment SHOULD NOT be provided through any scheme of dedicated or pre-reserved bandwidth or resources. Pref-7 In those cases in which such dedication or reservation of bandwidth or resources is used, when such dedicated or pre- reserved bandwidth or resources have been consumed by the high precedence traffic, further traffic of that same high precedence MUST NOT be provided worse treatment than any of the lower precedence levels. 4.3.2. Packet Transfer Treatment Pref-8 It MUST be possible at any point where congestion occurs to determine which packets require preferential treatment over other packets, including for voice media packets. Pref-8 It MUST be known by the device experiencing congestion what to do with two or more competing packets. Pref-10 It MUST be possible for a network node to discard packets for lower precedence calls in favor of those for higher precedence calls. Pref-11 Media packets MUST NOT starve all potential bandwidth of a node interface, thus not allowing signaling packets through that same interface. (Note that this requirement is not unique to Assured Service.) 4.3.3. Procedural Requirements Mike Pierce Expires April 20, 2005 [Page 8]
Internet Draft Requirements for Assured Service October 20, 2004 Pref-12 It MUST be possible to detect various congestion conditions which might require preferential treatments to be applied. Pref-13 Preferential treatment measures used to manage congestion MUST be automatic and MUST NOT have to be manually "turned on" in reaction to a congestion event of any kind. Pref-14 Upon onset of congestion, it MUST NOT be necessary to perform configuration functions, exchange a significant amount of information between network entities, or perform extensive calculations in order for effective control mechanisms to began operating. The information required to perform the various preferential treatment procedures SHOULD be in place in each network entity before congestion in encountered. Pref-15 The application of preferential treatment on an individual call MUST not require a significant delay to activate or perform (such that it would be noticeable to the party originating a precedence call). Possible methods of providing Preferential Treatment using the provisions of this memo, as well as other existing IETF protocols, are described in [Pierce1]. 4.4. Diversion if Not Answered In situations is which the called party is busy and can not be preempted or in which the called party does not answer, it is required to provide a diversion service to a predetermined address for any call signaled with a precedence level above the lowest. The following apply: Div-1 If a precedence call (one higher than the lowest level) is blocked by the called party being busy with a call of equal or higher precedence, the call MUST be diverted to a predetermined alternate party. Div-2 If a precedence call is not answered within a designated time, the call MUST be diverted to a predetermined alternate party. While the actual requirement previously was for a single "diverted- to" address for an entire "switch", this is not feasible in the IP case, so the specification of the "diverted-to" address is assumed to be per called user. In general, it is expected that this diversion capability will operate similar to a normal "Call Forwarding on No Answer" service. 4.5. Notifications It is required that a user who is currently on a call and is preempted either at the remote end or in between be notified of this Mike Pierce Expires April 20, 2005 [Page 9]
Internet Draft Requirements for Assured Service October 20, 2004 event. Generally a distinct tone is provided, after which the call is released. Noti-1 All preempted parties MUST be provided with a distinct notification informing them that their call has been preempted. Noti-2 Preempted parties MUST NOT be provided with any indication of the reason for the preemption or where the preemption occurred. Specific notifications are required to inform the calling party of reasons for a precedence call not being successful. They are the following: Noti-3 When a user attempts to use a precedence level to which they are not authorized, the caller MUST be notified of this fact. The notification MUST NOT provide an indication of what level is authorized. Noti-4 When a precedence call can not be established due to the called party being busy at an equal or higher precedence with no alternate party diversion possible or due to no preemptable resources in the network, the caller MUST be notified of this fact. The caller MUST NOT be notified what precedence level would be necessary to successfully complete the call. 4.6. Acknowledge by Preempted Party When a user is involved in a call and that call is preempted in favor of establishing a higher precedence call with that same user, the user is required to actively accept this new call before the media is connected. This is no different from normal calls. Ack-1 When an existing call has been preempted for delivery of a higher precedence call to the same party, the party MUST acknowledge the preemption before the new call is connected. That is, there MUST be a positive acknowledgement before any audio information is transferred in either direction. 4.7. Protection of Signaling/Routing Information from Disclosure Although protection is not actually an integral part of the Assured Service functionality, it is specifically identified here since this capability is generally required in those networks which are assumed to be the primary users of Assured Service. Prot-1 Sensitive information MUST NOT be made available to non- secure portions of the network or to any non-secure network through which the traffic passes. Prot-2 Sensitive information MUST NOT be accessible by users Mike Pierce Expires April 20, 2005 [Page 10]
Internet Draft Requirements for Assured Service October 20, 2004 connected to the network. Prot-3 Precedence information regarding each call (as well as the other information such as calling/called party identity) SHOULD be protected from disclosure. This non-disclosure requirement especially applies to information which is used to control link state routing protocols based on knowledge of the current traffic load at each precedence level on each route or through each router. 4.8. Accounting Proper administration of the Assured Service capability requires that use of the service can be reviewed after the fact for potential abuse. Acct-1 It MUST be possible for the appropriate records to be kept of calls made, including the calling and called parties' identities, time of the call, duration, and the precedence level used. This is similar to the requirements for Call Detail Recording (CDR) for billing purposes for other services in a commercial environment. 4.9. Call Control Signaling Precedence Since it competes for the same transport resources as the voice packets, it is essential that preferential treatments can be applied to the call control signaling. Specifically the following apply: CC-1 The call control signaling MUST NOT adversely affect the voice (e.g., by introducing excessive packet delay variation due to extremely long messages). CC-2 The voice traffic MUST NOT significantly delay important call control signaling (e.g., by preventing release messages from getting through). 4.10. Interworking Although Assured Service will likely be the only priority scheme within many network using it, it still needs to interwork with other schemes. Int-1 Assured Service calls MUST interwork with other priority schemes which are being provided within the same network, such as the one defined for [ETS]. This includes the following two cases: a. both types of traffic may exist in a single network, for example, an IEPS call may be originated from within a network which also supports "Assured Service" calls. Procedures to determine the relative priority and the Mike Pierce Expires April 20, 2005 [Page 11]
Internet Draft Requirements for Assured Service October 20, 2004 resulting preferential treatment are required. b. a network which provides "Assured Service" needs to support interworking of calls to and from a network which provides another scheme such as IEPS as well as another network which provides "Assured Service". Mapping between the precedence levels of the two networks must be supported. 5. Non-requirements Although it is always desirable to provide the best quality of service with regards to transmission performance (delay, distortion, etc.), it is not a specific requirement that higher precedence call be given a better QoS than lower. Neither is it an absolute requirement that any single call be guaranteed a specific QoS value, for example, and MOS score. In all cases, the requirement to setup a high precedence call takes priority over any complementary requirements to provide a specific QoS level. 6. Security Considerations 6.1. Authentication/authorization of User Access There is a need within SIP to authenticate/authorize all access to capabilities, since virtually any function could be misused, resulting in harm to the network or to other users. Because Assured Service is intended to provide an authorized user with better service than other users, including the potential of actually preempting resources, it is even more important to authenticate/authorize the user's access to the Assured Service capabilities. However, the requirement already exists for all cases, not just Assured Service, therefore the solution is not unique to Assured Service. 6.2. Security of Signaling Information The need to protect signaling information from disclosure is independent from the provision of Assured Service. Many networks have long been built on the premise that such information needs to be protected. Bulk encryption of signaling links (as well as the user data channels) between secure switches provided much of this protection. In addition, the Signal Transfer Points of the SS#7 network could be physically secured against unauthorized access. It should be noted that commercial networks have recognized the need for the same level of protection previously only applied to various government networks. In the IP environment, the signaling packets traverse many routers and could be accessed by unauthorized persons at any one of them. While the contents of the individual signaling messages could be hidden by encryption of the request and response for end-to-end protection of information, the IP header must be visible to intermediate routers. It is preferable to not require decryption/ Mike Pierce Expires April 20, 2005 [Page 12]
Internet Draft Requirements for Assured Service October 20, 2004 encryption at each router. The approach has been to encrypt the contents of the IP packets (the signaling message) but not the IP headers which are needed by the routers. However, the IP headers themselves may contain sensitive information such as precedence level and ways to identify the called party, or least the location of the called party. 6.3. Security of Routing Data In IP today, there is no Routing Data to secure. When enhancements are made to provide for route selection, especially to route around congestion, procedures must be developed to prevent unauthorized access to that data. It is presumed that procedures will also be required to prevent unauthorized modifications. 6.4. Security of User Data While there may typically be a greater need to protect the user data (voice packets) of a call which utilizes priority, since such a call may often be more sensitive than calls for which no priority is specified, this requirement is not unique to the Assured Service, and therefore no specific requirements are given here. The same requirements exist for non-Assured Service traffic. 7. IANA Considerations There is no IANA involvement in support of Assured Service beyond what is described for the Resource Priority Header [Resource]. 8. References 8.1. Normative References None 8.2. Informative References [T1.523] ANSI T1.523-2001, "Telecommunications Glossary". [T1.619] ANSI T1.619-1992 (R1999) and ANSI T1.619a-1994 (R1999), "Multi-Level Precedence and Preemption (MLPP) Service, ISDN Supplementary Service Description". [T1.631] ANSI T1.631-1993 (R1999), "Telecommunications - Signalling System No. 7 (SS7) - High Probability of Completion (HPC) Network Capability". [E.106] ITU-T Recommendation E.106 (2003), "International Emergency Preference Scheme for Telecommunications for Disaster Relief Operations(IEPS)". Mike Pierce Expires April 20, 2005 [Page 13]
Internet Draft Requirements for Assured Service October 20, 2004 [F.706] ITU-T Recommendation F.706 (draft), "International Preference Scheme for Multimedia Service in Support of Disaster Relief Operations and Mitigation". [I.255.3] ITU-T Recommendation I.255.3 (1990), "Multilevel precedence and preemption service (MLPP)". [Q.735.3] ITU-T Recommendation Q.735.3 (1993), "Description for community of interest supplementary services using SS No. 7 - Multilevel precedence and preemption (MLPP)". [Q.955.3] ITU-T Recommendation Q.955.3 (1993), "Description for community of interest supplementary services using DSS1 - Multilevel precedence and preemption (MLPP)". [RFC3261] "SIP: Session Initiation Protocol", J. Rosenberg, et al, June 2002. [ETS] draft-ietf-ieprep-framework-09, "Framework for Supporting ETS in IP Telephony", Ken Carlberg, et al, Feb 2004. [Pierce1] draft-pierce-tsvwg-pref-treat-examples-01, "Examples for Provision of Preferential Treatment in Voice over IP", Mike Pierce, et al, October 2004. [Resource] draft-ietf-sip-resource-priority-04, "SIP Communications Resource Priority Header", Henning Schulzrinne and James Polk, August 2004. 9. Acknowledgements The authors would like to thank James Polk and Fred Baker for the many suggestions made to improve this document throughout its development. Authors' Addresses Michael Pierce Artel 1893 Preston White Drive Reston, VA 20191 Phone: +1 410.817.4795 Email: pierce1m@ncr.disa.mil Don Choi DISA 5600 Columbia Pike Falls Church, VA 22041-2717 Phone: +1 703.681.2312 Email: choid@ncr.disa.mil Mike Pierce Expires April 20, 2005 [Page 14]
Internet Draft Requirements for Assured Service October 20, 2004 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. Intellectual Property 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Mike Pierce Expires April 20, 2005 [Page 15]