One document matched: draft-ietf-l2tpext-tunnel-switching-05.txt
Differences from draft-ietf-l2tpext-tunnel-switching-04.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 13:10:36 |