Internet Draft Juniper Networks
Expiration Date: Dec 2005
Dirk Steinberg
Deutsche Telekom AG
Andrea De Carolis
Telecom Italia
BGP-MPLS IP VPN extensions for ISO/CLNS VPN
draft-vohra-l3vpn-bgp-clns-00.txt
1. Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 July 7, 2005.
Vohra et al. [Page 1]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
2. Copyright Notice
Copyright (C) The Internet Society (2005).
3. Abstract
This document describes a method by which a Service Provider may use
its packet switched backbone to provide Virtual Private Network
services for its ISO/CLNS customers. These customers may be islands
of ISO/CLNS networks which are part of the Service Provider network
itself and are interconnected by the Service Provider's IP core. This
method reuses the 2547 style BGP-MPLS VPN model. This document
defines an ISO/CLNS VPN address family and describes the
corresponding ISO/CLNS VPN route distribution mechanism using
"Multiprotocol BGP".
4. Introduction
This document describes a mechanism by which a Service Provider may
use its packet switched backbone to provide Virtual Private Network
services for its ISO/CLNS customers.
This mechanism reuses, and extends where necessary, the "BGP/MPLS IP
VPN" mechanism [2547bis] in support of ISO/CLNS. In particular, this
method uses the same "peer model" as [2547bis], in which the
customers' edge routers ("CE routers") send their ISO/CLNS routes to
the Service Provider's edge routers ("PE routers"). BGP ("Border
Gateway Protocol", [BGP, BGP-MP]) is then used by the Service
Provider to exchange the routes of a particular ISO/CLNS VPN among
the PE routers that are attached to that ISO/CLNS VPN. Eventually,
the PE routers distribute, to the CE routers in a particular VPN, the
ISO/CLNS routes from other CE routers in that VPN.
This document adopts the definitions, acronyms and mechanisms
described in [2547bis]. Unless otherwise stated, the mechanisms of
[2547bis] apply and will not be re-described here.
A VPN is said to be an ISO/CLNS VPN, when each site of this VPN is
ISO/CLNS capable and is natively connected over an ISO/CLNS interface
or sub- interface to the SP backbone via a Provider Edge device (PE).
In a similar manner to how IPv4 VPN routes are distributed in
[2547bis], BGP and its extensions are used to distribute routes from
an ISO/CLNS VPN site to all the other PE routers connected to a site
of the same ISO/CLNS VPN. PEs use "VPN Routing and Forwarding tables"
(VRFs) to separately maintain the reachability information and
Vohra et al. [Page 2]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
forwarding information of each ISO/CLNS VPN.
Each ISO/CLNS VPN will have its own ISO/CLNS address space, which
means that a given address may denote different systems in different
VPNs. This is achieved via a new address family, the VPN-ISO Address
Family. A VPN-ISO address is constructed by prepending a Route
Distinguisher to the ISO/NSAP address.
This document allows support of an ISO/CLNS VPN service over MPLS
LSPs as well as over other tunneling techniques including GRE
tunnels.
This document allows support for an ISO/CLNS VPN service over an IPv4
backbone as well as over an IPv6 backbone. The ISO/CLNS VPN service
supported is identical in both cases.
5. The VPN-ISO Address Family
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
from multiple "address families". We introduce the notion of the
"VPN-ISO address family", that is similar to the VPN-IPv4 address
family introduced in [2547bis].
A VPN-ISO address is variable in size, beginning with an 8-byte
"Route Distinguisher" (RD) and ending with a 7-bytes to 19-byte ISO
NSAP prefix. If two VPNs use the same ISO NSAP prefix (effectively
denoting different physical systems), the PEs translate these into
unique VPN-ISO address prefixes using different RDs. This ensures
that if the same address is used in two different VPNs, it is
possible to install two completely different routes to that address,
one in each VPN.
The purpose of the RD is solely to allow one to create distinct
routes to a common ISO NSAP prefix, similarly to the purpose of the
RD defined in [2547bis]. As it is possible per [2547bis], the RD can
also be used to create multiple different routes to the very same
system. This can be achieved by creating two different VPN-ISO routes
that have the same ISO NSAP prefix part, but different RDs. This
allows BGP to install multiple different routes to the same system,
and allows policy to be used to decide which packets use which route.
Note that VPN-ISO address prefixes and ISO NSAP prefixes are always
considered by BGP to be incomparable.
A VRF may have multiple equal-cost VPN-ISO routes for a single ISO
NSAP prefix. When a packet's destination address is matched in a VRF
Vohra et al. [Page 3]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
against a VPN-ISO route, only the ISO NSAP prefix part is actually
matched.
The Route Distinguisher format and encoding is as specified in
[2547bis].
6. VPN-ISO route distribution
6.1. Route Distribution Among PEs by BGP
As described in [2547bis], if two sites of a VPN attach to PEs which
are in the same Autonomous System, the PEs can distribute VPN routes
to each other by means of an (IPv4 or IPv6) iBGP connection between
them. Alternatively, each PE can have iBGP connections to route
reflectors. Similarly, for ISO/CLNS VPN route distribution, PEs can
use iBGP connections between them or use iBGP connections to route
reflectors. For ISO/CLNS VPN, the iBGP connections MAY be over IPv4
or over IPv6.
The PE routers exchange, via MP-BGP [MP-BGP], reachability
information for the ISO NSAP prefixes in the ISO/CLNS VPNs and
thereby announce themselves as the BGP Next Hop.
The rules for encoding the reachability information and the BGP Next
Hop address are specified in the following sections.
6.2. VPN ISO/CLNS NLRI encoding
When distributing ISO/CLNS VPN routes, the advertising PE router MUST
assign and distribute MPLS labels with the ISO/CLNS VPN routes.
Essentially, PE routers do not distribute ISO/CLNS VPN routes, but
Labeled ISO/CLNS VPN routes [MPLS-BGP]. When the advertising PE then
receives a packet that has this particular advertised label, the PE
will pop the MPLS stack, and process the packet appropriately (i.e.
forward it directly based on the label or perform a lookup in the
corresponding ISO/CLNS VPN context).
The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the
ISO/CLNS VPN routes in the MP_REACH NLRI. The AFI and SAFI fields
MUST be set as follows:
- AFI: 3; for ISO NSAP
- SAFI: 128; for MPLS labeled VPN unicast
Vohra et al. [Page 4]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
The NLRI field itself is encoded as specified in [MPLS-BGP]. In the
context of this extension, the prefix belongs to the VPN-ISO Address
Family and thus consists of an 8-byte Route Distinguisher followed by
an ISO NSAP prefix as specified in section 5 above.
6.2.1. BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the
BGP speaker is to request that ISO/CLNS VPN traffic be transported to
that BGP Next Hop using IPv4 signalled MPLS LSPs or GRE over IPv4
tunnels ("BGP speaker requesting IPv4/MPLS transport") or using IPv6
signalled MPLS LSPs or GRE over IPv6 tunnels ("BGP speaker requesting
IPv6/MPLS transport").
Definition of this policy is the responsibility of the network
operator and is beyond the scope of this document. We note that it is
possible for that policy to request IPv4/MPLS (resp. IPv6/MPLS)
transport while the BGP speakers exchange ISO/CLNS VPN reachability
information over IPv6 (resp. IPv4). However, in that case, a number
of operational implications are worth considering. In particular, an
undetected fault affecting the IPv4/MPLS (resp. IPv6/MPLS) transport
path and not affecting the IPv6 (resp. IPv4) data path, could remain
undetected by BGP, which in turn may result in blackholing of
traffic.
Control of this policy is beyond the scope of this document and may
be based on user configuration.
6.2.2. BGP Speaker requesting IPv4/MPLS transport
When the ISO/CLNS VPN traffic is to be transported to the BGP speaker
using IPv4 signalled MPLS LSPs or GRE over IPv4 tunnels, the BGP
speaker SHALL advertise to its peer a Next Hop Network Address field
containing a VPN-ISO address:
- whose 8-byte RD is set to zero, and
- whose ISO NSAP address is encoded as an IPv4-mapped ISO NSAP
address as specified in [RFC986] containing the IPv4 address of
the advertising BGP speaker. This IPv4 address must be routable by
the other BGP Speaker.
The value of the Length of the Next Hop Network Address field in the
MP_REACH_NLRI attribute shall be set to 17, where the RD accounts for
8 bytes and the IPv4-mapped ISO NSAP accounts for the remaining 9
bytes.
Vohra et al. [Page 5]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
6.2.3. BGP speaker requesting IPv6/MPLS tranpsport
When the ISO/CLNS VPN traffic is to be transported to the BGP speaker
using IPv6 singalled MPLS LSPs or GRE over IPv6 tunnels, the BGP
speaker SHALL advertise a Next Hop Network Address field containing a
VPN-ISO address:
- whose 8-byte RD is set to zero, and
- whose ISO NSAP address is encoded as an IPv6-mapped ISO NSAP
address as specified in [RFC1888] containing the IPv6 address of
the
advertising BGP speaker. This IPv6 address must be routable by the
other BGP Speaker.
The value of the Length of the Next Hop Network Address field in the
MP_REACH_NLRI attribute shall be set to 28, where the RD accounts for
8 bytes and the IPv6-mapped ISO NSAP accounts for the remaining 20
bytes.
6.3. Route Target
The use of route target is specified in [2547bis] and applies to
ISO/CLNS VPNs. Encoding of the extended community attribute is
defined in [BGP-EXTCOM].
6.4. BGP Capability Negotiation
In order for two PEs to exchange labeled ISO/CLNS VPN NLRIs, they
MUST use BGP Capabilities Negotiation to ensure that they both are
capable of properly processing such NLRIs. This is done as specified
in [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol
BGP), with AFI and SAFI values as specified above in section 6.2.
Vohra et al. [Page 6]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
7. Encapsulation
The ingress PE Router MUST transport ISO/CLNS VPN data over the
backbone towards the Egress PE router identified as the BGP Next Hop
for the corresponding destination ISO/CLNS VPN prefix.
When the ISO NSAP contained in the BGP Next Hop field is encoded as
an IPv4-mapped ISO/NSAP address (see section 6.2.2), the ingress PE
MUST use either IPv4 signalled MPLS LSPs or GRE over IPv4 tunnels .
When the ISO NSAP contained in the BGP Next Hop field is encoded as
an IPv6-mapped ISO/NSAP address (see section 6.2.3), the ingress PE
MUST use either IPv6 signalled MPLS LSPs or GRE over IPv6 tunnels.
When a PE receives a packet from an attached CE, it looks up the
packet's ISO destination NSAP in the VRF corresponding to that CE.
This enables it to find a VPN-ISO route. The VPN-ISO route will have
an associated MPLS label and an associated BGP Next Hop. First, this
MPLS label is pushed on the packet as the bottom label. Then, this
labeled packet is encapsulated into an MPLS LSP or a GRE tunnel for
transport to the egress PE identified by the BGP Next Hop. Details of
this encapsulation depend on the actual tunneling technique as
follows:
As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done
using IPv4 GRE tunnels or IPv6 GRE tunnels, encapsulation of the
labeled ISO/CLNS VPN packet results in an MPLS-in-GRE encapsulated
packet as specified in [MPLS-in-GRE]. The IPsec Transport Mode could
be used to secure this GRE tunnel from ingress PE to egress PE.
When tunneling is done using IPv4 GRE tunnels (whether IPsec secured
or not), the Ingress PE Router MUST use the IPv4 address which is
encoded in the IPv4-mapped ISO NSAP field of the BGP next hop field,
as the destination address of the prepended IPv4 tunneling header. It
uses one of its IPv4 addresses as the source address of the prepended
IPv4 tunneling header.
When tunneling is done using IPv6 GRE tunnels (whether IPsec secured
or not), the Ingress PE Router MUST use the IPv6 address which is
encoded in the IPv6-mapped ISO NSAP field of the BGP next hop field,
as the destination address of the prepended IPv6 tunneling header. It
uses one of its IPv6 addresses as the source address of the prepended
IPv6 tunneling header.
When tunneling is done using MPLS LSPs, the LSPs can be established
using any label distribution technique (LDP [LDP], RSVP-TE [RSVP-
TE]). Nevertheless, to ensure interoperability among systems that
mplement this VPN architecture using MPLS LSPs as the tunneling
technology, all such systems MUST support LDP [LDP].
Vohra et al. [Page 7]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
When tunneling is done using MPLS LSPs, the ingress PE Router MUST
directly push the LSP tunnel label on the label stack of the labeled
ISO/CLNS VPN packet (i.e. without prepending any IPv4 or IPv6
header). This pushed label corresponds to the LSP starting on the
ingress PE Router and ending on the egress PE Router. The BGP Next
Hop field is used to identify the egress PE router and in turn the
label to be pushed on the stack. In case the ISO NSAP in the BGP Next
Hop field is a IPv4-mapped (IPv6-mapped) ISO NSAP, the embedded IPv4
(IPv6) address will determine the tunnel label to push on the label
stack.
8. Multi-AS Backbones
The same procedures described in section 10 of [2547bis] can be used
(and have the same scalability properties) to address the situation
where two sites of an ISO/CLNS VPN are connected to different
Autonomous Systems. However some additional points should be noted
when applying these procedures for ISO/CLNS VPNs; these are further
described in the remainder of this section.
Approach (a): VRF-to-VRF connections at the AS (Autonomous System)
border routers.
This approach is the equivalent for ISO/CLNS VPNs to procedure (a)
described in section 10 of [2547bis]. In the case of ISO/CLNS VPNs,
ISO/CLNS needs to be activated on the inter-ASBR VRF-to-VRF
(sub)interfaces. In this approach, the ASBRs exchange ISO/CLNS routes
(as opposed to VPN-ISO routes). These routes may be exchanged via BGP
by using multiprotocol extensions to BGP. The specification of such a
mechanism is outside the scope of this document and may be specified
in a separate document in future. This method does not require the
use of inter-AS LSPs.
Finally note that with this procedure, every AS implements its own
intra-AS transport procedure, independent of other ASes, for
transporting ISO/CLNS VPN traffic.
Approach (b): EBGP redistribution of labeled VPN-ISO routes from AS
to neighboring AS
This approach is the equivalent for ISO/CLNS VPNs to procedure (b)
described in section 10 of [2547bis]. With this approach, the ASBRs
use EBGP to redistribute labeled VPN-ISO routes to ASBRs in other
ASes.
With this approach, the ASBR routers exchanging VPN-ISO routes need
not be ISO/CLNS capable if they peer over IPv4 or IPv6. In that case
Vohra et al. [Page 8]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
ASBRs need only understand the ISO/CLNS VPN NLRI. The exchange of
labeled VPN-ISO routes MUST be carried out as described in this
document. If the ASBR routers peer over IPv4 (IPV6), the BGP Next Hop
Field SHALL contain an IPv4-mapped ISO NSAP (IPv6-mapped ISO NSAP).
ISO/CLNS traffic corresponding to a labeled VPN-ISO route is
transported from one ASBR to another directly over the MPLS label
associated with that route. No further tunnelling is required if the
peering ASBR routers are directly connected.
As such the corresponding (security) considerations described for
procedure (b) in section 10 of [2547bis] apply equally to this
approach for CLNS.
Finally note that with this procedure, every AS implements its own
intra-AS transport procedure (IPv4/IPv6 signalled MPLS LSPs or GRE
over IPv4/IPv6 tunnelling), independent of other ASes, for
transporting ISO/CLNS VPN traffic.
approach (c) : Multihop EBGP redistribution of labeled VPN-ISO routes
between source and destination ASes, with EBGP redistribution of
labeled IPv4 or IPv6 routes from AS to neighboring AS.
This approach is the equivalent for exchange of VPN-ISO routes to
procedure (c) described in section 10 of [2547bis] for exchange of
VPN-IPv4 routes.
This approach requires that the participating ASes either all use
IPv4-mapped ISO address in the BGP Next Hop Field or alternatively
all use IPv6-mapped ISO address in the BGP Next Hop Field.
In this approach, VPN-ISO routes are neither maintained nor
distributed by the ASBR routers. The ASBR routers need not be
ISO/CLNS capable. An ASBR needs to maintain labeled IPv4 (or IPv6)
routes to the PE routers within its AS. It uses EBGP to distribute
these routes to other ASes. ASBRs in any transit ASes will also have
to use EBGP to pass along the labeled IPv4 (or IPv6) routes. This
results in the creation of a label switched path from ingress PE
router to egress PE router whose destination is indentified by the
IPv4 (IPv6) address of the nexthop PE. Now PE routers in different
ASes can establish multi-hop EBGP connections to each other over IPv4
or IPv6, and can exchange labeled VPN-ISO routes over those EBGP
connections. Note that the BGP Next Hop field of these distributed
VPN-ISO routes will contain an IPv4-mapped ISO NSAP (IPv6-mapped ISO
NSAP).
The considerations described for procedure (c) in section 10 of
[2547bis] with respect to possible use of route-reflectors, with
respect to possible use of a third label, and with respect to LSPs
Vohra et al. [Page 9]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
spanning multiple ASes apply equally to this ISO/CLNS VPN approach.
9. Security Considerations
The security considerations discussed for IPv4 VPNs in section 13 of
[2547bis] are equally applicable to ISO/CLNS VPNs.
10. Scalability
The scalability considerations summarized for IPv4 VPNs in section 15
of [2547bis] are equally applicable to ISO/CLNS VPNs.
11. IANA Considerations
This document specifies (see section 6.2) the use of the BGP AFI
(Address Family Identifier) value 3, along with the BGP SAFI
(Subsequent Address Family Identifier) value 128, to represent the
address family "VPN-ISO Labeled Addresses", which is defined in this
document.
The use of AFI value 3 for ISO/CLNS is as currently specified in the
IANA registry "Address Family Identifier", so IANA need take no
action with respect to it.
The use of SAFI value 128 is specified as "MPLS labeled VPN address"
in the IANA "Subsequent Address Family Identifier" registry. This
document is in line with this and no additional IANA action is
needed.
12. Acknowledgements
We would like to thank Pedro Marques and Yakov Rekhter who
contributed to this document, and Hannes Gredler for carefully
reviewing the document.
Vohra et al. [Page 10]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
13. Normative References
[2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis,
work in progress
[BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
Attribute", work in progress
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
for BGP4", June 2000, RFC2858
[IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460.
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
Switching Architecture", RFC3031
[MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
RFC3107
[MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
Conta, "MPLS Label Stack Encoding", RFC3032
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", November 2002, RFC3392
[MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", RFC3036
[RFC986] Callon R., Braun H., "Guidelines for the use of Internet-IP
addresses in the ISO Connectionless-Mode Network Protocol", June
1986, RFC986
[RFC1888] Bound, J., et al., "OSI NSAPs and IPv6", June 1996, RFC1888
14. Informative References
[2547-GRE] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547
VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress
[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", December 2001, RFC3209
[MPLS-in-GRE] Worster, T., et al., "Encapsulating MPLS in IP or GRE",
draft-ietf-mpls-in-ip-or-gre, work in progress
Vohra et al. [Page 11]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
15. Author Information
Quaizar Vohra
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
qv@juniper.net
Dirk Steinberg
Deutsche Telekom AG
T-Com Headquarters TE122
Am Kavalleriesand 3
D-64295 Darmstadt
Germany
dws@steinbergnet.net
Andrea De Carolis
Telecom Italia
Tel: +39 0636887162
andrea.decarolis@telecomitalia.it
16. 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
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.
Vohra et al. [Page 12]
Internet Draft draft-vohra-l3vpn-bgp-clns-00.txt November 2001
17. 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.
18. Copyright (C) The Internet Society (YYYY).
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 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.
19. Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vohra et al. [Page 13]