Network Working Group Thomas D. Nadeau
Internet Draft Cisco Systems, Inc.
Expires: December 2004
Rahul Aggarwal
Juniper Networks
Editors
June 2004
Pseudo Wire Virtual Circuit Connectivity
Verification (VCCV)
draft-ietf-pwe3-vccv-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
Distribution of this document is unlimited. Please send comments to
the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net.
Abstract
This document describes Virtual Circuit Connection Verification
(VCCV) procedures for use with pseudo wire connections. VCCV
supports connection verification applications for pseudo wire
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 pseudo wire. A network
operator may use the VCCV procedures to test the network's
forwarding plane liveliness.
Contents
Abstract.............................................................1
IETF PWE3 Working Group Expires December 2004 [Page 1]
Internet Draft PWD June 23, 2004
1. Contributors.........................................................1
2. Introduction.........................................................2
3. Overview of VCCV Modes of Operation..................................3
4. VCCV Control Channel Types for MPLS PSN..............................3
4.1 Inband VCCV ........................................................3
4.2 Out-of-band VCCV ...................................................4
4.3 TTL Expiry VCCV ....................................................4
5. VCCV Types ..........................................................5
5.1. MPLS LSP Ping Packet .............................................5
5.2 Bidirectional Forwarding Detection ...............................5
6. OAM Capability Indication ...........................................6
6.1. Optional VCCV Parameter ..........................................6
7. VCCV Control Channel for L2TPv3/IP PSN...............................8
7.1. L2TPv3 VCCV Message...............................................11
7.2. L2TPv3 VCCV Capability Indication.................................11
7.3. L2TPv3 VCCV Operation.............................................11
8. Acknowledgments.....................................................11
9. References..........................................................11
9.2 Normative References...............................................11
9.2 Informative References.............................................11
10. Security Considerations............................................12
11. Intellectual Property Rights Notices...............................12
12. Full Copyright Statement...........................................13
1. Contributors
Thomas D. Nadeau Rahul Aggarwal
Cisco Systems, Inc. Juniper Networks
300 Beaver Brook Road 1194 North Mathilda Ave.
Boxborough, MA 01719 Sunnyvale, CA 94089
Email: tnadeau@cisco.com Email: rahul@juniper.net
George Swallow Monique Morrow
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road Glatt-com
Boxborough, MA 01719 CH-8301 Glattzentrum
Email: swallow@cisco.com Switzerland
Email: mmorrow@cisco.com
Yuichi Ikejiri Kenji Kumaki
NTT Communication Corporation KDDI Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku KDDI Bldg. 2-3-2,
Tokyo 100-8019 Nishishinjuku,
Shinjuku-ku, JAPAN Tokyo 163-8003,
Email: y.ikejiri@ntt.com JAPAN
E-mail: ke-kumaki@kddi.com
Peter B. Busschbach Vasile Radoaca
Lucent Technologies Nortel Networks
IETF PWE3 Working Group Expires December 2004 [Page 2]
Internet Draft PWD June 23, 2004
67 Whippany Road Billerica, MA, 01803
Whippany, NJ, 07981 Email: vasile@nortelnetworks.com
E-mail: busschbach@lucent.com
2. Introduction
As network operators deploy pseudo wire services, fault
detection 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 pseudo wire service is critical for the network
operator. Operators have indicated in [MPLSOAMREQS][PWREQ] that
such a tool is required for pseudo wire 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
several means of creating a control channel between PEs that
attaches the PW under test.
IETF PWE3 Working Group Expires December 2004 [Page 3]
Internet Draft PWD June 23, 2004
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | Emulated Service | Emulated |
| Services | | Services |
+-------------+ +-------------+
| | VCCV/pseudo wire | |
|Demultiplexer| Control Channel |Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
---------| 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 messages, 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
verify connectivity of the pseudo wire. To make sure that pseudo wire
packets follow the same path as the data flow, they are encapsulated
with the same labels. VCCV can operate in two modes:
IETF PWE3 Working Group Expires December 2004 [Page 4]
Internet Draft PWD June 23, 2004
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
pseudo wire is bi-directional, it makes sense to require that the
reply is send over the PSN tunnel that makes up the other half
of the PW under test. For example, if the PSN is an MPLS LSP,
the reply should be sent on the LSP representing the reverse
path. If this fails, the operator can use other reply modes to
determine what is wrong. The specific type of reply mode is
indicated during PW circuit set-up (see section 6).
The fault detection mode provides a way to emulate fault
detection mechanisms in other technologies, such as ATM for
example. For example, in the fault detection mode, the BFD
(Bidirectional Forward mechanism) 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 declares that direction of the PW down and
it notifies the upstream PE. Based on the emulated service, the
PEs may send native indications 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 the PSN is MPLS, the LSP Ping header is used as described
in [LSP-PING] as a connectivity verification and diagnostic
tool for pseudo wires.
3.2 L2TPV3
When IP is used as the PSN, various protocols can be deployed for PW
Demultiplexing (see [PWEARCH]). If L2TP or UDP is used, ICMP ECHO
packets [ICMP] can be used as the means by which connectivity
verification is achieved. If MPLS is used for PW Demultiplexing, the
LSP Ping header is used as described in [LSP-PING] for verifying the
connectivity status of pseudo wires.
3.4 Bidirectional Forwarding Detection
When fault detection indication is necessary for one or more
pseudo wires, 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 underlying
PSN technology.
IETF PWE3 Working Group Expires December 2004 [Page 5]
Internet Draft PWD June 23, 2004
4. VCCV Control Channel Types for MPLS PSN
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 indicate 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 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 PWE3 payload type identifier for VCCV control channel
traffic is defined as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| Control Word-specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| reserved = 0 | PA=0 |PPP DLL Proto Number=0021/0057 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first nibble is set to 0x0001, the protocol of the frame is
indicated by the Protocol Number. IP OAM flows are identified by
either an IPv4 (0021) or IPv6 (0057) codepoint [IANAPPP].
It should be noted that pseudo-wires are not required to
carry the control word, and that this method can only be
used for those pseudo-wires that do.
IETF PWE3 Working Group Expires December 2004 [Page 6]
Internet Draft PWD June 23, 2004
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), MPLS is utilized as the PSN,
a VCCV control channel can be created alternatively by including
the MPLS router alert label [RFC3032] immediately above the PW label.
If the control word is in use on this VC it is also included in the
VCCV control flow. It should be noted that this approach may
alter equal cost multi-path (ECMP) hashing behavior, and thus
the VCCV traffic may take a path which differs from that of the
data traffic under test.
4.3 TTL Expiry VCCV
The TTL of the inner 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.
It should be noted that this mode may not work in cases
where the penultimate hop overwrites the TTL values of
labels underneith the top-most label. Some older implementations
do this, and the result would be a false positive. Therefore,
we recommend that operators investigate the TTL behavior
of the routers in their networks to determine if this
situation can occur, and if it is discovered that it can,
that this mode should not be used for the reasons explained.
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 accepted by a router
are indicated during signaling as described in section 6.
With the exception of the BFD protocol which applies to
all PSN types, all other VCCV types supported SHOULD be
used only when they apply to the PSN in use. For example,
the LSP Ping type should only be used when MPLS is utilized
as the PSN.
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 indicate the the
circuit to be verified.
5.2 Bidirectional Forwarding Detection
IETF PWE3 Working Group Expires December 2004 [Page 7]
Internet Draft PWD June 23, 2004
When heart-beat indication is necessary for one or more
pseudo wires, 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 pseudo wire connection must
have signaled 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 pseudo wire (FEC). Thus normal BFD
initialization procedures are followed. BFD MUST be run in
asynchronous mode.
It may be desirable to use LSP-Ping additionally for periodic
diagnostics in addition to BFD for fault detection on the same
PW [BFDMPLS].
When one of the PEs (PE2) doesn't receive control messages
from PE1 during the specified amount of time, or if it
determines that reachability to PE1 is no longer available, it
declares that the PW in the direction from PE2 to PE1 is down.
It stores the cause (e.g. control detection time expired) and
sends a message to PE1 with H (i.e. "I don't hear you"). In
turn, PE1 declares the PW in the direction from PE1 to PE2
down and stores as cause: neighbor signaled session down.
Depending on the emulated services, PE2 may send a FDI
indication on its attachment circuits and PE1 may send an RDI
indication on its attachment circuits.
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
Of these, 0 is used when the PW is up and 2 is not applicable
to asynchronous mode.
6. OAM Capability Indication
To permit the advertisement of the type of pseudo wire control
IETF PWE3 Working Group Expires December 2004 [Page 8]
Internet Draft PWD June 23, 2004
channel or channels, and connectivity verification mode or modes
over a particular pseudo wire, a VCCV parameter is defined below
that is used as part of the pseudo wire establishment signaling.
When a PE signals a pseudo wire and desires pseudo wire OAM for that
pseudo wire, 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.
As the overall method of PWE3 signaling is downstream,
unsolicited, 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 pseudo wire. The capablity of
supporting a control channel or channels, and connectivity type or
types used over that control channel or channels MUST be signaled
BEFORE the remote PE may send VCCV messages, and then only on the
control channel or channels, and using 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. Further
action should be taken to prevent the remote PE from continuing
to send the unwanted messages.
The requesting PE indicates 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 sub-TLV portion of the FEC TLV.
The requesting PE MAY indicate that it supports multiple control
channel options, and in doing so agrees to support any and all
advertised types if transmitted to it. Local policy may direct the
PE to support certain OAM capability and to advertise it. The absence
of the VCCV interface parameter sub-TLV in the FEC TLV 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 sub-TLV 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 different options and
try to signal the PW again.
6.1. Optional VCCV Parameter
IETF PWE3 Working Group Expires December 2004 [Page 9]
Internet Draft PWD June 23, 2004
[PWE3CONTROL] defines a PW FEC Interface TLV Parameters for LDP.
Parameters can be carried within that TLV 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 as follows.
The TLV field structure is defined in [PWE3CONTROL].
The VCCV parameter ID is defined as follows in [PWE3IANA]:
Parameter ID Length Description
0x0c 4 VCCV
The format of the VCCV parameter TLV is as 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 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Channel (CC) 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 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 transmitted 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 inner label TTL = 1
The CV Type Indicators field defines a bitmask used to indicate the
specific 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
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.
IETF PWE3 Working Group Expires December 2004 [Page 10]
Internet Draft PWD June 23, 2004
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
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 status
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
troubleshoot potential problems deeper within the dataplane of L2TP
endpoints themselves, or to provide additional connection status of
individual pseudo wires.
In order to carry VCCV messages within an L2TPv3 session data packet,
the default L2-Specific Sublayer MUST be present. 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
messageheader. 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
pseudo wire associated with the session.
7.1.2. L2TPv3 VCCV BFD AVP
IETF PWE3 Working Group Expires December 2004 [Page 11]
Internet Draft PWD June 23, 2004
This AVP encodes a BFD packet that is used to verify the session.
When heart-beat indication is necessary for one or more
pseudo wires, 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 pseudo wire associated with the session.
7.2. L2TPv3 VCCV Capability Negotiation
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
packets 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
A PE sends VCCV echo requests on a L2TPv3 signaled pseudo wire for
fault detection and diagnostic of the L2TPv3 session. The destination
IETF PWE3 Working Group Expires December 2004 [Page 12]
Internet Draft PWD June 23, 2004
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 pseudo wire, 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 pseudo wire 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
signaled 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. Acknowledgments
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.
9. References
9.1 Normative References
[BFD] Katz, D., Ward, D., Bidirectional Forwarding
Indication, draft-katz-ward-bfd-01.txt, August
2003.
[PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for
pseudo Wire Edge to Edge Emulation (PWE3)",
draft-ietf-pwe3-iana-allocation-04.txt, April
2004.
[IANAPPP] IANA Point-to-Point Protocol Field Assignments,
April 12, 2004,
http://www.iana.org/assignments/ppp-numbers
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
G., Wadhwa, S., Bonica, R., " Detecting MPLS Data Plane
Failures", Internet Draft draft-ietf-mpls-lsp-ping-05.txt,
February 2004.
[PWCTRL] Martini, L., et. al., "Pseudo Wire Setup and Maintenance
IETF PWE3 Working Group Expires December 2004 [Page 13]
Internet Draft PWD June 23, 2004
using LDP", draft-ietf-pwe3-control-protocol-07.txt,
June 2004
[ENETENCAP] Martini, L., et. al., "Encapsulation Methods for Transport
of Ethernet Frames Over IP/MPLS Networks",
draft-ietf-pwe3-ethernet-encap-06.txt, April 2004.
[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.
9.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", Internet
Draft, draft-ietf-pwe3-arch-07.txt, March 2004
[PWREQ] Xiao, X., McPherson, D., Pate, P., "Requirements for
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-raggarwa-mpls-bfd-00.txt>, October 2003.
10. 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
IETF PWE3 Working Group Expires December 2004 [Page 14]
Internet Draft PWD June 23, 2004
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 advertise 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.
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
considerations as specified in [RFC3031] apply. If the PSN is a
MPLS tunnel, PSN tunnel label spoofing is also required.
11. Intellectual Property Rights Notices
IETF PWE3 Working Group Expires December 2004 [Page 15]
Internet Draft PWD June 23, 2004
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF
Executive Director.
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS 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.
IETF PWE3 Working Group Expires December 2004 [Page 16]
