Network Working Group Hamid Ould-Brahim
Internet Draft Bryan Gleeson
draft-ouldbrahim-vpn-vr-01.txt Gregory Wright
Expiration Date: January 2001 Nortel Networks
Timon Sloane
N.E.T
Rainer Bach
T-Data
Rick Bubenik
SAVVIS Communications
Abraham Young
Huawei Technologies
July 2000
Network based IP VPN Architecture
using Virtual Routers
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
Ould-Brahim, et. al [Page 1]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
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.
Abstract
This draft describes a network based VPN architecture using virtual
routers. The VPN service is built based on the virtual router (VR)
concept, which has exactly the same mechanisms as a physical router,
and therefore inherits all existing mechanisms and tools for
configuration, operation, accounting, and maintenance. Within a VPN
domain, an instance of routing is used to distribute VPN
reachability information among VR routers. Any routing protocol can
be used, and no VPN-related modifications or extensions are needed
to the routing protocol for achieving VPN reachability. Virtual
routers can be deployed in different VPN configurations, direct VR
to VR connectivity through layer-2 or by aggregating multiple VRs
into a single VR combined with IP or MPLS based tunnels. This
architecture accommodates different backbone deployment scenarios,
e.g. where the service provider owns their own backbone, and where
the service provider obtains backbone service from one or more other
service providers.
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.
Table of Contents
1 Introduction ........................................ 3
2 Requirements ........................................ 4
3 Network Reference Model .............................. 5
3.1 The Backbone ........................................ 5
4 Virtual Router Definition ............................ 5
5 How VPNs are built and deployed using VRs?............ 6
5.1 VR to VR Connectivity over layer-2 Connections........ 6
5.2 Virtual Router Backbone Aggregation .................. 7
5.2.1 Relationship between the VRs and the Backbone VR ..... 8
5.2.2 Multiple Backbones connected to a single PE .......... 8
6 VPN Topology and Membership Discovery ................ 9
7 Operations and Management ............................ 10
7.1 Backbone Migration ................................... 10
7.2 Troubleshooting ...................................... 10
Ould-Brahim, et al. July 2000 [Page 2]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
8 Quality of Service ................................... 11
9 Scalability .......................................... 11
10 Security Considerations .............................. 11
11 References............................................ 11
11 Acknowledgments ..................................... 12
12 Authors' Addresses .................................. 12
14 Full Copyright Statement ............................ 14
1. Introduction
Several solutions have been put forward to achieve different levels
of network privacy when building VPNs across a shared backbone. Most
of these solutions require separate per VPN forwarding capabilities
and make use of IP or MPLS based tunnels across the backbone [VPN-
VR], [VPN-CORE], and [VPN-RFC2547].
This document describes a network based VPN architecture using
virtual routers. The architecture complies with the IP VPN framework
described in [VPN-RFC2764]. The objective is to provide per VPN
based routing, forwarding, quality of service, and service
management capabilities. The VPN service is built based on the
virtual router concept, which has exactly the same mechanisms as a
physical router, and therefore inherits all existing mechanisms and
tools for configuration, deployment, operation, troubleshooting,
monitoring, and accounting. Virtual routers can be deployed in
different VPN configurations, direct VR to VR connectivity through
layer-2 links/tunnels or by aggregating multiple VRs into a single
VR combined with IP or MPLS based tunnels. This architecture
accommodates different backbone deployment scenarios, e.g. where the
service provider owns their own backbone, and where the service
provider obtains backbone service from one or more other service
providers.
Within a VPN domain, an instance of routing is used to distribute
VPN reachability information among VR routers. Any routing protocol
can be used, and no VPN-related modifications or extensions are
needed to the routing protocol for achieving VPN reachability.
VPN reachability information to and from customer sites can be
dynamically learned from the CE using standard routing protocols or
it can be statically provisioned on the VR. The routing protocol
between the virtual routers and CEs is independent of the routing
used in the VPN backbone. The routing protocol between the VRs maybe
the same or it might be different than the routing mechanism used
between the CE and VR.
There are two fundamental architectures for implementing network
based VPNs, virtual routers (VR) and piggybacking. The main
difference between the two architectures resides in the model used
to achieve VPN reachability and membership functions. In the VR
Ould-Brahim, et al. July 2000 [Page 3]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
model, each VR in the VPN domain is running an instance of routing
protocol responsible to disseminate VPN reachability information
between VRs. Therefore, VPN membership and VPN reachability are
treated as separate functions, and separate mechanisms are used to
implement these functions. VPN reachability is carried out by a per-
VPN instance of routing, and a range of mechanisms is possible for
determining membership (see section 6.0). In the piggyback model the
VPN network layer is terminated at the edge of the backbone, and a
backbone routing protocol (i.e. BGP-4) is responsible for
disseminating the VPN membership and reachability information
between provider edge routers (PE) for all the VPNs configured on
the PE. [VPN-RFC2547bis] is an example of a piggyback VPN
architecture.
2. Requirements
This section lists some requirements addressed by the proposed
architecture:
(a) It should be easy to configure, deploy, operate and
troubleshoot each VPN independently using existing
mechanisms and tools.
(b) The architecture should accommodate different levels of data
and routing security.
(c) The backbone internal nodes must not be VPN aware and will
not keep any VPN state inside the backbone (for scalability
purposes).
(d) It is desirable to support the use of any routing protocol in
the VPN domain and in the backbone.
(e) The architecture must support overlapping VPN address spaces
in separate VPNs.
(f) Quality of service should be configurable per VPN.
(g) The architecture should accommodate different sizes of VPNs,
and one VPN should not impact other VPNs on the PE.
(h) The addition of a new VPN site or the reconfiguration of an
existing VPN site must not impact other VPNs.
(i) The architecture should support direct paths between VPN
sites that bypass the service provider backbone (backdoor
links). Traffic can be directed to the backdoor link, or
injected to the backbone with the flexibility of using both
the backbone access, and the backdoor link as internal or
external paths.
(j) The architecture must work over different deployment
scenarios, e.g. where the service provider owns their own
backbone, and where the service provider obtains backbone
service from one or more other service providers.
(k) The architecture should not be limited to a single tunneling
mechanism.
Ould-Brahim, et al. July 2000 [Page 4]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
3. Network Reference Model
A VPN customer site is connected to the provider backbone by means
of a connection between a CE device, (which can either be a bridge
or a router) and a virtual router. CE devices are preconfigured to
connect to one (or more) VR(s). M ul tiple virtual routers
coexist on the same service provider edge device (PE).
CE devices can be attached to VRs over any type of access link (e.g.
ATM, frame relay, ethernet, PPP or IP tunneling mechanism such as
IPSec, L2TP or GRE tunnels).
+---+ +---+
| P |....| P |
+---+ +---+
PE / \ PE
+----+ +------+ +------+ +---+
| CEs|--|-{VRs}| |{VRs}-|--|CEs|
+----+ +------+ +------+ +---+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Network Reference Model
CE sites can be statically connected to the provider network via
dedicated circuits, or can use dial-up links. Routing tables
associated with each virtual router define the site-to-site
reachability for each VPN. The internal backbone provider routers
(P) are not VPN aware and do not keep VPN state.
3.1 Backbone
In general the backbone is a shared network infrastructure, which
represents:
(a) A layer-2 ATM or frame relay network.
(b) An IP network.
(c) An MPLS network.
Not all VPNs existing on the same PE are necessarily connected to
the same backbone. The same backbone can be built from multiple
transport technologies.
4. Virtual Router Definition
Ould-Brahim, et al. July 2000 [Page 5]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
A virtual router (VR) is an emulation of a physical router at the
software and hardware levels. Virtual routers have independent IP
routing and forwarding tables and they are isolated from each other.
This means that a VPN's addressing space can overlap with another
VPN's address space. The addresses need only be unique within a VPN
domain.
A virtual router has two main functions:
1. Constructing routing tables describing the paths between VPN
sites using any routing technologies (e.g., static, OSPF, RIP,
or BGP).
2. Forwarding packets to the next hops within the VPN domain.
From the VPN user point of view, a virtual router provides the same
functionality as a physical router. Separate routing, and forwarding
capabilities provide each VPN CE link with the appearance of a
dedicated router that guarantees isolation from other VPN traffic
while running on shared forwarding and transmission resources.
Virtual routers belonging to the same VPN domain must have the same
Virtual Private Network Identifier (VPNID). An example of VPNID
format is described in [VPN-RFC2685]. To the CE access device, the
virtual router appears as a neighbor router in the CE based network,
to which it sends all traffic for non-local VPN destinations. Each
CE access device must learn the set of destinations reachable
through its connection to the virtual router; this may be as simple
as a default route. Virtual routers participating in a single VPN
domain are responsible for learning and disseminating VPN
reachability information among themselves. A given virtual router
holds the routes only for the specific VPNs configured for that VR.
Any routing protocol can be used between the VRs and the CEs.
5. How VPNs are built and deployed using VRs?
Two main VR deployment scenarios can be used for building virtual
private networks:
. VR to VR connectivity over a layer 2 connections.
. Aggregating multiple virtual routers over a single virtual router.
The above VR deployment scenarios can coexist on a single PE and
they are not mutually exclusive.
5.1 VR to VR Connectivity over Layer 2 Connections
As illustrated in figure 2, virtual routers can be deployed over
direct layer-2 frame relay or ATM connections or other layer-2
transport technology.
Ould-Brahim, et al. July 2000 [Page 6]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A| | +----+ Layer-2 connections +----+ | |VPN-A|
|sites|-|-|VR-A| <--------------------------->|VR-A|-|-|sites|
+-----+ | +----+ | -------- | +----+ | +-----+
| |-( Layer-2)-| |
+-----+ | +----+ | (Backbone) | +----+ | +-----+
|VPN-B|-|-|VR-B| | -------- | |VR-B|-|-|VPN-B|
|sites| | +----+<--------------------|------->+----+ | |sites|
+-----+ | | | | +-----+
+---------------+ +---------------+
Figure 2: VR to VR connectivity over a layer-2 backbone
This type of VR deployment allows direct quality of service
engineering per VPN connection basis. The connections can be
statically configured or dynamically established.
5.2 Virtual Router Backbone Aggregation
Another typical VPN configuration consists of connecting multiple
virtual routers to the backbone through the use of a single virtual
router (figure 3). For easy reference in the following sections
let's call this single virtual router "the backbone virtual router"
or "the backbone VR".
The backbone virtual router is not functionally different than other
virtual routers. It is only a virtual router that is configured and
deployed in a special configuration.
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A| | +----+ MPLS/IP based Tunnels +----+ | |VPN-A|
|sites|-|-|VR-A|\<--------------------------->|VR-A|-|-|sites|
+-----+ | +----+ +----+ | -------- | +----+/+----+ | +-----+
| |VR-1|-|-(IP/MPLS )-|-|VR-2| |
+-----+ | +----+/+----+ |(Backbones )| +----+\+----+ | +-----+
|VPN-B|-|-|VR-B| | ---------- | |VR-B|-|-|VPN-B|
|sites| | +----+<-------|-------------------->+----+ | |sites|
+-----+ | MPLS/IP based Tunnels | +-----+
| | | |
+---------------+ +---------------+
Figure 3: VR-1 and VR-2 used as backbone VRs
Ould-Brahim, et al. July 2000 [Page 7]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
The backbone virtual router connects each PE to a shared backbone
infrastructure. Backbone virtual routers can be deployed over ATM,
FR, IP, or MPLS networks. Since the backbone VR allows the
aggregation of VPN VRs, backbone configuration remains unaffected as
new VPN sites are added. The relationship between the VRs and the
backbone VR is an overlay relationship. No routing relationship
exists between the VRs and the backbone VRs.
VPN data and routing information is tunneled through the use of IP
or MPLS based tunnels. Other types of tunneling are not excluded
with this architecture. The tunnels can be statically configured or
dynamically established. The tunnel appears to VRs as a point-to-
point link. Traffic sent through the tunnel, and forwarded by the
backbone VR is opaque to the underlying backbone technology used.
The backbone VR makes it appear as if each VR within a VPN is
directly connected (full and partial mesh configurations supported).
Each VR within the VPN exchanges routing information directly with
the other VRs in the VPN. The backbone VR exchanges routing
information with other backbone entities (P routers and possibly
other backbone VRs).
Virtual routers can run any routing protocol on their local VPN
domain. Both static routes and dynamic routing protocols such as
RIP, OSPF, and BGP-4 can be used. VPN sites exchange routing
information through the tunnels over the backbone.
If a backdoor link is used between private CE based network running
any IGP, then by adjusting the backdoor link costs appropriately,
the backbone link can be favored for forwarding VPN traffic. By
lowering the weight, the backdoor link can be used as a backup link
in case the backbone path fails.
5.2.1 Relationship between the VRs and the Backbone VR
The routing domain of a set of VRs participating in a single VPN has
no relation to the routing domain of the backbone VR. The backbone
VR is not necessarily aware of the routing instances running on each
private virtual router.
5.2.2 Multiple Backbones connected to a single PE
Figure 4 illustrates an example where multiple backbones are
connected to the same PE. This type of configuration can be used
when the PE is connected to multiple service provider backbones, or
when the service provider offers different VPN services for
different type of backbones.
Ould-Brahim, et al. July 2000 [Page 8]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
PE PE
+---------------+ +---------------+
+-----+ | | | | +-----+
|VPN-A| | +----+ | | +----+ | |VPN-A|
|sites|-|-|VR-A|\ | | |VR-A|-|-|sites|
+-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+
| |VR-1|-|-(Backbones)|-|VR-2| |
+-----+ | +----+/+----+ | ( 1 )| +----+\+----+ | +-----+
|VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B|
|sites| | +----+ | | +----+ | |sites|
+-----+ | | | | +-----+
| | | |
+-----+ | | | | +-----+
|VPN-C| | +----+ | | +----+ | |VPN-C|
|sites|-|-|VR-C|\ | | |VR-C|-|-|sites|
+-----+ | +----+ +----+ | -------- | +----+/+----+ | +-----+
| |VR-3|-|-(Backbone)-|-|VR-4| |
+-----+ | +----+/+----+ | ( 2 & 3 ) | +----+\+----+ | +-----+
|VPN-D|-|-|VR-D| | -------- | |VR-D|-|-|VPN-D|
|sites| | +----+ | | +----+ | |sites|
+-----+ | | | | +-----+
+---------------+ +---------------+
Figure 4: Multiple Backbones connected to a single PE
6. VPN Topology and Membership Discovery
The virtual router approach explicitly separates the mechanisms used
for distributing reachability information from mechanisms used for
achieving VPN topology determination. VPN membership information
refers to the set of PEs that have customers in a particular VPN.
VPN topology represents the set of PEs and their interconnectivity.
The topology can be a full-mesh of PEs, a hub and spoke, or anything
in between. Dynamic topology can also be handled due to on-demand
VPN customers.
VPN membership discovery can be achieved through different
mechanisms, for example [VPN-ITU]:
. Directory server approach, which VRs query a server to determine
their neighbors.
. Explicit configuration via a management platform.
. Piggybacking VPN information using existing routing protocols
(e.g., BGP) [VPN-BGP].
The above mechanisms can be combined on a single PE. As an example,
for some VPNs topology discovery is done only through a management
Ould-Brahim, et al. July 2000 [Page 9]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
platform. For others, dynamic topology discovery is achieved using
existing routing protocol [VPN-BGP].
7. Operations and Management
One of the greatest strengths of the VR approach to VPN creation is
that all the existing tools for operating, managing and debugging IP
networks can continue to be used without modification. All the
standard MIBs, such as the forwarding/route table and interface MIBs
are available.
In case of PE failure (e.g. migration, upgrades, etc.), the service
provider may want to control and decide what VPN services gets
reestablished first. This particular point is important when a large
number of VPNs is supported on the PE where each VPN service has
different service availability requirements.
Since each VR operates as an independent router, it is possible for
the management of the VRs to be outsourced. VPN customers may
choose to configure (or perhaps only to monitor) the VRs that make
up their VPN. It is also possible that the backbone VRs could be
managed by a separate entity. Each VR operates independently, and
can be individually reconfigured without effecting other VRs on the
same PE. In some implementations, it may even be possible for a VR
to be "rebooted" by a customer without effecting other VRs.
7.1 Backbone Migration
One benefit in using multiple backbone virtual routers is the
ability for the backbone network administrator to migrate its
backbone from one core technology to another with minimal disruption
to VPN services. Indeed a VPN configuration change or a VPN-software
upgrade is totally transparent to the backbone protocol and policies
(this is due to decoupling the VPN routing protocol from the
provider backbone routing protocol).
7.2 Troubleshooting
The service provider or the VPN customer can use all existing
troubleshooting tools per VPN basis (e.g. ping and traceroute). As
an example a VPN customer can telnet to its own VR and performs some
troubleshooting operations. In this particular case, the service
provider can configure for each VPN customer restricted privileges
over the virtual router associated with the customer VPN network.
However, backbone topology information is completely hidden to the
VPN VR, and therefore to the service provider customer.
Ould-Brahim, et al. July 2000 [Page 10]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
8. Quality of Service
This architecture can utilize different quality of service
mechanisms. QoS mechanisms developed for physical routers can be
used with VRs, on a per-VR basis. e.g. classification, policing,
drop policies, traffic shaping and scheduling/bandwidth reservation.
The architecture allows separate quality of service engineering of
the VPNs and the backbone.
9. Scalability
Only the PEs are handling the VPN type information. The internal
backbone routers (the P routers) are not VPN aware. Furthermore,
virtual routers allow multiple privates CE based networks to connect
to a single PE.
One advantage of the ability to contain the VPN address space and
VPN routing and forwarding capabilities within the virtual router
entity is the possibility to distribute PE system resources per VPN
basis. Indeed, as an example, different scheduling mechanisms can be
used for processing each VPN activity within the PE. This type of
per VPN resource management contributes in establishing a wide range
of priority schemes among VPNs within the PE.
10. Security Considerations
Different levels of data, routing and configuration security can be
implemented. Any existing security related mechanisms supported by
existing routing protocols (e.g. authentication) can be used
unmodified in the VR architecture. If IPSec tunneling is used as the
tunneling protocol, then both the control and data traffic that
travels over the tunnel can be secured; so that routing specific
security enhancements are not needed. Any private routing,
forwarding and addressing manipulation are done within the virtual
router context. Direct layer-2 connections (ATM, FR), or specific
tunneling mechanisms can also provide different levels of data
security.
11. References
[GRE-RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[CR-LDP] Jamoussi, B., et al, "Constraint-based LSP Setup using
LDP", Work in Progress.
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
Ould-Brahim, et al. July 2000 [Page 11]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
[RFC-2401] Kent S., Atkinson R., "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[RFC-2411] Thayer, R., et al, "IP Security Document Roadmap", RFC
2411, November 1998.
[RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP",
RFC2661, August 1999.
[RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[VPN-CORE] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN
Architecture", Work in Progress
[VPN-BGP] Ould-Brahim, H., et al., "BGP/VPN: VPN Information
Discovery for network based VPNs", work in progress, July 2000.
[VPN-INW] Sumimoto, J., et al, "MPLS VPN Interworking", Work in
Progress.
[VPN-ITU] "Draft Recommendation Y.IPVPN", Study Group 13, Q20/13,
May 2000.
[VPN-RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress.
[VPN-RFC2685] Fox B., et al, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[VPN-RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual
Private Networks", RFC 2764, February 2000.
12. Acknowledgments
The authors would like to acknowledge the following individuals for
their helpful comments and suggestions: Bilel Jamoussi, David
Hudson, David Drynan, Ru Wadasinghe, Peter Ashwood-Smith, Can Aysan,
Martin Pepin, Ahmad Khalid, John Luetchford, and Don Fedyk.
13. Author's Addresses
Ould-Brahim, et al. July 2000 [Page 12]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
Hamid Ould-Brahim Bryan Gleeson
Nortel Networks Nortel Networks
P O Box 3511 Station C 2305 Mission College Blvd
Ottawa, ON K1Y 4H7 Santa Clara CA 95054
Canada USA
Phone: +1 (613) 765 3418 Phone: +1 (408) 565 2625
Email: hbrahim@nortelnetworks.com Email:bgleeson@shastanets.com
Gregory Wright Timon Sloane
Nortel Networks N.E.T
P O Box 3511 Station C 6500 PASEO Padre Parkway
Ottawa, ON K1Y 4H7 Fremont, CA 94555
Canada USA
Phone: +1 (613) 765 7912 Phone: +1 (510) 574 2477
Email: gwright@nortelnetworks.com Email:timon_sloane@net.com
Rainer Bach Rick Bubenik,
T-Data SAVVIS Communications
Hans-Guenther-Sohl-Strasse7 717 Office Parkway
40235, Duesseldorf St. Louis, Mo. 63141
Germany USA
Phone: 49 211 694 2420 Phone: +1 (314) 468-7021
Email: Rainer.Bach@telekom.de rickb@savvis.net
Abraham Young
HUAWEI Technologies Co., LTD.
Kefa Road
Science-Based Industrial Park
Nanshan District, Shenzhen 518057
China
Phone: +86-755-6543662
Email: abyoung@huawei.com.cn
Ould-Brahim, et al. July 2000 [Page 13]
Internet-Draft draft-ouldbrahim-vpn-vr-01.txt January 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Ould-Brahim, et al. July 2000 [Page 14]