A Unified Control Channel for Pseudowires
draft-ietf-pwe3-vccv-for-gal-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Luca Martini , Thomas Nadeau | ||
| Last updated | 2012-01-27 | ||
| Replaced by | draft-ietf-pals-vccv-for-gal, draft-ietf-pals-vccv-for-gal, draft-ietf-pals-vccv-for-gal, RFC 7708 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pwe3-vccv-for-gal-00
Network Working Group T. Nadeau
Internet-Draft CA Technologies
Intended status: Standards Track
Expires: July 27, 2012 L. Martini
Cisco Systems, Inc.
January 27, 2012
A Unified Control Channel for Pseudowires
draft-ietf-pwe3-vccv-for-gal-00.txt
Abstract
This document describes a unified mode of operation for Virtual
Circuit Connectivity Verification (VCCV), which provides a control
channel that is associated with a pseudowire (PW). VCCV applies to
all supported access circuit and transport types currently defined
for PWs, as well as those being transported by The MPLS Transport
Profile. This new mode is intended to augment those described in
RFC5085, but this document describes new rules requiring this mode
to be used as the default/mandatory mode of operation for
VCCV. The older types will remain optional.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 27, 2012.
Copyright Notice
Nadeau & Martini Expires July 2011 [Page 1]
VCCV 2 January 27, 2011
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. VCCV Control Channel When The Control Word is Used . . . . . . 6
3. VCCV Control Channel When The Control Word is Not Used . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
4.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19
4.1.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction
There is a need for fault detection and diagnostic mechanisms that
can be used for end-to-end fault detection and diagnostics for a
Pseudowire, as a means of determining the PW's true operational
state. Operators have indicated in [RFC4377], [RFC3916].
that such a tool is required for PW operation and maintenance. To
this end, the IETF's PWE3 Working Group defined The Virtual
Circuit Connectivity Verification Protocol (VCCV) in [RFC5085].
Since then a number of interoperability issues have arisen with the
protocol as it is defined.
Over time, a variety of VCCV options or "modes" have been created to
support legacy hardware, the use of the control word in some cases,
while in others not. The difficulty of operating these
different combinations of "modes" have been detailed in an
implementation survey the PWE3 Working Group conducted. Many of the
motivations of this survey are detailed in [MAN-CW]. This document
Nadeau & Martini Expires July 2011 [Page 2]
VCCV 2 January 27, 2011
and the implementation survey concluded that operators have had
difficulty deploying the protocol given the number of combinations
and options for its use.
In addition to the implementation issues just described, the ITU-T
and IETF have set out to enhance MPLS to make it suitable as an
optical transport protocol. The requirements for this protocol are
defined as the MPLS Transport Profile (MPLS-TP). The requirements
for this protocol can be found in [RFC5654]. In order to support
VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created;
this effectively resulted in another mode of operation.
This document defines two modes of operation of VCCV: 1) with
a control word or 2) without a control word, but
with a ACH encapsulation making it possible to handle all of the
other cases handled by the other modes of VCCV. In either case, it
will be mandatory to implement and use that mode under that
scenario.
Figure 1 depicts the architecture of a pseudowire as defined in
[RFC3985]. It further depicts where the VCCV control channel resides
within this architecture, which will be discussed in detail shortly.
|<-------------- Emulated Service ---------------->|
| |<---------- VCCV ---------->| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 1: PWE3 VCCV Operation Reference Model
From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to
Nadeau & Martini Expires July 2011 [Page 3]
VCCV 2 January 27, 2011
the emulated service via Attachment Circuits (ACs), and to each of
the Provider Edge (PE) routers (PE1 and PE2, respectively). An AC
can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM
Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an
Ethernet port, etc. The PE devices provide pseudowire emulation,
enabling the CEs to communicate over the PSN. A pseudowire exists
between these PEs traversing the provider network. VCCV provides
several means of creating a control channel over the PW, between the
PE routers that attach the PW.
Figure 2 depicts how the VCCV control channel is associated with the
pseudowire protocol stack.
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | < Emulated Service > | Emulated |
| Services | | Services |
+-------------+ +-------------+
| | VCCV/PW | |
|Demultiplexer| < Control Channel > |Demultiplexer|
+-------------+ +-------------+
| PSN | < PSN Tunnel > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP or IP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 2: PWE3 Protocol Stack Reference Model including the VCCV
Control Channel
VCCV messages are encapsulated using the PWE3 encapsulation as
described in Sections 2 and 3, so that they are handled and processed
in the same manner (or in some cases, a similar manner) as the PW
PDUs for which they provide a control channel. These VCCV messages
are exchanged only after the capability (expressed as two VCCV type
spaces, namely the VCCV Control Channel and Connectivity Verification
Types) and desire to exchange such traffic has been advertised
between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.
Nadeau & Martini Expires July 2011 [Page 4]
VCCV 2 January 27, 2011
1.2. Acronyms
AC Attachment Circuit [RFC3985].
AVP Attribute Value Pair [RFC3931].
CC Control Channel (used as CC Type).
CE Customer Edge.
CV Connectivity Verification (used as CV Type).
CW Control Word [RFC3985].
L2SS L2-Specific Sublayer [RFC3931].
LCCE L2TP Control Connection Endpoint [RFC3931].
OAM Operation and Maintenance.
PE Provider Edge.
PSN Packet Switched Network [RFC3985].
PW Pseudowire [RFC3985].
PW-ACH PW Associated Channel Header [RFC4385].
VCCV Virtual Circuit Connectivity Verification [RFC5085].
2. VCCV Control Channel When The Control Word is Used
When the PWE3 Control Word is used to encapsulate pseudowire
traffic, the rules described for encapsulating VCCV CC Type 1 as
specified in section 9.5.1 [RFC6073] and section 5.1.1 of [RFC5085]
MUST be used. In this case the advertised CC Type is 1, and
Associated Channel Types of 21, 07, or 57 are allowed.
3. VCCV Control Channel When The Control Word is Not Used
When the PWE3 Control Word is not used a new CC Type 4 is
defined as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Nadeau & Martini Expires July 2011 [Page 5]
VCCV 2 January 27, 2011
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Associated Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VCCV Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Label must set the TTL field to 1. In the case
of multi-segment pseudo-wires, the PW Label TTL MUST be set to the
correct value to reach the intended destination PE as described
in [RFC6073].
The GAL field MUST contain the reserved label as defined in
[RFC5586].
The first nibble of the next field is set to 0001b to indicate
an ACH associated with a pseudowire (see Section 5 of [RFC4385]
and Section 3.6 of [RFC4446]) instead of PW data. The Version and
the Reserved fields MUST be set to 0, and the Channel Type is
set to 0x0021 for IPv4, 0x0057 for IPv6 payloads [RFC5085] or
0x0007 for BFD payloads [RFC5885].
The "VCCV Message Body" field is defined based on the Associated
Channel Type and defined therein.
4. VCCV Capability Advertisement
The capability advertisement MUST match that c-bit setting
that is advertised in the PW FEC element. If the c-bit is set,
indicating the use of the control word, type 1 MUST be advertised
and type 4 MUST NOT be advertised. If the c-bit is not set,
indicating that the control word is not in use, type 4 MUST
be advertised, and type 1 MUST NOT be advertised.
A PE supporting Type 4 MAY advertise other CC types
as defined in RFC5085. If the remote PE also supports Type
4, then Type 4 MUST be used superceding the Capability
Advertisement Selection rules of section 7 from RFC5085.
If a remote PE does not support Type 4, then the rules
from section 7 of RFC5085 apply. If a CW is in use, then
Type 4 is not applicable, and therefore the normal
Nadeau & Martini Expires July 2011 [Page 6]
VCCV 2 January 27, 2011
capability advertisement selection rules of section 7
from RFC5085 apply.
4. IANA Considerations
4.1. VCCV Interface Parameters Sub-TLV
The VCCV Interface Parameters Sub-TLV codepoint is defined in
[RFC4446]. IANA has created and will maintain registries for the CC
Types and CV Types (bitmasks in the VCCV Parameter ID). The CC Type
and CV Type new registries (see Sections 8.1.1 and 8.1.2,
respectively) have been created in the Pseudo Wires Name Spaces,
reachable from [IANA.pwe3-parameters]. The allocations must be done
using the "IETF Consensus" policy defined in [RFC5226].
4.1.1. MPLS VCCV Control Channel (CC) Type 4
IANA is requested to augment the registry of "MPLS VCCV Control
Channel Types" with the new type defined below. As defined in
RFC5058, this new bitfield is to be assigned by IANA using
the "IETF Consensus" policy defined in [RFC5226]. A VCCV
Control Channel Type description and a reference to an RFC approved
by the IESG are required for any assignment from this registry.
MPLS Control Channel (CC) Types:
Bit (Value) Description
============ ==========================================
Bit 3 (0x08) - Type 4
The most significant (high order) bit is labeled Bit 7, and the least
significant (low order) bit is labeled Bit 0, see parenthetical
"Value".
5. Security Considerations
This document does not by itself raise any particular security
considerations that differ from those described in RFC5085.
6. Acknowledgements
7. References
7.1. Normative References
Nadeau & Martini Expires July 2011 [Page 7]
VCCV 2 January 27, 2011
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[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.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", RFC 5885,
June 2010.
[RFC5654] Niven-Jenkins, B., Brungard, D., and M. Betts,
"Requirements of an MPLS Transport Profile", RFC 5654,
September 2009
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and
M. Aissaoui, "Segmented Pseudowire", RFC 6073,
January 2011.
12.2. Informative References
[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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
Nadeau & Martini Expires July 2011 [Page 8]
VCCV 2 January 27, 2011
RFC 5226, May 2008.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks",
RFC 4377, February 2006.
[MAN-CW] Del Regno, N., Nadeau, T., Manral, V., Ward, D.,
"Mandatory Use of Control Word for PWE3 Encapsulations",
"Work in progress", October 2010.
8. Authors' Addresses
Thomas D. Nadeau
CA Technologies
273 Corporate Drive, Portsmouth, NH, USA
Email: thomas.nadeau@ca.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112 USA
EMail: lmartini@cisco.com
Nadeau & Martini Expires July 2011 [Page 9]