PWE3 T. Nadeau, Ed.
Internet-Draft BT
Intended status: Standards Track C. Pignataro, Ed.
Expires: May 12, 2008 Cisco Systems, Inc.
November 9, 2007
Bi-directional Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)
draft-ietf-pwe3-vccv-bfd-00
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.
This Internet-Draft will expire on May 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes new Connectivity Verification (CV) types for
using Bi-directional Forwarding Detection (BFD) with Virtual Circuit
Connectivity Verification (VCCV). VCCV provides a control channel
that is associated with a Pseudowire (PW), as well as the
corresponding operations and management functions such as
connectivity verification to be used over that control channel.
Nadeau & Pignataro Expires May 12, 2008 [Page 1]
Internet-Draft BFD VCCV November 2007
Table of Contents
1. Specification of Requirements . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bidirectional Forwarding Detection Connectivity
Verification . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. BFD CV Type Operation . . . . . . . . . . . . . . . . . . 4
3.2. BFD Encapsulation . . . . . . . . . . . . . . . . . . . . 5
3.3. CV Types for BFD . . . . . . . . . . . . . . . . . . . . . 5
4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 7
5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 8
5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 8
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Nadeau & Pignataro Expires May 12, 2008 [Page 2]
Internet-Draft BFD VCCV November 2007
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
This document describes new Connectivity Verification (CV) types for
using Bi-directional Forwarding Detection (BFD) with Virtual Circuit
Connectivity Verification (VCCV). VCCV [I-D.ietf-pwe3-vccv] provides
a control channel that is associated with a Pseudowire (PW), as well
as the corresponding operations and management functions such as
connectivity/fault verification to be used over that control channel.
Some BFD CV Types can additionally carry fault status between the
endpoints of the Pseudowire. Furthermore, this information can then
be translated into the native OAM status codes used by the native
access technologies, such as ATM, Frame-Relay or Ethernet. The
specific details of such status interworking are out of the scope of
this document, and are only noted here to illustrate the utility of
BFD over VCCV for such purposes. Those details can be found in
[I-D.ietf-pwe3-oam-msg-map].
The new BFD CV Types are PSN-agnostic, and hence applicable for both
MPLS and L2TPv3 PSNs. This document concerns itself with the BFD
VCCV operation over Single-Segment Pseudowires (SS-PW).
3. Bidirectional Forwarding Detection Connectivity Verification
VCCV can support several Connectivity Verification types (CV types)
or protocols. This section defines new CV types for use when BFD is
used as the VCCV payload. These types apply to both MPLS and L2TPv3
Pseudowire demultiplexors.
The CV Type indicator field is defined as a bitmask used to indicate
the specific CV type or types (i.e., none, one or more) of VCCV
packets that may be sent on the VCCV control channel. The values
shown below augment those already defined in [I-D.ietf-pwe3-vccv].
They represent the numerical value corresponding to the actual bit
being set in the CV Type bitfield.
BFD CV Types:
The defined values for the different BFD CV Types for MPLS and
L2TPv3 PWs are:
Nadeau & Pignataro Expires May 12, 2008 [Page 3]
Internet-Draft BFD VCCV November 2007
Bit (Value) Description
============ ==========================================
Bit 2 (0x04) - BFD for PW Fault Detection Only.
Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling.
Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
payload without IP/UDP headers.
Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling, carrying BFD payload without
IP/UDP headers.
It should be noted that two pairs of BFD CV Types have been defined,
see Section 3.3.
3.1. BFD CV Type Operation
When heart-beat indication is necessary for one or more PWs, the
Bidirectional Forwarding Detection (BFD) [I-D.ietf-bfd-base] provides
a means of continuous monitoring of the PW data path and propagation
of forward and reverse defect indications.
In order to use BFD, both ends of the PW connection must have
signaled the existence of a control channel and the ability to run
BFD on it (see Section 3.3 and Section 4). Once a node has both
signaled and received signaling from its peer of these capabilities,
it begins sending BFD control packets. The packets are sent on the
VCCV control channel. The use of the control channel provides the
context required to bind and bootstrap the BFD session; the
Pseudowire demultiplexer field (e.g., MPLS PW Label or L2TPv3 Session
ID) provides the context to demultiplex the first BFD control packet,
and thus single-hop BFD initialization procedures are followed (see
Section 3 of [I-D.ietf-bfd-v4v6-1hop]). BFD MUST be run in
asynchronous mode (see [I-D.ietf-bfd-base]).
When the downstream PE (D-PE) does not receive control messages from
its upstream peer PE (U-PE) during a certain number of transmission
intervals (a number provisioned by the operator), D-PE declares that
the PW in its receive direction is down. In other words, D-PE enters
the "forward defect" state for this PW. D-PE then sends a message to
U-PE with H=0 (i.e., "I do not hear you") and with Diagnostic code 1.
In turn, U-PE declares the PW is down in its transmit direction and
it uses Diagnostic code 3 in its control messages to D-PE. U-PE
enters the "reverse defect" state for this PW. How it further
processes this error condition, and conveys this status the
attachment circuits is out of the scope of this specification, and is
instead defined in [I-D.ietf-pwe3-oam-msg-map].
The VCCV message comprises a BFD packet [I-D.ietf-bfd-base]
Nadeau & Pignataro Expires May 12, 2008 [Page 4]
Internet-Draft BFD VCCV November 2007
encapsulated as specified by the CV Type (see Section 3.2).
3.2. BFD Encapsulation
This document defines two pairs of BFD CV Types (see Section 3) which
specify two ways in which a BFD connectivity verification packet may
be encapsulated over the VCCV control channel. Table 1 in
Section 3.3 summarizes the BFD CV Types.
When the BFD CV Type used is either 0x04 or 0x08, the VCCV
encapsulation of BFD includes the IP/UDP headers as defined in
Section 4 of [I-D.ietf-bfd-v4v6-1hop]. The IP Protocol Number and
UDP Port numbers discriminate among the possible VCCV payloads (i.e.,
differentiate among ICMP Ping and LSP Ping defined in
[I-D.ietf-pwe3-vccv] and BFD).
However, when BFD CV Types of 0x10 or 0x20 are employed, the IP/UDP
headers are omitted from the BFD encapsulation. Therefore, these BFD
CV Types can only be used when the Pseudowire utilizes a Control Word
(CW) or Layer-2 Specific Sublayer (L2SS) that can take the PW
Associated Channel Header (PW-ACH) Control Word format. The PW
Associated Channel (PW-AC) is defined in Section 5 of [RFC4385], and
its Channel Type field is used as a payload type identifier to
discriminate the VCCV payload types. The usage of the PW-AC for VCCV
is specified in Sections 5.1.1, 5.1.2 and 5.1.3 of
[I-D.ietf-pwe3-vccv]. When VCCV carries raw BFD, the Pseudowire CW's
or L2SS' Channel Type MUST be set to 0x0007 to indicate "BFD Without
IP/UDP Headers" (see Section 5.2), to allow the identification of the
encased BFD payload when demultiplexing the control channel.
In summary, if a PW Associated Channel Header is used, the Channel
Type can indicate IPv4 (0x0021) or IPv6 (0x0057) for CV Types 0x04
and 0x08, or BFD without IP/UDP headers (0x0007) for CV Types 0x10
and 0x20.
3.3. CV Types for BFD
Two distinctive pairs of CV Types are defined for BFD. Table 1
summarizes the BFD CV Types, grouping them by encapsulation (i.e.,
with and without IP/UDP headers) and by functionality (i.e., fault
detection only, or fault detection and status signaling).
Nadeau & Pignataro Expires May 12, 2008 [Page 5]
Internet-Draft BFD VCCV November 2007
+---------------------+-----------------+---------------------------+
| | Fault Detection | Fault Detection and |
| | Only | Status Signaling |
+---------------------+-----------------+---------------------------+
| BFD with IP/UDP | 0x04 | 0x08 |
| Headers | | |
| | | |
| BFD without IP/UDP | 0x10 | 0x20 |
| Headers | | |
+---------------------+-----------------+---------------------------+
Table 1: Bitmask Values for BFD CV Types
Given the bidirectional nature of BFD, before selecting a given BFD
CV Type capability to be used, there MUST be a match in the given CV
Type capability advertised and received. That is, only BFD CV Types
that were both advertised and received are available to be selected.
Additionally, only one BFD CV Type can be used (selecting a BFD CV
Type excludes all the remaining BFD CV Types).
The following list enumerates restrictions and their corollaries on
the usage of BFD CV Types:
1. CV Types 0x08 and 0x20, SHOULD NOT be used when a control
protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
that can signal the AC/PW status to the remote endpoint of the
PW.
A. In the case of CV Type 0x08 or 0x20, the AC and PW status is
conveyed via BFD status codes as specified in
[I-D.ietf-pwe3-oam-msg-map].
2. Similarly, CV Types 0x04 and 0x10 SHOULD NOT be used when there
is no control protocol available to signal the AC/PW status.
A. In the case of type 0x04 or 0x10, BFD is used exclusively to
detect faults on the PW and the status of those faults are to
be conveyed using some means other than BFD, such as using
LDP status messages when using MPLS as a transport (see
Section 5.4 of [RFC4447]), or the Circuit Status AVP in an
L2TPv3 SLI message for L2TPv3 (see Section 5.4.5 of
[RFC3931]).
3. Only a single BFD CV Type can be seleced and used.
Nadeau & Pignataro Expires May 12, 2008 [Page 6]
Internet-Draft BFD VCCV November 2007
4. Capability Selection
The precedence rules for selection of various CC and CV types is
clearly outlined in Section 7 of [I-D.ietf-pwe3-vccv]. This section
augments these rules when the BFD CV types defined herein are
supported. The selection of a specific BFD CV Type to use out of the
four available CV Types defined is tied to multiple factors, as
detained in Section 3.3. Given that BFD is bidirectional in nature,
only CV Types that are both received and sent in VCCV capability
signaling advertisement can be selected.
As already enumerated, when a control protocol that can signal the
AC/PW status is not available, CV Types CV Types 0x04 and 0x10 (i.e.,
for Fault Detection only) SHOULD NOT be used. When a control
protocol that can signal the AC/PW status (such as LDP [RFC4447] or
L2TPv3 [RFC3931]) is available, CV Types 0x08 and 0x20 (i.e., for
Fault Detection and Status Signaling) SHOULD NOT be used. All BFD CV
Types are mutually exclusive with the rest, selecting a BFD CV Type
prevents the use of any of the other three BFD CV Types.
Finally, only Pseudowires that use a CW or L2SS using the PW
Associated Channel Header support the use of BFD CV Types 0x10 or
0x20 (i.e., encapsulation of BFD without IP/UDP headers), and
consequently the their concurrent use along with another CV Type that
uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping).
PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as
defined in Sections 5.1.1 and 6.1 of [I-D.ietf-pwe3-vccv]), and MPLS
CC Types 2 and 3 when using a Control Word (as specified in Sections
5.1.2 and 5.1.3 of [I-D.ietf-pwe3-vccv]). This restriction stems
from the fact that the PW-ACH contains a Protocol Identification
(PID) field, the Channel Type.
5. IANA Considerations
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV
The VCCV Interface Parameters Sub-TLV codepoint is defined in
[RFC4446], and the VCCV CV Types registry is defined in
[I-D.ietf-pwe3-vccv]. This section lists the new BFD CV Types.
IANA is requested to augment the "VCCV Connectivity Verification
Types" registry in the Pseudo Wires Name Spaces, reachable from
[IANA.pwe3-parameters]. These are bitfield values. CV Type values
0x04 0x08, 0x10 and 0x20 are specified in Section 3.
Nadeau & Pignataro Expires May 12, 2008 [Page 7]
Internet-Draft BFD VCCV November 2007
MPLS Connectivity Verification (CV) Types:
Bit (Value) Description
============ ==========================================
Bit 2 (0x04) - BFD for PW Fault Detection Only.
Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault Status
Signaling.
Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
payload without IP/UDP headers.
Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault Status
Signaling, carrying BFD payload without IP/UDP
headers.
5.2. PW Associated Channel Type
The PW Associated Channel Types used by VCCV rely on previously
allocated numbers from the Pseudowire Associated Channel Types
Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from
[IANA.pwe3-parameters]. In particular, 0x21 (Internet Protocol
version 4) is used whenever an IPv4 payload follows the Pseudowire
Associated Channel Header, or 0x57 is used when an IPv6 payload
follows the Pseudowire Associated Channel Header.
In cases where raw BFD follows the Pseudowire Associated Channel as
specified in Section 3.2 (i.e., when the IP/UDP encapsulation as
specified in [I-D.ietf-bfd-v4v6-1hop] is be present), a new
Pseudowire Associated Channel Types Registry [RFC4385] entry of 0x07
is used. IANA is requested to reserve a new Pseudowire Associated
Channel Type value as follows:
Value (in hex) Protocol Name Reference
-------------- ------------------------------- ---------
0x0007 BFD Without IP/UDP Headers [This document]
5.3. L2TPv3 CV Types for the VCCV Capability AVP
This section lists the new BFD CV Types to be added to the existing
"VCCV Capability AVP" registry in the L2TP name spaces. The Layer
Two Tunneling Protocol "L2TP" Name Spaces are reachable from
[IANA.l2tp-parameters].
IANA is requested to reserve the following L2TPv3 Connectivity
Verification (CV) Types in the VCCV Capability AVP Values registry.
Nadeau & Pignataro Expires May 12, 2008 [Page 8]
Internet-Draft BFD VCCV November 2007
VCCV Capability AVP (Attribute Type AVP-TBD) Values
---------------------------------------------------
L2TPv3 Connectivity Verification (CV) Types:
Bit (Value) Description
============ ==========================================
Bit 2 (0x04) - BFD for PW Fault Detection Only.
Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling.
Bit 4 (0x10) - BFD for PW Fault Detection Only, carrying BFD
payload without IP/UDP headers.
Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling, carrying BFD payload without
IP/UDP headers.
6. Congestion Considerations
The congestion considerations that apply to [I-D.ietf-pwe3-vccv]
apply to this mode of operation as well.
7. Security Considerations
Routers that implement the additional CV Types defined herein are
subject to the same security considerations as defined in
[I-D.ietf-pwe3-vccv], [I-D.ietf-bfd-base], and
[I-D.ietf-bfd-v4v6-1hop].
8. Acknowledgements
This work forks from a previous revision of the PWE3 WG document
[I-D.ietf-pwe3-vccv], to which a number of people contributed,
including Rahul Aggarwal, Peter B. Busschbach, Yuichi Ikejiri, Kenji
Kumaki, Luca Martini, Monique Morrow, George Swallow, and others.
9. References
9.1. Normative References
[I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-06 (work in progress),
March 2007.
Nadeau & Pignataro Expires May 12, 2008 [Page 9]
Internet-Draft BFD VCCV November 2007
[I-D.ietf-bfd-v4v6-1hop]
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-06 (work in progress),
March 2007.
[I-D.ietf-pwe3-vccv]
Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV) A Control Channel for
Pseudowires", draft-ietf-pwe3-vccv-15 (work in progress),
September 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
9.2. Informative References
[I-D.ietf-pwe3-oam-msg-map]
Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping",
draft-ietf-pwe3-oam-msg-map-05 (work in progress),
March 2007.
[IANA.l2tp-parameters]
Internet Assigned Numbers Authority, "Layer Two Tunneling
Protocol "L2TP"", April 2007,
<http://www.iana.org/assignments/l2tp-parameters>.
[IANA.pwe3-parameters]
Internet Assigned Numbers Authority, "Pseudo Wires Name
Spaces", June 2007,
<http://www.iana.org/assignments/pwe3-parameters>.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
Nadeau & Pignataro Expires May 12, 2008 [Page 10]
Internet-Draft BFD VCCV November 2007
Authors' Addresses
Thomas D. Nadeau (editor)
BT
BT Centre
81 Newgate Street
London, EC1A 7AJ
United Kingdom
Email: thomas.nadeau@bt.com
Carlos Pignataro (editor)
Cisco Systems, Inc.
7200 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
Email: cpignata@cisco.com
Nadeau & Pignataro Expires May 12, 2008 [Page 11]
Internet-Draft BFD VCCV November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nadeau & Pignataro Expires May 12, 2008 [Page 12]
