Network Working Group N. Bahadur
Internet-Draft K. Kompella
Intended status: Standards Track Juniper Networks, Inc.
Expires: April 29, 2009 October 26, 2008
Mechanism for performing LSP-Ping over RSVP protection paths
draft-nitinb-lsp-ping-rsvp-protection-00
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 April 29, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes methods for performing lsp ping over mpls
rsvp-te protection paths, when the protection paths are not in use.
Conventional LSP-Ping follows the same path as data traffic. In some
cases, it might be useful to follow the data path of protection paths
(detours and bypasses) to ensure that the those paths are fully
functional. This document describes enhancements to LSP-Ping to
perform ping over such paths.
Bahadur & Kompella Expires April 29, 2009 [Page 1]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Exercising the protection path . . . . . . . . . . . . . . . . 4
3.1. Transit node re-route indication . . . . . . . . . . . . . 4
3.1.1. RSVP IPv4 LSP Target FEC Stack Sub-TLV . . . . . . . . 4
3.1.2. RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV . . . 5
3.1.3. RSVP IPv6 LSP Target FEC Stack Sub-TLV . . . . . . . . 6
3.1.4. RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV . . . 7
3.2. Transit node re-route error reporting . . . . . . . . . . 7
3.3. Transit node automatic forwarding along protected path . . 8
4. Performing LSP Ping along a protection path . . . . . . . . . 8
4.1. Ingress node procedure . . . . . . . . . . . . . . . . . . 8
4.2. Transit node procedure . . . . . . . . . . . . . . . . . . 8
4.3. Egress node procedure . . . . . . . . . . . . . . . . . . 9
4.4. P2MP Considerations . . . . . . . . . . . . . . . . . . . 9
4.5. Re-routing echo requests via forwarding plane . . . . . . 9
4.6. Multiple protection path consideration . . . . . . . . . . 10
4.7. Traceroute along protection path . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Bahadur & Kompella Expires April 29, 2009 [Page 2]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
1. Introduction
This document describes methods for performing lsp ping over MPLS
RSVP-TE protection paths, when the protection paths are not in use.
Convention LSP-ping [RFC4379] packets follow the same path as data
traffic and thus it validates the LSP control and forwarding planes.
For MPLS LSPs signaled using RSVP-TE [RFC3209], protection mechanisms
have been defined in [RFC4090] enable the re-direction of traffic
onto backup LSP tunnels in the event of a failure. Under normal
operation, no data traffic passes through the backup tunnels. So
under normal conditions, there is no way of verifying that when a
failure will happen, data will correctly take the backup tunnel and
eventually reach the LSP end point. This document defines
enhancements to the LSP-Ping to enable verification of end-to-end
data path via the backup LSP tunnel when the backup LSP tunnel is not
in use.
1.1. Conventions used in this document
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 [RFC2119].
2. Motivation
[RFC4090] describes mechanisms for performing protection of RSVP-TE
signaled MPLS tunnels. The protection can be a one-to-one backup
(detour) or a facility backup method (bypass) that creates one or
more bypass LSPs for protecting one or more LSPs. I either case, the
signaling is done in the control plane and protection path is not
used until there is a failure in the LSP path being protected.
LSP-Ping [RFC4379] allows one to ping and trace the path of a LSP.
LSP-Ping can be used (without any new extensions) to ping and trace
the path of RSVP-TE protection paths. Thus, one can monitor the
health of protection paths. However, this monitoring of the
protection paths is done in isolation and not in combination with the
actual path(s) being protected. In other words, the protection path
might be UP, but on failure of the protected path, data traffic might
not make it to the protected LSP end-point. Some of the reasons for
this are as described below:
1. Point of local repair (PLR) does not currently forward the
incoming LSP traffic onto the protection path
2. Actual forwarding failure with the protection path
Bahadur & Kompella Expires April 29, 2009 [Page 3]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
3. Merge point (end of protection path) does not correctly merge the
traffic back to the LSP path
Thus, it is essential to have a mechanism to validate that the LSP
protection will actually work in case of a failure. This draft
provides extensions to LSP-Ping to allow the PLR to re-route the lsp-
ping packets via the protection path
3. Exercising the protection path
3.1. Transit node re-route indication
To re-route an incoming packet via a protection path at a transit
node, we need to provide some indication to the transit node that it
should forward the lsp-ping echo request along the protection path.
This is done by adding a flag field in the Target FEC Stack sub-TLV
objects [RFC4379] for RSVP FECs.
3.1.1. RSVP IPv4 LSP Target FEC Stack Sub-TLV
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero |P| Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSVP IPv4 LSP Target FEC Stack Sub-TLV
RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in
[RFC4379]. The P-bit has been added to indicate that the echo-
request MUST be forwarded along a protection-path, if one is
available. If a node does not understand the P-bit, it MUST return
an error code of either" Malformed echo request received" or "One or
more of the TLVs was not understood" [RFC4379]. If no protection-
path is available, then the node MUST return the error code defined
in Section 3.2.
Bahadur & Kompella Expires April 29, 2009 [Page 4]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
3.1.2. RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero |P| Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSVP P2MP IPv4 Session Target FEC Stack Sub-TLV
RSVP P2MP IPv4 Session is a sub-TLV of Target FEC Stack TLV, defined
in [I-D.ietf-mpls-p2mp-lsp-ping]. The P-bit has been added to
indicate that the echo-request MUST be forwarded along a protection-
path, if one is available. If a node does not understand the P-bit,
it MUST return an error code of either" Malformed echo request
received" or "One or more of the TLVs was not understood" [RFC4379].
If no protection-path is available, then the node MUST return the
error code defined in Section 3.2.
Bahadur & Kompella Expires April 29, 2009 [Page 5]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
3.1.3. RSVP IPv6 LSP Target FEC Stack Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero |P| Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSVP IPv6 LSP Target FEC Stack Sub-TLV
RSVP IPv4 LSP is a sub-TLV of Target FEC Stack TLV, defined in
[RFC4379]. The P-bit has been added to indicate that the echo-
request MUST be forwarded along a protection-path, if one is
available. If a node does not understand the P-bit, it MUST return
an error code of either" Malformed echo request received" or "One or
more of the TLVs was not understood" [RFC4379]. If no protection-
path is available, then the node MUST return the error code defined
in Section 3.2.
Bahadur & Kompella Expires April 29, 2009 [Page 6]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
3.1.4. RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| P2MP ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero |P| Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSVP P2MP IPv6 Session Target FEC Stack Sub-TLV
RSVP P2MP IPv6 Session is a sub-TLV of Target FEC Stack TLV, defined
in [I-D.ietf-mpls-p2mp-lsp-ping].The P-bit has been added to indicate
that the echo-request MUST be forwarded along a protection-path, if
one is available. If a node does not understand the P-bit, it MUST
return an error code of either" Malformed echo request received" or
"One or more of the TLVs was not understood" [RFC4379]. If no
protection-path is available, then the node MUST return the error
code defined in Section 3.2.
3.2. Transit node re-route error reporting
If a transit-node receives a echo request with an indication that the
request needs to traverse a protection path, but no protection path
is available, then the transit node should respond back with a new
return code as defined below:
Value Meaning
----- -------
TBD Protection path not available
Bahadur & Kompella Expires April 29, 2009 [Page 7]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
The Return Subcode for this Return Code MUST be set to zero and MUST
be ignored.
3.3. Transit node automatic forwarding along protected path
LSP-Ping [RFC4379] mandates that the destination IP of the lsp-ping
echo request MUST be from the 127/8 range. This document proposes
the use of address 127.255.255.255/32 to reflect that the packet be
forwarded along a protection path. Details of the procedure are
described in Section 4.5.
4. Performing LSP Ping along a protection path
4.1. Ingress node procedure
The RRO object sent upstream during the signaling of a MPLS RSVP-TE
LSP contains information regarding protection availability on the
downstream node. More specifically, [RFC4090] specifies bits in the
RSVP record-route object (RRO), which specify if a transit node
provides protection and if it provides node protection. Given this,
the ingress node of a RSVP-TE LSP knows the state of protection along
all hops of a LSP. Using this information, the ingress MAY choose to
perform LSP pings only via nodes where protection is available.
Attempting to perform lsp-ping via nodes where no protection is
available will not cause harm, except for additional OAM load in the
nodes.
4.2. Transit node procedure
Ingress Egress
A B C D E
o -------- o -------- o --------- o --------- o
| |
\____________________/
Bypass
Figure 6: Protected RSVP path
In the above figure node C provides node protection. To perform a
lsp-ping along the protection path originating at node C, ingress A
MUST send a lsp-ping echo request message with TTL=2 and with the
P-bit set in the RSVP FEC stack sub-TLV, see Section 3.1. Due to
TTL=2, the echo request will expire at node C. The transit node C on
receipt of such a request SHOULD perform one of the following:
Bahadur & Kompella Expires April 29, 2009 [Page 8]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
1. If C does not understand the P-bit, C MAY respond back to A with
an error.
2. If C ignores the P-bit, then C MAY respond back to A with a
return code indicating that it is a transit node
3. If C understands the P-bit, then C SHOULD forward the lsp-ping
echo request along the bypass path.
When the lsp-ping echo request is forwarded along the protection
path, the following rules MUST be followed:
Node C MUST NOT forward the lsp-ping echo request along the regular
(non-protection) LSP path.
4.3. Egress node procedure
When the echo request reaches the egress, the egress will either
identify it as a malformed packet (if it does not understand the
P-bit and enforces the Must-be-zero) or the egress will process the
packet as a regular lsp-ping echo request and respond back with an
appropriate return code.
In either case, a response from the egress indicates that the packet
indeed made it via the forwarding plane of the LSP's protection path.
An error message from the egress does not necessarily mean that the
packet was correctly forwarded to the egress. It only means that the
packet made it to the egress.
4.4. P2MP Considerations
[RFC4875] specifies P2MP extenions for RSVP-TE and
[I-D.ietf-mpls-p2mp-lsp-ping] specifies extensions to lsp-ping for
P2MP.
The procedures outlined above are sufficient for P2MP. Using an
appropriate MPLS TTL value (in the echo request) and P2MP Responder
Identifier TLV ( [I-D.ietf-mpls-p2mp-lsp-ping] ), an ingress should
be able to direct an echo request along a particular protection path
to a particular egress. A protection path in P2MP may be protecting
multiple egresses and for scalability considerations, one should
regulate the number of lsp-pings exercising the same protection path.
4.5. Re-routing echo requests via forwarding plane
The above mechanisms described for re-routing the echo requests on
transit nodes onto a protection path may involve processing the lsp-
ping echo request in the slow (non-forwarding) path. This document
proposes the use of 127.255.255.255/32 IP destination address in the
lsp-ping echo request to indicate that the packet should be forwarded
Bahadur & Kompella Expires April 29, 2009 [Page 9]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
along a protection path, if one exists. Thus, a transit node
forwards packets along a protection path if and only if the
destination IP address is 127.255.255.255/32 and the MPLS-TTL=1
The above technique is NOT mandatory and in the absence of the above,
the packet will get processed by the slow-path on node C.
4.6. Multiple protection path consideration
A transit node MAY have multiple paths protecting a downstream link
or node. In such a case, which path the transit node chooses to
forward the packets is a dependent on the transit node. This
document does not make any requirements on the transit node to
forward packets along a specific path or provide information along
which path the packet was forwarded. In general, the transit node
behavior for lsp-ping echo request messaegs should mimic the behavior
for data packets in case there is a failure in the LSP path.
4.7. Traceroute along protection path
At this time, it is not deemed necessary to provide any extensions to
support traceroute (starting at LSP ingress) that traverses the
protection path. Traceroute is a tool often used during network
trouble-shooting. During trouble-shooting, one could use lsp-ping
(with extensions specified in this draft) to detect/validate a
failure with the path. Once a failure has been detected, one could
use traceroute on the main LSP path and a traceroute on the
protection path to isolate the issue. Proxy lsp-ping
[I-D.ietf-mpls-remote-lsp-ping] could be used to automate the
network-troubleshooting by performing both the procedures from the
LSP ingress itself.
5. Security Considerations
The draft does not introduce any new security considerations. Those
discussed in [RFC4379] are also applicable to this document.
Tracing inside a bypass tunnel can be prevented by not propagating
the MPLS TTL into the outer tunnel (at the start of the outer
tunnel).
6. IANA Considerations
A new Return Code is defined in Section 3.2. IANA is requested to
assign a new Return Code value for the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
Bahadur & Kompella Expires April 29, 2009 [Page 10]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
"Return Codes" sub-registry as follows using a Standards Action
value.
Value Meaning
----- -------
TBD Protection path not available
7. Acknowledgements
The authors would like to thank Kenji Kumaki and Vach Kompella for
their suggestions on the draft.
8. References
8.1. Normative References
[I-D.ietf-mpls-p2mp-lsp-ping]
Yasukawa, S., Farrel, A., Ali, Z., Fenner, B., Swallow,
G., and T. Nadeau, "Detecting Data Plane Failures in
Point-to-Multipoint Multiprotocol Label Switching (MPLS)
- Extensions to LSP Ping",
draft-ietf-mpls-p2mp-lsp-ping-07 (work in progress),
September 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
8.2. Informative References
[I-D.ietf-mpls-remote-lsp-ping]
Swallow, G. and V. Lim, "Proxy LSP Ping",
draft-ietf-mpls-remote-lsp-ping-02 (work in progress),
July 2008.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
Bahadur & Kompella Expires April 29, 2009 [Page 11]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
Authors' Addresses
Nitin Bahadur
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
Email: nitinb@juniper.net
URI: www.juniper.net
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
Email: kireeti@juniper.net
URI: www.juniper.net
Bahadur & Kompella Expires April 29, 2009 [Page 12]
Internet-Draft LSP-Ping over RSVP protection paths October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bahadur & Kompella Expires April 29, 2009 [Page 13]