Network Working Group M. Kelkar Internet Draft T. Mistretta Expires: September 2005 P. Howard Juniper Networks V. Jain Riverstone Networks March 17, 2005 PPP over L2TP Tunnel Switching draft-ietf-l2tpext-tunnel-switching-05.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Distribution of this document is unlimited. Please send comments to the Layer Two Tunneling Protocol Extensions (l2tpext) working group at l2tpext@ietf.org. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Kelkar, et al. Expires September 17, 2005 [Page 1] Internet-Draft PPP over L2TP Tunnel Switching March 2005 Abstract PPP over L2TP Tunnel Switching, also called L2TP Multihop, is the process of forwarding PPP payload from an L2TP session to another L2TP session over a different tunnel. It facilitates moving the logical termination point of an L2TP session, based on layer 2 characteristics or administrative policies, to different LNS. This document introduces the L2TP tunnel switching nomenclature and defines the behavior of standard AVPs in tunnel switching deployment. The scope of this document is limited to the discussion of switching PPP frames over L2TPv2 or L2TPv3 tunnels. Table of Contents 1. Introduction...................................................3 2. L2TPv2 to L2TPv3 switch........................................3 3. AVP Behavior...................................................4 3.1. IETF Vendor AVPs..........................................5 4. Loop Detection.................................................9 5. CDN Messages and L2TP tunnel Switching........................10 6. IANA Considerations...........................................10 7. Security Considerations.......................................11 8. Acknowledgments...............................................11 9. References....................................................12 9.1. Normative References.....................................12 9.2. Informative References...................................12 Author's Addresses...............................................13 Intellectual Property Statement..................................13 Disclaimer of Validity...........................................14 Copyright Statement..............................................14 Acknowledgment...................................................14 Terminology Tunnel Switching Aggregator (TSA): These are the devices that switch the layer 2 payload on an incoming L2TP session/tunnel on to another L2TP session/tunnel. TSA functions as an LNS for the inbound tunnel and as a LAC for the outbound tunnel. Inbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LNS. Outbound Tunnel: L2TP Tunnel on TSA where TSA is acting as LAC. L2TP, as defined in [1], is now referred to as "L2TPv2," while the extended version defined in [2] is referred to as "L2TPv3". The remainder of this document will refer simply to L2TP in general, Kelkar, et al. Expires September 17, 2005 [Page 2] Internet-Draft PPP over L2TP Tunnel Switching March 2005 unless contrasting specific features of L2TPv2 or L2TPv3, which may differ in function. 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]. 1. Introduction L2TP allows processing of PPP packets to be divorced from the termination of the layer 2 circuit. L2TP tunnel switching facilitates moving the termination point of a PPP session further on to another LNS that is possibly unknown to the first LAC. It does so by re- tunneling the PPP session within another L2TP tunnel to a different LNS. The knowledge of whether to switch a PPP session to another L2TP tunnel can be static or dynamic (for example, during PPP session establishment). PPP LAC TSA LNS User [LNS LAC] |---- PPP----| | | | |---- PPP/L2TP ----| | | |-- PPP --| | | |----- PPP/L2TP -----| |<----- tunnel switching ----->| Figure 1: L2TP tunnel Switching The figure above presents a typical tunnel switching scenario for incoming calls. The user opens a PPP session to a LAC, which tunnels the session to TSA as defined by L2TP protocol. The TSA, based on the local policies, determines if the incoming session should be further tunneled. If the TSA decides to tunnel the session further, then, for every such session it initiates another session onto another L2TP tunnel originating on the TSA terminating on a different LNS. Once the session is established, the data packets are switched from an incoming tunnel to a corresponding outgoing tunnel. 2. L2TPv2 to L2TPv3 switch If inbound and outbound tunnels use different versions of L2TP protocol at TSA i.e. if it involves a 'version switch', then it must adapt the data encapsulation change. Kelkar, et al. Expires September 17, 2005 [Page 3] Internet-Draft PPP over L2TP Tunnel Switching March 2005 +------------------------+ +----------------------------+ | PPP Tunneled Frame | | PPP Tunneled Frame | | | | | +------------------------+ +----------------------------+ | | | PPP Specific Sublayer | | L2TPv2 Data Header | | (Ref [6] section 4.1) | | over UDP | +----------------------------+ | (Ref [1] section 3.1) | | L2TPv3 Data Session | | | | Header over UDP or IP | | | | (Ref [2] section 4.1.1.1 | | | | and 4.1.2.1) | +------------------------+ +----------------------------+ | L2TPv2 Data Channel | | L2TPv3 Data Channel | | (unreliable) | | (unreliable) | +------------------------+----+----------------------------+ | Packet-Switched Network (UDP, IP, FR, MPLS, etc.) | +----------------------------------------------------------+ Figure 2: L2TPv2 to L2TPv3 data encapsulation switch When PPP frames, which are encapsulated in the L2TPv2 header, are received at the TSA and are switched to outbound tunnel using L2TPv3, then L2TPv2 headers are stripped and PPP frame is encapsulated with the PPP sublayer followed by the L2TPv3 data header and forwarded over the session. The version switch may involve a transport change i.e. L2TPv3-IP to L2TPv2-UDP. TSA MUST be able to adapt to such change. 3. AVP Behavior An incoming AVP MUST be either handled in four ways - it could be relayed, dropped, regenerated, or stacked. They are defined as follows. - RELAYED AVP: (also known as pass-through AVP) AVP is forwarded transparently if it was present in the incoming message. - DROPPED AVP: AVP is dropped if it was present in the incoming message. All the L2TPv3 only AVPs are dropped when switched onto L2TPv2 tunnel. - REGENERATED AVP: AVP in the inbound message is ignored upon receipt. A new AVP is regenerated for the outbound message based on the local policy at the TSA. The local policy may or may not use the Kelkar, et al. Expires September 17, 2005 [Page 4] Internet-Draft PPP over L2TP Tunnel Switching March 2005 received AVP to regenerate the new value. The regenerated value may or may not match with the received AVP value. - STACKABLE AVP: Multiple instances of this AVP exist in the incoming message, each representing a hop in the tunnel switched path in order from first to last. When a TSA receives it, all the instances of AVP are copied as-is to the next hop. A locally generated AVP is appended to the outbound message. If no value is appropriate then an AVP with a null value, as determined by the AVP definition, MUST be appended. However, If TSA couldn't copy all of incoming AVPs then it MUST not copy any one of them and drop all of the instances. If this is an AVP required to establish the tunnel or session and TSA cannot copy all of the stacked AVPS, then TSA MUST terminate the connection. 3.1. IETF Vendor AVPs This section defines the behavior of AVPs according to the guidelines in section 3. It describes the behavior of AVPs defined in [1], [2], [3], [4], and [5]. All the future AVP extensions MUST define AVP behavior for tunnel switching. An optional AVP whose behavior is defined as RELAYED, MUST be RELAYED only if the AVP exists in the inbound message. Hence the behavior for such AVP is stated as 'RELAYED if present in the inbound message'. An optional AVP whose behavior is defined as REGENERATED, could be DROPPED from the outbound message at the TSA's discretion. Hence the behavior for such AVP is stated as 'REGENERATED or DROPPED' Message Type (All Messages) - MUST be REGENERATED Random Vector (All Messages) - MUST be either REGENERATED or DROPPED. Result Code (CDN, StopCCN) - MUST be either RELAYED or REGENERATED based on recommendations discussed in section 5. In case of version switch, if L2TPv3 Result Codes and Error Codes are RELAYED then they MUST be translated into general error (Result Code 2, Error Code 0). Protocol Version (SCCRQ, SCCRP) - MUST be REGENERATED. This would allow TSA to switch sessions when inbound and outbound tunnels use different versions of the L2TP protocol. Framing Capabilities (SCCRQ, SCCRP) - MUST be REGENERATED. Bearer Capabilities (SCCRQ, SCCRP) - MUST be either REGENERATED or DROPPED. Kelkar, et al. Expires September 17, 2005 [Page 5] Internet-Draft PPP over L2TP Tunnel Switching March 2005 Tie Breaker (SCCRQ) - MUST be either REGENERATED or DROPPED. Firmware Revision (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED. Host Name (SCCRP, SCCRQ) - MUST be REGENERATED. Vendor Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED. Assigned tunnel ID (SCCRP, SCCRQ, StopCCN) - MUST be REGENERATED. Receive Window Size (SCCRQ, SCCRP) - MUST be either REGENERATED or DROPPED. Challenge (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED. Challenge Response (SCCCN, SCCRP) - MUST be either REGENERATED or DROPPED. Q.931 Cause Code (CDN) - MUST be either RELAYED if present in the inbound message or DROPPED. Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) - MUST be REGENERATED. Call Serial Number (ICRQ, OCRQ) - MUST be RELAYED. It would best serve the intended purpose of this AVP and facilitate easier debugging. Minimum BPS (OCRQ) - MUST be RELAYED. Maximum BPS (OCRQ) - MUST be RELAYED. Bearer Type (ICRQ, OCRQ) - MUST be RELAYED if present in the inbound message. Framing Type (ICCN, OCCN, OCRQ) - MUST be RELAYED. Called Number (ICRQ, OCRQ) - MUST be RELAYED if present in the inbound message. Calling Number (ICRQ) - MUST be RELAYED if present in the inbound message. Sub-Address (ICRQ, OCRQ) - MUST be RELAYED if present in the inbound message. Kelkar, et al. Expires September 17, 2005 [Page 6] Internet-Draft PPP over L2TP Tunnel Switching March 2005 Tx Connect Speed (ICCN, OCCN) - MUST be RELAYED. In case of version switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type 74). Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED if present in the inbound message. In case of version switch, TSA should relay it as a Rx Connect Speed AVP (Attribute Type 75). Physical Channel ID (ICRQ, OCRP) - MUST be either RELAYED if present in the inbound message, REGENERATED, or DROPPED. Private Group ID (ICCN) - MUST be RELAYED if present in the inbound message. Sequencing Required (ICCN, OCCN) - MUST be either REGENERATED or DROPPED. Proxy LCP AVPs (ICCN) - All the Proxy LCP AVPs (Initial Received LCP CONFREQ, Last Sent LCP CONFREQ and Last Received LCP CONFREQ) MUST be either all RELAYED, all REGENERATED or all DROPPED. If an AVP is REGENERATED then it would mean the LCP was renegotiated; whereas, RELAYED conveys the fact that it was passed along and was not renegotiated. Proxy Authentication AVPs (ICCN) - All the Proxy Authentication AVPs (Proxy Authen Type, Proxy Authen Name AVP, Proxy Authen Challenge Proxy Authen ID and Proxy Authen Response AVP) MUST be either all RELAYED, all REGENERATED, or all DROPPED. If an AVP is REGENERATED then it would mean the Authentication was renegotiated; whereas, RELAYED conveys the fact that it was passed along and was not renegotiated. Call Errors (WEN) - MUST be RELAYED. ACCM (SLI) - MUST be RELAYED. PPP Disconnect Cause AVP (CDN) (Ref [3])- MUST be either RELAYED if present in the inbound message or DROPPED if it's not supported. LCP Want Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if present in the inbound message or DROPPED if it's not supported. LCP Allow Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if present in the inbound message or DROPPED if it's not supported. Control Connection DS AVP (SCCRQ, SCCRP) (Ref [4]) - MUST be either RELAYED if present in the inbound message or DROPPED if it's not Kelkar, et al. Expires September 17, 2005 [Page 7] Internet-Draft PPP over L2TP Tunnel Switching March 2005 supported. The value of this AVP could be chosen based on 'PHB Code' used (or to be used) on the tunnels, which the TSA is going to be switching sessions to. TSA need not use same PHB-to-DSCP mappings on an incoming tunnel and outgoing tunnel. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either RELAYED if present in the inbound message or DROPPED if it's not supported. The value of this AVP could be chosen based on 'PHB Code' used (or to be used) on the tunnels, which the TSA is going to be switching sessions to. TSA need not use same PHB-to-DSCP mappings on an incoming tunnel and outgoing tunnel. Extended Vendor ID AVP (Version 3) (All Messages) - MUST be either REGENERATED or DROPPED. Message Digest AVP (Version 3) (All Messages) - MUST be either REGENERATED or DROPPED. Router Id AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED or DROPPED. Assigned Control Connection Id AVP (Version 3) (SCCRQ, SCCRP, StopCCN) - MUST be either REGENERATED or DROPPED. Pseudowire Capabilities List AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED or DROPPED. Local Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED. Remote Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED. Assigned Cookie AVP (Version 3) (ICRQ, ICRP, OCRQ, OCRP) - MUST be either REGENERATED or DROPPED. Remote End Id AVP (Version 3) (ICRQ, OCRQ) - MUST be either REGENERATED or DROPPED. Session Tie Breaker AVP (Version 3) (ICRQ, OCRQ) - MUST be either REGENERATED or DROPPED. Pseudowire Type AVP (Version 3) (ICRQ, OCRQ) - MUST be either REGENERATED or DROPPED. L2-specific Sublayer AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) - MUST be either REGENERATED or DROPPED. Kelkar, et al. Expires September 17, 2005 [Page 8] Internet-Draft PPP over L2TP Tunnel Switching March 2005 Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) - MUST be either REGENERATED or DROPPED. Circuit Status AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) - MUST be either REGENERATED or DROPPED. Preferred Language AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED or DROPPED. Tx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) MUST be either RELAYED, REGENERATED or DROPPED. In case of version switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type 24). If value is greater than 4 octets, it SHOULD be dropped. Rx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) MUST be either RELAYED if present in the inbound message, REGENERATED or DROPPED. In case of version switch, TSA should relay it as a Rx Connect Speed AVP (Attribute Type 38). If value is greater than 4 octets, it SHOULD be dropped. TSA Id AVPs (defined in this document) - MUST be STACKED. The local TSA Id AVP is stacked to the incoming set of TSA Id AVPs. 4. Loop Detection The TSA ID AVP, Attribute Type TBD, could be used to detect if a session is looping in an L2TP tunnel switched network. This AVP MUST be STACKED. If this AVP was received in an incoming control packet (ICRQ, OCRQ) then the TSA MUST check to see if its own TSA Id (a configured value) is present in the stack of incoming TSA ID AVPs. Upon finding a match, the TSA MUST respond with a CDN carrying a Result Code indicating 'Loop Detected' TBD, and optionally a description indicating the loop condition. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSA Id ... (maximum 64 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSA Id is a configured value (human readable string) with a maximum length of 64 octets. It is administratively controlled to ensure its Kelkar, et al. Expires September 17, 2005 [Page 9] Internet-Draft PPP over L2TP Tunnel Switching March 2005 uniqueness among all the inter-connected LACs, LNSs and TSAs. If no value is configured then the AVP value MUST be of length 0. This AVP MUST be either hidden (the H-bit can be either 0 or 1). The M-bit for this AVP MUST be set to 0. 5. CDN Messages and L2TP tunnel Switching To identify the error conditions explicitly in tunnel switching setup, new set error codes are defined. Existing error codes are not used because they might trigger an unwarranted behavior depending upon why it was generated. Error codes are defined as follows: Upstream unreachable (Result Code 2, Error Code TBD) - TSA MUST generate a CDN message with this Error Code for the LAC, if upstream LNS is unreachable and no other alternative paths are available as determined by the local policy. Upstream busy (Result Code 2, Error Code TBD) - TSA MUST generate a CDN message with this Error Code for the LAC, if upstream LNS disconnects the outgoing call with an error code 'TSA Busy' or other indications from upstream indicates the upstream is too busy to take more sessions and no other alternative paths are available as determined by the local policy TSA busy (Result Code 2, Error Code TBD) - TSA MUST generate a CDN message with this Error Code for the LAC, if it is congested or temporarily running out of resources. The TSA MUST generate a CDN with an error code for the LAC, indicating the failure to establish the call. In the case of multiple levels of TSAs, this error code needs to be propagated back until it reaches either the original LAC or an intermediate TSA, which has an alternate path. On the receipt of these error codes, local policy on the LAC or the intermediate TSA should handle the fallback and use it for the congestion recovery design. 6. IANA Considerations This document requires following parameters to be assigned through IETF Consensus [RFC 2434] as indicated in Section 5 of [1]. These are: AVP - Loop Detection AVP (Section 4) Result Code - Loop Detection (Section 4) Kelkar, et al. Expires September 17, 2005 [Page 10] Internet-Draft PPP over L2TP Tunnel Switching March 2005 Error Codes - Upstream unreachable, Upstream busy and TSA busy (Section 5). 7. Security Considerations TSA Id AVP could reveal the set of nodes that a given L2TP session is traversing in the network. AVP hiding, described in [1] MUST be either used to help mitigate this, though it is not widely regarded as cryptographically secure. [RFC 3193] describes a more robust method for securing L2TP in general, and should be used to encrypt all L2TP messages if access to the information sent within the AVPs described in this document is of concern. 8. Acknowledgments Authors gratefully acknowledge the valuable contributions of: Mark W. Townsley, Reinaldo Penno, Ly Loi and Marc Eaton-Brown. Kelkar, et al. Expires September 17, 2005 [Page 11] Internet-Draft PPP over L2TP Tunnel Switching March 2005 9. References 9.1. Normative References [1] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999. [2] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol (Version 3)", draft-ietf-l2tpext-l2tp-base-15.txt, December 2004. [3] RFC 3145, Verma, et. al. "L2TP Disconnect Cause Information", July 2001. [4] RFC 3308, P. Calhoun, W. Luo, D. McPherson, K. Peirce, "Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension", November 2002. [5] RFC 3437, W. Palter, W. Townsley, "Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation", December 2002. [6] J. Lau, M. Townsley, A. Valencia, G. Zorn, M. Verma, I. Goyret, G. Pall, A. Rubens, B. Palter, "PPP Tunneling Using Layer Two Tunneling Protocol" work in progress, draft-ietf-l2tpext-l2tp- ppp-01.txt, November 2001. [7] RFC 1661, W. Simpson, "The Point-to-Point Protocol (PPP)", STD 51, July 1994. 9.2. Informative References [8] L. Martini, M. Townsley, C. Metz, T. Nadeau, M. Duckett, V. Radoaca, "Pseudo Wire Switching" work in progress, draft- martini-pwe3-pw-switching-01.txt, October 2004. Kelkar, et al. Expires September 17, 2005 [Page 12] Internet-Draft PPP over L2TP Tunnel Switching March 2005 Author's Addresses Mahesh Kelkar Juniper Networks 10 Technology Park Drive Westford, MA 01886 Phone: +1 978 589 0535 Email: mkelkar@juniper.net Tom Mistretta Juniper Networks 10 Technology Park Drive Westford, MA 01886 Phone: +1 978 589 0290 Email: tmistretta@juniper.net Paul Howard Juniper Networks 10 Technology Park Drive Westford, MA 01886 Phone: +1 978 589 0368 Email: phoward@juniper.net Vipin Jain Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054 Phone: +1 408 878 0464 Email: vipin@riverstonenet.com 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 Kelkar, et al. Expires September 17, 2005 [Page 13] Internet-Draft PPP over L2TP Tunnel Switching March 2005 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 MUST be either required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kelkar, et al. Expires September 17, 2005 [Page 14]