Internet DRAFT - draft-ietf-pwe3-vccv-for-gal
draft-ietf-pwe3-vccv-for-gal
PWE3 T. Nadeau
Internet-Draft lucidvision
Updates: 5085 (if approved) L. Martini
Intended status: Standards Track S. Bryant
Expires: March 6, 2015 Cisco Systems
September 2, 2014
A Unified Control Channel for Pseudowires
draft-ietf-pwe3-vccv-for-gal-02
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. It describes new rules requiring this mode to be used as
the default/mandatory mode of operation for VCCV. The older VCCV
types will remain optional.
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 March 6, 2015.
Copyright Notice
Copyright (c) 2014 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
Nadeau, et al. Expires March 6, 2015 [Page 1]
Internet-Draft VCCV 2 September 2014
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. Requirements Language and Terminology . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. VCCV Control Channel When The Control Word is Used . . . . . 5
4. VCCV Control Channel When The Control Word is Not Used . . . 6
5. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 7
8.2. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
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].
Nadeau, et al. Expires March 6, 2015 [Page 2]
Internet-Draft VCCV 2 September 2014
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. 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], and [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, these modes use of the CW in some cases,
while in others the CW is not used. The difficulty of operating
these different combinations of "modes" have been detailed in an
implementation survey conducted by the PWE3 Working Group and
documented in [RFC7079]. The implementation survey and the PWE3
Working Group have concluded that operators have difficulty deploying
the VCCV OAM protocol due to 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 MPLS-TP 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 [RFC5586].
This resulted in yet another mode of VCCV operation.
This document defines two modes of operation of VCCV: 1) with a
control word or 2) without a control word, both with a ACH
encapsulation making it possible to handle all of the other cases
handled by the other modes of VCCV. The modes of operation defined
in this document MUST be implemented.
Nadeau, et al. Expires March 6, 2015 [Page 3]
Internet-Draft VCCV 2 September 2014
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 later in
this document.
|<-------------- 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
the emulated service via Attachment Circuits (AC), 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, or any other attachment type for which a PW is defined. 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.
Nadeau, et al. Expires March 6, 2015 [Page 4]
Internet-Draft VCCV 2 September 2014
+-------------+ +-------------+
| 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 Section 3 and Section 4, so that they are handled and
processed in the same manner (or in some cases, a similar manner) the
PW PDUs for which they provide a control channel. These VCCV
messages are exchanged only after the capability (the VCCV Control
Channel and Connectivity Verification types) and the desire to
exchange VCCV traffic has been advertised between the PEs (see
Sections 5.3 and 6.3 of [RFC5085]), and VCCV type to use have been
chosen.
[EDITOR'S NOTE - Why are we talking about 6.3 which is L2TPv3 related
in a text on GAL?]
3. 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 of [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.
Nadeau, et al. Expires March 6, 2015 [Page 5]
Internet-Draft VCCV 2 September 2014
4. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL LSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Associated Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VCCV Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EDITOR's note = when we wrote RFC3985 I seem to remember that TTL=1
was problematic do we want to specify TTL=1 in the text below?
EDITOR's note = not sure if it should be MUST or SHOULD in the text
below.
When the PW is a single segment PW, the TTL field of the PW Label
Stack Entry (LSE) SHOULD be set to 1. In the case of multi-segment
pseudo-wires, the PW LSE TTL SHOULD be set to the value needed to
reach the intended destination PE as described in [RFC6073].
The GAL LSE MUST contain the GAL reserved label as defined in
[RFC5586].
As defined in [RFC4385] and [RFC4446] the first nibble of the next
field is set to 0001b to indicate an ACH associated with a pseudowire
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 Associated Channel Type defines how the "VCCV Message Body" field
is to be interpreted by the receiver.
Nadeau, et al. Expires March 6, 2015 [Page 6]
Internet-Draft VCCV 2 September 2014
5. VCCV Capability Advertisement
The capability advertisement MUST match the 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 superseding 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 capability
advertisement selection rules of section 7 from [RFC5085] apply.
6. Manageability Considerations
Editor's note - this is a placeholder - I am not sure if it sis
needed
7. Security Considerations
This document does not by itself raise any new security
considerations beyond those described in [RFC5085].
8. IANA Considerations
8.1. VCCV Interface Parameters Sub-TLV
EDITOR'S NOTE ASFAICS this section can be deleted.
The VCCV Interface Parameters Sub-TLV code point is defined in
[RFC4446]. IANA has created and will maintain registries for the CC
Types and CV Types (bit masks in the VCCV Parameter ID). The CC Type
and CV Type new registries (see Sections 8.1.1 and 8.1.2,
respectively of[RFC5085] ) have been created in the Pseudo Wires Name
Spaces, . The allocations must be done using the "IETF Review" policy
defined in [RFC5226].
8.2. MPLS VCCV Control Channel (CC) Type 4
IANA is requested to assign a new bit from the MPLS VCCV Control
Channel (CC) Types registry in the PWE3-parameters name space in
order to identify VCCV type 4. It is recommended that Bit 3 be
assigned to this purpose which would have a value of 0x08.
Nadeau, et al. Expires March 6, 2015 [Page 7]
Internet-Draft VCCV 2 September 2014
MPLS VCCV Control Channel (CC) Types
Bit (Value) Description Reference
============ =========== ====================
Bit X (0x0Y) Type 4 [This Specification]
9. Acknowledgements
10. References
10.1. Normative References
[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., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
10.2. Informative References
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
Nadeau, et al. Expires March 6, 2015 [Page 8]
Internet-Draft VCCV 2 September 2014
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and
Virtual Circuit Connectivity Verification (VCCV)
Implementation Survey Results", RFC 7079, November 2013.
Authors' Addresses
Thomas D. Nadeau
lucidvision
Email: tnadeau@lucidvision.com
Luca Martini
Cisco Systems
Email: lmartini@cisco.com
Stewart Bryant
Cisco Systems
Email: stbryant@cisco.com
Nadeau, et al. Expires March 6, 2015 [Page 9]