Network Working Group T. D. Nadeau (Editor)
Internet Draft Cisco Systems, Inc.
Expiration Date: February 2006
R. Aggarwal (Editor)
Juniper Networks
August 2005
Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
draft-ietf-pwe3-vccv-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Abstract
This document describes Virtual Circuit Connection Verification
(VCCV) procedures for use with pseudo wire (PW) connections. VCCV
supports connection verification applications for PWs regardless of
the underlying public service network technology. VCCV makes use of
IP-based protocols to perform operations and maintenance functions.
This is accomplished by providing a control channel associated with
each PW. A network operator may use the VCCV procedures to test the
network's forwarding plane liveliness.
Table of Contents
PWE3 Working Group Expires February 2006 [Page 1]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
1 Specification of requirements .......................... 4
2 Introduction ........................................... 4
3 Overview of VCCV ....................................... 5
3.1 LSP Ping ............................................... 6
3.2 L2TPV3 ................................................. 6
3.3 Bidirectional Forwarding Detection ..................... 6
4 VCCV Control Channels for PWs Demultiplexed using MPLS .. 7
4.1 Inband VCCV ............................................ 7
4.2 Out-of-Band VCCV ....................................... 8
4.3 TTL Expiry VCCV ........................................ 8
5 VCCV Types ............................................. 8
5.1 MPLS LSP Ping Packet ................................... 9
5.2 Bidirectional Forwarding Detection ..................... 9
6 OAM Capability Indication for PWs Demultiplexed using MPLS 10
6.1 Optional VCCV Parameter ................................ 11
7 VCCV Control Channel for L2TPv3/IP PSN ................. 12
7.1 L2TPv3 VCCV Message .................................... 13
7.1.1 L2TPv3 VCCV ICMP Ping AVP .............................. 13
7.1.2 L2TPv3 VCCV BFD AVP .................................... 13
7.2 L2TPv3 VCCV Capability Indication ...................... 13
7.2.1 L2TPv3 VCCV Capability AVP ............................. 13
7.3 L2TPv3 VCCV Operation .................................. 14
8 IANA Considerations .................................... 14
8.1 VCCV Parameter ID ...................................... 14
8.1.1 CC Types ............................................... 15
8.1.2 CV Types ............................................... 15
8.2 L2TPv3 Assignments ..................................... 15
8.2.1 CV Types ............................................... 15
9 Security Considerations ................................ 15
10 Acknowledgements ....................................... 17
11 References ............................................. 17
11.1 Normative References ................................... 17
11.2 Informative References ................................. 18
12 Editor Information ...................................... 18
13 Contributor Information ................................ 19
14 Intellectual Property Statement ........................ 20
15 Full Copyright Statement ............................... 20
1. Specification of requirements
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 [RFC2119].
2. Introduction
PWE3 Working Group Expires February 2006 [Page 2]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
As network operators deploy pseudo wire (PW) services, fault detec-
tion and diagnostic mechanisms particularly for the PSN portion of
the network are pivotal. Specifically, the ability to provide end-to-
end fault detection and diagnostics for an emulated PW service is
critical for the network operator. Operators have indicated in
[MPLSOAMREQS][PWREQ] that such a tool is required for PW deployments.
This document describes procedures for PSN-agnostic fault detection
and diagnostics called Virtual Circuit Connection Verification
(VCCV).
|<----- Pseudo Wire ---->|
| |
Attachment | |<-- PSN Tunnel -->| | Attachment
Circuit V V V V Circuit
| +----+ +----+ |
+----+ | | PE1|==================| PE2| | +----+
| |----------|............PW1.............|----------| |
| CE1| | | | | | | |CE2 |
| |----------|............PW2.............|----------| |
+----+ | | |==================| | | +----+
^ +----+ +----+ | ^
| Provider Edge 1 Provider Edge 2 |
| |
|<--------------- Emulated Service --------------->|
|<---------- VCCV ------>|
Customer Customer
Edge 1 Edge 2
Figure 1: PWE3 VCCV Operation Reference Model
Figure 1 depicts the basic functionality of VCCV. VCCV provides sev-
eral means of creating a control channel between PEs that attaches
the PW under test.
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | Emulated Service | Emulated |
| Services | | Services |
+-------------+ +-------------+
| | VCCV/PW | |
|Demultiplexer| Control Channel |Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
+-------------+ +-------------+
| Physical | | Physical |
PWE3 Working Group Expires February 2006 [Page 3]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ ___/ _/ __ |
| / __/ _ |
| / |
---------| MPLS or IP Network |-----
/
___ ___ __ _/
_/ ____/ ___/ ____/
Figure 2: PWE3 Protocol Stack Reference Model
including the VCCV control channel.
Figure 2 depicts how the VCCV control channel is associated with the
pseudo wire. Ping and other IP messages are encapsulated using the
PWE3 encapsulation as described below in sections 5 and 6. These mes-
sages, referred to as VCCV messages, are exchanged only after the
desire to exchange such traffic has been negotiated between the PEs
(see section 8).
3. Overview of VCCV
VCCV defines a set of messages that are exchanged between PEs to ver-
ify connectivity of the pseudo wire. To make sure that VCCV packets
follow the same path as the PW data flow, they are encapsulated in
the PW demultiplexer and trasported over the PSN tunnel. VCCV can
operate in two modes:
1) as a diagnostic tool
2) as a fault detection tool
In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, or
ICMP Ping [ICMP] modes depending on the underlying PSN. Since a PW
service is bi-directional, the reply SHOULD be sent over the PW in
the reverse direction, that makes up the other half of the PW service
under test. For example, if the PSN is MPLS, the reply should be sent
over the reverse PW, which is transported over the PSN LSP in the
reverse direction. If this fails, the operator may use other reply
modes to determine the fault [LSP-PING].
The fault detection mode provides a way to emulate fault detection
mechanisms in other technologies, such as ATM for example. For exam-
ple, in the fault detection mode, the BFD Bidirectional Forwarding
Detection (BFD) mechanism can be used as following: the upstream PE
sends BFD control messages periodically. When the downstream PE
doesn't receive these message for a defined period of time, it
PWE3 Working Group Expires February 2006 [Page 4]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
declares that direction of the PW down and it notifies the upstream
PE. Based on the emulated service, the PEs may send native indica-
tions over the related attachment circuits to notify the end points
of the fault condition. The specific details of the handling of these
conditions is out of the scope of this document, and are only noted
here to illustrate the utility of VCCV for these purposes.
3.1. LSP Ping
When PWs are demultiplexed using MPLS, LSP Ping is used as described
in [LSP-PING] as a connectivity verification and diagnostic tool for
PWs. The PSN may be MPLS or IP.
3.2. L2TPV3
When IP is used as the PSN, various protocols can be deployed for PW
Demultiplexing [PWEARCH]. If L2TP or UDP is used, ICMP ECHO packets
[ICMP] can be used as the means by which connectivity verification is
achieved.
3.3. Bidirectional Forwarding Detection
When fault detection indication is necessary for one or more PWs, the
Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
weight means of continuous monitoring and propagation of forward and
reverse defect indications. BFD can be used regardless of the under-
lying PSN technology.
4. VCCV Control Channels for PWs Demultiplexed using MPLS
In order to apply IP monitoring tools to PWE3 circuits, VCCV creates
a control channel between PWE3 PEs [PWEARCH]. Packets sent across
this channel are IP packets, allowing maximum flexibility.
Ideally such a control channel would be completely in band. When a
control word is present on virtual circuit, it is possible to indi-
cate the control channel by setting a bit in the control header.
This method is described in section 4.1 and is referred to as PWE3
inband VCCV.
4.1. Inband VCCV
The PW set-up protocol [PWSIG] determines whether a PW uses a control
word. When a control word is used, it SHOULD have the following form
PWE3 Working Group Expires February 2006 [Page 5]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
for the purpose of indicating VCCV control channel messages. (Note
that for data, one uses the control word defined just above the MPLS
payload [PWEARCH].)
The PW Associated Channel for VCCV control channel traffic is defined
as follows in [PW-CW]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| FmtID | Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Associated Channel Header
The first nibble is set to 0x0001. The Format ID and the reserved
fields are set to 0 and the channel type is used as defined in [PW-
CW, PWE3IANA].
For example, the following is an example of how the ethernet control
word would be received [ENETENCAP]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| 0 | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PW Associated Channel Header for VCCV
It should be noted that PWs are not required to carry the control
word, and that this method can only be used for those PWs that do.
4.2. Out-of-Band VCCV
When the control word is not used, or the receiving hardware cannot
divert control traffic based on information in the control word
(i.e.: older hardware), a VCCV control channel can be created alter-
natively by including the MPLS router alert label [RFC3032] immedi-
ately above the PW label. If the control word is in use on this PW it
is also included in the VCCV control flow. It should be noted that
this approach may alter equal cost multi-path (ECMP) hashing behav-
ior, and thus the VCCV traffic may take a path which differs from
that of the data traffic under test.
PWE3 Working Group Expires February 2006 [Page 6]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
4.3. TTL Expiry VCCV
The TTL of the PW demultiplexor label can be set to 1 to force the
packet to be processed within the destination router's control plane.
This is an inband control channel identification mechanism that is an
alternate to section 4.1.
When the PSN is MPLS it should be noted that this mode may not work
in cases where the penultimate hop overwrites the TTL values of
labels underneath the top-most label. Some older implementations do
this, and the result would be a false positive. Therefore, we recom-
mend that operators investigate the TTL handling behavior of the
routers in their networks to determine if this situation can occur.
If it is discovered that it can, than this mode should not be used
for the reasons explained above.
5. VCCV Types
VCCV can carry several types of protocols that can be used on the
control channel either at the same time, or serially. The specific
type or types of VCCV packets accepted by a router are indicated dur-
ing signaling as described in section 6. The various VCCV types sup-
ported SHOULD be used only when they apply to the PW demultiplexor in
use. For example, the LSP Ping type should only be used when MPLS is
utilized as the PW demultiplexor.
5.1. MPLS LSP Ping Packet
The LSP Ping header must be used as described [LSP-PING] and must
also contain the sub-TLV of 8 for the L2 VPN endpoint or 9 for the L2
circuit ID. The sub-TLV indicates the PW to be verified.
5.2. Bidirectional Forwarding Detection
When heart-beat indication is necessary for one or more PWs, the
Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
weight means of continuous monitoring and propagation of forward
and reverse defect indications.
In order to use BFD, both ends of the PW connection must have sig-
naled the existence of a control channel and the ability to run BFD.
Once a node has both signaled and received signaling from its peer of
these capabilities, it MUST begin sending BFD control packets. The
packets MUST be sent on the control channel. The use of the control
channel provides the context required to bind the BFD session to a
particular PW (FEC). Thus normal BFD initialization procedures are
PWE3 Working Group Expires February 2006 [Page 7]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
followed. BFD MUST be run in asynchronous mode. In addition, it may
also be desirable to use LSP-Ping for periodic diagnostics, in addi-
tion to BFD, for fault detection on the same PW. The procedures for
this are described in [BFDMPLS].
When one of the PEs (PE2) doesn't receive control messages from PE1
during the specified amount of time it declares that the PW in the
direction from PE2 to PE1 is down. It stores the cause (e.g., con-
trol detection time expired) and sends a message to PE1 with H (i.e.,
"I don't hear you"). This causes PE1 to declare the PW in the direc-
tion from PE1 to PE2 down and it stores as cause: neighbor signaled
session down. Depending on the emulated services, PE2 may send a
forward direction indication (FDI) indication on its attachment
circuits and PE1 may send an RDI indication on its attachment
circuits [OAM-MAP].
BFD defines the following diagnostics:
0 -- No Diagnostic
1 -- Control Detection Time Expired
2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset (Local equipment failure)
5 -- Path Down (Alarm Suppression)
6 -- Concatenated Path Down (Propagating access link alarm)
7 -- Administratively Down
Note that the value, 0 is used when the PW is up and 2 is not appli-
cable to asynchronous mode.
6. OAM Capability Indication for PWs Demultiplexed using MPLS
To permit the indication of the type or types of PW control chan-
nel(s), and connectivity verification mode or modes over a particular
PW, a VCCV parameter is defined below that is used as part of the PW
establishment signaling. When a PE signals a PW and desires PW OAM
for that PW, it MUST indicate this during PW establishment using the
messages defined below. Specifically, for LDP the PE MUST include the
VCCV parameter in the PW setup message.
The decision of the type of VCCV control channel is left completely
to the receiving control entity. When a PE sends a label for a PW, it
uses the VCCV parameter to indicate the type of OAM control channels
and connectivity verification type or types it is willing to receive
on that PW. The capablity of supporting a control channel or chan-
nels, and connectivity type or types used over that control channel
or channels MUST be signaled before the remote PE may send VCCV mes-
sages, and then only on the control channel or channels, and using
PWE3 Working Group Expires February 2006 [Page 8]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
the connectivity verification type or types indicated.
If a PE receives VCCV messages prior to advertising capability for
this message, it MUST discard these messages and not reply to them.
In this case, the PE SHOULD increment an error counter and optionally
issue a system and/or SNMP notification to indicate to the system
administrator that this condition exists.
When LDP is used as the PW signaling protocol the requesting PE indi-
cates its configured VCCV capability or capabilities to the remote PE
by including the VCCV parameter with appropriate options indicating
which methods of OAM it supports in the interface parameter field of
the PW ID FEC TLV (FEC 128) or in the interface parameter TLV of the
Genralized PW ID FEC TLV (FEC 129). The requesting PE MAY indicate
that it supports multiple control channel options, and in doing so
agrees to support any and all indicated types if transmitted to it.
Local policy may direct the PE to support certain OAM capability and
to indicate it. The absence of the VCCV parameter indicates that no
OAM functions are supported by the requesting PE, and thus the
receiving PE MUST NOT send any VCCV control channel traffic to it.
The reception of a VCCV parameter with no options set MUST be ignored
as if one is not transmitted at all.
The receiving PE agrees to accept any of the indicated OAM types and
options by virtue of establishing the PW. If it does not or cannot
support at least one of the options specified, it MUST not establish
the PW. If the requesting PE wishes to continue, it may choose dif-
ferent options and try to signal the PW again.
6.1. Optional VCCV Parameter
[PWE3CONTROL] defines an Interface Parameter field in the LDP PW ID
FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized
PW ID FEC (FEC 129) to signal different capabilities for specific
PWs. We propose an optional parameter to be used to indicate the
desire to use a control channel for VCCV. This is the VCCV parameter
field. If FEC 128 is used the VCCV parameter field is carried in the
Interface Parameters field. If FEC 129 is used it is carried as a
sub-TLV in the Interface Parameters TLV.
The VCCV parameter ID is defined as follows in [PWE3IANA]:
Parameter ID Length Description
0x0c 4 VCCV
The format of the VCCV parameter field is as follows:
0 1 2 3
PWE3 Working Group Expires February 2006 [Page 9]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
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 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Channel (CC Types) type field defines a bitmask used to
indicate the type of control channel(s) (i.e.: none, one or both)
that may be used to receive OAM control channel traffic on. If more
than one control channel is specified, the router agrees to accept
control traffic at any time over either control channel. If none of
the types are supported, a CC Type Indicator of 0x00 SHOULD be trans-
mitted to indicate this to the peer. However, if no capability is
signaled, then the peer MUST assume that the peer is incapable of
receiving VCCV and MUST NOT send any OAM control channel traffic to
it.
0x01 PWE3 control word with 0x0001 as first nibble
0x02 MPLS Router Alert Label
0x04 MPLS PW Demultiplexor Label TL = 1
The CV Type Indicators field is a bitmask used to indicate the spe-
cific type or types (i.e.: none, one or more) of control channel
packets that may be sent on the specified control channel. The
defined values are:
0x01 ICMP Ping
0x02 LSP Ping
0x04 BFD for PW Fault Detection only
0x08 BFD for PW Fault Detection and AC/PW Fault
Status Signaling
It should be noted that two different CV Types have been defined
when BFD is used. In the first case, type 0x04 indicates that
BFD is used exclusively to detect faults on the PW and the
status of those faults should be conveyed using some means other
than BFD. In the case of type 0x08, the AC and PW status SHOULD
be conveyed via BFD status codes as specified in [OAM-MAP].
If none of the types above are supported, a CV Type Indicator of 0x00
SHOULD be transmitted to indicate this to the peer. However, if no
capability is signaled, then the peer MUST assume that the peer has
no VCCV capability.
7. VCCV Control Channel for L2TPv3/IP PSN
When L2TPv3 is used to setup a PW over an IP PSN, VCCV packets are
carried over the L2TPv3 session as defined in this section. It should
PWE3 Working Group Expires February 2006 [Page 10]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
be noted that L2TPv3 has a built-in "Hello" keepalive mechanism for
its control plane that operates "in-band" over IP with respect to the
IP protocol number, port (when UDP is used), source and destination
IP addresses. This built-in Hello mechanism provides connection sta-
tus only for the group of sessions associated with the L2TP Control
Channel. VCCV, however, allows individual L2TP sessions to be tested.
This provides a more granular mechanism which can be used to trou-
bleshoot potential problems deeper within the dataplane of L2TP end-
points themselves, or to provide additional connection status of
individual pseudo wires.
In order to carry VCCV messages within an L2TPv3 session data packet,
this draft relies on the presence of the L2-Specific Sublayer. The
presence of this field is signaled via the L2-Specific Sublayer AVP
as defined in [L2TPv3]. The 'V' bit within the Default L2-Specific
Sublayer is used to identify that a VCCV message follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Default L2-Specific Sublayer Format with V bit.
The 'V' bit indicates that a VCCV session message follows. If the PW
has not been signaled to include a L2-specific sublayer format, other
mechanisms are needed to indicate the VCCV message. Such mechanisms
are for further study.
7.1. L2TPv3 VCCV Message
The VCCV message MUST contain a VCCV AVP. It does not contain a mes-
sage header. This could either be a new VCCV ICMP Ping AVP or VCCV
BFD AVP. The usage of the L2TPv3 AVP format leaves room for adding
further AVPs to this message in the future as needed.
7.1.1. L2TPv3 VCCV ICMP Ping AVP
This AVP encodes the ICMP Ping Echo Packet [ICMP]. This AVP may be
followed by the L2TPv3 Remote End Identifier AVP to identify the PW
associated with the session.
7.1.2. L2TPv3 VCCV BFD AVP
PWE3 Working Group Expires February 2006 [Page 11]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
This AVP encodes a BFD packet that is used to verify the session.
When heart-beat indication is necessary for one or more PWs, the
Bidirectional Forwarding Detection (BFD) [BFD] provides a light-
weight means of continuous monitoring and propagation of forward and
reverse defect indications.
BFD MUST be run in asynchronous mode. BFD control packets [BFD] are
encapsulated in the AVP. The L2TPv3 session provides the context to
demultiplex the first BFD control packet.
The L2TPv3 VCCV BFD AVP may be followed by the L2TPv3 Remote End
Identifier AVP to identify the PW associated with the session.
7.2. L2TPv3 VCCV Capability Indication
A LCCE or a LAC should be able to indicate whether the session is
capable of processing VCCV packets. This is done by including the
optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP.
7.2.1. L2TPv3 VCCV Capability AVP
This AVP specifies the VCCV capability. Its attribute type is TBD.
The value field has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CV Type Indicators field defines a bitmask used to indicate the
specific type or types (i.e.: none, one or more) of IP control pack-
ets that may be sent on the specified control channel. The defined
values are:
0x01 ICMP Ping
0x02 BFD
If none of the types above are supported, a CV Type Indicator of 0x00
SHOULD be transmitted to indicate this to the session peer. However,
if no capability is signaled, then the peer MUST assume that the
other peer has no VCCV capability.
7.3. L2TPv3 VCCV Operation
PWE3 Working Group Expires February 2006 [Page 12]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
A PE sends VCCV echo requests on a L2TPv3 signaled PW for fault
detection and diagnostic of the L2TPv3 session. The destination IP
address in the echo request is set to the remote PE's IP address,
while the source IP address is set to the local PE's IP address. The
egress of the L2TPv3 session verifies the signaling and forwarding
state of the PW, on reception of the VCCV message. Any faults
detected can be signaled in the VCCV echo response. Its to be noted
that the VCCV mechanism for L2TPv3 is primarily targeted at verifying
the PW forwarding and signaling state at the egress PE. It also helps
when L2TPv3 control and session paths are not identical.
A PE must send VCCV packets on a L2TPv3 session only if it has sig-
naled VCCV capability to the remote end and received VCCV capability
from the remote end. If a PE receives VCCV packets and its not VCCV
capable or it has not received VCCV capability indication from the
remote end, it must discard these messages. In addition if a PE
receives VCCV messages and it has not received VCCV capability from
the remote end, it should increment an error counter. In this case
the PE can optionally issue a system and/or SNMP notification.
8. IANA Considerations
8.1. VCCV Parameter ID
VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA is
requested to maintain a registry for the CC Types and CV Types, bit-
masks in the VCCV parameter ID. The allocations must be done using
the "First Come First Served" policy defined in RFC2434. IANA is
requested to reserve the following bits in this registry:
8.1.1. CC Types
0x01 PWE3 control word with 0x0001 as first nibble
0x02 MPLS Router Alert Label
0x04 MPLS PW Demultiplexor Label TL = 1
8.1.2. CV Types
0x01 ICMP Ping
0x02 LSP Ping
0x04 BFD
8.2. L2TPv3 Assignments
PWE3 Working Group Expires February 2006 [Page 13]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
The 'V' bit within the L2TPv3 Default L2-Specific Sublayer has to
assigned by IANA. L2TPv3 VCCV ICMP Ping AVP, BFD AVP, VCCV Capability
AVP must also be assigned by IANA. IANA is requested to maintain a
registry for the CV Types, bit-mask in the VCCV Capability AVP. The
allocations must be done using the "First Come First Served" policy
defined in RFC2434. IANA is requested to reserve the following bits
in this registry:
8.2.1. CV Types
0x01 ICMP Ping
0x02 BFD
9. Security Considerations
Routers that implement the mechanism described herein are subject to
to additional denial-of-service attacks as follows:
An intruder may impersonate an LDP peer in order to
force a failure and reconnection of the TCP connection, but
where the intruder sets the Recovery Time to 0 on
reconnection.
An intruder could intercept the traffic between LDP or
peers and override the setting of the TCP Recovery Time to
be set to 0.
An intruder could inject traffic into the TCP connection
and effectively masquerade as an LDP peer. The same is
possible for the UDP stream between L2TPv3 peers. In doing
so could falsely indicate VCCV capabilities to a peer.
An intruder could intercept or inject VCCV packets effectively
providing false positives or false negatives.
An intruder could deliberately flood a peer router with VCCV
messages to either obtain services without authorization or to
deny services to others.
A misconfigured or misbehaving device could inadvertantly flood
a peer router with VCCV messages which could result in a denial
of services. In particular, if a router is either implicitly or
explicitly indicated that it cannot support one or all of the
types of VCCV, but is sent those messages in sufficient quantity,
could result in a denial of service.
PWE3 Working Group Expires February 2006 [Page 14]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
All of attacks above which concern the L2TPv3 or LDP control planes
may be countered by use of a control message authentication scheme
between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in
[LDP] or [L2TPv3]. Implementation of IP address filters may also aid
in deterring these types of attacks.
VCCV message throttling mechanisms should be employed, especially in
distributed implementations which have a centralized control plane
processor with various line cards attached by some data path. In
these architectures VCCV messages may be processed on the central
processor after being forwarded there by the receiving line card. In
this case, the path between the line card and the control processor
may become saturated if appropriate VCCV traffic throttling is not
employed, which could lead to a denial of service. Such filtering is
also useful for preventing the processing of unwanted VCCV messages,
such as those which are sent on unwanted (and perhaps unadvertised)
control channel types or VCCV types.
VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN
tunnel header. As far as the PW label is concerned the same consider-
ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel,
PSN tunnel label spoofing is also required.
10. Acknowledgements
The authors would like to thank Hari Rakotoranto, Michel Khouderchah,
Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric
Rosen, Dan Tappan,Danny McPherson and Luca Martini for their valuable
comments and suggestions.
11. References
11.1. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[BFD] Katz, D., Ward, D., Bidirectional Forwarding
Indication, draft-ietf-bfd-03.txt, July 2005
[PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for
pseudo Wire Edge to Edge Emulation (PWE3)",
draft-ietf-pwe3-iana-allocation-11.txt, June
2005.
[IANAPPP] IANA Point-to-Point Protocol Field Assignments,
April 12, 2004,
PWE3 Working Group Expires February 2006 [Page 15]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
http://www.iana.org/assignments/ppp-numbers
[LSPPING] Kompella, K., G. Swallow, " Detecting MPLS Data Plane
Failures", Internet Draft draft-ietf-mpls-lsp-ping-09.txt,
May 2005.
[PWCTRL] Martini, L., et. al., "Pseudo Wire Setup and Maintenance
using LDP", draft-ietf-pwe3-control-protocol-17.txt,
June 2005
[ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Trans-
port
of Ethernet Frames Over IP/MPLS Networks",
draft-ietf-pwe3-ethernet-encap-10.txt, June 2005.
[RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D.,
Fedorkow,
G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC
3032, January 2001.
[L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
Protocol version 3", draft-ietf-l2tpext-l2tp-base-12.txt,
March 2004.
[ICMP] Postel, J. "Internet Control Message Protocol, RFC 792
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "Label Distribution Protocol", RFC
3036, January 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[PW-CW] S. Bryant et. al., "PWE3 Control Word for use over an
MPLS PSN", draft-ietf-pwe3-cw-05.txt, June 2005.
11.2. Informative References
[MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS
Networks, Internet Draft
draft-ietf-oam-requirements-02.txt, June 2003.
[PWEARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,
March 2005
[PWREQ] Xiao, X., McPherson, D., Pate, P., "Requirements for
PWE3 Working Group Expires February 2006 [Page 16]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
Pseudo Wire Emulation Edge to-Edge (PWE3)",
draft-ietf-pwe3-requirements-08.txt, December 2003
[BFDMPLS] R. Aggarwal, et al, "BFD for MPLS LSPs", Internet
Draft <draft-ietf-bfd-mpls-02.txt>, June 2005.
[RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[OAM-MAP] T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map-
ping", draft-ietf-pwe3-oam-msg-map-03.txt,
September 2005
12. Editor Information
Thomas D. Nadeau
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
Email: tnadeau@cisco.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
13. Contributor Information
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
Email: swallow@cisco.com
Monique Morrow
Cisco Systems, Inc.
Glatt-com
CH-8301 Glattzentrum
Switzerland
Email: mmorrow@cisco.com
Yuichi Ikejiri
NTT Communication Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku
PWE3 Working Group Expires February 2006 [Page 17]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
Tokyo 100-8019
Shinjuku-ku, JAPAN
Email: y.ikejiri@ntt.com
Kenji Kumaki
KDDI Corporation
KDDI Bldg. 2-3-2,
Nishishinjuku,
Tokyo 163-8003,
JAPAN
E-mail: ke-kumaki@kddi.com
Peter B. Busschbach
Lucent Technologies
67 Whippany Road
Whippany, NJ, 07981
E-mail: busschbach@lucent.com
Vasile Radoaca
Nortel Networks
Billerica, MA, 01803
Email: vasile@nortelnetworks.com
14. Intellectual Property Statement
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.
PWE3 Working Group Expires February 2006 [Page 18]
draft-ietf-pwe3-vccv-07 VCCV September 20, 2005
15. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"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.
PWE3 Working Group Expires February 2006 [Page 19]
