Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3270

Multi-Protocol Label Switching (MPLS) Support of Differentiated Services

Pages: 64
Proposed Standard
Errata
Updates:  3032
Updated by:  5462
Part 3 of 3 – Pages 49 to 64
First   Prev   None

Top   ToC   RFC3270 - Page 49   prevText

7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces

The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations are specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces, ATM Interfaces which are not label controlled and Frame Relay interfaces which are not label controlled. On these interfaces, this specification allows any of the following LSP combinations per FEC:
Top   ToC   RFC3270 - Page 50
   -  Zero or any number of E-LSP, and

   -  Zero or any number of L-LSPs.

   A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured
   `EXP<-->PHB mapping' over these interfaces.

   A Diff-Serv capable LSR MAY support E-LSPs which use signaled
   `EXP<-->PHB mapping' and L-LSPs over these interfaces.

8. MPLS Support of Diff-Serv over LC-ATM Interfaces

This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled ATM (LC-ATM) interfaces. This document allows any number of L-LSPs per FEC within an MPLS ATM Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces.

8.1 Use of ATM Traffic Classes and Traffic Management mechanisms

The use of the "ATM service categories" specified by the ATM Forum, of the "ATM Transfer Capabilities" specified by the ITU-T or of vendor specific ATM traffic classes is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. Since there is only one bit (CLP) for encoding the PHB drop precedence value over ATM links, only two different drop precedence levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two ATM drop precedence levels. This mapping is in accordance with the requirements specified in [DIFF_AF] for the case when only two drop precedence levels are supported. To avoid discarding parts of the packets, frame discard mechanisms, such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled in the ATM-LSRs for all PHBs described in this document.

8.2 LSR Implementation With LC-ATM Interfaces

A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces. This specification assumes that Edge-LSRs of the ATM-LSR domain use the "shim header" encapsulation method defined in [MPLS_ATM]. Operations without the "shim header" encapsulation are outside the scope of this specification.
Top   ToC   RFC3270 - Page 51

9. MPLS Support of Diff-Serv over LC-FR Interfaces

This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled Frame Relay (LC-FR) interfaces. This document allows any number of L-LSPs per FEC within an MPLS Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR interfaces.

9.1 Use of Frame Relay Traffic parameters and Traffic Management mechanisms

The use of the Frame Relay traffic parameters as specified by ITU-T and Frame Relay-Forum or of vendor specific Frame Relay traffic management mechanisms is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the Frame Relay LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. Since there is only one bit (DE) for encoding the PHB drop precedence value over Frame Relay links, only two different drop precedence levels are supported in Frame Relay LSRs. Sections 4.2.3 and 4.4.3 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two Frame Relay drop precedence levels. This mapping is in accordance with the requirements specified in [DIFF_AF] for the case when only two drop precedence levels are supported.

9.2 LSR Implementation With LC-FR Interfaces

A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay interfaces. This specification assumes that Edge-LSRs of the FR-LSR domain use the "generic encapsulation" method as recommended in [MPLS_FR]. Operations without the "generic encapsulation" are outside the scope of this specification.
Top   ToC   RFC3270 - Page 52

10. IANA Considerations

This document defines a number of objects with implications for IANA. This document defines in section 5.2 a new RSVP object, the DIFFSERV object. This object required a number from the space defined in [RSVP] for those objects which, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number. Within that space, this object required a number from the "IETF Consensus" space. "65" has been allocated by IANA for the DIFFSERV object. This document defines in section 5.5 a new RSVP error code, "Diffserv Error". Error code "27" has been assigned by IANA to the "Diffserv Error". This document defines values 1 through 5 of the value field to be used within the ERROR_SPEC object for this error code. Future allocations of values in this space should be handled by IANA using the First Come First Served policy defined in [IANA]. This document defines in section 6.1 a new LDP TLV, the Diffserv TLV. The number for this TLV has been assigned by working group consensus according to the policies defined in [LDP]. This document defines in section 6.2 five new LDP Status Code values for Diffserv-related error conditions. The values for the Status Code have been assigned by working group consensus according to the policies defined in [LDP].

11. Security Considerations

This document does not introduce any new security issues beyond those inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms proposed for those technologies.

12. Acknowledgments

This document has benefited from discussions with Eric Rosen, Angela Chiu and Carol Iturralde. It has also borrowed from the work done by D. Black regarding Diff-Serv and IP Tunnels interaction.
Top   ToC   RFC3270 - Page 53

Appendix A. Example Deployment Scenarios

This section does not provide additional specification and is only here to provide examples of how this flexible approach for Diff-Serv support over MPLS may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document.

A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS Protection

