Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL
Luca Martini <lmartini@cisco.com> Wed, 30 November 2005 21:50 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZq9-0003k9-88; Wed, 30 Nov 2005 16:50:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhZq7-0003j1-Bn for pwe3@megatron.ietf.org; Wed, 30 Nov 2005 16:50:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03426 for <pwe3@ietf.org>; Wed, 30 Nov 2005 16:49:25 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhaAR-0001mR-Fa for pwe3@ietf.org; Wed, 30 Nov 2005 17:11:13 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2005 13:49:58 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="16269408:sNHT35006584"
Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id jAULnpdr002521; Wed, 30 Nov 2005 16:49:52 -0500 (EST)
Message-ID: <438E1E7E.7080307@cisco.com>
Date: Wed, 30 Nov 2005 14:49:50 -0700
From: Luca Martini <lmartini@cisco.com>
User-Agent: Mail/News 1.4 (X11/20050929)
MIME-Version: 1.0
To: Stewart Bryant <stbryant@cisco.com>
Subject: Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL
References: <433A4216.6010902@cisco.com>
In-Reply-To: <433A4216.6010902@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 4.7.1.128075
X-from-outside-Cisco: [10.32.241.115]
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 6d39d9cb416e7ea3531f8325a5a3638e
Content-Transfer-Encoding: 7bit
Cc: "Thomas D. Nadeau" <tnadeau@cisco.com>, pwe3 <pwe3@ietf.org>
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org
Stewart,
Specific comments are in line below. However I have some general comments.
First it seems that this draft is not using the terminology in RFC3985,
Why ? Specifically what is a "Virtual Circuit" ? In this context it
could be the ATM VC inside the PW, or something else.
This needs to be made clear.
I am also concerned that there is no discussion of how status
notifications will be processed. This draft defines some situations that
requires sending a status notification, yet there is no specification of
which pw status message should be sent.
Another question to answer is what should a PE send ? For example , if
all possible modes of VCCV are acceptable by the remote PE, what should
be used ?
I think the answer is at most one mode at once.
Luca
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.
LM: what is the definition of a virtual circuit ?
A clearer text would be:
This document describes Pseudo Wire Connection Verification
(PWCV) procedures for use with pseudo wire (PW) connections.
Connection verification applications are supported for PWs
regardless
of the underlying public service network technology.
Pseudo wire connection verification is supported by making use of
IP-based protocols to perform operations and maintenance functions.
A control channel associated with each PW is used to transport
connection verification packets that can be used by the network
operator to verify network's forwarding plane operation.
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.
LM:
If you must use the term VC , then it needs to be defined here.
+-------------+ +-------------+
| 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.
LM: Can you please fix this picture ?
if you use the xml or nroff macros it saves time for the rfc editor ,
and trouble like this ....
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
LM: nothing should be sent over the reverse PW.
it should be sent over the PW associated channel in the reverse direction.
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-
LM: How do we notify the upstream PE ?
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.
LM: Nit , the text below is probably not needed.
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
LM: what form ?
this text does not parse
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].)
LM: one ? Grammar needs fixing. ;-)
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
LM: picture is broken , needs a bunch of 0's and aligment.
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
LM: here we say that the Cw is used , but also the router alert is used
? Is this negotiated ?
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.
LM: this needs to be clearer. The TTL of the PW demultiplexor label
stack .... why would the ttl of the other labels be something else ?
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.
LM: I believe that we should drop the "older implementations" (
everywhere ) part ...
Let's stick to RFCs here. What does RFC3032 say in this matter ?
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
LM: Ok, so when can the LSP Ping type be used with IP ?
The point is that if this is a SHOULD then you need to explain why one
should not do this ...
Bottom line this need to be a MUST.
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
LM: must need to be capital ...
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].
LM: I see a big problem here. How is the message sent ? using BFD ?
We have a status notification mechanisms in the control protocol. I
believe that the control protocol can be more reliable then inband
notifications in most cases.
I believe that you should specify the use of the BFD status notification
method only if there is no other control protocol status message facility.
At minimum you must define who will be the master of the status, and why
one should not follow the control protocol procedures ...
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.
LM: for LDP ? you mean when using the pwe3 control protocol .....
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
LM: terminology: PE send a label mapping message for a PW
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-
LM: spelling ^^^^^^
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.
LM: ok, so we send a sting of bits that say " I can receive , router
alert, I can also receive CW associated channel"
Does this mean that both must be used ? or only one ?
If only one , then there is a conflict with text above ...
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM: picture needs fixing ...
LM: what is a CV type ?
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
LM:but what should be sent ? both channels ? or just one ?
I think you should specify that one should be used when sending ...
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
LM: TL ? it should be TTL
Also i believe that combining of these types should be specifically not
be allowed. For example the use of a CW with TTL=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].
LM:
In the case when the control protocol is used , I believe that a clear
statement need to be made on how all of this will work. Le me give an
example : In an ATM VC PW case , the receiving PE will receive an AIS
alarm. It will then issue a BFD equivalent, and a PW status message for
AC TX fault ... When this gets cleared a race condition will arise, and
the PW may never work again.
Note that this has nothing to do with the message mapping, it's simply a
conflict between several asynchronous state machines.
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.
LM: so which method is to be believed if there is a conflict ?
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.
LM: where is this APV defined ?
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
LM: to make it clear you should move this section up. SO you can answer
my question above ... before goin into the detail of how this is used ...
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
LM: this IANA section needs re-writing. First I think you need to
section the iana allocation ranges in a similar fashion as to the PWE3
iana document.
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
----------------------------------------------------
New iana section:
.Pa "IANA Considerations"
The IANA registries defined here, are in general subdivided into
three main ranges: a range to be allocated by IETF consensus according
to [RFC2434], a range to be allocated by the expert review process
according to [RFC2434], and a range to be allocated in a first come
first served basis reserved for vendor proprietary allocations. It
should be noted that vendor proprietary types MUST NOT be registered for
IETF standards or extensions of those, whether still in development or
already completed.
IANA is requested to create several registries as described in the
following sections. Each of these registries contains numeric values
used to identify data types. In each of these registries the value of 0
is reserved,
.Pb "Expert Review Directives"
Throughout this document allocation procedures for several registries
call for an expert review process according to [RFC2434]. The expert
should consider the following points:
.Pz *
Avoid Duplication of code point allocations.
.Pz *
A brief clear description of the code point allocation requested.
.Pz *
Whether the type allocation requested is appropriate for the particular
requested value range in the registry.
.En
The Expert reviewing the request MUST provide an answer, approving, or
disapproving the request within 10 business days from when the he or she
received the expert review request.
.Pb "VCCV Parameter ID"
VCCV parameter ID codepoint is already allocated in [PWE3IANA].
.Pb "Control Channel Type"
IANA needs to set up a registry of "Control Channel Type". These are
bit strings of length 8. Bits 0 to 2 are defined in this document.CC
Type bits 3 to 7 are to be assigned by IANA using the "Expert Review"
policy defined in [RFC2434].
Any requests for allocation from this registry require a description up
to 65 characters.
Initial Control Channel Type allocations are as follows:
0x01 PWE3 control word with 0x0001 as first nibble
0x02 MPLS Router Alert Label
0x04 MPLS PW Demultiplexor Label TTL = 1
.Pb "Control V????? Type"
IANA needs to set up a registry of "Control V????? Type". These are
bit strings of length 8. Bits 0 to 2 are defined in this document.CV
Type bits 3 to 7 are to be assigned by IANA using the "Expert Review"
policy defined in [RFC2434].
Any requests for allocation from this registry require a description up
to 65 characters.
Initial Control V?????? Type allocations are as follows:
0x01 ICMP Ping
0x02 LSP Ping
0x04 BFD
.Pb "L2TPv3 allocations"
[The 'V' bit within the L2TPv3 Default L2-Specific Sublayer has to be
assigned by IANA.] this section does not parse - please fix.
Iana should assign values for the following Attribute Value Pairs from
the "Control Message Attribute Value Pairs" registry:
Value Description
TBD VCCV ICMP Ping AVP
TBD Bidirectional Forwarding Detection (BFD) AVP
TBD VCCV Capability
[ editor note : VCCV Capability AVP must use the same format and CV/CC
types as in the PW capability sub-tlv ]
-----------------------------------------------------------------------
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]
Stewart Bryant wrote:
> This is the start of a two week last call for
>
> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-07.txt
>
> Last call will end at 9AM UK on Wednesday 12th October.
>
> - Stewart
>
>
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
- [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Stewart Bryant
- RE: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Hamid Ould-Brahim
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Carlos Pignataro
- RE: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Mustapha Aissaoui
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Thomas D. Nadeau
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Thomas D. Nadeau
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Thomas D. Nadeau
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Carlos Pignataro
- RE: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Hamid Ould-Brahim
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Thomas D. Nadeau
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Thomas D. Nadeau
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Rahul Aggarwal
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Carlos Pignataro
- Re: [PWE3] draft-ietf-pwe3-vccv-07.txt - LAST CALL Luca Martini