PPVPN Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-app-vpn-test-01.txt Category: Informational August 2002 Architecture, Model and Requirements for Operations and Maintenance (Testability) of Virtual Private Networks AND Application Level VPN Testability Solution Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract In this document we present, Architecture, Model and Requirements for Operation and Maintenance of Virtual Private Networks (VPN). Operation and Maintenance of VPN is divided in to Application Level VPN testability, Tunnel Level VPN testability and Tunnel specific VPN testability. Also, presented in this document is a solution for Application level VPN Operation and Maintenance (Testability). Senevirathne Informational - Expiration February 2003 1 draft-tsenevir-app-vpn-test-01.txt August 2002 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Placement of This Memo in Sub-IP Area RELATED DOCUMENTS: See the reference WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN WHY IS IT TARGETED AT THIS WG PPVPN WG charter specifies manageability as an important aspect of VPN services. JUSTIFICATION As VPN technology matures, VPN services can either be VPRN or VPLS or VPWS. A given provider may support any combination of these. As reach of VPN services expands from local Metro area to global level. A given provider MAY require supporting large number of VPN services. Well defines methods for VPN testability seriously improve providers ability to support large number of VPN services. Acronyms: VPN Class: A VPN class is any one of the following VPN types; L3 VPN (VPRN), VPLS, VPWS or any future VPN type. Testability: Word Testability may be used interchangeably with Operation and Maintenance, 1. Introduction Current VPN testability methods depend on the underlying tunneling method used. As a result different tunneling protocols MAY provide different methods or degree of testability, or sometimes may totally lacks such capabilities. It is also possible some testability methods may use constructs that are largely different from the actual data packets, thus impacting the validity of the test results. It is also important that test packets does not violate any industry standards (such as IETF or IEEE standards). In this document we attempt to provide a framework and Requirements to address these issues. Senevirathne Informational - Expiration February 2003 2 draft-tsenevir-app-vpn-test-01.txt August 2002 Architecturally VPN functionality has two major components, namely VPN service and PE to PE VPN connectivity (tunnel connectivity). Hence it is important that any VPN testability method has ability to test these logical areas independently. In this document we introduce Application level VPN testability or generic VPN testability that is independent of the underlying tunneling implementation. Application level VPN tests are expected be available across all implementation as a generic method of testability. 2.0 Architecture for Operation and Maintenance of VPN. It is important to have proper architectural definition for VPN testability (Operation and Maintenance). Availability of Architecture definition facilitates proper identification of Requirement and development of VPN testability solutions. / / / +-------------------+ General VPN liveliness Test | Application Level | Specific VPN health test | - VPN testability | Test for VPN properties +-------------------+--------------- | Tunnel Level | Path Trace | - VPN testability | Tunnel (Path) Reachability +-------------------+------------- | Tunnel specific | Provided by Tunneling method | - testability | (eg: LSP ping) +-------------------+....... Fig: Architecture for Operation and Maintenance of VPN 2.1 Scope of Application Level VPN testability Application level VPN tests are independent of underlying tunnel method used. Application Level VPN testability can be broadly classified into three different areas. . General VPN liveliness . Specific VPN health Test . Test for VPN properties. 2.1.1 General VPN liveliness General VPN liveliness test is defined per VPN class. General VPN liveliness test specifies . Availability of a specific VPN class at a PE Senevirathne Informational - Expiration February 2003 3 draft-tsenevir-app-vpn-test-01.txt August 2002 . Health and Liveliness of specific VPN class at that PE. . General VPN Reachability for that VPN class at that PE. 2.1.2 Specific VPN health test Specific VPN health test is defined per specific VPN of a specific VPN class at a specific PE devices. Specific VPN health test specifies . Availability of the specific VPN of a specific VPN class at a specific PE device . Health and Liveliness of that VPN at that PE device . General PE to PE reachability for that VPN. . Health and operational status of forwarding process of that VPN (VSI/VFI) at the PE. 2.1.3 Test for VPN properties Test for VPN properties are defined per specific VPN of a specific VPN class at a specific PE device. Test for VPN properties specifies . Availability of the specific VPN property of a specific VPN class at a specific PE device . Health and Liveliness of that VPN with specified VPN properties at that PE device . General PE to PE reachability for that VPN with the given property. . Health and operational status of the VSI with the specified property 2.2 Scope of Tunnel Level VPN testability Tunnel level testability provides methods to perform Operation and Maintenance of VPN aspects of the tunnel. Tunnel level VPN testability can be classified into several areas. . Path Trace . Path Reachability 2.2.1 Path Trace Senevirathne Informational - Expiration February 2003 4 draft-tsenevir-app-vpn-test-01.txt August 2002 Path trace provides methods to test and trace the path that a given VPN data packet traverse. Path trace is defined per specific VPN and specific tunnel method. 2.2.2 Path (Tunnel) Reachability Path Reachability provides method to test reachability of a PE device for a specific VPN of a specific class. 2.3 Scope of Tunnel specific testability Tunnel specific testability is defined per tunneling method used. And specific to the tunneling method used. Tunnel specific test may not be performed in the context of VPN. As an example, consider, ping status if IP based tunnels such as GRE is used, LSP ping status if MPLS tunnels used or control status if L2TP is used, none of these tests are VPN aware but only provide health status of underlying connectivity in general. Requirements and implementation details of Tunnel specific testability are provided in related documentation and considered out of scope in this document. 3.0 Model for VPN testability The VPN test model is based on query and response method. VPN test context MUST be specified per PE, per VPN class, per VPN. The VPN test context is denoted by {PE, Class, VPN} (p). The (p) denotes the VPN property under test and may be omitted if specific property is not identified. 4.0 Requirements for Operation and Maintenance (Test) of VPN 4.1 General Requirements . VPN test methods MUST not violate standards (IETF, IEEE, ITU) for the purpose of testability . Test results of one VPN SHOULD not be used to deduce the test result of another VPN . Results of VPN test of specific PE MUST not be used to deduce the test results of another PE. . Test results of a specific VPN test layer (Application, Tunnel and Tunnel specific) SHOULD not be used to deduce the results of another Layer. Senevirathne Informational - Expiration February 2003 5 draft-tsenevir-app-vpn-test-01.txt August 2002 . Absence of the test Response MUST be deduced as failure of the test. . Presence of a response MAY not be concluded as successful test. Validation of the test response SHOULD be provided by specification of each test method. . A PE device MUST honor local forwarding policies. As an example; a test response MUST not be generated if there were a violation of a local forwarding policy. 4.2 Requirements for Application Level VPN test. 4.2.1 General VPN liveliness . MUST be defined per VPN class per PE. . MUST indicate the availability and health of specific VPN class at a specific PE. . Liveliness of one VPN class MUST not be used to deduce the liveliness of any other class of VPN or a specific VPN. . A response MUST not be generated if, - the specified VPN class is not configured - the health check criteria has failed for the VPN class - the reachability for that VPN class is not established or partially established or has failed. 4.2.2 Specific VPN health test . MUST be defined {PE, Class, VPN}. . MUST indicate the availability and health of {PE, class, VPN} . SHOULD indicate the health of VSI/VFI of {PE,class,VPN} instance. . A PE device MUST not generate a response if, - the specified {PE,class,VPN} instance is not configured. - the health check criteria has failed for the {PE,class,VPN} - the reachability between the querying PE and the responding PE for the instance {PE,class, VPN} has either not established or partially established or has failed. . Test results of one {PE,class,VPN} MUST not be used to deduce the results of any other {PE,class,VPN}. 4.2.3 Requirements for Test of VPN properties Senevirathne Informational - Expiration February 2003 6 draft-tsenevir-app-vpn-test-01.txt August 2002 . MUST be defined {PE, Class, VPN} (p) where p is the property tested. Maximum Packet size, Quality of Services are some of the properties that can be tested per VPN context. . MUST indicate the availability and health of {PE, class, VPN} (p) . SHOULD indicate the health of VSI/VFI of {PE,class,VPN} (p) instance. . A PE device MUST not generate a response if, - the specified {PE,class,VPN}(p) instance is not configured. - the health check criteria has failed for the {PE,class,VPN}(p) - the reachability between the querying PE and the responding PE for the instance {PE,class, VPN}(p) has either not established or partially established or has failed. . Test results of one {PE,class,VPN}(p) MUST not be used to deduce the results of any other {PE,class,VPN}(p). 4.3 Requirements for Tunnel Level VPN test . Adaptation of tunnel encapsulation for testability MUST be compliant with the appropriate standards in use. . Construct of tunnel encapsulation for testability MUST be as close as possible to the tunnel Encapsulation used for VPN data. (ie: label depth etc..) . Tunnel test methods must not violate the configuration parameters of the tunnels used in data forwarding. . Test method and data plane both MUST used the same encapsulation construct. (ie GRE vs GRE but not GRE vs MPLS) 5. Application Level VPN testability 5.1 Use of Reserved VPN id for General VPN liveliness We propose to reserve a set of specific VPN ids from the VPN addressing method used. The reserved VPN id represents the loop back VPN id for identified VPN class. As an example if integer based numbering is used for VPN addresses, one may choose VPN id 0 to represent loopback VPN id for L3 VPN, VPN id 1 (one) for VPLS and so on. PE devices that comply with the methods presented in this document MUST setup reachability between loopback VPN of all supported VPN classes. Senevirathne Informational - Expiration February 2003 7 draft-tsenevir-app-vpn-test-01.txt August 2002 The reachability methods setup for the loopback VPN id MUST be exactly the same method as used for other VPN of the same class. Any PE device may request VPN liveliness from any other PE. 5.2 Implementation of specific VPN liveliness We propose to use a reserved address from each VPN class for the purpose of specific VPN liveliness. As an example; for VPLS a specific MAC address may be reserved. (The actual MAC address to be determined). The implementation that comply to Application level VPN liveliness MUST identify such MAC address at Forwarding plane and process as explained in this document. For Layer 3 VPN it is possible to reserve one of the 127.0.0.x addresses for the purpose. (This requires further discussion). Implementations that comply with Application level VPN liveliness MUST identify Layer 3 VPN reserved address at Forwarding plane and process as explained in this document. 5.3 Discussion Application level test query/responses are created using similar template as data packets. As an example if VPN testability is performed on L3 VPN, the testability packet is IP packet. This similarity allows Application level VPN tests to test wider range of properties. Application level VPN test MAY include testability for varied packet sizes. A local PE may generate a "liveliness" request to a remote PE with specified packet size. Specific packet size is implied by the size of the actual liveliness query packet. The responding PE MUST respond only if above specified criteria are satisfied and there are no packet size violations. Successful response to a "liveliness" query of a specific packet size MAY be used to deduce the support for data packet of that size along the path. Application level VPN test MAY include testability for Quality of service. As explained in the Requirement section, Quality of Service test MUST be encoded exactly the same manner as data packets encode quality of service. As an example queried Quality of service for IP packets may encoded as a Type of Service (or Differential Service Code Point (DSCP)). In VPLS, this may be encoded as 802.1Q Priority bits. 5.4. Advantages Senevirathne Informational - Expiration February 2003 8 draft-tsenevir-app-vpn-test-01.txt August 2002 - Independent of tunneling methods used. - Ability to test operation and health of actual forwarding process (VFI) at remote PE. - Ability to test application level properties such as Quality of Service, Packet size. TTL processing etc. - No extra burden/modification on tunneling methods. As an example in MPLS based testability methods proposed, a special label is used or label depth is increased. Such variations impact the validity of testability. - Ability to test VPN service across mixed mode tunnel configurations. - Provides a generic VPN testability method. Absence of such generic method requires vendors to implement scores of testability methods and service providers MAY require using combination of such methods. Hence generic VPN testability provide ease of implementation and deployment. 6. Security Considerations The methods presented in this document do not introduce any additional security risk on PE to PE side. It is recommended that implementation provide optional policy for handling VPN test queries arriving on access ports. Absence of such policy may lead to undefined behavior of VPN testability and may lead to exploitation of security infrastructure. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8. Acknowledgments Senevirathne Informational - Expiration February 2003 9 draft-tsenevir-app-vpn-test-01.txt August 2002 Special acknowledgments to members of the Layer 2 VPN design team. Comments and feedback provided by the team contributed to work presented in the second version of the document. 9. Author's Addresses Tissa Senevirathne 1567 Belleville Way Sunnyvale CA 94087 Phone: 408-245-5897 Email: tsenevir@hotmail.com Senevirathne Informational - Expiration February 2003 10 draft-tsenevir-app-vpn-test-01.txt August 2002 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 Senevirathne Informational - Expiration February 2003 11