A Service Provider running 8 (or fewer) BAs over MPLS, not performing Traffic engineering, not using MPLS protection and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via LDP. Furthermore the Service Provider may elect to use the preconfigured `EXP<-->PHB mapping'. Operations can be summarized as follows: - the Service Provider configures at every LSR, the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13) - LSRs signal establishment of a single E-LSP per FEC using LDP in accordance with the specification above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping)

A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS Protection

A Service Provider running more than 8 BAs over MPLS, not performing Traffic Engineering, not using MPLS protection and using MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS using for each FEC: - one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND - one L-LSP per <FEC,OA> established via LDP for support of the other BAs.
Top   ToC   RFC3270 - Page 54
   Operations can be summarized as follows:

   -  the Service Provider configures at every LSR the bi-directional
      mapping between each PHB and a value of the EXP field for the BAs
      transported over the E-LSP

   -  the Service Provider configures at every LSR, and for every
      interface, the scheduling behavior for each PSC supported over the
      E-LSP and the dropping behavior for each corresponding PHB

   -  the Service Provider configures at every LSR, and for every
      interface, the scheduling behavior for each PSC supported over the
      L-LSPs and the dropping behavior for each corresponding PHB

   -  LSRs signal establishment of a single E-LSP per FEC for the set of
      E-LSP transported BAs using LDP as specified above (i.e., no
      Diff-Serv TLV in LDP Label Request/Label Mapping messages to
      implicitly indicate that the LSP is an E-LSP and that it uses the
      preconfigured mapping)

   -  LSRs signal establishment of one L-LSP per <FEC,OA> for the other
      BAs using LDP as specified above (i.e., Diff-Serv TLV in LDP Label
      Request/Label Mapping messages to indicate the L-LSP's PSC).

A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, Aggregate MPLS Protection

A Service Provider running 8 (or fewer) BAs over MPLS, performing aggregate Traffic Engineering (i.e., performing a single common path selection for all BAs), using aggregate MPLS protection (i.e., restoring service to all PSCs jointly) and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of a single E-LSP per FEC which will use the preconfigured mapping:
Top   ToC   RFC3270 - Page 55
      *  using the RSVP protocol as specified above (i.e., no DIFFSERV
         RSVP Object in the PATH message containing the LABEL_REQUEST
         Object), OR

      *  using the CR-LDP protocol as specified above (i.e., no Diff-
         Serv TLV in LDP Label Request/Label Mapping messages).

   -  protection is activated on all the E-LSPs in order to achieve MPLS
      protection via mechanisms outside the scope of this document.

A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection

A Service Provider running any number of BAs over MPLS, performing per-OA Traffic Engineering (i.e., performing a separate path selection for each OA) and performing per-OA MPLS protection (i.e., performing protection with potentially different levels of protection for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP. Operations can be summarized as follows: - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13) - LSRs signal establishment of one L-LSP per <FEC,OA>: * using the RSVP as specified above to signal the L-LSP's PSC (i.e., DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR * using the CR-LDP protocol as specified above to signal the L- LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages). - the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection for each PSC) via mechanisms outside the scope of this document.
Top   ToC   RFC3270 - Page 56

A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS Protection

A Service Provider running 8 (or fewer) BAs over MPLS, performing per-OA Traffic Engineering (i.e., performing a separate path selection for each OA) and performing per-OA MPLS protection (i.e., performing protection with potentially different levels of protection for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or CR-LDP. Furthermore, the Service Provider may elect to use the preconfigured mapping on all the E-LSPs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13) - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) - LSRs signal establishment of one E-LSP per <FEC,OA>: * using the RSVP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR * using the CR-LDP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages) - the Service Provider configures, for each E-LSP, at the head-end of that E-LSP, a filtering/forwarding criteria so that only the packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA. - the appropriate level of protection is activated on the different E-LSPs (potentially with a different level of protection depending on the PSC actually transported over each E-LSP) via mechanisms outside the scope of this document.
Top   ToC   RFC3270 - Page 57

A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA Traffic Engineering/MPLS Protection on other BAs.

A Service Provider not performing Traffic Engineering/MPLS Protection on 8 (or fewer) BAs, performing per-OA Traffic Engineering/MPLS Protection on the other BAs (i.e., performing a separate path selection for each OA corresponding to the other BAs and performing MPLS Protection with a potentially different policy for each of these OA) and using the MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS, using for each FEC: - one E-LSP using the preconfigured mapping established via LDP to support the set of 8 (or fewer) non-traffic-engineered/non- protected BAs, AND - one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for support of the other BAs. Operations can be summarized as follows: - the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs supported over the E-LSP - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB - LSRs signal establishment of a single E-LSP per FEC for the non- traffic engineered BAs using LDP as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages) - LSRs signal establishment of one L-LSP per <FEC,OA> for the other BAs: * using the RSVP protocol as specified above to signal the L-LSP PSC (i.e., DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR * using the CR-LDP protocol as specified above to signal the L- LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages).
Top   ToC   RFC3270 - Page 58
   -  protection is not activated on the E-LSPs.

   -  the appropriate level of protection is activated on the different
      L-LSPs (potentially with a different level of protection depending
      on the L-LSP's PSC) via mechanisms outside the scope of this
      document.

A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS Protection

A Service Provider running more than 8 BAs over MPLS, not performing Traffic engineering, not performing MPLS protection and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff- Serv over MPLS using two E-LSPs per FEC established via LDP and using signaled `EXP<-->PHB mapping'. Operations can be summarized as follows: - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13) - LSRs signal establishment of two E-LSPs per FEC using LDP in accordance with the specification above (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages to explicitly indicate that the LSP is an E-LSP and its `EXP<-->PHB mapping'). The signaled mapping will indicate the subset of 8 (or less) BAs to be transported on each E-LSP and what EXP values are mapped to each BA on each E-LSP.

