PWE3 T. Nadeau, Ed.
Internet-Draft BT
Intended status: Standards Track C. Pignataro, Ed.
Expires: December 27, 2008 Cisco Systems, Inc.
June 25, 2008
Bidirectional Forwarding Detection (BFD) for
the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
draft-ietf-pwe3-vccv-bfd-02
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 December 27, 2008.
Abstract
This document describes new Connectivity Verification (CV) types
using Bidirectional 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 December 27, 2008 [Page 1]
Internet-Draft BFD VCCV June 2008
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 . . . . . . . . . . . . . . . . . . . . . 6
4. Capability Selection . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 9
5.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 9
5.3. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 10
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Nadeau & Pignataro Expires December 27, 2008 [Page 2]
Internet-Draft BFD VCCV June 2008
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].
The reader is expected to be familiar with the terminology and
abbreviations defined in [RFC5085].
2. Introduction
This document describes new Connectivity Verification (CV) types
using Bidirectional Forwarding Detection (BFD) with Virtual Circuit
Connectivity Verification (VCCV). VCCV [RFC5085] 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.
BFD [I-D.ietf-bfd-base] is used over the VCCV control channel
primarily as a pseudowire fault detection mechanism, for detecting
dataplane failures. 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 PW Demultiplexer-agnostic, and hence
applicable for both MPLS and L2TPv3 Pseudowire Demultiplexers. This
document concerns itself with the BFD VCCV operation over Single-
Segment Pseudowires (SS-PW). This specification describes procedures
only for BFD asynchronous mode.
3. Bidirectional Forwarding Detection Connectivity Verification
VCCV can support several Connectivity Verification (CV) types. This
section defines new CV Types for use when BFD is used as the VCCV
payload.
The CV Type is defined as a bitmask field 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 [RFC5085]. They represent the
numerical value corresponding to the actual bit being set in the CV
Nadeau & Pignataro Expires December 27, 2008 [Page 3]
Internet-Draft BFD VCCV June 2008
Type bitfield.
BFD CV Types:
The defined values for the different BFD CV Types for MPLS and
L2TPv3 PWs are:
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
It should be noted that four BFD CV Types have been defined by
permutation of their encapsulation and functionality, 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, in some
operational modes, propagation of forward and reverse defect
indications.
In order to use BFD, both ends of the PW connection need to agree on
the BFD CV Type to use:
For statically provisioned pseudowires, both ends need to be
statically configured to use the same BFD CV Type (in addition to
be statically configured for VCCV with the same CC Type).
For dynamically established pseudowires, both ends of the PW 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 selected a valid BFD CV Type to use (either
statically provisioned or selected dynamically after the node has
both signaled and received signaling from its peer of these
capabilities), it begins sending BFD control packets.
The BFD control packets are sent on the VCCV control channel. The
use of the VCCV control channel provides the context required to bind
and bootstrap the BFD session, since discriminator values are not
exchanged; the pseudowire demultiplexer field (e.g., MPLS PW Label or
Nadeau & Pignataro Expires December 27, 2008 [Page 4]
Internet-Draft BFD VCCV June 2008
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] and Section 6 of
[I-D.ietf-bfd-generic]). A single BFD session exists per-pseudowire.
Both PW endpoints take the Active role sending initial BFD Control
packets with a "Your Discriminator" field of zero, and BFD Control
packets received with a "Your Discriminator" field of zero are
associated to the BFD session bound to the PW. BFD MUST be run in
asynchronous mode (see [I-D.ietf-bfd-base]).
When the downstream PE (D-PE) does not receive BFD control messages
from its upstream peer PE (U-PE) during a certain number of
transmission intervals (a number provisioned by the operator as
Detect Mult), 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. After this calculated Detection Time, D-PE declares the
session Down, and signals this to the remote end via the State (Sta)
with Diagnostic code 1 (Control Detection Time Expired). In turn,
U-PE declares the PW is down in its transmit direction setting the
State to Down, and it using Diagnostic code 3 (Neighbor signaled
session down) in its control messages to D-PE. U-PE enters the
"reverse defect" state for this PW. If needed, how it further
processes this error condition, and conveys this status to 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 Control packet [I-D.ietf-bfd-base]
encapsulated as specified by the CV Type (see Section 3.2).
3.2. BFD Encapsulation
There are two ways in which a BFD connectivity verification packet
may be encapsulated over the VCCV control channel. This document
defines four BFD CV Types (see Section 3), which can be grouped into
two pairs of BFD CV Types from an encapsulation point of view.
Table 1 in Section 3.3 summarizes the BFD CV Types.
o IP/UDP BFD Encapsulation (BFD with IP/UDP Headers)
In the first method, the VCCV encapsulation of BFD includes the
IP/UDP headers as defined in Section 4 of
[I-D.ietf-bfd-v4v6-1hop]. BFD Control packets are therefore
transmitted in UDP with destination port 3784 and source port
within the rage 49152 through 65535. 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
[RFC5085] and BFD).
Nadeau & Pignataro Expires December 27, 2008 [Page 5]
Internet-Draft BFD VCCV June 2008
The source IP address is a routable address of the sender. The
destination IP address is a (randomly chosen) IPv4 address from
the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/
104. The rationale is explained in Section 2.1 of [RFC4379]. The
Time to Live/Hop Limit procedures from Section 5 of
[I-D.ietf-bfd-v4v6-1hop] apply to this encapsulation, and hence
the TTL/Hop Limit is set to 255. In this encapsulation, the BFD
CV Type used in signaling (if used) is either 0x04 or 0x08.
o PW-ACH BFD Encapsulation (BFD without IP/UDP Headers)
In the second method, a BFD Control packet (format defined in
Section 4 of [I-D.ietf-bfd-base]) is encapsulated directly in the
VCCV control channel (see Sections 6 and 8 of
[I-D.ietf-bfd-generic]) and the IP/UDP headers are omitted from
the BFD encapsulation. Therefore, to utilize this encapsulation,
a pseudowire MUST use a Control Word (CW) or Layer-2 Specific
Sublayer (L2SS) that can take the PW Associated Channel Header
(PW-ACH) Control Word format.
In this encapsulation, a "raw" BFD Control packet follows directly
the PW-ACH, and the PW-ACH Channel Type identifies "raw" BFD. The
PW Associated Channel (PWAC) 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-ACH on different VCCV CC Types is specified
for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1,
5.1.2 and 5.1.3 of [RFC5085], in all cases depending on the use of
a CW. When VCCV carries raw BFD, the PW-ACH (Pseudowire CW's or
L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD
Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers,
see Section 5.2), to allow the identification of the encased BFD
payload when demultiplexing the VCCV control channel. In this
case, the BFD CV Type employed in signaling (if used) is either
0x10 or 0x20.
In summary, for the IP/UDP encapsulation of BFD (BFD with IP/UDP
headers), if a PW Associated Channel Header is used, the Channel Type
can indicate IPv4 (0x0021) or IPv6 (0x0057). For the PW-ACH
encapsulation of BFD (BFD without IP/UDP headers), the PW Associated
Channel Header MUST be used and indicates BFD Control packet
(0x0007).
3.3. CV Types for BFD
Four CV Types are defined for BFD. Table 1 summarizes the BFD CV
Types, grouping them by encapsulation (i.e., with and without IP/UDP
Nadeau & Pignataro Expires December 27, 2008 [Page 6]
Internet-Draft BFD VCCV June 2008
headers) and by functionality (i.e., fault detection only, or fault
detection and status signaling).
+----------------------------+--------------+-----------------------+
| | Fault | Fault Detection and |
| | Detection | Status Signaling |
| | Only | |
+----------------------------+--------------+-----------------------+
| BFD, IP/UDP encapsulation | 0x04 | 0x08 |
| (with IP/UDP Headers) | | |
| | | |
| BFD, PW-ACH encapsulation | 0x10 | 0x20 |
| (without IP/UDP 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 in dynamically established pseudowires,
there MUST be common CV Types in the VCCV 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 rules, restrictions and clarifications
on the usage of BFD CV Types:
1. BFD CV Types used for fault detection and status signaling (i.e.,
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. More details can be found in [I-D.ietf-pwe3-oam-msg-map].
2. BFD CV Types used for fault detection only (i.e., CV Types 0x04
and 0x10) can be used whether a protocol that can signal AC/PW
status is available or not. This includes both statically
provisioned and dynamically signaled pseudowires.
A. In this case, BFD is used exclusively to detect faults on the
PW; if it is desired to convey AC/PW fault status, some means
other than BFD are to be used. Examples include using LDP
status messages when using MPLS as a transport (see Section
5.4 of [RFC4447]), and the Circuit Status AVP in an L2TPv3
SLI message for L2TPv3 (see Section 5.4.5 of [RFC3931]).
Nadeau & Pignataro Expires December 27, 2008 [Page 7]
Internet-Draft BFD VCCV June 2008
3. Pseudowires that do not use a CW or L2SS using the PW Associated
Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e.,
PW-ACH encapsulation of BFD, without IP/UDP headers).
A. 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 [RFC5085]),
and MPLS CC Types 2 and 3 when using a Control Word (as
specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This
restriction stems from the fact that the PW-ACH contains a
Protocol Identification (PID) field, the Channel Type.
B. PWs that do not use a PW-ACH can use the VCCV BFD
encapsulation with IP/UDP headers, including its concurrent
use along with another CV Type that uses an encapsulation
with IP headers (e.g., ICMP Ping or LSP Ping). For example,
as specified in Section 7 of [RFC4385], a Pseudowire
operating without CW MUST NOT use the PW-ACH.
4. Only a single BFD CV Type can be selected and used. All BFD CV
Types are mutually exclusive with the rest, after selecting a BFD
CV Type, a node MUST NOT use any of the other three BFD CV Types.
4. Capability Selection
The precedence rules for selection of various CC and CV Types is
clearly outlined in Section 7 of [RFC5085]. 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 hinted 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.
There may be more than one CV Type available for selection after
considering the intersection of advertised and received BFD CV Types,
and applying the rules in Section 3.3. For these cases were multiple
BFD CV Types are available for selection, the following precedence
order applies when choosing the single BFD CV Type to use. The
lowest numbered item (where both ends have set the indicated flag and
such flag is allowed by the rules above) is used:
1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
Fault Detection and AC/PW Fault Status Signaling
2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
Fault Detection only
Nadeau & Pignataro Expires December 27, 2008 [Page 8]
Internet-Draft BFD VCCV June 2008
3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW
Fault Status Signaling
4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only
This precedence order prioritizes superset of functionality and
simplicity of encapsulation.
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 [RFC5085].
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.
MPLS Connectivity Verification (CV) Types:
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
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 a raw BFD Control packet follows the Pseudowire
Associated Channel as specified in Section 3.2 (i.e., when using the
PW-ACH-encapsulated BFD without IP/UDP headers), a new "Pseudowire
Associated Channel Types" Registry [RFC4385] entry of 0x07 is used.
Nadeau & Pignataro Expires December 27, 2008 [Page 9]
Internet-Draft BFD VCCV June 2008
IANA is requested to reserve a new Pseudowire Associated Channel Type
value as follows:
Value (in hex) Protocol Name Reference
-------------- --------------------------------- ---------
0x0007 BFD Control, PW-ACH encapsulation [This document]
(without IP/UDP Headers)
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.
VCCV Capability AVP (Attribute Type AVP-TBD) Values
---------------------------------------------------
L2TPv3 Connectivity Verification (CV) Types:
Bit (Value) Description
============ ====================================================
Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
AC/PW Fault Status Signaling
6. Congestion Considerations
The congestion considerations that apply to [RFC5085] 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 [RFC5085],
[I-D.ietf-bfd-base], and [I-D.ietf-bfd-v4v6-1hop]. This
specification does not raise any additional security issues beyond
Nadeau & Pignataro Expires December 27, 2008 [Page 10]
Internet-Draft BFD VCCV June 2008
these. The IP/UDP-encapsulated BFD makes use of the TTL/Hop Limit
procedures described in Section 5 of [I-D.ietf-bfd-v4v6-1hop],
including the use of the Generalized TTL Security Mechanism (GTSM) as
a security mechanism.
8. Acknowledgements
This work forks from a previous revision of the PWE3 WG document that
resulted in [RFC5085], 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.
Stewart Bryant, Luca Martini, Pankil Shah, and George Swallow
provided useful feedback and valuable comments and suggestions on the
newer versions of this document.
9. References
9.1. Normative References
[I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-08 (work in progress),
March 2008.
[I-D.ietf-bfd-generic]
Katz, D. and D. Ward, "Generic Application of BFD",
draft-ietf-bfd-generic-04 (work in progress),
January 2008.
[I-D.ietf-bfd-v4v6-1hop]
Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-08 (work in progress),
March 2008.
[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.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
Nadeau & Pignataro Expires December 27, 2008 [Page 11]
Internet-Draft BFD VCCV June 2008
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-06 (work in progress),
February 2008.
[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.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[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.
Authors' Addresses
Thomas D. Nadeau (editor)
BT
BT Centre
81 Newgate Street
London, EC1A 7AJ
United Kingdom
Email: tom.nadeau@bt.com
Nadeau & Pignataro Expires December 27, 2008 [Page 12]
Internet-Draft BFD VCCV June 2008
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 December 27, 2008 [Page 13]
Internet-Draft BFD VCCV June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Nadeau & Pignataro Expires December 27, 2008 [Page 14]
