Internet Draft Document Olen Stokes Layer 2 VPN WG Extreme Networks Expires April 2005 Vach Kompella Alcatel Giles Heron Tellabs Yetik Serbest SBC Communications October 2004 Testing Hierarchical Virtual Private LAN Services draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on April 30, 2005. Abstract This document describes a methodology for testing the operation, administration and maintenance (OA&M) of a general VPN service, that is applied here to Hierarchical Virtual Private LAN Services (HVPLS) as described in [VPLS]. As part of this methodology, the MPLS ping concepts described in [LSP-PING] are extended to enable HVPLS spoke- draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 1 to-spoke connectivity testing. The approaches to identifying OAM packets has also been made compatible with [LSP-PING] and [PWE3-VCCV]. These are the goals of this draft: - checking connectivity between "service-aware" nodes of a network, - verifying data plane and control plane integrity, - verifying service membership There are two specific requirements to which we call attention because of their seemingly contradictory nature: - the checking of connectivity MUST involve the ability to use packets that look like customer packets - the OAM packets MUST not propagate beyond the boundary of the provider network Table of Contents 1. Conventions............................................3 2. Introduction...........................................3 2.1. Connectivity Verification............................3 2.2. Service Verification.................................4 2.3. Topology Discovery...................................4 2.4. Performance Monitoring...............................4 3. Terminology............................................4 4. Structural Model.......................................4 4.1. Identification.......................................4 4.2. Addressing...........................................5 4.3. FIB Traversal........................................5 4.4. Intermediate Failure Processing......................5 4.5. Control and Data Plane...............................5 5. OA&M Extensions........................................5 5.1. Reply Mode...........................................5 5.2. Error Code TLV.......................................6 6. VPLS OA&M Operations...................................7 6.1. VPLS Ping............................................7 6.1.1. VPLS Ping Encapsulation............................8 6.1.1.1. Using the Router Alert Label.....................8 6.1.1.2. Using the Control Word...........................8 6.1.1.3. Ingress Node Operation...........................9 6.1.1.4. Egress Node Operation............................9 6.2. VPLS Traceroute.....................................10 6.2.1. HVPLS Operational Requirements....................10 6.2.2. VPLS Traceroute Encapsulation.....................11 6.2.3. VPLS traceroute procedures........................13 7. Load sharing considerations...........................13 8. Determining the Forwarding Topology...................14 9. Security Considerations...............................14 10. Acknowledgments......................................14 draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 2 11. Copyright Notice.....................................14 12. Disclaimer...........................................15 13. IPR Disclosure Acknowledgment........................15 14. Normative References.................................15 15. Authors' Addresses...................................16 1. Conventions 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. Introduction This document describes a methodology for the operation, administration and maintenance (OA&M) of a Hierarchical VPLS (HVPLS) as described in [VPLS]. Service providers wanting to deploy such a service need to be able to test its operation across the entire hierarchy of the VPLS. While today's standards are able to test parts of an HVPLS, there are some aspects that cannot be tested. This OA&M methodology requires extensions to the MPLS ping concepts described in [LSP-PING] and [PWE3-VCCV] to enable VPLS spoke-to-spoke connectivity testing. It also requires extensions to the HVPLS concepts in [VPLS]. We define the following four functions that are needed to provide OA&M for services: - Connectivity verification - Service verification - Topology discovery - Performance monitoring 2.1. Connectivity Verification There are five logical steps to verifying the operation of an HVPLS: - Verify that all HVPLS nodes are operational - Verify that all HVPLS peer sessions are operational - Verify that all HVPLS tunnel LSPs are transporting data packets correctly - Verify that data packets can be exchanged between any two nodes in the HVPLS - Verify that actual customer devices can communicate with devices at any site Existing tests can verify the first three steps. This document describes how to address the final two issues. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 3 2.2. Service Verification Service verification has to do with whether the service aware nodes have been consistently configured for the service or not. This can be achieved by defining TLVs to describe service parameters that can be verified at service points. These extensions will be described in a later version. 2.3. Topology Discovery Topology discovery has to do with the current layout of a VPN service, e.g., the PEs and MTUs participating in a VPLS. Elementary topology discovery is discussed in Section 8. 2.4. Performance Monitoring Performance monitoring, such as determining round-trip times, jitter, average packet throughput, etc. will be described in a future version. 3. Terminology The following terms are used in this text: - Service point: a provider device that has knowledge of the service. We note here that the transport tunnel, while an integral part of the service, only serves to carry the service. In contrast, service-aware nodes participate in the signaling and maintenance of the VPN service. - Service ping: a protocol for testing end-to-end connectivity through the data plane - Service traceroute: a protocol for identifying intermediate nodes in an end-to-end service 4. Structural Model We describe below the structural model that implements OA&M for VPN services. The encapsulation and traversal methodology is described. We note that while it is not possible to make an OA&M packet look indistinguishable from customer frames, a reasonable verisimilitude may be maintained. This allows the lookup methods and encapsulation used in the data plane to be preserved. 4.1. Identification We use loopback or "always on" IP addresses to identify the service points. This allows service points to address each other, which is especially important in case of last ditch error reporting. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 4 4.2. Addressing We require the addressing in the OA&M packets to be configurable to match customer VPN addresses, whether MAC addresses, DLCIs, private IP addresses, etc. While addresses in the service provider network MAY be usable, they may not have relevance in proving that customer packets can traverse the service domain. 4.3. FIB Traversal We require that OA&M packets following the data plane traverse the service points using the forwarding lookup tables just as customer packets are. 4.4. Intermediate Failure Processing Failures at intermediate service points should be reported back using the control plane. This provides the basis for a traceroute function. 4.5. Control and Data Plane Typically, connectivity should first be checked against the data plane. If the request packet makes it to the destination service point, the reply packet should be sent along the data plane. Otherwise, after some interval, the sender should send another packet along the data plane, requesting a reply back on the control plane. If this fails, a final attempt may be made, with the request sent along the control plane, and the reply back along the control plane. If this fails, then the network is probably partitioned. 5. OA&M Extensions The OA&M extensions described below have specific reference to a particular VPN service, i.e., HVPLS. A later revision will deal with general VPN service OA&M. 5.1. Reply Mode [LSP-PING] defines multiple reply modes for MPLS pings. For a VPLS ping, an additional reply mode is required. Since a VPLS implies bi- directional operation, a reply mode is required that specifies that the reply packet be sent using the VPLS. Therefore, Value 5 (subject to IANA approval), "Reply via a VPLS IPv4 UDP packet," is proposed, which requests that the reply be sent via the VPLS forwarding path. Value Meaning ----- ------- 5 Reply via a VPLS IPv4/IPv6 UDP packet draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 5 This provides multiple reply methods to help in failure detection. E.g., if the ping is successful using reply mode Value 2, but unsuccessful using reply mode Value 5, this indicates that the ping is reaching the remote peer but there is a problem with the VPLS return path. 5.2. Error Code TLV The proposed Error Code TLV for use with [LSP-PING] is shown below. The encoding below is more complex than necessary because it attempts to circumnavigate the lack of specificity in the [LSP-PING] definition by adding structure. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x0004) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The field MUST be set to a value of 0x0004 (pending IANA allocation) for Error Code TLV. Length This field specifies the total length of the Value fields in octets. In this case the Value field is an Error Code Sub-TLV. Status Code Sub-TLV The proposed encoding for these Sub-TLVs is shown below. The Status Code Sub-TLV uses the Target FEC Stack sub-TLV type values defined in [LSP-PING] as the type field value. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x0009) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The field MUST be set to a value of 0x0009 for L2 VPN FEC 128. Length This field specifies the total length of the Value field in octets. In this case the Value field is an Error Code Sub-TLV. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 6 Status Code The following codes are defined: Value Meaning ----- ------- 1 Replying router is the egress for the given MAC address 2 Replying router is not a member of the indicated HVPLS 3 Replying router a member of the indicated HVPLS, but is not one of the "Downstream Routers" 4 Replying router is one of the "Downstream Routers" and it has the given MAC address in its forwarding database but it is not the egress 5 Replying router is one of the "Downstream Routers" but the label mapping is incorrect 6 Replying router is one of the "Downstream Routers" but it does not have the given MAC address in its forwarding database 7 Replying router is one of the "Downstream Routers" and is a member of the indicated HVPLS, and it does not have the given MAC address and is unable to flood the request 6. VPLS OA&M Operations We define two types of VPLS OA&M operations, VPLS ping, which is a connectivity verification operation, and VPLS traceroute, which is a topology discovery operation. 6.1. VPLS Ping There are two parts to connectivity verification. The first is ensuring that a particular remote service point is reachable. The second is determining what information is available at the endpoints, after reachability has been ascertained. The primary goal of connectivity verification is to check the data plane consistency. This requires intermediate service points to forward OAM messages using FIB lookups, next hop table matches, etc., just as they would for a conventional customer packet. We call this the VPLS (service) ping function. Verifying that data packets can be exchanged between any two spokes in the HVPLS detects problems with the "bridging" aspects of the HVPLS. Doing a complete test requires each spoke node to verify that it can exchange packets with every other spoke node in the HVPLS. This requires that each spoke node know some MAC address in the FIB of a remote spoke node. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 7 6.1.1. VPLS Ping Encapsulation It is desirable, for both operational and security reasons, to recognize easily that a received packet is a VPLS ping. We describe two encapsulation styles to achieve this purpose. 6.1.1.1. Using the Router Alert Label As defined in [LSP-PING], the special label added be the Router Alert Label (value of 1). It should be noted that this requires special handling of the Router Alert Label, as it is not normally present at the bottom of the label stack. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Encapsulation | ~ (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | EXP |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Alert Label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Header | + (source MAC, VLAN, destination MAC, VLAN, ethertype) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Payload | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While this approach is simple to describe, it affects how the data plane is checked in load sharing cases where the label stack is used in the load sharing hashing algorithm. 6.1.1.2. Using the Control Word [PWE3-VCCV] also allows for an alternate method for identifying OAM packets, by negotiating the use of the control word and setting the control word PID to the OAM value. This method avoids using an extra label, and thus allows the OAM packets to follow the same path as customer packets when ECMP is being used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Encapsulation | ~ (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | EXP |1| TTL | draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA=0 |PPP DLL Proto Number=0021/0057 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Header | + (source MAC, VLAN, destination MAC, VLAN, ethertype) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Payload | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ While this approach allows the OAM packet to be identified without changing the encapsulation between the customer packet and the OA&M packet, it adds the overhead of the control word to each customer payload, and requires all service nodes to support identification of the OAM PID. 6.1.1.3. Ingress Node Operation When an OAM packet is sent, one of the two encapsulations above is used. The FIB is consulted to determine if the destination MAC is known or not. If it is known, then a unicast packet is sent. If not, the packet is flooding within the VPLS context, as it normally would for any customer packet. 6.1.1.4. Egress Node Operation When an egress node's forwarding plane receives a packet, it uses the encapsulation format to determine if the packet is an OAM packet. Assuming it is an OAM packet, the following steps are taken, and the data plane handling ceases if the packet is sent to the control plane: - Check the destination MAC address field to determine if it is a MAC address belonging to that node. OAM packets addressed to a local MAC address are passed to the control plane. - Check if the MAC is known in the context of the forwarding database associated with the HVPLS indicated by the incoming PW label. If the MAC address is present, o If the MAC is associated with a customer attachment circuit, the packet is passed up to the control plane. o If the MAC is not known in that forwarding database, but the next forwarding decision would send the packet on a customer attachment circuit, the packet is sent to the control plane - Check if the TTL in the PW label, after decrementing, is zero. TTL 0 OAM packets are sent to the control plane. - Forward the packet normally, with flooding, if necessary. At the control plane, the OAM packet can be checked for consistency against the control plane information, including PW label, and PW FEC draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 9 information. The reply code is set according the codes described in Section 5.2. When a VPLS ping target MAC address is unknown in a core node, the VPLS ping packet is flooded. Consequently, it potentially reaches other spoke nodes in addition to the spoke where the destination is actually present. In order to avoid getting a flurry of useless information that the packet has reached a spoke node which does not know of the destination MAC address, if the message type is "ping" and the next forwarding decision would take the packet out on a customer attachment circuit, no reply is generated. Whenever it is determined that an OAM packet is to be processed by the control plane, it SHOULD be sent. If it cannot be passed to the control plane, the packet MUST be discarded. The packet MUST NOT be forwarded to the customer network. The rate at which OAM packets are passed to the control plane SHOULD be regulated to prevent overloading. 6.2. VPLS Traceroute When a VPLS ping using reply mode 5 (Reply via a VPLS IPv4 UDP packet) is unsuccessful, additional capabilities are required to identify the problem location. A VPLS traceroute is described below. 6.2.1. HVPLS Operational Requirements To provide an HVPLS traceroute capability, the basic operation of an HVPLS needs further definition. In particular, the handling of the TTL field in PW labels needs to be defined. When a data packet is forwarded from a HVPLS spoke node to a HVPLS core node, at the core HVPLS node, the PW label received from the spoke node is used to determine the HVPLS service associated with the packet. The frame is decapsulated and a check is made for the frame's destination MAC address. If the destination MAC is known, the frame is forwarded to the core peer from which the MAC was learned [VPLS]. As the frame is forwarded, the frame is again encapsulated using the next PW label received from the peer core node. Each time that this process occurs, the received PW label TTL value MUST be decremented and the result placed in the outgoing PW label TTL field. If the resulting value is 0, the packet MUST be passed to the node's control plane. If it cannot be passed to the control plane, the packet MUST be discarded. The rate at which packets are passed to the control plane should be regulated to prevent overloading. If the destination MAC is not known and the packet is flooded to multiple peer nodes or multiple spoke nodes, the same TTL processing described above is performed for each PW label. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 10 Given that the forwarding plane should not tell the difference between a ping and a traceroute, the PW label TTL processing SHOULD occur on all packets, and in particular, on OAM packets, in case the entire MPLS shim label is used in hash algorithms. In normal operation, the TTL value in the PW label should be set to a value larger than the number of "HVPLS Hops" through which the data packet will pass, e.g., 255. This PW label TTL decrement also provides some protection against the effects of loops at the HVPLS level. 6.2.2. VPLS Traceroute Encapsulation A VPLS traceroute uses the same general echo request packet encapsulation described in Section 6.1 for a VPLS ping. In addition, the echo request packet SHOULD contain one or more Downstream Mapping TLVs [LSP-PING]. In this case the Downstream Router ID field contains the IPv4 address of the next HVPLS node that would be used to reach the destination MAC address in the OAM packet. The Downstream Label field contains the label stack used to reach the downstream peer. This includes the label(s) for the underlying tunnel LSP and the PW label from the targeted LDP session with the downstream peer. The Protocol field for the PW label indicates a value of 3 for (targeted) LDP. When the destination MAC address is not known and a packet with this destination MAC would be flooded, the information for all HVPLS peers to which the packet would be flooded is added. For the case where the packet cannot be flooded (such as a limit on MAC addresses that has been exceeded for this HVPLS, MTU size limits, etc.), a new MPLS ping Return code is defined. This new Value 7 is shown in Section 5.2. For the case where the destination MAC address is known, but the packet would not be forwarded, no Downstream Mapping TLV is included. For example, the packet may have been received at one core node from another core node, but the MAC address was previously learned from a different core node. The Downstream Mapping TLV in [LSP-PING] includes a Hash Key Type to address ECMP considerations. The Hash Keys defined deal with IP addresses and MPLS labels. In an HVPLS, it is possible that a hash may be performed on the source and/or destination MAC addresses of the encapsulated L2 frame. For the case where a hash is performed on MAC address(es) including the destination MAC address, new MAC-based Hash Keys are proposed. The resulting list of Hash Keys is shown below. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 11 Hash Key Type IP Address or Next Label -------------------- ------------------------ 0 no multipath (nothing; M = 0) 1 label M labels 2 IP address M IP addresses 3 label range M/2 low/high label pairs 4 IP address range M/2 low/high address pairs 5 no more labels (nothing; M = 0) 6 All IP addresses (nothing; M = 0) 7 no match (nothing; M = 0) 8 MAC address M/2 MAC addresses 9 MAC address range M/4 low/high MAC pairs This results in the Downstream Mapping format shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | Resvd(SBZ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IPv4 Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash Key Type | Depth Limit | Multipath Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multipath Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (more IP Addresses or Next labels or MAC Addresses) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the case of a MAC address, the following format is used for the "IP Address or Next label or MAC Address" field(s): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 12 The semantics of the new Hash Key Types and the associated MAC Address(es) are shown below. Value Meaning ----- ------- 10 a list of single MAC addresses is provided, any one of which will cause the hash to match this MP path. 11 a list of MAC address ranges is provided, any one of which will cause the hash to match this MP path. 6.2.3. VPLS traceroute procedures To create a traceroute, an echo request is created using the destination Ethernet MAC address of the remote spoke or customer device. The TTL in the PW label is set successively to 1, 2, 3, ... As with MPLS traceroute, the echo request SHOULD contain one or more Downstream Mapping TLVs. For TTL=1, all the peer nodes (and corresponding PW labels) for the sender with respect to the remote spoke being pinged SHOULD be sent in the echo request. As the echo request may be flooded to multiple nodes, the sending node may receive replies from multiple remote nodes. Thus, for n>1, the Downstream Mapping TLVs from all of the received echo replies for TTL=(n-1) are copied to the echo request with TTL=n. Note that this allows an operator to determine which remote nodes would receive a flood of an actual customer data packet destined to the target MAC address. The requisite checks for determining if the packet should go to the control plane are the same as for a VPLS ping. In the control plane, an echo reply is created as described in [LSP- PING] and Section 6.1. This includes completing the Downstream Mapping TLV. The reply is sent based on the value indicated in the Reply Mode field of the echo request. If it is determined that the OAM packet is not to be processed by the control plane, and that it should be forwarded, the PW TTL is decremented and the result is placed in the PW label TTL for the forwarded packet. This packet is encapsulated in the same manner as a customer data packet and then passed to the downstream node that would normally be used to reach the indicated Ethernet MAC. If the packet is flooded to multiple peer nodes, this same TTL value is placed in the PW label TTL of each of the packets. 7. Load sharing considerations This issue will be addressed in a future revision. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 13 8. Determining the Forwarding Topology We can use the VPLS traceroute capability to determine the forwarding topology from any given node. By sending out a VPLS traceroute with destination MAC address set to the broadcast MAC address (ff:ff:ff:ff:ff:ff), each service point in the VPLS can flood and reply to the packet. 9. Security Considerations The VPLS ping and VPLS traceroute capabilities described operate within the HVPLS in the same manner as customer data. This is required to properly test the HVPLS. Care must be taken to prevent provider network information contained in these test packets from being exposed to the customer network. An OAM packet that is forwarded to the customer network exposes provider network information to the customer network. Therefore, spoke nodes MUST check for such OAM packets. Any detected OAM packet MUST NOT be forwarded to the customer network. Another security concern is the receipt of a VPLS ping or traceroute from a node that is not a member of the HVPLS. Should an HVPLS node respond to a test request from a non-HVPLS member, the response would improperly expose provider network information. To prevent this from happening, the HVPLS node SHOULD check to ensure that the PW labels are valid, and packets with unknown labels SHOULD be discarded. Further, if the peer association cannot be made, i.e., the sender address does not agree with the PW label, the packet SHOULD be discarded. Finally, OAM packets SHOULD be rate-limited to prevent over-running the control plane. 10. Acknowledgments We would like to acknowledge the contributions of Joe Regan, Sunil Khandekar, Kevin Frick, Charles Burton, and Charlie Hudnall in the development of these ideas. 11. Copyright Notice Copyright (C) The Internet Society (2004). 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. draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 14 12. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 13. IPR Disclosure Acknowledgment 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 http://www.ietf.org/ipr. 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- ipr@ietf.org. 14. Normative References [VPLS] "Virtual Private LAN services over MPLS", draft-ietf-l2vpn- vpls-ldp-05.txt, October 2004 (Work In Progress) [LSP-PING] "Detecting Data Plane Liveliness in MPLS", draft-ietf-mpls- lsp-ping-06.txt, July 2004 (Work In Progress) [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3- control-protocol-11.txt, October 2004 (Work In Progress) [PWE3-ENET] "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-08.txt, September 2004 (Work In Progress) draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 15 [PWE3-IANA] "IANA Allocations for Pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-07.txt, October 2004 (Work In Progress) [PWE3-VCCV] "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-03.txt, June 2004 (Work In Progress) [MPLS-LDP] Andersson, et al., "LDP Specification", RFC 3036, January 2001 [LABEL-ENC] Rosen, et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 15. Authors' Addresses Olen Stokes Extreme Networks Email: ostokes@extremenetworks.com Vach Kompella Alcatel Email: vach.kompella@alcatel.com Giles Heron Tellabs Email: giles.heron@tellabs.com Yetik Serbest SBC Communications yetik_serbest@labs.sbc.com draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt October 2004 Page 16