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