Appendix B. Example Bandwidth Reservation Scenarios

B.1 Scenario 1: No Bandwidth Reservation

Consider the case where a network administrator elects to: - have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...) - have Shortest Path Routing used for all the Diff-Serv traffic. This is the closest model to provisioned Diff-Serv over non-MPLS IP. In that case, E-LSPs and/or L-LSPs would be established without signaled bandwidth.
Top   ToC   RFC3270 - Page 59

B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control

Consider the case where a network administrator elects to: - have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...) - use L-LSPs - have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC. In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to perform admission control at every hop to ensure that the constraint on availability of bandwidth for the relevant PSC is met.

B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and per-PSC Resource Adjustment

Consider the case where a network administrator elects to: - use L-LSPs - have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC. - have Diff-Serv resources dynamically adjusted In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to attempt to adjust the resources allocated to the relevant PSC (e.g., scheduling weight) and then perform admission control to ensure that the constraint on availability of bandwidth for the relevant PSC is met after the adjustment.
Top   ToC   RFC3270 - Page 60

References

[ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e). [ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", March 1999. [CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. [DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [DIFF_HEADER] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [DIFF_NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Top   ToC   RFC3270 - Page 61
   [IEEE_802.1]     ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998
                    Edition (Revision and redesignation of ISO/IEC
                    10038:98.

   [LDP]            Andersson, L., Doolan, D., Feldman, N., Fredette, A.
                    and B. Thomas, "LDP Specification", RFC 3036,
                    January 2001.

   [MPLS_ARCH]      Rosen, E., Viswanathan, A. and R. Callon,
                    "Multiprotocol Label Switching Architecture", RFC
                    3031, January 2001.

   [MPLS_ATM]       Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
                    Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using
                    LDP and ATM VC Switching", RFC 3035, January 2001.

   [MPLS_ENCAPS]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                    Farinacci, D., Li, T. and A. Conta, "MPLS Label
                    Stack Encoding", RFC 3032, January 2001.

   [MPLS_FR]        Conta, A., Doolan, P. and A. Malis, "Use of Label
                    Switching on Frame Relay Networks Specification",
                    RFC 3034, January 2001.

   [MPLS_VPN]       Rosen, E., "BGP/MPLS VPNs", Work in Progress.

   [NULL]           Bernet, Y., Smith, A. and B. Davie, "Specification
                    of the Null Service Type", RFC 2997, November 2000.

   [PHBID]          Black, D., Brim, S., Carpenter, B. and F. Le
                    Faucheur, "Per Hop Behavior Identification Codes"
                    RFC 3140, June 2001.

   [RSVP]           Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                    Jamin, "Resource ReSerVation Protocol (RSVP) -
                    Version 1 Functional Specification", RFC 2205,
                    September 1997.

   [RSVP_MPLS_TE]   Awduche, D., Berger, L., Gan, D., Li, T.,
                    Srinivasan, V. and G. Swallow, "Extensions to RSVP
                    for LSP Tunnels", RFC 3209, December 2001.
Top   ToC   RFC3270 - Page 62

Authors' Addresses

Francois Le Faucheur Cisco Systems Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA Phone: +1 (408) 853-4065 EMail: liwwu@cisco.com Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA Phone: +1 (978) 244-8000 EMail: bsd@cisco.com Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada Phone: +1 (613) 271-4018 EMail: davari@ieee.org
Top   ToC   RFC3270 - Page 63
   Pasi Vaananen
   Nokia
   3 Burlington Woods Drive, Suit 250
   Burlington, MA 01803
   USA

   Phone +1 (781) 993-4900
   EMail: pasi.vaananen@nokia.com


   Ram Krishnan
   Axiowave Networks
   200 Nickerson Road
   Marlboro, MA 01752

   EMail: ram@axiowave.com


   Pierrick Cheval
   Alcatel
   5 rue Noel-Pons
   92737 Nanterre Cedex
   France
   EMail: pierrick.cheval@space.alcatel.fr


   Juha Heinanen
   Song Networks, Inc.
   Hallituskatu 16
   33200 Tampere, Finland

   EMail: jh@song.fi
Top   ToC   RFC3270 - Page 64
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 RFC Editor function is currently provided by the
   Internet Society.