one's peering points. The vast majority of TE policy is based upon a
"closest exit" strategy, which offloads interdomain traffic at the
nearest outbound peer point towards the destination autonomous
system. Most methods of manipulating the point at which inbound
traffic enters a network from an EBGP peer (inconsistent route
announcements between peering points, AS pre-pending, and sending
MEDs) are either ineffective, or not accepted in the peering
community.
Inter-domain TE with BGP is generally effective, but it is usually
applied in a trial-and-error fashion. A systematic approach for
inter-domain traffic engineering is yet to be devised.
Inter-domain TE is inherently more difficult than intra-domain TE
under the current Internet architecture. The reasons for this are
both technical and administrative. Technically, while topology and
link state information are helpful for mapping traffic more
effectively, BGP does not propagate such information across domain
boundaries for stability and scalability reasons. Administratively,
there are differences in operating costs and network capacities
between domains. Generally, what may be considered a good solution
in one domain may not necessarily be a good solution in another
domain. Moreover, it would generally be considered inadvisable for
one domain to permit another domain to influence the routing and
management of traffic in its network.
MPLS TE-tunnels (explicit LSPs) can potentially add a degree of
flexibility in the selection of exit points for inter-domain routing.
The concept of relative and absolute metrics can be applied to this
purpose. The idea is that if BGP attributes are defined such that
the BGP decision process depends on IGP metrics to select exit points
for inter-domain traffic, then some inter-domain traffic destined to
a given peer network can be made to prefer a specific exit point by
establishing a TE-tunnel between the router making the selection to
the peering point via a TE-tunnel and assigning the TE-tunnel a
metric which is smaller than the IGP cost to all other peering
points. If a peer accepts and processes MEDs, then a similar MPLS
TE-tunnel based scheme can be applied to cause certain entrance
points to be preferred by setting MED to be an IGP cost, which has
been modified by the tunnel metric.
Similar to intra-domain TE, inter-domain TE is best accomplished when
a traffic matrix can be derived to depict the volume of traffic from
one autonomous system to another.
Generally, redistribution of inter-domain traffic requires
coordination between peering partners. An export policy in one
domain that results in load redistribution across peer points with
another domain can significantly affect the local traffic matrix
inside the domain of the peering partner. This, in turn, will affect
the intra-domain TE due to changes in the spatial distribution of
traffic. Therefore, it is mutually beneficial for peering partners
to coordinate with each other before attempting any policy changes
that may result in significant shifts in inter-domain traffic. In
certain contexts, this coordination can be quite challenging due to
technical and non- technical reasons.
It is a matter of speculation as to whether MPLS, or similar
technologies, can be extended to allow selection of constrained paths
across domain boundaries.
8.0 Overview of Contemporary TE Practices in Operational IP Networks
This section provides an overview of some contemporary traffic
engineering practices in IP networks. The focus is primarily on the
aspects that pertain to the control of the routing function in
operational contexts. The intent here is to provide an overview of
the commonly used practices. The discussion is not intended to be
exhaustive.
Currently, service providers apply many of the traffic engineering
mechanisms discussed in this document to optimize the performance of
their IP networks. These techniques include capacity planning for
long time scales, routing control using IGP metrics and MPLS for
medium time scales, the overlay model also for medium time scales,
and traffic management mechanisms for short time scale.
When a service provider plans to build an IP network, or expand the
capacity of an existing network, effective capacity planning should
be an important component of the process. Such plans may take the
following aspects into account: location of new nodes if any,
existing and predicted traffic patterns, costs, link capacity,
topology, routing design, and survivability.
Performance optimization of operational networks is usually an
ongoing process in which traffic statistics, performance parameters,
and fault indicators are continually collected from the network.
This empirical data is then analyzed and used to trigger various
traffic engineering mechanisms. Tools that perform what-if analysis
can also be used to assist the TE process by allowing various
scenarios to be reviewed before a new set of configurations are
implemented in the operational network.
Traditionally, intra-domain real-time TE with IGP is done by
increasing the OSPF or IS-IS metric of a congested link until enough
traffic has been diverted from that link. This approach has some
limitations as discussed in Section 6.2. Recently, some new intra-
domain TE approaches/tools have been proposed
[RR94][FT00][FT01][WANG]. Such approaches/tools take traffic matrix,
network topology, and network performance objective(s) as input, and
produce some link metrics and possibly some unequal load-sharing
ratios to be set at the head-end routers of some ECMPs as output.
These new progresses open new possibility for intra-domain TE with
IGP to be done in a more systematic way.
The overlay model (IP over ATM or IP over Frame relay) is another
approach which is commonly used in practice [AWD2]. The IP over ATM
technique is no longer viewed favorably due to recent advances in
MPLS and router hardware technology.
Deployment of MPLS for traffic engineering applications has commenced
in some service provider networks. One operational scenario is to
deploy MPLS in conjunction with an IGP (IS-IS-TE or OSPF-TE) that
supports the traffic engineering extensions, in conjunction with
constraint-based routing for explicit route computations, and a
signaling protocol (e.g., RSVP-TE or CRLDP) for LSP instantiation.
In contemporary MPLS traffic engineering contexts, network
administrators specify and configure link attributes and resource
constraints such as maximum reservable bandwidth and resource class
attributes for links (interfaces) within the MPLS domain. A link
state protocol that supports TE extensions (IS-IS-TE or OSPF-TE) is
used to propagate information about network topology and link
attribute to all routers in the routing area. Network administrators
also specify all the LSPs that are to originate each router. For
each LSP, the network administrator specifies the destination node
and the attributes of the LSP which indicate the requirements that to
be satisfied during the path selection process. Each router then
uses a local constraint-based routing process to compute explicit
paths for all LSPs originating from it. Subsequently, a signaling
protocol is used to instantiate the LSPs. By assigning proper
bandwidth values to links and LSPs, congestion caused by uneven
traffic distribution can generally be avoided or mitigated.
The bandwidth attributes of LSPs used for traffic engineering can be
updated periodically. The basic concept is that the bandwidth
assigned to an LSP should relate in some manner to the bandwidth
requirements of traffic that actually flows through the LSP. The
traffic attribute of an LSP can be modified to accommodate traffic
growth and persistent traffic shifts. If network congestion occurs
due to some unexpected events, existing LSPs can be rerouted to
alleviate the situation or network administrator can configure new
LSPs to divert some traffic to alternative paths. The reservable
bandwidth of the congested links can also be reduced to force some
LSPs to be rerouted to other paths.
In an MPLS domain, a traffic matrix can also be estimated by
monitoring the traffic on LSPs. Such traffic statistics can be used
for a variety of purposes including network planning and network
optimization. Current practice suggests that deploying an MPLS
network consisting of hundreds of routers and thousands of LSPs is
feasible. In summary, recent deployment experience suggests that
MPLS approach is very effective for traffic engineering in IP
networks [XIAO].
As mentioned previously in Section 7.0, one usually has no direct
control over the distribution of inbound traffic. Therefore, the
main goal of contemporary inter-domain TE is to optimize the
distribution of outbound traffic between multiple inter-domain links.
When operating a global network, maintaining the ability to operate
the network in a regional fashion where desired, while continuing to
take advantage of the benefits of a global network, also becomes an
important objective.
Inter-domain TE with BGP usually begins with the placement of
multiple peering interconnection points in locations that have high
peer density, are in close proximity to originating/terminating
traffic locations on one's own network, and are lowest in cost.
There are generally several locations in each region of the world
where the vast majority of major networks congregate and
interconnect. Some location-decision problems that arise in
association with inter-domain routing are discussed in [AWD5].
Once the locations of the interconnects are determined, and circuits
are implemented, one decides how best to handle the routes heard from
the peer, as well as how to propagate the peers' routes within one's
own network. One way to engineer outbound traffic flows on a network
with many EBGP peers is to create a hierarchy of peers. Generally,
the Local Preferences of all peers are set to the same value so that
the shortest AS paths will be chosen to forward traffic. Then, by
over-writing the inbound MED metric (Multi-exit-discriminator metric,
also referred to as "BGP metric". Both terms are used
interchangeably in this document) with BGP metrics to routes received
at different peers, the hierarchy can be formed. For example, all
Local Preferences can be set to 200, preferred private peers can be
assigned a BGP metric of 50, the rest of the private peers can be
assigned a BGP metric of 100, and public peers can be assigned a BGP
metric of 600. "Preferred" peers might be defined as those peers
with whom the most available capacity exists, whose customer base is
larger in comparison to other peers, whose interconnection costs are
the lowest, and with whom upgrading existing capacity is the easiest.
In a network with low utilization at the edge, this works well. The
same concept could be applied to a network with higher edge
utilization by creating more levels of BGP metrics between peers,
allowing for more granularity in selecting the exit points for
traffic bound for a dual homed customer on a peer's network.
By only replacing inbound MED metrics with BGP metrics, only equal
AS-Path length routes' exit points are being changed. (The BGP
decision considers Local Preference first, then AS-Path length, and
then BGP metric). For example, assume a network has two possible
egress points, peer A and peer B. Each peer has 40% of the
Internet's routes exclusively on its network, while the remaining 20%
of the Internet's routes are from customers who dual home between A
and B. Assume that both peers have a Local Preference of 200 and a
BGP metric of 100. If the link to peer A is congested, increasing
its BGP metric while leaving the Local Preference at 200 will ensure
that the 20% of total routes belonging to dual homed customers will
prefer peer B as the exit point. The previous example would be used
in a situation where all exit points to a given peer were close to
congestion levels, and traffic needed to be shifted away from that
peer entirely.
When there are multiple exit points to a given peer, and only one of
them is congested, it is not necessary to shift traffic away from the
peer entirely, but only from the one congested circuit. This can be
achieved by using passive IGP-metrics, AS-path filtering, or prefix
filtering.
Occasionally, more drastic changes are needed, for example, in
dealing with a "problem peer" who is difficult to work with on
upgrades or is charging high prices for connectivity to their
network. In that case, the Local Preference to that peer can be
reduced below the level of other peers. This effectively reduces the
amount of traffic sent to that peer to only originating traffic
(assuming no transit providers are involved). This type of change
can affect a large amount of traffic, and is only used after other
methods have failed to provide the desired results.
Although it is not much of an issue in regional networks, the
propagation of a peer's routes back through the network must be
considered when a network is peering on a global scale. Sometimes,
business considerations can influence the choice of BGP policies in a
given context. For example, it may be imprudent, from a business
perspective, to operate a global network and provide full access to
the global customer base to a small network in a particular country.
However, for the purpose of providing one's own customers with
quality service in a particular region, good connectivity to that
in-country network may still be necessary. This can be achieved by
assigning a set of communities at the edge of the network, which have
a known behavior when routes tagged with those communities are
propagating back through the core. Routes heard from local peers
will be prevented from propagating back to the global network,
whereas routes learned from larger peers may be allowed to propagate
freely throughout the entire global network. By implementing a
flexible community strategy, the benefits of using a single global AS
Number (ASN) can be realized, while the benefits of operating
regional networks can also be taken advantage of. An alternative to
doing this is to use different ASNs in different regions, with the
consequence that the AS path length for routes announced by that
service provider will increase.
9.0 Conclusion
This document described principles for traffic engineering in the
Internet. It presented an overview of some of the basic issues
surrounding traffic engineering in IP networks. The context of TE
was described, a TE process models and a taxonomy of TE styles were
presented. A brief historical review of pertinent developments
related to traffic engineering was provided. A survey of
contemporary TE techniques in operational networks was presented.
Additionally, the document specified a set of generic requirements,
recommendations, and options for Internet traffic engineering.
10.0 Security Considerations
This document does not introduce new security issues.
11.0 Acknowledgments
The authors would like to thank Jim Boyle for inputs on the
recommendations section, Francois Le Faucheur for inputs on Diffserv
aspects, Blaine Christian for inputs on measurement, Gerald Ash for
inputs on routing in telephone networks and for text on event-
dependent TE methods, Steven Wright for inputs on network
controllability, and Jonathan Aufderheide for inputs on inter-domain
TE with BGP. Special thanks to Randy Bush for proposing the TE
taxonomy based on "tactical vs strategic" methods. The subsection
describing an "Overview of ITU Activities Related to Traffic
Engineering" was adapted from a contribution by Waisum Lai. Useful
feedback and pointers to relevant materials were provided by J. Noel
Chiappa. Additional comments were provided by Glenn Grotefeld during
the working last call process. Finally, the authors would like to
thank Ed Kern, the TEWG co-chair, for his comments and support.
12.0 References
[ASH2] J. Ash, Dynamic Routing in Telecommunications Networks,
McGraw Hill, 1998.
[ASH3] Ash, J., "TE & QoS Methods for IP-, ATM-, & TDM-Based
Networks", Work in Progress, March 2001.
[AWD1] D. Awduche and Y. Rekhter, "Multiprocotol Lambda
Switching: Combining MPLS Traffic Engineering Control
with Optical Crossconnects", IEEE Communications
Magazine, March 2001.
[AWD2] D. Awduche, "MPLS and Traffic Engineering in IP
Networks", IEEE Communications Magazine, Dec. 1999.
[AWD5] D. Awduche et al, "An Approach to Optimal Peering Between
Autonomous Systems in the Internet", International
Conference on Computer Communications and Networks
(ICCCN'98), Oct. 1998.
[CRUZ] R. L. Cruz, "A Calculus for Network Delay, Part II:
Network Analysis", IEEE Transactions on Information
Theory, vol. 37, pp. 132-141, 1991.
[DIFF-TE] Le Faucheur, F., Nadeau, T., Tatham, M., Telkamp, T.,
Cooper, D., Boyle, J., Lai, W., Fang, L., Ash, J., Hicks,
P., Chui, A., Townsend, W. and D. Skalecki, "Requirements
for support of Diff-Serv-aware MPLS Traffic Engineering",
Work in Progress, May 2001.
[ELW95] A. Elwalid, D. Mitra and R.H. Wentworth, "A New Approach
for Allocating Buffers and Bandwidth to Heterogeneous,
Regulated Traffic in an ATM Node", IEEE IEEE Journal on
Selected Areas in Communications, 13:6, pp. 1115-1127,
Aug. 1995.
[FGLR] A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J.
Rexford, "NetScope: Traffic Engineering for IP Networks",
IEEE Network Magazine, 2000.
[FLJA93] S. Floyd and V. Jacobson, "Random Early Detection
Gateways for Congestion Avoidance", IEEE/ACM Transactions
on Networking, Vol. 1 Nov. 4., p. 387-413, Aug. 1993.
[FLOY94] S. Floyd, "TCP and Explicit Congestion Notification", ACM
Computer Communication Review, V. 24, No. 5, p. 10-23,
Oct. 1994.
[FT00] B. Fortz and M. Thorup, "Internet Traffic Engineering by
Optimizing OSPF Weights", IEEE INFOCOM 2000, Mar. 2000.
[FT01] B. Fortz and M. Thorup, "Optimizing OSPF/IS-IS Weights in
a Changing World",
www.research.att.com/~mthorup/PAPERS/papers.html.
[HUSS87] B.R. Hurley, C.J.R. Seidl and W.F. Sewel, "A Survey of
Dynamic Routing Methods for Circuit-Switched Traffic",
IEEE Communication Magazine, Sep. 1987.
[ITU-E600] ITU-T Recommendation E.600, "Terms and Definitions of
Traffic Engineering", Mar. 1993.
[ITU-E701] ITU-T Recommendation E.701, "Reference Connections for
Traffic Engineering", Oct. 1993.
[ITU-E801] ITU-T Recommendation E.801, "Framework for Service
Quality Agreement", Oct. 1996.
[JAM] Jamoussi, B., Editior, Andersson, L., Collon, R. and R.
Dantu, "Constraint-Based LSP Setup using LDP", RFC3212,
January 2002.
[KATZ] Katz, D., Yeung, D. and K. Kompella, "Traffic Engineering
Extensions to OSPF", Work in Progress, February 2001.
[LNO96] T. Lakshman, A. Neidhardt, and T. Ott, "The Drop from
Front Strategy in TCP over ATM and its Interworking with
other Control Features", Proc. INFOCOM'96, p. 1242-1250,
1996.
[MA] Q. Ma, "Quality of Service Routing in Integrated Services
Networks", PhD Dissertation, CMU-CS-98-138, CMU, 1998.
[MATE] A. Elwalid, C. Jin, S. Low, and I. Widjaja, "MATE: MPLS
Adaptive Traffic Engineering", Proc. INFOCOM'01, Apr.
2001.
[MCQ80] J.M. McQuillan, I. Richer, and E.C. Rosen, "The New
Routing Algorithm for the ARPANET", IEEE. Trans. on
Communications, vol. 28, no. 5, pp. 711-719, May 1980.
[MR99] D. Mitra and K.G. Ramakrishnan, "A Case Study of
Multiservice, Multipriority Traffic Engineering Design
for Data Networks", Proc. Globecom'99, Dec 1999.
[RFC-1458] Braudes, R. and S. Zabele, "Requirements for Multicast
Protocols", RFC1458, May 1993.
[RFC-1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC1771, March 1995.
[RFC-1812] Baker, F., "Requirements for IP Version 4 Routers", STD
4, RFC1812, June 1995.
[RFC-1992] Castineyra, I., Chiappa, N. and M. Steenstrup, "The
Nimrod Routing Architecture", RFC1992, August 1996.
[RFC-1997] Chandra, R., Traina, P. and T. Li, "BGP Community
Attributes", RFC1997, August 1996.
[RFC-1998] Chen, E. and T. Bates, "An Application of the BGP
Community Attribute in Multi-home Routing", RFC1998,
August 1996.
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP) - Version 1
Functional Specification", RFC2205, September 1997.
[RFC-2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997.
[RFC-2212] Shenker, S., Partridge, C. and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC2212, September
1997.
[RFC-2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC
2215, September 1997.
[RFC-2216] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC2216, September 1997.
[RFC-2328] Moy, J., "OSPF Version 2", STD 54, RFC2328, July 1997.
[RFC-2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
"Framework for IP Performance Metrics", RFC2330, May
1998.
[RFC-2386] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A
Framework for QoS-based Routing in the Internet", RFC
2386, August 1998.
[RFC-2474] 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.
[RFC-2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[RFC-2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC2597, June 1999.
[RFC-2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC2678, September 1999.
[RFC-2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC2679, September 1999.
[RFC-2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC2680, September 1999.
[RFC-2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering over
MPLS", RFC2702, September 1999.
[RFC-2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC2722, October 1999.
[RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy-based Admission Control", RFC2753, January
2000.
[RFC-2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC2961, April 2000.
[RFC-2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
Felstaine, "A Framework for Integrated Services Operation
over Diffserv Networks", RFC2998, November 2000.
[RFC-3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC3031, January 2001.
[RFC-3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules
for their Specification", RFC3086, April 2001.
[RFC-3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC3124, June 2001.
[RFC-3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001.
[RFC-3210] Awduche, D., Hannan, A. and X. Xiao, "Applicability
Statement for Extensions to RSVP for LSP-Tunnels", RFC
3210, December 2001.
[RFC-3213] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G.
Wright, "Applicability Statement for CR-LDP", RFC3213,
January 2002.
[RFC-3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaahanen,
P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC3270, April 2002.
[RR94] M.A. Rodrigues and K.G. Ramakrishnan, "Optimal Routing in
Shortest Path Networks", ITS'94, Rio de Janeiro, Brazil.
[SHAR] Sharma, V., Crane, B., Owens, K., Huang, C., Hellstrand,
F., Weil, J., Anderson, L., Jamoussi, B., Cain, B.,
Civanlar, S. and A. Chui, "Framework for MPLS Based
Recovery", Work in Progress.
[SLDC98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury,
"Design Considerations for Supporting TCP with Per-flow
Queueing", Proc. INFOCOM'98, p. 299-306, 1998.
[SMIT] Smit, H. and T. Li, "IS-IS extensions for Traffic
Engineering", Work in Progress.
[WANG] Y. Wang, Z. Wang, L. Zhang, "Internet traffic engineering
without full mesh overlaying", Proceedings of
INFOCOM'2001, April 2001.
[XIAO] X. Xiao, A. Hannan, B. Bailey, L. Ni, "Traffic
Engineering with MPLS in the Internet", IEEE Network
magazine, Mar. 2000.
[YARE95] C. Yang and A. Reddy, "A Taxonomy for Congestion Control
Algorithms in Packet Switching Networks", IEEE Network
Magazine, p. 34-45, 1995.
13.0 Authors' Addresses
Daniel O. Awduche
Movaz Networks
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Phone: 703-298-5291
EMail: awduche@movaz.com
Angela Chiu
Celion Networks
1 Sheila Dr., Suite 2
Tinton Falls, NJ 07724
Phone: 732-747-9987
EMail: angela.chiu@celion.com
Anwar Elwalid
Lucent Technologies
Murray Hill, NJ 07974
Phone: 908 582-7589
EMail: anwar@lucent.com
Indra Widjaja
Bell Labs, Lucent Technologies
600 Mountain Avenue
Murray Hill, NJ 07974
Phone: 908 582-0435
EMail: iwidjaja@research.bell-labs.com
XiPeng Xiao
Redback Networks
300 Holger Way
San Jose, CA 95134
Phone: 408-750-5217
EMail: xipeng@redback.com
14.0 Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.