tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4031


Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)

Part 3 of 3, p. 36 to 50
Prev RFC Part


prevText      Top      Up      ToC       Page 36 
7.  Service Provider Management Requirements

   A service provider MUST have a means to view the topology,
   operational state, order status, and other parameters associated with
   each customer's VPN.  Furthermore, an SP MUST have a means to view
   the underlying logical and physical topology, operational state,
   provisioning status, and other parameters associated with the
   equipment providing the VPN service(s) to its customers.

   Currently, proprietary methods are often used to manage VPNs.  The
   additional expense associated with operators using multiple
   proprietary management methods (e.g., command line interface (CLI)
   languages) to access such systems is undesirable.  Therefore, devices
   SHOULD provide standards-based interfaces wherever feasible.

   The remainder of this section presents detailed SP management
   requirements for a Network Management System (NMS) in the traditional
   fault, configuration, accounting, performance, and security (FCAPS)
   management categories.  Much of this text was adapted from ITU-T

Top      Up      ToC       Page 37 
7.1.  Fault Management

   Support for fault management includes:

   -  indication of customers impacted by failure,
   -  fault detection (incidents reports, alarms and failure
   -  fault localization (analysis of alarms reports and diagnostics),
   -  incident recording or logs (creation and follow-through of trouble
      tickets), and
   -  corrective actions (traffic, routing, and resource allocation).

   As PE-based VPNs rely on a common network infrastructure, the NMS
   MUST provide a means to inform the provider of the VPN customers
   impacted by a failure in the infrastructure.  The NMS SHOULD provide
   pointers to the related customer configuration information to aid in
   fault isolation and determining corrective action.

   Detecting faults caused by configuration errors is desirable, because
   these may cause VPN service failure or may disrupt other requirements
   (e.g., traffic and routing isolation).  This is a likely case of
   compromised security [VPNSEC].  Detection of such errors is
   inherently difficult because the problem involves more than one node
   and may reach across a global perspective.  One approach could be a
   protocol that systematically checks whether all constraints and
   consistency checks hold among tunnel configuration parameters at the
   various end points.

   A capability to verify L3 reachability within a VPN MUST be provided
   for diagnostic purposes.

   A capability to verify the parameter configuration of a device
   supporting an L3VPN MUST be provided for diagnostic purposes.

7.2.  Configuration Management

   Overall, the NMS must support a configuration necessary to realize
   the desired L3-reachability of an L3VPN.  Toward this end, an NMS
   MUST provide configuration management to provision at least the
   following L3VPN components: PE,CE, hierarchical tunnels, access
   connections, routing, and QoS, as detailed in this section.  If
   shared access to the Internet is provided, then this option MUST also
   be configurable.

   As VPN configuration and topology are highly dependent on a
   customer's organization, provisioning systems MUST address a broad
   range of customer-specific requirements.  The NMS MUST ensure that

Top      Up      ToC       Page 38 
   these devices and protocols are provisioned consistently and

   Provisioning for adding or removing sites SHOULD be as localized and
   automated as possible.

   Configuration management for VPNs, according to service templates
   defined by the provider MUST be supported.  A service template
   contains fields that, when used, yield a definite service requirement
   or policy.  For example, a template for an IPSec tunnel would contain
   fields such as tunnel end points, authentication modes, encryption
   and authentication algorithms, pre-shared keys (if any), and traffic
   filters.  An SLA template would contain fields such as delay, jitter,
   and throughput and packet loss thresholds, as well as end points over
   which the SLA has to be satisfied.  In general, a customer's service
   order can be regarded as a set of instantiated service templates.
   This set can, in turn, be regarded as the logical service
   architecture of the customer's VPN.

   Service templates can also be used by the provider to define the
   service architecture of the provider's own network.  For example,
   OSPF templates could contain fields such as the subnets that form a
   particular area, the area identifier, and the area type.  BGP service
   template could contain fields that, when used, would yield a BGP
   policy, such as for expressing a preference about an exit router for
   a particular destination.

   The set of service templates SHOULD be comprehensive in that it can
   capture all service orders in some meaningful sense.

   The provider SHOULD provide means to translate service templates into
   device configurations so that associated services can be provisioned.

   Finally, the approach SHOULD provide means to check whether a service
   order is correctly provisioned.  This would represent one method of
   diagnosing configuration errors.  Configuration errors can arise due
   to a variety of reasons: manual configuration, intruder attacks, and
   conflicting service requirements.

7.2.1.  Configuration Management for PE-Based VPNs

   Requirements for configuration management unique to a PE-based VPN
   are as follows:

   o  The NMS MUST support configuration of at least the following
      aspects of L3 PE routers: intranet and extranet membership, CE
      routing protocol for each access connection, routing metrics, and

Top      Up      ToC       Page 39 
   o  The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs,
      hierarchical tunnels, and access connections, as described in
      section 6.3.

   o  Tunnels MUST be configured between PE and P devices.  This
      requires coordination of identifiers of tunnels, hierarchical
      tunnels, VPNs, and any associated service information, for
      example, a QoS/SLA service.

   o  Routing protocols running between PE routers and CE devices MUST
      be configured per VPN.

   o  For multicast service, multicast routing protocols MUST also be

   o  Routing protocols running between PE routers and between PE and P
      routers MUST also be configured.

   o  The configuration of a PE-based L3VPN MUST be coordinated with the
      configuration of the underlying infrastructure, including Layer 1
      and 2 networks interconnecting components of an L3VPN.

7.2.2.  Configuration Management for CE-Based VPN

   Requirements for configuration management unique to a CE-based VPN
   are as follows:

   o  Tunnels MUST be configured between CE devices.  This requires
      coordination of identifiers of tunnels, VPNs, and any associated
      service information, for example, a QoS/SLA service.

   o  Routing protocols running between PE routers and CE devices MUST
      be configured.  For multicast service, multicast routing protocols
      MUST also be configurable.

7.2.3.  Provisioning Routing

   A means for a service provider to provision parameters for the IGP
   for an L3VPN MUST be provided.  This includes link level metrics,
   capacity, QoS capability, and restoration parameters.

7.2.4.  Provisioning Network Access

   A service provider MUST have the means to provision network access
   between SP-managed PE and CE, as well as the case where the customer
   manages the CE.

Top      Up      ToC       Page 40 
7.2.5.  Provisioning Security Services

   When a security service is requested, an SP MUST have the means to
   provision the entities and associated parameters involved with the
   service.  For example, for IPsec service, tunnels, options, keys, and
   other parameters must be provisioned at either the CE or the PE.  In
   the case of an intrusion detection service, the filtering and
   detection rules must be provisioned on a VPN basis.

7.2.6.  Provisioning VPN Resource Parameters

   A service provider MUST have a means to provision resources
   associated with VPN services dynamically.  For example, in a PE-based
   service, the number and size of virtual switching and forwarding
   table instances must be provisionable.

   Dynamic VPN resource assignment is crucial for coping with the
   frequent change requests from customers (e.g., sites joining or
   leaving a VPN), as well as for achieving scalability.  The PEs SHOULD
   be able to dynamically assign the VPN resources dynamically.  This
   capability is especially important for dial and wireless VPN

   If an SP supports a "Dynamic Bandwidth management" service, then the
   provisioning system MUST be able to make requested changes within the
   ranges and bounds specified in the SLA.  Examples of SLA parameters
   are response time and probability of being able to service such a

7.2.7.  Provisioning Value-Added Service Access

   An L3VPN service provides controlled access between a set of sites
   over a common backbone.  However, many service providers also offer a
   range of value-added services. (for example, Internet access,
   firewall services, intrusion protection, IP telephony and IP Centrex,
   application hosting, and backup).  It is outside of the scope of this
   document to define whether and how these different services interact
   with the VPN to solve issues such as addressing, integrity, and
   security.  However, the VPN service MUST be able to provide access to
   these various types of value-added services.

   A VPN service SHOULD allow the SP to supply the customer with
   different kinds of standard IP services, such as DNS, NTP, and
   RADIUS, that are needed for ordinary network operation and
   management.  The provider SHOULD be able to provide IP services to
   multiple VPN customers.

Top      Up      ToC       Page 41 
   A firewall function MAY be required to restrict access to the L3VPN
   from the Internet [Y.1311].

   A managed firewall service MUST be carrier grade.  For redundancy and
   failure recovery, a means for firewall fail-over should be provided.
   Managed firewall services that may be provided include dropping
   specified protocol types, intrusion protection, and traffic-rate
   limiting against malicious attacks.

   Managed firewalls MUST be supported on a per-VPN basis, although
   multiple VPNs may be supported by the same physical device (e.g., in
   a PE-based solution).  Managed firewalls SHOULD be provided at the
   major access point(s) for the L3VPN.  Managed firewall services may
   be embedded in CE or PE device or implemented in standalone devices.

   The NMS SHOULD allow a customer to outsource the management of an IP
   networking service to the SP providing the VPN or to a third party.

   The NMS SHOULD support collection of information necessary for
   optimal allocation of IP services in response to customer orders.

   Reachability to and from the Internet to sites within a VPN MUST be
   configurable by an SP.  This could be controlled by configuring
   routing policy to control distribution of VPN routes advertised to
   the Internet.

7.2.8.  Provisioning Hybrid VPN Services

   Configuration of interworking or interconnection between L3VPN
   solutions SHOULD be also supported.  Ensuring that security and
   end-to-end QoS issues are provided consistently SHOULD be addressed.

7.3.  Accounting

   Many service providers require collection of measurements regarding
   resource usage for accounting purposes.  The NMS MAY need to
   correlate accounting information with performance and fault
   management information to produce billing that takes into account SLA
   provisions for periods of time when the SLS is not met.

   An L3VPN solution MUST describe how the following accounting
   functions can be provided:

   - Measurements of resource utilization.
   - collection of accounting information.
   - storage and administration of measurements.

Top      Up      ToC       Page 42 
   Some providers may require near - real time reporting of measurement
   information and may offer this as part of a customer network
   management service.

   If an SP supports a "Dynamic Bandwidth management" service, then the
   dates, times, amounts, and interval required to perform requested
   bandwidth allocation change(s) MUST be traceable for monitoring and
   accounting purposes.

   Solutions should state compliance with accounting requirements, as
   described in section 1.7 of RFC 2975 [RFC2975].

7.4.  Performance Management

   Performance management MUST support functions involved with
   monitoring and collecting performance data for devices, facilities,
   and services, as well as determining conformance to SLS, such as QoS
   and availability measurements.

   Performance management SHOULD also support analysis of important
   aspects of an L3VPN, such as bandwidth utilization, response time,
   availability, QoS statistics, and trends based on collected data.

7.4.1.  Performance Monitoring

   The NMS MUST monitor device behavior to evaluate performance metrics
   associated with an SLA.  Different measurement techniques may be
   necessary depending on the service for which an SLA is provided.
   Example services are QoS, security, multicast, and temporary access.
   These techniques MAY be either intrusive or non-intrusive depending
   on the parameters being monitored.

   The NMS MUST also monitor aspects of the VPN not directly associated
   with an SLA, such as resource utilization, state of devices, and
   transmission facilities, as well as control of monitoring resources
   such as probes and remote agents at network access points used by
   customers and mobile users.

7.4.2.  SLA and QoS Management Features

   The NMS SHOULD support SLAs between an SP and the various VPN
   customers according to the corresponding SLSes by measurement of the
   indicators defined within the context of the SLA, on a regular basis.

   The NMS SHOULD use the QoS parameter measurement definitions,
   techniques, and methods as defined by the IETF IP Performance Metrics
   (IPPM) working group for delay, loss, and delay variation.

Top      Up      ToC       Page 43 
   The NMS SHOULD support allocation and measurement of end-to-end QoS
   requirements to QoS parameters for one or more VPN network(s).

   Devices supporting L3VPN SLAs SHOULD have real-time performance
   measurements that have indicators and threshold crossing alerts.
   Such thresholds should be configurable.

7.5.  Security Management

   The security management function of the NMS MUST include management
   features to guarantee the security of devices, access connections,
   and protocols within the L3VPN network(s), as well as the security of
   customer data and control as described in section 6.9.

7.5.1.  Resource Access Control

   Resource access control determines the privileges that a user has to
   access particular applications and VPN network resources.  Without
   such control, only the security of the data and control traffic is
   protected, leaving the devices providing the L3VPN network
   unprotected.  Access control capabilities protect these devices to
   ensure that users have access only to the resources and applications
   they are authorized to use.

   In particular, access to the routing and switching resources managed
   by the SP MUST be tightly controlled to prevent and/or effectively
   mitigate a malicious attack.  More detailed requirements in this area
   are described in [VPNSEC].

7.5.2.  Authentication

   Authentication is the process of verifying that the sender is
   actually who he or she claims to be.  The NMS MUST support standard
   methods for authenticating users attempting to access management

   Scalability is critical, as the number of nomadic/mobile clients is
   increasing rapidly.  The authentication scheme implemented for such
   deployments MUST be manageable for large numbers of users and VPN
   access points.

   Strong authentication schemes SHALL be supported to ensure the
   security of both VPN access point-to-VPN access point  (e.g., PE to
   PE in a PE-based case) and client-to-VPN access point (e.g., CE-to-PE
   in a PE-based case) communications.  This is particularly important
   for preventing VPN access point spoofing, a situation where an
   attacker tries to convince a PE or CE that the attacker is the VPN
   access point.  If an attacker can convince a PE or CE device of this,

Top      Up      ToC       Page 44 
   then that device will send VPN traffic to the attacker (who could
   forward it to the true access point after compromising
   confidentiality or integrity).  In other words, a non-authenticated
   VPN AP can be spoofed with a man-in-the-middle attack, because the
   endpoints never verify each other.  A weakly authenticated VPN AP may
   be subject to such an attack.  Strongly authenticated VPN APs are not
   subject to such attacks, because the man-in-the-middle cannot be
   authenticated as the real AP due to the strong authentication

7.6.  Network Management Techniques

   Each L3VPN solution approach MUST specify the management information
   bases (MIB) modules for the network elements involved in L3VPN
   services.  This is an essential requirement in network provisioning.
   The approach SHOULD identify any information not contained in a
   standard MIB related to FCAPS that is necessary to meet a generic

   An IP VPN (Policy) Information model, when available, SHOULD reuse
   the policy information models being developed in parallel for
   specific IP network capabilities [IM-REQ].  This includes the QoS
   Policy Information Model [QPIM] and the IPSEC Configuration Policy
   Model [IPSECIM].  The IP VPN Information model SHOULD provide the OSS
   with adequate "hooks" to correlate service level specifications with
   traffic data collected from network elements.  The use of policies
   includes rules that control corrective actions taken by OSS
   components responsible for monitoring the network and ensuring that
   it meets service requirements.

   Additional requirements on VPN information models are given in
   reference [IM-PPVPN].  In particular, an information model MUST allow
   an SP to change VPN network dimensions with minimal influence on
   provisioning issues.  The adopted model SHOULD be applicable to both
   small/medium size and large-scale L3VPN scenarios.

   Some service providers MAY require systems that visually, audibly, or
   logically present FCAPS information to internal operators and/or

8.  Security Considerations

   Security considerations occur at several levels and dimensions within
   L3VPNs, as detailed within this document.  This section provides a
   summary with references to detailed supporting information

Top      Up      ToC       Page 45 
   The requirements in this document separate traditional notions of
   security requirements, such as integrity, confidentiality, and
   authentication, from issues such as isolating (or separating) the
   exchange of VPN data and control traffic between specific sets of
   sites (as defined in sections 3.3 and 4.1).  Further detail on
   security requirements is given from the customer and service provider
   perspectives in sections 5.9 and 6.9, respectively.  Further detail
   on data and control traffic isolation requirements are given from the
   customer and service provider perspectives in sections 5.1 and 6.8,

   Furthermore, requirements regarding management of security from a
   service provider perspective are described in section 7.5.

9.  Acknowledgements

   The authors of this document would like to acknowledge the
   contributions from the people who launched the work on VPN
   requirements inside ITU-T SG13 and the authors of the original IP VPN
   requirements and framework document [RFC2764], as well as Tom
   Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau,
   Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le
   Garrec.  The authors are also grateful to the helpful suggestions and
   direction provided by the technical advisors, Alex Zinin, Scott
   Bradner, Bert Wijnen, and Rob Coltun.  Finally, the authors wish to
   acknowledge the insights and requirements gleaned from the many
   documents listed in the references section.  Citations to these
   documents were made only where the authors believed that additional
   insight could be obtained from reading the source document.

10.  References

10.1.  Normative References

   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
                 Protocol (v3): Technical Specification", RFC 3377,
                 September 2002.

   [RFC1918]     Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
                 G., and E. Lear, "Address Allocation for Private
                 Internets", BCP 5, RFC 1918, February 1996.

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

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

Top      Up      ToC       Page 46 
   [RFC2211]     Wroclawski, J., "Specification of the Controlled-Load
                 Network Element Service", RFC 2211, September 1997.

   [RFC2212]     Shenker, S., Partridge, C., and R. Guerin,
                 "Specification of Guaranteed Quality of Service", RFC
                 2212, September 1997.

   [RFC2251]     Wahl, M., Howes, T., and S. Kille, "Lightweight
                 Directory Access Protocol (v3)", RFC 2251, December

   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                 Z., and W. Weiss, "An Architecture for Differentiated
                 Service", RFC 2475, December 1998.

   [RFC2597]     Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
                 "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC2661]     Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
                 G., and B. Palter, "Layer Two Tunneling Protocol
                 "L2TP"", RFC 2661, August 1999.

   [RFC2685]     Fox, B. and B. Gleeson, "Virtual Private Networks
                 Identifier", RFC 2685, September 1999.

   [RFC3246]     Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
                 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
                 D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
                 Behavior)", RFC 3246, March 2002.

   [RFC3270]     Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                 Vaananen, P., Krishnan, R., Cheval, P., and J.
                 Heinanen, "Multi-Protocol Label Switching (MPLS)
                 Support of Differentiated Services", RFC 3270, May

   [RFC3809]     Nagarajan, A., "Generic Requirements for Provider
                 Provisioned Virtual Private Networks (PPVPN)", RFC
                 3809, June 2004.

