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:

   -  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.

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.

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.

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.

   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:

      *  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.

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.

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).

   -  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.

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.

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.

   [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.

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

   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

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.