One document matched: draft-ietf-pwe3-vccv-for-gal-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pwe3-vccv-for-gal-02"
ipr="trust200902" updates="5085">
<front>
<title abbrev="VCCV 2">A Unified Control Channel for Pseudowires</title>
<author fullname="Thomas D. Nadeau" initials="T D" surname="Nadeau">
<organization>lucidvision</organization>
<address>
<email>tnadeau@lucidvision.com</email>
</address>
</author>
<author fullname="Luca Martini" initials="L " surname="Martini">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
</postal>
<email>lmartini@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<date year="2014" />
<area>Routing</area>
<workgroup>PWE3</workgroup>
<keyword>VCCV</keyword>
<keyword>GAL</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Requirements Language and Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t><list hangIndent="15" style="hanging">
<t hangText="AC">Attachment Circuit <xref
target="RFC3985"></xref>.</t>
<t hangText="AVP">Attribute Value Pair <xref
target="RFC3931"></xref>.</t>
<t hangText="CC">Control Channel (used as CC Type).</t>
<t hangText="CE">Customer Edge.</t>
<t hangText="CV">Connectivity Verification (used as CV Type).</t>
<t hangText="CW">Control Word <xref target="RFC3985"></xref>.</t>
<t hangText="L2SS">L2-Specific Sublayer <xref
target="RFC3931"></xref>.</t>
<t hangText="LCCE">L2TP Control Connection Endpoint <xref
target="RFC3931"></xref>.</t>
<t hangText="OAM">Operation and Maintenance.</t>
<t hangText="PE">Provider Edge.</t>
<t hangText="PSN">Packet Switched Network <xref
target="RFC3985"></xref>.</t>
<t hangText="PW">Pseudowire <xref target="RFC3985"></xref>.</t>
<t hangText="PW-ACH">PW Associated Channel Header <xref
target="RFC4385"></xref>.</t>
<t hangText="VCCV">Virtual Circuit Connectivity Verification <xref
target="RFC5085"></xref>.</t>
</list></t>
</section>
<section title="Introduction">
<t>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 <xref target="RFC4377"></xref>, and <xref
target="RFC3916"></xref> 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 <xref
target="RFC5085"></xref> . Since then a number of interoperability
issues have arisen with the protocol as it is defined.</t>
<t>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 <xref target="RFC7079"></xref>. 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.</t>
<t>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 <xref target="RFC5654"></xref>. In order to support VCCV
when an MPLS-TP PSN is in use, the GAL-ACH had to be created <xref
target="RFC5586"></xref>. This resulted in yet another mode of VCCV
operation.</t>
<t>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.</t>
<t><xref target="VCCVREF"></xref> depicts the architecture of a
pseudowire as defined in <xref target="RFC3985"></xref>. It further
depicts where the VCCV control channel resides within this architecture,
which will be discussed in detail later in this document.</t>
<figure anchor="VCCVREF" title="PWE3 VCCV Operation Reference Model">
<artwork><![CDATA[ |<-------------- 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
]]></artwork>
</figure>
<t></t>
<t>From <xref target="VCCVREF"></xref>, 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.</t>
<t><xref target="PSREF"></xref> depicts how the VCCV control channel is
associated with the pseudowire protocol stack.</t>
<figure anchor="PSREF"
title="PWE3 Protocol Stack Reference Model including the VCCV Control Channel">
<artwork><![CDATA[ +-------------+ +-------------+
| 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 |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
]]></artwork>
</figure>
<t></t>
<t>VCCV messages are encapsulated using the PWE3 encapsulation as
described in <xref target="VCCVwithCW"></xref> and <xref
target="VCCVwithoutCW"></xref>, 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 <xref
target="RFC5085"></xref>), and VCCV type to use have been chosen.</t>
<t>[EDITOR'S NOTE - Why are we talking about 6.3 which is L2TPv3 related
in a text on GAL?]</t>
</section>
<section anchor="VCCVwithCW"
title="VCCV Control Channel When The Control Word is Used">
<t>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 <xref target="RFC6073"></xref> and section 5.1.1 of
<xref target="RFC5085"></xref> MUST be used. In this case the advertised
CC Type is 1, and Associated Channel Types of 21, 07, or 57 are
allowed.</t>
</section>
<section anchor="VCCVwithoutCW"
title="VCCV Control Channel When The Control Word is Not Used">
<t>When the PWE3 Control Word is not used a new CC Type 4 is defined as
follows:</t>
<figure>
<artwork><![CDATA[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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t></t>
<t>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?</t>
<t>EDITOR's note = not sure if it should be MUST or SHOULD in the text
below.</t>
<t>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 <xref
target="RFC6073"></xref>.</t>
<t>The GAL LSE MUST contain the GAL reserved label as defined in <xref
target="RFC5586"></xref>.</t>
<t>As defined in <xref target="RFC4385"></xref> and <xref
target="RFC4446"></xref> 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 <xref
target="RFC5085"></xref> or 0x0007 for BFD payloads <xref
target="RFC5885"></xref>.</t>
<t>The Associated Channel Type defines how the "VCCV Message Body" field
is to be interpreted by the receiver.</t>
</section>
<section title="VCCV Capability Advertisement">
<t>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.</t>
<t>A PE supporting Type 4 MAY advertise other CC types as defined in
<xref target="RFC5085"></xref> . If the remote PE also supports Type 4,
then Type 4 MUST be used superseding the Capability Advertisement
Selection rules of section 7 from <xref target="RFC5085"></xref> . If a
remote PE does not support Type 4, then the rules from section 7 of
<xref target="RFC5085"></xref> 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 <xref target="RFC5085"></xref>
apply.</t>
</section>
<section title="Manageability Considerations">
<t>Editor's note - this is a placeholder - I am not sure if it sis
needed</t>
</section>
<section title="Security Considerations">
<t>This document does not by itself raise any new security
considerations beyond those described in <xref
target="RFC5085"></xref>.</t>
</section>
<section title="IANA Considerations">
<t></t>
<section title="VCCV Interface Parameters Sub-TLV">
<t>EDITOR'S NOTE ASFAICS this section can be deleted.</t>
<t>The VCCV Interface Parameters Sub-TLV code point is defined in
<xref target="RFC4446"></xref>. 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<xref target="RFC5085"></xref> ) have
been created in the Pseudo Wires Name Spaces, . The allocations must
be done using the "IETF Review" policy defined in <xref
target="RFC5226"></xref>.</t>
<t></t>
</section>
<section title="MPLS VCCV Control Channel (CC) Type 4">
<t>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.</t>
<figure>
<artwork><![CDATA[MPLS VCCV Control Channel (CC) Types
Bit (Value) Description Reference
============ =========== ====================
Bit X (0x0Y) Type 4 [This Specification]]]></artwork>
</figure>
<t></t>
</section>
</section>
<section title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.4446'?>
<?rfc include='reference.RFC.5654'?>
<?rfc include='reference.RFC.6073'?>
<?rfc include='reference.RFC.3931'?>
<?rfc include='reference.RFC.4385'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.5885'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.4377'?>
<?rfc include='reference.RFC.3916'?>
<?rfc include='reference.RFC.7079'?>
<?rfc include='reference.RFC.3985'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:36:18 |