PPVPN Working Group Tissa Senevirathne Internet Draft (Consultant) Document: draft-tsenevir-app-vpn-test-02.txt Lior Shabtay Category: Informational (Atrica) October 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 into Application Level VPN testability, Technology dependent VPN testability, and Technology specific VPN testability. This document presents a solution for Application level VPN Operation and Maintenance (Testability). 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]. Senevirathne Informational - Expiration February 2003 1 draft-tsenevir-app-vpn-test-02.txt October 2002 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,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 defined methods for VPN testability seriously improve providers ability to support a 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: The word Testability may be used interchangeably with Operation and Maintenance. VFI - Virtual Forwarding Instance VSI - Virtual Switching Instance 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 lack such capabilities. It is possible for some testability methods to use constructs that are largely different from the actual data packets, thus possibly affecting the validity of the test results. It is important that test packets do not violate any industry standards (such as IETF or IEEE standards). In this document we provide a framework and Requirements to address these issues. Architecturally VPN functionality has two major components:VPN service, and PE to PE VPN connectivity (tunnel connectivity). Any VPN testability method must have the ability to test these logical areas independently. Senevirathne Informational - Expiration February 2003 2 draft-tsenevir-app-vpn-test-02.txt October 2002 In this document we introduce Application level VPN testability that is independent of the underlying tunneling implementation. Application level VPN tests are expected to be available across all implementations as a generic method of testability. 2.0 Architecture for Operation and Maintenance of VPN. It is important to have proper architectural definitions for VPN testability (Operation and Maintenance). Architectural definitions facilitate proper identification of Requirement and development of VPN testability solutions. / /Technology Independent / +-------------------+ | Application Level | | - VPN testability | +-------------------+--------------- |Technology dependent | | - VPN testability | +-------------------+------------- |Technology specific| Provided by Technology method | - testability | (eg: LSP ping) +-------------------+....... Fig: Architecture for Operation and Maintenance of VPN In the above architecture, the distinction between application-level VPN testing and technology-dependent VPN testing depends on how VPN test packets are distinguished from actual data and control packets. The distinction between technology-dependent VPN test and technology-specific VPN test depends on whether VPN properties or technology properties are tested. The ability to identify VPN test messages from actual data and control packets is important for successful implementation of VPN testability. There are two possible approaches; 1. Use of properties or special fields (such as reserved addresses or special protocol types) on actual data packet. 2. Use of technology-dependent parameters (such as reserved labels in MPLS). 2.1 Scope of Application-Level VPN testability Application-level VPN tests are independent of the underlying tunnel method used. Hence it is anticipated that Application-level testability will be available as a generic testability method independent of underlying technology. Senevirathne Informational - Expiration February 2003 3 draft-tsenevir-app-vpn-test-02.txt October 2002 Application-level VPN testability can be broadly classified into three areas: . VPN health test. . Test for VPN properties. . VPN performance monitoring. 2.1.1 VPN Health Test VPN health test is defined per specific VPN of a specific VPN class between two specific PE devices. A 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 the forwarding process of that VPN (VSI/VFI) at the local and remote PEs. . Connectivity from the local PE to the remote PE for that VPN. 2.1.2 Test for VPN Properties Test for VPN properties is defined per specific VPN of a specific VPN class at a specific PE device. The 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. Maximum Packet size and Quality of Service are some of the properties that can be tested per VPN context. 2.1.3 Test for VPN Performance Test for VPN performance is defined per specific VPN of a specific VPN class at a specific PE device. Senevirathne Informational - Expiration February 2003 4 draft-tsenevir-app-vpn-test-02.txt October 2002 A VPN performance test at minimum MUST provide the ability to: . Measure round trip delay between Local and Remote PE for that VPN. . Measure round trip delay variation between Local and Remote PE for that VPN over a specified period of time. .. Measure one-way delay variation between Local and Remote PE for that VPN over a specified period of time. 2.2 Scope of Technology-Dependent VPN Test The technology-dependent VPN test provides methods to test technology-dependent aspects of a VPN. In addition, technology- dependent VPN tests MAY provide methods to perform the VPN tests defined in section 2.1 that are technology independent. A technology-dependent VPN test MAY provide . Path Trace . Path Reachability 2.2.1 Path Trace Path trace provides methods to test and trace the path that a given VPN data packet traverses. Path trace is defined per specific VPN and specific tunnel method. 2.2.2 Path (Tunnel) Reachability Path Reachability provides methods to test reachability of a PE device for a specific VPN of a specific class. 2.3 Scope of Technology-Specific Testability Technology-specific testability is defined per tunneling method used and is specific to the tunneling method used. Tunnel-specific testing 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 and 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 Senevirathne Informational - Expiration February 2003 5 draft-tsenevir-app-vpn-test-02.txt October 2002 Query and response method is used as the base model for VPN test. In this document we refer this as Base VPN test model. Using the base VPN test model, more elaborate VPN test models can be derived. For example, for an application that requires continuous periodic connectivity testing, it is more efficient to send the response for received query messages from the other side/sides embedded in the query messages periodically sent to that other side. This is siimilar to a Hello-protocol approach. This approach reduces the number of required messages by half. A VPN test is specified from the point of view of a local PE. VPN test context SHOULD be specified per remote PE, per VPN class, per VPN. The VPN test context in a local PE 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. Additional, possible, VPN-contexts are {class, VPN} and {class, VPN, destination-address}. When knowing the specific VPN and VPN-class, it may not be necessary to know the remote PE to initiate a VPN- test. In some cases the remote PE identity is not known. In other cases, the objective of VPN test procedure may be to discover the remote PE. For this reason, the context of {class, VPN} is a very important one. In this case, the messages of the VPN test procedure are simply forwarded along the VPN to whoever is there on the other side (might be one or more). The identity of the other PE-devices connected to the VPN is discovered from the response or responses received. The context of (Class, VPN, destination-address), in which the destination address is in the context of the VPN, is very useful for testing the VPN for packets of specific destination address. This is important in two cases: First, when the PE to which the CE with this address connects is unknown; Second, for testing the forwarding database of the VPN for the specific CE destination address. 4.0 Requirements for Operation and Maintenance (Test) of VPN 4.1 General Requirements 4.1.1 Standard Compliant . VPN test methods MUST not violate standards (IETF, IEEE, ITU) for the purpose of testability. 4.1.2 Scope of VPN Test . 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. Senevirathne Informational - Expiration February 2003 6 draft-tsenevir-app-vpn-test-02.txt October 2002 . Test results of a specific VPN test layer (Application, Tunnel and Tunnel specific) SHOULD not be used to deduce the results of another layer. 4.1.3 Forwarding Policies and VPN Test . A PE device MUST honor local forwarding policies. As an example; a test response MUST not be generated if there was a violation of a local forwarding policy. 4.1.4 Scalability Presence of VPN test solutions MUST not affect the scalability of the VPN solution. 4.1.5 Measurement of Performance VPN test methods SHOULD provide methods to measure performance. 4.1.6 Technology Independent VPN test MUST not depend on the underlying tunnel methods. Such dependencies MUST only be used to test technology specific aspects of VPN. 4.1.7 Extensibility The protocol should be extensible, to allow new measurements and new items to be monitored. 4.1.8 Security It is recommended that implementation provide an 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. VPN test MUST honor local Forwarding and Security polices. 4.2 Requirements for Application Level VPN Test. The discussion below is from the point of view of a specific end- point of a VPN (a specific PE participating in a VPN). This end- point is regarded as the local-PE. 4.2.1 VPN Health Test . MUST be defined VPN-context. . MUST indicate the availability and health of VPN-context. . SHOULD indicate the health of VSI/VFI of VPN-context instance. Senevirathne Informational - Expiration February 2003 7 draft-tsenevir-app-vpn-test-02.txt October 2002 . A PE device SHOULD generate a response with specific error indication if: - the specified VPN-context instance is not configured. - the health check criteria has failed for the VPN-context. - the reachability between the querying PE and the responding PE for the instance {PE,class, VPN} has either not established, partially established, or failed. . Test results of one VPN-context MUST not be used to deduce the results of any other VPN-context. 4.2.3 Requirements for Test of VPN Properties . MUST be defined VPN-context (p) where p is the property tested. Maximum Packet size and Quality of Service are some of the properties that can be tested per VPN context. . MUST indicate the availability and health of VPN-context (p). . SHOULD indicate the health of VSI/VFI of VPN-context (p) instance. . A PE device MUST not generate a response if: - the specified VPN-context(p) instance is not configured. - the health check criteria has failed for the VPN-context(p). - the reachability between the querying PE and the responding PE for the instance {PE,class, VPN}(p) has either not established, partially established, or failed. . Test results of one VPN-context(p) MUST not be used to deduce the results of any other VPN-context(p). 4.3 Requirements for Technology Dependent 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 Application level VPN test requires methods to identify VPN test packets from control or data packets. Senevirathne Informational - Expiration February 2003 8 draft-tsenevir-app-vpn-test-02.txt October 2002 There are two possible approaches: 1. Use of reserved address for that VPN class (e.g. reserved MAC address). 2. Use of VPN test protocol Type on the Data packet (e.g. VPN- OAMprotocol type on IP). 5.1 Implementation of specific VPN liveliness We propose to use two approaches to meassure VPN liveliness. 1. Reserved address for the purpose of specific VPN liveliness. Use of reserved addresses provide direct method of testing using the same data forwarding logic. For example, for VPLS a specific MAC address may be reserved (the actual MAC address to be determined). The implementation that complies with application level VPN liveliness MUST identify such MAC address at forwarding plane and process as explained in this document. 2. Use of special VPN protocol type for purpose of specific VPN liveliness. For layer 3 VPN obtaining a reserved address may be difficult. 127.0.0.x can lead to violation of the forwarding rules at the originating PE. Another reason for using a protocol-type/Ethernet-type field for VPN test messages is the fact that when messages are identified as VPN test messages according to the protocol/type field, the VPN behavior for a packet with a specific destination address can be tested. This is valid for layer 2 as well as for layer 3 VPNs. We propose to use a new IP protocol type VPN-OAM to identify IP packets that are intended for the purpose. Similarly, each class of VPN SHOULD define protocol type (upper layer identifier) for Application Level VPN test purpose. 5.3 Discussion Application level test query/responses are created using a similar template as data packets. For example, if VPN testability is performed on a layer 3 VPN, the testability packet is an IP packet. This similarity allows application level VPN tests to test a wider range of properties. Senevirathne Informational - Expiration February 2003 9 draft-tsenevir-app-vpn-test-02.txt October 2002 Application level VPN tests 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 without an error indication only if the 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 a data packet of that size along the path. Application level VPN testing MAY include testability for quality of service. As explained in the Requirement section, quality of service testing MUST be encoded in exactly the same manner as data packets encode quality of service. For 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 - 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. For example, in the 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 a generic method requires vendors to implement scores of testability methods and service providers MAY require using a combination of such methods. Hence generic VPN testability provides ease of implementation and deployment. 6. VPN test Protocol Data Unit 6.1 VPN Test PDU Architecture Senevirathne Informational - Expiration February 2003 10 draft-tsenevir-app-vpn-test-02.txt October 2002 +--------------+ | UTM | User defined VPN test messages +--------------+ | CTM | Class specific VPN Test Message +--------------+ | VTM | Class Independent VPN Test Message +--------------+ | VTH | VPN Test Header +--------------+ | VCH | VPN Class Header +--------------+ (IP, L2.._) Fig : VPN PDU Architecture 6.1.2 VPN Class Header (VCH) The VCH depends on whether the VPN is a layer 3 VPN, layer 2 VPN, VPLS, etc. In the case of a layer 3 VPN, the VCH is an IP header and MUST contain VPN-OAM IP protocol Type. In the case of VPLS, the VCH MUST contain an Ethernet header with DA:SA:EtherType. The Ethertype field MUST be set to the VPN-OAM Ethertype. The DA MAY be set to the VPN-OAM reserved MAC address. We propose to treat Layer 2 VPN as a subset of VPLS, for the purpose of definition of VPN class header. 6.1.3 VPN Test Header (VTH) This is the common VPN test header. A VPN test header MUST be present in all VPN test packets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version |Reserved | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Next Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - 01; all other values reserved. Reserved - Transmitted as zero and ignored on receipt. Total Length: Length of the entire VPN test message, including VPN class header, in bytes. Message Type - 1 for VPN class header. Flags - Not defined at this time. Senevirathne Informational - Expiration February 2003 11 draft-tsenevir-app-vpn-test-02.txt October 2002 Checksum - Checksum calculated over the entire VPN test message, including this header. The checksum calculation method used on the IP header MUST be used here. 6.1.4 Class Independent VPN Test Message (VTM): Class independent VPN test messages define class independent, well known VPN tests, such as liveliness test. There can be either, no, one, or more than one class independent VPN test messages per VPN test message. Class independent VPN test messages MUST be according to the VPN test message format specified below. The message content MUST be defined according to the specification of the VPN test message. 6.1.5 Class Specific VPN Test Message (CTM) The class specific VPN test message defines class specific VPN tests. There can be either, no, one, or more than one class independent VPN test messages per VPN test message. The class specific VPN test message MUST be according to the VPN test message format specified below. The Message content MUST be defined according to the specification of the VPN class test message. 6.1.6 User Defined VPN Test Messages (UTM) User defined VPN test messages are defined by the user and are considered out of scope in this document. However, user defined VPN test messages MUST be according to the VPN test message format specified below. Message Types 128-255 are reserved for user defined VPN test messages. 6.2 VPN Test Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version |Reserved | Length of the Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Next Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Message content . | | . . | | Senevirathne Informational - Expiration February 2003 12 draft-tsenevir-app-vpn-test-02.txt October 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - Version of the message type, MUST be according to the specification of the VPN test. Reserved - Transmitted as zero and ignored on receipt. Length of Message: Length of the entire VPN test message, including this header, in bytes. Message Type - Type of this message. Well known messages contain a type from 1-127. Message 0 is reserved and invalid for Message Type field. Flags - Not defined at this time. Next Message Type - Type of the next message. Value 0 (zero) indicates there is no message to follow. 6.3 VPN Test Message Type Codes: Message Type Description 0 Last Message Type 1 VPN Class Header 2 VPN Padding 3 VPN liveliness 4 Round Trip Delay 5 One-way Delay variation 6-127 TBD 128-255 Reserved For User defined Messages Comments: 1. Need a different message type for query/response for each of the types (e.g. VPN-liveliness query and VPN-liveliness response). 2. We can do VPN-liveliness / round-trip-delay / one-way-delay- variation with a single set of query/response messages. 3. There is still work to do about how each measurement is performed and which specific fields are required for each measurement. 4. Hello-protocol messages (query + response in the same message). 7. Security Considerations The methods presented in this document do not introduce any additional security risks on PE to PE side. It is recommended that implementation provide an optional policy for handling VPN test queries arriving on access ports. Absence of such Senevirathne Informational - Expiration February 2003 13 draft-tsenevir-app-vpn-test-02.txt October 2002 a policy may lead to undefined behavior of VPN testability and may lead to exploitation of security infrastructure. 8. Intelectual Property Protection Certain section of this publication may be subjected to intelectual property protection. 9. 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 10. Acknowledgments 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. 11. Author's Addresses Tissa Senevirathne 1567 Belleville Way Sunnyvale CA 94087 Phone: 408-245-5897 Email: tsenevir@hotmail.com Lior Shabtay Atrica Email: lior_shabtay@atrica.com 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 14