10.2.  Informative References

   [2547bis]     Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in

   [IM-PPVPN]    Lago, P., et al., "An Information Model for Provider
                 Provisioned Virtual Private Networks", Work in

Top      Up      ToC       Page 47 
   [IM-REQ]      Iyer, M., et al., "Requirements for an IP VPN Policy
                 Information Model", Work in Progress.

   [IPSECIM]     Jason, J., "IPsec Configuration Policy Model", Work in

   [CE-PPVPN]    De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C.,
                 "An Architecture for Provider Provisioned CE-based
                 Virtual Private Networks using IPsec", Work in

   [IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned
                 VPNs", Work in Progress.

   [L2VPN]       Rosen, E., et al., "An Architecture for L2VPNs", Work
                 in Progress.

   [MPLSSEC]     Behringer, M., "Analysis of the Security of the MPLS
                 Architecture", Work in Progress.

   [PPVPN-TERM]  Andersson, L., Madsen, T., "PPVPN Terminology", Work in

   [L3VPN-SEC]   Fang, L., et al., "Security Framework for Provider
                 Provisioned Virtual Private Networks", Work in

   [L3VPN-FR]    Callon, R., Suzuki, M., et al. "A Framework for Layer 3
                 Provider Provisioned Virtual Private Networks", Work in

   [PPVPN-VR]    Knight, P., Ould-Brahim, H., Gleeson, B., "Network
                 based IP VPN Architecture using Virtual Routers", Work
                 in Progress.

   [QPIM]        Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS
                 Information Model", Work in Progress.

   [RFC2385]     Heffernan, A., "Protection of BGP Sessions via the TCP
                 MD5 Signature Option", RFC 2385, August 1998.

   [RFC2764]     Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
                 A. Malis, "A Framework for IP Based Virtual Private
                 Networks", RFC 2764, February 2000.

   [RFC2975]     Aboba, B., Arkko, J., and D. Harrington, "Introduction
                 to Accounting Management", RFC 2975, October 2000.

Top      Up      ToC       Page 48 
   [RFC2983]     Black, D., "Differentiated Services and Tunnels", RFC
                 2983, October 2000.

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

   [RFC3198]     Westerinen, A., Schnizlein, J., Strassner, J.,
                 Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
                 Carlson, M., Perry, J., and S. Waldbusser, "Terminology
                 for Policy-Based Management", RFC 3198, November 2001.

   [TE-INTERAS]  Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
                 Engineering requirements", Work in Progress.

   [VPNDISC]     Squire, M. et al., "VPN Discovery Discussions and
                 Options", Work in Progress.

   [VPNIW]       Kurakami, H., et al., "Provider-Provisioned VPNs
                 Interworking", Work in Progress.

   [VPNSEC]      De Clercq, J., et al., "Considerations about possible
                 security extensions to BGP/MPLS VPN", Work in Progress.

   [VPNTUNNEL]   Worster, T., et al., "A PPVPN Layer Separation: VPN
                 Tunnels and Core Connectivity", Work in Progress.

   [VPN-CRIT]    Yu, J., Jou, L., Matthews, A ., Srinivasan, V.,
                 "Criteria for Evaluating VPN Implementation
                 Mechanisms", Work in Progress.

   [VPN-NEEDS]   Jacquenet, C., "Functional needs for the deployment of
                 an IP VPN service offering : a service provider
                 perspective", Work in Progress.

   [Y.1311.1]    Carugi, M. (editor), "Network Based IP VPN over MPLS
                 architecture", Y.1311.1 ITU-T Recommendation, July

   [Y.1311]      Knightson, K. (editor), "Network based VPNs  - Generic
                 Architecture and Service Requirements", Y.1311 ITU-T
                 Recommendation, March 2002.

Top      Up      ToC       Page 49 
Authors' Addresses

   Marco Carugi (co-editor)
   Nortel Networks
   Parc d'activites de Magny-Chateaufort
   Les Jeunes Bois - MS CTF 32B5 - Chateaufort
   78928 YVELINES Cedex 9  - FRANCE


   Dave McDysan (co-editor)
   22001 Loudoun County Parkway
   Ashburn, VA 20147, USA


   Luyuan Fang
   200 Laurel Ave - Room C2-3B35
   Middletown, NJ 07748 USA


   Ananth Nagarajan
   Juniper Networks


   Junichi Sumimoto
   NTT Communications Corporation
   3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan


   Rick Wilder


Top      Up      ToC       Page 50 
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-


   Funding for the RFC Editor function is currently provided by the
   Internet Society.