One document matched: draft-kothari-l2vpn-auto-site-id-01.txt
Differences from draft-kothari-l2vpn-auto-site-id-00.txt
Network Working Group B. Kothari
Internet-Draft K. Kompella
Updates: 4761 (if approved) Juniper Networks
Intended status: Standards Track T. Spencer
Expires: May 2, 2009 AT&T
October 29, 2008
Automatic Generation of Site IDs for Virtual Private LAN Service
draft-kothari-l2vpn-auto-site-id-01.txt
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 May 2, 2009.
Abstract
This document defines procedures that allow for Virtual Private LAN
Service (VPLS) provider edge (PE) devices that use BGP in the control
plane to automatically generate VE ID values in a consistent manner.
Kothari, et al. Expires May 2, 2009 [Page 1]
Internet-Draft BGP VPLS Auto Site ID October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Keeping track of site IDs in use . . . . . . . . . . . . . 5
3.2. Claiming an unused site ID . . . . . . . . . . . . . . . . 6
3.3. Collision Detection . . . . . . . . . . . . . . . . . . . 6
3.4. Resolving a Collision . . . . . . . . . . . . . . . . . . 7
3.4.1. New control flags in a VPLS site advertisement . . . . 7
3.4.2. Collision Resolution Rules . . . . . . . . . . . . . . 8
3.5. Interaction with BGP path selection . . . . . . . . . . . 8
3.6. Lifetime of a claimed site ID . . . . . . . . . . . . . . 9
3.7. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 9
3.8. Timers used in this approach . . . . . . . . . . . . . . . 9
3.9. Interoperating with explicitly configured site IDs . . . . 10
3.10. Operation over a Multi-AS/Multi-provider MPLS core . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Kothari, et al. Expires May 2, 2009 [Page 2]
Internet-Draft BGP VPLS Auto Site ID October 2008
1. Introduction
Service providers are actively deploying VPLS in their networks.
[RFC4761] describes mechanisms that allow VPLS PEs to use the BGP
protocol to automatically discover PE membership in VPLS domains and
to signal pseudowires required to carry VPLS traffic. These
mechanisms make VPLS much easier to deploy and manage compared to
when manual configuration of a full mesh of pseudowires is required.
A VPLS domain is an instantiation of an emulated LAN. A VPLS domain
consists of a number of VPLS instances, one on each PE to which a
customer site of the VPLS domain is attached. For each VPLS instance
on a given PE, [RFC4761] requires a service provider to configure a
route distinguisher (RD), a route target (RT) that identifies the
VPLS domain, and a VE ID that is used to uniquely identify the VPLS
site in the VPLS domain. The VE IDs configured must generally be
unique per VPLS domain. The exception to having unique VE IDs in a
VPLS domain is when a particular VPLS site is multi-homed to two or
more PEs. Having the same VE ID on all the PEs to which the site is
attached can be used to indicate multi-homing.
Site IDs are used by a VPLS PE to index into label blocks in order to
derive the transmit and receive pseudowire labels for the pseudowires
needed for transport of VPLS traffic. Thus, it is desirable for VE
ID allocation in each VPLS domain to be in dense clusters in order to
both minimize the number of label blocks advertised per VPLS domain
and to maximize the usage of labels in a label block. For example,
the set of VE IDs 1, 2, 3, 4, 5, 101, 102, 103, 104 and 105 is an
efficient allocation of VE IDs for a VPLS domain.
This document describes procedures by which PEs that are offering
VPLS service using BGP, as described in [RFC4761], can automatically
generate VE IDs in dense clusters, thereby easing the burden on the
service provider to configure and manage VE IDs per VPLS domain. The
procedures to automatically generate route distinguishers for VPLS or
IP VPN [RFC4364] instances on each PE are already well known. Thus,
from a control plane perspective, a service provider is only required
to provision route targets for each VPLS domain.
The procedures are designed to be backward compatible with the
current approach of explicitly configured VE IDs. In other words, it
is perfectly acceptable to have some sites in a VPLS domain with
explicitly configured VE IDs (for example, to indicate multi-homing),
while others have their VE IDs automatically generated. The
procedures are also designed to work not only in a single autonomous
system, but also in scenarios where VPLS domains span multiple
autonomous systems.
Kothari, et al. Expires May 2, 2009 [Page 3]
Internet-Draft BGP VPLS Auto Site ID October 2008
2. Terminology
Terminology as described in [RFC4761] is used in this document.
Additional terms are describe below.
VPLS domain: A VPLS domain represents a bridging domain
per customer. A Route Target community as
described in [RFC4360] is used to identify
all the PE routers participating in a
particular VPLS domain.
VPLS site: A VPLS site is a set of attachment circuits
(ports) on a PE that belong to the same
VPLS domain. Sites are referred to as
local or remote depending on whether they
belong to the PE router in context or to
one of the remote PE routers (network
peers).
Site ID: VE ID as encoded in VPLS BGP NLRI.
Real advertisement: A VPLS BGP NLRI that contains a non-zero
value for VE ID, VE block offset and VE
block size. Information contained in a
real advertisement is required to bring up
pseudowires between PEs in the same VPLS
domain.
Claim advertisement: A VPLS BGP NLRI that contains VE block
offset of zero and VE block size of zero.
Information contained in a claim
advertisement is insufficient to bring up
pseudowires between PEs in the same VPLS
domain.
2.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].
3. Solution
The central idea of this solution is that within a VPLS domain, each
PE that is configured for automatic negotiation of site identifiers
will allocate an unused site ID for the VPLS site configured on the
PE. It accomplishes this by keeping track of all site IDs used
Kothari, et al. Expires May 2, 2009 [Page 4]
Internet-Draft BGP VPLS Auto Site ID October 2008
within the VPLS domain based on received advertisements. A Route
Target community (RT), as described in [RFC4360], is used to identify
all the PE routers participating in a particular VPLS domain. When
the PE needs a new site ID for an RT, it picks one of the unused site
IDs for that RT and tries to claim it for a certain time period by a
"claim advertisement" for this site ID. A collision occurs if this
PE receives another advertisement within this time period with the
same site ID and route target.
If no collision occurs, the PE takes ownership of the claimed site ID
by a real advertisement for that site ID, and begins using it
(establishing pseudowires, etc.). In case of a collision, the PE
runs procedures as outlined in this document to resolve the
collision, whereby it would either use the site ID or pick a new one
based on whether it won or lost the collision resolution.
It is expected that the chance of a collision is small, especially if
optimizations such as those described in this document are
implemented.
The following sections provide details on the procedures required for
automatic negotiation of site IDs among PEs participating in a VPLS
domain.
3.1. Keeping track of site IDs in use
When a PE comes up, it SHOULD wait for time period T1 to receive
advertisements from all other PEs participating in the same VPLS
domain. Similarly, when a new VPLS site is configured, it SHOULD
wait for time period T2 to receive advertisements from all other PEs
participating in the same VPLS domain. For either of these, a PE may
use BGP route refresh as described in [RFC2918] or other similar
mechanisms.
The time to wait (T1 or T2) to receive relevant information can be
based on configurable timers in addition to implementation specific
heuristics. For example, if BGP End-of-RIB marker functionality as
described in [RFC4724] is in use, the PE knows exactly when it has
received all VPLS advertisements after it has come up.
A PE synthesizes a list of site IDs in use per route target from the
advertisements it receives from other PEs. Note that maintaining a
list of site IDs in use within a VPLS domain adds very little extra
state on the VPLS PE since a VPLS PE is required to keep all VPLS
advertisements for configured route targets.
When all advertisements for a site with a particular site ID are
withdrawn, the site ID is deemed to be no longer in use, and MUST be
Kothari, et al. Expires May 2, 2009 [Page 5]
Internet-Draft BGP VPLS Auto Site ID October 2008
removed from the list of used site IDs. Note that a PE may advertise
a single site using multiple advertisements with each advertisement
carrying the label block to be used by a different set of remote
sites in the VPLS domain. If the site is multi-homed, multiple PEs
may advertise the same site ID.
3.2. Claiming an unused site ID
When either timer T1 or T2 expires, a PE SHOULD pick an unused site
ID based on the list of site IDs in use within that VPLS domain. To
indicate its interest in the selected site ID, a PE MUST send a
"claim advertisement" for this site ID to all other PEs participating
in the same VPLS domain. A VPLS BGP NLRI, as described in [RFC4761],
for a claim advertisement MUST contain a site ID that a PE is
interested in, a block offset of zero and a block size of zero.
Optimizations are possible to reduce the chance of collisions when
selecting an unused site ID. For example, an implementation could
determine a subset of unused site IDs and randomly select one of them
instead of always selecting the unused site ID with the lowest value.
An implementation might also decide to use heuristics designed to
minimize the number of label blocks per VPLS domain by selecting an
unused site ID that falls in the range of VPLS site advertisements
from other PEs.
3.3. Collision Detection
After a claim advertisement has been send to all other PEs in a VPLS
domain, a PE SHOULD wait for time period T3 to detect any collision
of site ID.
A collision occurs if a PE receives any advertisement that contains
the same site ID that was send in the claim advertisement. In case
of a collision, a PE MUST follow the collision resolution procedures
described in Section 3.4.
If a PE does not receive any advertisement with the same site ID from
other PEs within time interval T3, the PE can then start using the
site ID it claimed for "real advertisements". A BGP VPLS NLRI for a
real advertisement MUST contain a valid site ID, a non-zero block
offset and a non-zero block size in addition to valid label base
value. Note that a claim advertisement contains a block offset and a
block size of zero. Thus, a PE MUST withdraw a claim advertisement
it previously advertised after it has send a real advertisement for
its site ID.
Even after a PE starts using the site ID, it is still possible for it
to receive advertisements from other PEs using the same site ID.
Kothari, et al. Expires May 2, 2009 [Page 6]
Internet-Draft BGP VPLS Auto Site ID October 2008
This can happen for example, if two PEs are trying to claim the same
site ID, but neither has received each other's claim advertisements
within interval interval T3. The collision resolution procedures
described in Section 3.4 will handle this case as well.
3.4. Resolving a Collision
When a PE that is using a site ID or trying to claim it for its use
detects a collision, it MUST run collision resolution procedures to
resolve the collision. The collision could be caused by another PE
using the site ID or trying to claim the site ID for its use. The
collision is resolved in favor of the PE that has a better site
advertisement.
Two new control flags are defined in Section 3.4.1 and collision
resolution rules are described in Section 3.4.2
3.4.1. New control flags in a VPLS site advertisement
Two new control flags are proposed in this document.
1. 'A' (Automatic): Indicates whether an advertisement is for a site
with explicit site ID configuration or with automatic site ID
negotiation. The bit MUST be set to one in both a claim and a
real advertisement for a site that is negotiating site ID by
using procedures described in this document, otherwise the bit
MUST be set to zero.
2. 'D' (Down): Indicates connectivity status between a CE site and a
VPLS PE. The bit MUST be set to one if all the attachment
circuits connecting a CE site to a VPLS PE are down.
Figure 1 shows the position of 'A' and 'D' bits in the control flags
field.
Control Flags Bit Vector
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|A|Z|Z|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 1
Kothari, et al. Expires May 2, 2009 [Page 7]
Internet-Draft BGP VPLS Auto Site ID October 2008
3.4.2. Collision Resolution Rules
The algorithm to compare two site advertisements with the same site
ID is as follows:
1. An advertisement with the 'A' bit clear in the control flags is
always better than an advertisement with the A bit set to one.
2. For advertisements with the same A bit value, a real
advertisement is always better than a claim advertisement.
3. Between real advertisements, an advertisement with the higher BGP
local preference is better. Similarly, between claim
advertisements, an advertisement with the higher BGP local
preference is better.
4. For advertisements with the same BGP local preference value, an
advertisement with the lowest BGP next hop value is better.
The rules above MUST be applied in the order specified. The rules
will pick the best advertisement in a deterministic manner, and the
PE that has the best advertisement will end up using the site ID.
The PEs that have worse advertisements must withdraw all
advertisements for their site ID and SHOULD try to claim another
unused site ID for their use. Optimizations are possible to reduce
chance of further collisions. It is recommended that a PE that lost
a collision resolution wait for a short time period before making an
attempt to claim another site ID. A PE that has experienced multiple
collisions in succession could consider to select an unused site ID
that does not fall within the range of other PEs label block
advertisements, even though this would potentially result in the
expansion of existing label blocks from other PEs.
3.5. Interaction with BGP path selection
In order to avoid unnecessary interaction between the rules in the
previous sections and those of BGP path selection, it is recommended
that PEs use unique route distinguishers (RDs) when advertising VPLS
site information. This will prevent BGP route reflectors (RRs) from
inadvertently filtering VPLS site advertisement information that the
PEs need to receive. The procedures to automatically generate unique
route distinguishers for VPLS or IP VPN [RFC4364] instances on each
PE are already well known.
Kothari, et al. Expires May 2, 2009 [Page 8]
Internet-Draft BGP VPLS Auto Site ID October 2008
3.6. Lifetime of a claimed site ID
The lifetime of a claimed site ID is the duration for which the site
is being advertised by the PE using a real advertisement. In other
words, if all advertisements for a site that is allocated an
automatically generated site ID are withdrawn, the site ID is
implicitly released.
If all interfaces that connect a VPLS site to a PE are down, VPLS
requires that the PE signal this event to other PEs by either
withdrawing all site advertisements, or by some other means. Since
withdrawing all site advertisements for a site with an automatically
generated site ID has a side effect of relinquishing the site ID, it
is RECOMMENDED to re-advertise the site advertisements with a "down"
bit ('D' bit) set to one in the control flags instead of withdrawing
the advertisements. Upon receiving a site advertisement with the 'D'
bit set to one, a PE SHOULD remove all pseudowires to the advertising
PE for this site ID, but MUST still consider the site ID in the
advertisement to be in use. However since the new 'D' bit will not
be understood by older implementations, a configurable knob should be
provided in newer implementations for backward compatibility to force
the withdrawal of site advertisements when all attachment circuits
connecting a site to the PE go down.
3.7. Graceful Restart
When graceful restart procedures are in use for VPLS, a restarting PE
SHOULD select the same site ID that it used before the restart. If a
PE selects a different site ID than the one it used before the
restart, VPLS forwarding will be disrupted as all other PEs within
the same VPLS domain will bring down the pseudowires that were
established based on the old site ID.
Without graceful restart, a restarting PE SHOULD use the procedures
defined in this document for site ID negotiation.
3.8. Timers used in this approach
The procedures described in this document relies on three timers. It
is RECOMMENDED that these timers be configurable. A brief
description of each timer along with default values for each is given
below. Note that the default values are worst case values and as
such the corresponding events could be triggered by implementation
specific heuristics even before the corresponding timers expire.
o T1: time to wait at startup to receive all VPLS information for
configured route targets from other PEs. If End-of-RIB marker
functionality [RFC4724] is in use, the PE could terminate its wait
Kothari, et al. Expires May 2, 2009 [Page 9]
Internet-Draft BGP VPLS Auto Site ID October 2008
earlier than T1 if it receives End-of-RIB markers for VPLS NLRI
from all other BGP peers. The default value for T1 is recommended
to be 2 minutes.
o T2: time to wait to receive VPLS information for a newly
configured route target or a newly configured site for automatic
site ID negotiation. The default value for T2 is recommended to
be 20 seconds.
o T3: time to wait after issuing a "claim advertisement" before the
PE can start using the site ID if it does not hear a competing
claim. If the PE hears a competing claim within this time
interval, it runs collision resolution procedures. The default
value for T3 is recommended to be 30 seconds.
With the default values as specified above, a newly configured site
on an operational PE will take T2 + T3 = 50 seconds before it can
claim a site ID and start using it, assuming that there are no
collisions with other PEs trying to use the same site ID. Similarly
a PE that is restarting will take T1 + T3 = 150 seconds in the worst
case before it can claim site IDs for all its sites and start using
them, assuming that there are no collisions with other PEs.
3.9. Interoperating with explicitly configured site IDs
The solution presented in this document allows for automatic
generation of unique site IDs per VPLS domain. However the service
provider might want to explicitly configure site IDs in the network
for the following reasons:
o When a site is multi-homed to two or more PEs, then the site MUST
be configured with the same site ID on all the PEs. Since the
solution presented here always generates unique site IDs, a
service provider has to explicitly configure site IDs for multi-
homed sites.
o The service provider might have PEs in the network that do not
support the functionality for automatic generation of site IDs.
This could be because the service provider network is multi-vendor
and one or more vendors do not support this functionality, or
because some PEs have older versions of software running on them
that do not support the new functionality.
The procedures described in this document for sites with automatic
negotiation of site IDs will interoperate with sites with explicit
site configuration. Sites with explicitly configured site IDs will
always use the site ID as configured. For example, if a PE detects
that one of the automatically generated site IDs that it is already
Kothari, et al. Expires May 2, 2009 [Page 10]
Internet-Draft BGP VPLS Auto Site ID October 2008
using (or in the process of claiming) conflicts with an explicit site
ID, it will stop using the site ID by withdrawing all advertisements
with this site ID and try to claim another available site ID for its
use. This behavior is achieved by the first rule in the site
advertisement comparison algorithm that mandates that site
advertisements with explicitly configured site IDs always win over
site advertisements with automatically generated site IDs. In order
for PEs to distinguish between explicitly configured and
automatically generated site IDs, PEs that use automatically
generated site IDs MUST set a new 'A' bit in the control flags bit-
vector in advertisements for sites using automatically generated site
IDs.
The compatibility of this approach with implementations that do not
support this functionality also relies on these implementations
ignoring claim advertisements. As explained in Section 3.2, a VPLS
BGP NLRI for a claim advertisements contains a label block size of
zero and a block offset of zero. An implementation that do not
support automatic negotiation of site IDs SHOULD ignore an
advertisement that has either a block size of zero or a block offset
of zero. A claim advertisement does not have any valid labels
advertised with it due to the block size of zero. In addition the
block offset of zero is an invalid block offset for a real
advertisement. Thus, a claim advertisement cannot be used by a
remote PE to bring up a pseudowire to the site advertising the claim.
Also see the note on the 'D' bit at the end of Section 3.6.
3.10. Operation over a Multi-AS/Multi-provider MPLS core
The solution presented in this document works over a multi-AS and
multi-provider core.
Section 3.4 in [RFC4761] describes three methods (a, b and c) to
connect sites in a VPLS to PEs that are across multiple AS. Since
VPLS advertisements in method (a) do not cross AS boundaries,
procedures defined in this document for automatic site ID work in
exactly the same manner as they work within an AS. In methods (b)
and (c), the VPLS advertisement do cross AS boundaries, but the VE ID
contained in the VPLS BGP NLRI is not changed by the intermediate
ASBRs or RRs if any. Thus, each VPLS PE will receive site
advertisements from all other PEs for each VPLS domain, and as
described in this document, each PE will synthesize a list of site
IDs in use per VPLS domain based on the remote PEs site
advertisements. In such scenarios, since the advertisements have to
cross AS boundaries, it is recommended to increase the time that a PE
waits to hear advertisements from other PEs, both when it starts up
(T1, T2) and when it waits to hear competing claims after it has
Kothari, et al. Expires May 2, 2009 [Page 11]
Internet-Draft BGP VPLS Auto Site ID October 2008
issued a claim of its own (T3).
Note that this solution only ensures that automatically generated
site IDs are unique across AS boundaries. However, managing
uniqueness of explicitly configured site IDs across multiple AS is
outside the scope of this document.
4. Security Considerations
The procedures defined in this document allow VPLS PEs to
automatically generate site IDs per VPLS domain without the service
provider having to explicitly configure them. As such, no new
security issues are raised beyond those that already exist in
networks that use BGP-4 for exchanging VPN and VPLS membership and
signaling information. Moreover, since real advertisements have
priority over claim advertisements, the procedures defined in this
document do not introduce new means of disrupting VPLS traffic.
5. IANA Considerations
At this time, this memo includes no request to IANA.
6. Acknowledgments
The authors would like to thank Chaitanya Kodeboyina, Nischal Sheth,
Yakov Rekhter, Amit Shukla and others for the useful discussions on
the subject, their review and comments.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
Kothari, et al. Expires May 2, 2009 [Page 12]
Internet-Draft BGP VPLS Auto Site ID October 2008
7.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
Authors' Addresses
Bhupesh Kothari
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: bhupesh@juniper.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Thomas Spencer
AT&T
Email: tsiv@att.com
Kothari, et al. Expires May 2, 2009 [Page 13]
Internet-Draft BGP VPLS Auto Site ID 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.
Kothari, et al. Expires May 2, 2009 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-21 12:09:48 |