The receipt of the E2E Resv message with a DCLASS Object is the final
confirmation to the aggregating router of the mapping of the E2E
reservation onto an Aggregate Reservation. Under normal
circumstances, this is the only way it will be informed of this
association. It should now forward the E2E Resv to its previous hop,
following normal RSVP processing rules [RSVP].
2.9. Removal of E2E Reservation
E2E reservations are removed in the usual way via PathTear, ResvTear,
timeout, or as the result of an error condition. When they are
removed, their FLOWSPEC information must also be removed from the
allocated portion of the aggregate reservation. This same bandwidth
may be re-used for other traffic in the near future. When E2E Path
messages are removed, their SENDER_TSPEC information must also be
removed from the aggregate Path.
2.10. Removal of Aggregate Reservation
Should an aggregate reservation go away (presumably due to a
configuration change, route change, or policy event), the E2E
reservations it supports are no longer active. They must be treated
accordingly.
2.11. Handling of Data On Reserved E2E Flow by Aggregating Router
Prior to establishment that a given E2E flow is part of a given
aggregate, the flow's data should be treated as traffic without a
reservation by whatever policies prevail for such. Generally, this
will mean being given the same forwarding behavior as best effort
traffic. However, upon establishing that the flow belongs to a given
aggregate, the aggregating router is responsible for marking any
related traffic with the correct DSCP and forwarding it in the manner
appropriate to traffic on that reservation. This may imply
forwarding it to a given IP next hop, or piping it down a given link
layer circuit, tunnel, or MPLS label switched path.
The aggregator is responsible for performing per-reservation policing
on the E2E flows that it is aggregating. The aggregator performs
metering of traffic belonging to each reservation to assess
compliance to the token bucket for the corresponding E2E reservation.
Packets which are assessed in compliance are forwarded as mentioned
above. Packets which are assessed out of compliance must be either
dropped, reshaped or marked to a different DSCP. The detailed
policing behavior is an aspect of the service mapping described in
[RFC2998].
2.12. Procedures for Multicast Sessions
Because of the difficulties of aggregating multicast sessions
described above, we focus on the aggregation of scheduling and
classification state in the multicast case. The main difference
between the multicast and unicast cases is that rather than sending
an aggregate Path message to the unicast address of a single
deaggregating router, in the multicast case we send the "aggregate"
Path message to the same group address as the E2E session. This
ensures that the aggregate Path message follows the same route as the
E2E Path. This difference between unicast and multicast is reflected
in the Session objects defined below. A consequence of this approach
is that we continue to have reservation state per multicast session
inside the aggregation region.
A further challenge arises in multicast sessions with heterogeneous
receivers. Consider an interior router which must forward packets
for a multicast session on two interfaces, but has only received a
reservation request on one of those interfaces. It receives packets
marked with the DSCP chosen for the aggregate reservation. When
sending them out the interface which has no installed reservation, it
has the following options:
a) remark those packets to best effort before sending them out the
interface;
b) send the packets out the interface with the DSCP chosen for the
aggregate reservation.
The first approach suffers from the drawback that it requires nMF
classification at an interior router in order to recognize the flows
whose packets must be demoted. The second approach requires over-
reservation of resources on the interface on which no reservation was
received. In the absence of such over-reservation, the packets sent
with the "wrong" DSCP would be able to degrade the service
experienced by packets using that DSCP legitimately.
To make MF classification acceptable in an interior router, it may be
possible to treat the case of heterogeneous flows as an exception.
That is, an interior router only needs to be able to recognize those
individual microflows that have heterogeneous resource needs on the
outbound interfaces of this router.
3. Protocol Elements
3.1. IP Protocol RSVP-E2E-IGNORE
This specification requires the assignment of a protocol type RSVP-
E2E-IGNORE, whose number is at this point 134. This is used only on
E2E messages which require a router alert (Path, PathTear, and
ResvConf), and signifies that the message must be treated one way
when destined to an interior interface, and another way when destined
to an exterior interface. The protocol type is swapped by the
Aggregator from RSVP to RSVP-E2E-IGNORE in E2E Path, PathTear, and
ResvConf messages when they enter the Aggregation Region. The
protocol type is swapped back by the Deaggregator from RSVP-E2E-
IGNORE to RSVP in such E2E messages when they exit the Aggregation
Region.
3.2. Path Error Code
A PathErr code NEW-AGGREGATE-NEEDED is required. This value does not
signify that a fatal error has occurred, but that an action is
required of the aggregating router to avoid an error condition in the
near future.
3.3. SESSION Object
The SESSION object contains two values: the IP Address of the
aggregate session destination, and the DSCP that it will use on the
E2E data the reservation contains. For unicast sessions, the session
destination address is the address of the deaggregating router. For
multicast sessions, the session destination is the multicast address
of the E2E session (or sessions) being aggregated. The inclusion of
the DSCP in the session allows for multiple sessions toward the same
address to be distinguished by their DSCP and queued separately. It
also provides the means for aggregating scheduling and classification
state. In the case where a session uses a pair of PHBs (e.g., AF11
and AF12), the DSCP used should represent the numerically smallest
PHB (e.g., AF11). This follows the same naming convention described
in [BRIM].
Session types are defined for IPv4 and IPv6 addresses.
o IP4 SESSION object: Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = SESSION,
C-Type = RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Session Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
3.4. SENDER_TEMPLATE Object
The SENDER_TEMPLATE object identifies the aggregating router for the
aggregate reservation.
o IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
3.5. FILTER_SPEC Object
The FILTER_SPEC object identifies the aggregating router for the
aggregate reservation, and is syntactically identical to the
SENDER_TEMPLATE object.
4. Policies and Algorithms For Predictive Management Of Blocks Of
Bandwidth
The exact policies used in determining how much bandwidth should be
allocated to an aggregate reservation at any given time are beyond
the scope of this document, and may be proprietary to the service
provider in question. However, here we explore some of the issues
and suggest approaches.
In short, the ideal condition is that the aggregate reservation
always has enough resources to allocate to any E2E reservation that
requires its support, and never takes too much. Simply stated, but
more difficult to achieve. Factors that come into account include
significant times in the diurnal cycle: one may find that a large
number of people start placing calls at 8:00 AM, even though the hour
from 7:00 to 8:00 is dead calm. They also include recent history: if
more people have been placing calls recently than have been
finishing them, a prediction of the necessary bandwidth a few moments
hence may call for more bandwidth than is currently allocated.
Likewise, at the end of a busy period, we may find that the trend
calls for declining reservation amounts.
We recommend a policy something along this line. At any given time,
one should expect that the amount of bandwidth required for the
aggregate reservation is the larger of the following:
(a) a requirement known a priori, such as from history of the diurnal
cycle at a particular week day and time of day, and
(b) the trend line over recent history, with 90 or 99% statistical
confidence.
We further expect that changes to that aggregate reservation would be
made no more often than every few minutes, and ideally perhaps on
larger granularity such as fifteen minute intervals or hourly. The
finer the granularity, the greater the level of signaling required,
while the coarser the granularity, the greater the chance for error,
and the need to recover from that error.
In general, we expect that the aggregate reservation will not ever
add up to exactly the sum of the reservations it supports, but rather
will be an integer multiple of some block reservation size, which
exceeds that value.
5. Security Considerations
Numerous security issues pertain to this document; for example, the
loss of an aggregate reservation to an aggressor causes many calls to
operate unreserved, and the reservation of a great excess of
bandwidth may result in a denial of service. However, these issues
are not confined to this extension: RSVP itself has them. We believe
that the security mechanisms in RSVP address these issues as well.
One security issue specific to RSVP aggregation involves the
modification of the IP protocol number in RSVP Path messages that
traverse an aggregation region. If that field were maliciously
modified in a Path message, it would cause the message to be ignored
by all subsequent devices on its path, preventing reservations from
being made. It could even be possible to correct the value before it
reached the receiver, making it difficult to detect the attack. In
theory, it might also be possible for a node to modify the IP
protocol number for non-RSVP messages as well, thus interfering with
the operation of other protocols.
One way to mitigate the risks of malicious modification of the IP
protocol number is to use an IPSEC authentication header, which would
ensure that malicious modification of the IP header is detected.
This is a desirable approach but imposes some administrative burden
in the form of key management for authentication purposes.
It is RECOMMENDED that implementations of this specification only
support modification of the IP protocol number for RSVP Path,
PathTear, and ResvConf messages. That is, a general facility for
modification of the IP protocol number SHOULD NOT be made available.
Network operators deploying routers with RSVP aggregation capability
should be aware of the risks of inappropriate modification of the IP
protocol number and should take appropriate steps (physical security,
password protection, etc.) to reduce the risk that a router could be
configured by an attacker to perform malicious modification of the
protocol number.
6. IANA Considerations
Section 1.2 proposes a new protocol type, RSVP-E2E-IGNORE, which is
used to identify a message that routers in the network core will see;
further processing of such messages may or may not be required,
depending on the egress interface type, as described in Section 1.2.
The IANA assigned IP protocol number 134, in accordance with
[RFC2780], meeting the Standards Track publication criterion.
Section 1.4.9 describes the manner in which the Router Alert is used
in the context of this specification, which is essentially a simple
counter of the depth of nesting of aggregation. The IPv4 Router
Alert [RFC2113] has the option simply to ask the router to look at
the protocol type of the intercepted datagram and decide what to do
with it; the parameter is additional information to that decision.
The IPv6 Router Alert [RFC2711] turns the parameter into an option
sub-type. As a result, the IPv6 router alert option may not be used
algorithmically in the context of the protocol in question. The IANA
assigned a block of 32 values (3-35, "Aggregated Reservation Nesting
Level") which we may map to nesting depths 0..31, hoping that 32
levels is enough.
Section 3.2 discusses a new, required path error code. The IANA has
assigned RSVP Parameters Error Code 26 to NEW-AGGREGATE-NEEDED.
Sections 3.3, 3.4, and 3.5 describe extensions to three object
classes: Session, Filter Specification, and Sender Template. The
IANA has assigned two new common C-Types to be specified for the
aggregator's address. RSVP-AGGREGATE-IP4 is C-Type 9 and RSVP-
AGGREGATE-IP6 is C-Type 10. In adding these C-types to IANA RSVP
Class Names, Class Numbers and Class Types registry, the same
numbering for them is used in all three Classes, as is done for IPv4
and IPv6 address tuples in [RSVP].
7. Acknowledgments
The authors acknowledge that published documents and discussion with
several people, notably John Wroclawski, Steve Berson, and Andreas
Terzis materially contributed to this document. The design is
influenced by the RSVP tunnels document [TERZIS].
APPENDIX 1: Example Signalling Flow For First E2E Flow
This Appendix does not provide additional specification. It only
illustrates the specification detailed above through a possible flow
of RSVP signalling messages involved in the successful establishment
of a unicast E2E reservation which is the first between a given pair
of Aggregator/Deaggregator.
Aggregator Deaggregator
E2E Path
---------------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed, DCLASS=x)
<-------------------------------
E2E PathErr(New-agg-needed, DCLASS=y)
<-------------------------------
(3)
AggPath(DSCP=x)
------------------------------->
AggPath(DSCP=y)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (DSCP=x)
<-------------------------------
AggResv (DSCP=y)
<-------------------------------
(6)
AggResvConfirm (DSCP=x)
------------------------------>
AggResvConfirm (DSCP=y)
------------------------------>
(7)
E2E Resv
<----------
(8)
E2E Resv (DCLASS=x)
<-----------------------------
(9)
E2E Resv
<---------------
(1) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(2) Let's assume no Aggregate Path exists. To be able to accurately
update the ADSPEC of the E2E Path, the Deaggregator needs the
ADSPEC of Aggregate PATH. In this example the Deaggregator
elects to instruct the Aggregator to set up Aggregate Path
states for the two supported DSCPs by sending a New-Agg-Needed
PathErr code for each DSCP.
(3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both DSCPs.
(4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Path and updates the E2E Path
ADSPEC accordingly. The Deaggregator also modifies the E2E Path
IP Protocol Number to RSVP before forwarding it.
(5) In this example, the Deaggregator elects to immediately proceed
with establishment of Aggregate Reservations for both DSCPs. In
effect, the Deaggregator can be seen as anticipating the actual
demand of E2E reservations so that resources are available on
Aggregate Reservations when the E2E Resv requests arrive in
order to speed up establishment of E2E reservations. Assume
also that the Deaggregator includes the optional Resv Confirm
Request in these Aggregate Resv.
(6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(7) The Deaggregator has explicit confirmation that both Aggregate
Resv are established.
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto an Aggregate Reservation. Let's assume that this policy is
such that the E2E reservation is to be mapped onto the Aggregate
Reservation with DSCP=x. The Deaggregator knows that an
Aggregate Reservation is in place for the corresponding DSCP
since (7). The Deaggregator performs admission control of the
E2E Resv onto the Aggregate Resv for DSCP=x. Assuming that the
Aggregate Resv for DSCP=x had been established with sufficient
bandwidth to support the E2E Resv, the Deaggregator adjusts its
counter tracking the unused bandwidth on the Aggregate
Reservation and forwards the E2E Resv to the Aggregator
including a DCLASS object conveying the selected mapping onto
DSCP=x.
(9) The Aggregator records the mapping of the E2E Resv onto DSCP=x.
The Aggregator removes the DCLASS object and forwards the E2E
Resv towards the sender.
APPENDIX 2: Example Signalling Flow For Subsequent E2E Flow Without
Reservation Resizing
This Appendix does not provide additional specification. It only
illustrates the specification detailed above through a possible flow
of RSVP signalling messages involved in the successful establishment
of a unicast E2E reservation which follows other E2E reservations
between a given pair of Aggregator/Deaggregator. This flow could be
imagined as following the flow of messages illustrated in Appendix 1.
Aggregator Deaggregator
E2E Path
---------------->
(10)
E2E Path
------------------------------->
(11)
E2E Path
----------->
E2E Resv
<-----------
(12)
E2E Resv (DCLASS=x)
<-----------------------------
(13)
E2E Resv
<---------------
(10) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(11) Because previous E2E reservations have been established, let's
assume that Aggregate Path exists for all supported DSCPs. The
Deaggregator takes into account the information contained in the
ADSPEC from the Aggregate Paths and updates the E2E Path ADSPEC
accordingly. The Deaggregator also modifies the E2E Path IP
Protocol Number to RSVP before forwarding it.
(12) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto an Aggregate Reservation. Let's assume that this policy is
such that the E2E reservation is to be mapped onto the Aggregate
Reservation with DSCP=x. Because previous E2E reservations have
been established, let's assume that an Aggregate Reservation is
in place for DSCP=x. The Deaggregator performs admission
control of the E2E Resv onto the Aggregate Resv for DSCP=x.
Assuming that the Aggregate Resv for DSCP=x has sufficient
unused bandwidth to support the new E2E Resv, the Deaggregator
then adjusts its counter tracking the unused bandwidth on the
Aggregate Reservation and forwards the E2E Resv to the
Aggregator including a DCLASS object conveying the selected
mapping onto DSCP=x.
(13) The Aggregator records the mapping of the E2E Resv onto DSCP=x.
The Aggregator removes the DCLASS object and forwards the E2E
Resv towards the sender.
APPENDIX 3: Example Signalling Flow For Subsequent E2E Flow With
Reservation Resizing
This Appendix does not provide additional specification. It only
illustrates the specification detailed above through a possible flow
of RSVP signalling messages involved in the successful establishment
of a unicast E2E reservation which follows other E2E reservations
between a given pair of Aggregator/Deaggregator. This flow could be
imagined as following the flow of messages illustrated in Appendix 2.
Aggregator Deaggregator
E2E Path
---------------->
(14)
E2E Path
------------------------------->
(15)
E2E Path
----------->
E2E Resv
<-----------
(16)
AggResv (DSCP=x, increased Bw)
<-------------------------------
(17)
AggResvConfirm (DSCP=x, increased Bw)
------------------------------>
(18)
E2E Resv (DCLASS=x)
<-----------------------------
(19)
E2E Resv
<---------------
(14) Aggregator forwards E2E Path into aggregation region after
modifying its IP Protocol Number to RSVP-E2E-IGNORE
(15) Because previous E2E reservations have been established, let's
assume that Aggregate Path exists for all supported DSCPs. The
Deaggregator takes into account the information contained in the
ADSPEC from the Aggregate Paths and updates the E2E Path ADSPEC
accordingly. The Deaggregator also modifies the E2E Path IP
Protocol Number to RSVP before forwarding it.
(16) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto an Aggregate Reservation. Let's assume that this policy is
such that the E2E reservation is to be mapped onto the Aggregate
Reservation with DSCP=x. Because previous E2E reservations have
been established, let's assume that an Aggregate Reservation is
in place for DSCP=x. The Deaggregator performs admission
control of the E2E Resv onto the Agg Resv for DSCP=x. Let's
assume that the Aggregate Resv for DSCP=x does NOT have
sufficient unused bandwidth to support the new E2E Resv. The
Deaggregator then attempts to increase the Aggregate Reservation
bandwidth for DSCP=x by sending a new Aggregate Resv with an
increased bandwidth sufficient to accommodate all the E2E
reservations already mapped onto that Aggregate reservation plus
the new E2E reservation plus possibly some additional spare
bandwidth in anticipation of additional E2E reservations to
come. Assume also that the Deaggregator includes the optional
Resv Confirm Request in these Aggregate Resv.
(17) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(18) The Deaggregator has explicit confirmation that the Aggregate
Resv has been successfully increased. The Deaggregator performs
again admission control of the E2E Resv onto the increased
Aggregate Reservation for DSCP=x. Assuming that the increased
Aggregate Reservation for DSCP=x now has sufficient unused
bandwidth and resources to support the new E2E Resv, the
Deaggregator then adjusts its counter tracking the unused
bandwidth on the Aggregate Reservation and forwards the E2E Resv
to the Aggregator including a DCLASS object conveying the
selected mapping onto DSCP=x.
(19) The Aggregator records the mapping of the E2E Resv onto DSCP=x.
The Aggregator removes the DCLASS object and forwards the E2E
Resv towards the sender.
References
[CSZ] Clark, D., S. Shenker, and L. Zhang, "Supporting Real-
Time Applications in an Integrated Services Packet
Network: Architecture and Mechanism," in Proc.
SIGCOMM'92, September 1992.
[IP] Postel, J., "Internet Protocol", STD 5, RFC791,
September 1981.
[HOSTREQ] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC1122, October 1989.
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC2474, December
1998.
[PRINCIPLES] Carpenter, B., "Architectural Principles of the
Internet", RFC1958, June 1996.
[ASSURED] Heinanen, J, Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC2597, June 1999.
[BROKER] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC2638, June 1999.
[BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop
Behavior Identification Codes", RFC2836, May 2000.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP) Version 1
Functional Specification", RFC2205, September 1997.
[TERZIS] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC2746, January
2000.
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[INTEGRITY] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC2747, January 2000.
[RFC2998] Bernet Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
Felstaine, "Integrated Services Operation Over Diffserv
Networks", RFC2998, November 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P. and F.
Tommasi, "RSVP Refresh Reduction Extensions", RFC2961,
April 2001.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines
For Values In the Internet Protocol and Related
Headers", RFC2780, March 2000.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC2711, October 1999.
[RFC2113] Katz, D. "IP Router Alert Option", RFC2113, February
1997.
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA, 93117 USA
Phone: (408) 526-4257
EMail: fred@cisco.com
Carol Iturralde
Cisco Systems
250 Apollo Drive
Chelmsford MA, 01824 USA
Phone: 978-244-8532
EMail: cei@cisco.com
Francois Le Faucheur
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06410 Biot - Sophia Antipolis
France
Phone: +33.4.97.23.26.19
EMail: flefauch@cisco.com
Bruce Davie
Cisco Systems
250 Apollo Drive
Chelmsford MA,01824 USA
Phone: 978-244-8921
EMail: bdavie@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
document itself may not be modified in any way, such as by 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.