Using GAL as a VCCV Channel Indicator
draft-ietf-pals-vccv-for-gal-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (pals WG) | |
|---|---|---|---|
| Authors | Thomas Nadeau , Luca Martini , Stewart Bryant | ||
| Last updated | 2015-02-18 | ||
| Replaces | draft-ietf-pwe3-vccv-for-gal | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
(of
-05)
Ready with Issues
RTGDIR Early review
(of
-03)
Has Nits
|
||
| Stream | WG state | WG Document | |
| Document shepherd | Matthew Bocci | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Matthew Bocci" <matthew.bocci@alcatel-lucent.com> |
draft-ietf-pals-vccv-for-gal-02
PWE3 T D. Nadeau
Internet-Draft lucidvision
Intended status: Standards Track L . Martini
Expires: August 20, 2015 S. Bryant
Cisco Systems
February 18, 2015
Using GAL as a VCCV Channel Indicator
draft-ietf-pals-vccv-for-gal-02
Abstract
This document specifies a new Virtual Circuit Connectivity
Verification (VCCV) (RFC5085) control channel type for use with
pseudowires (PW) carried over an MPLS network. This new channel type
uses the Generic Associated Channel Label (GAL) (RFC5586) to
distinguish VCCV packets from packets carrying user data.
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 August 20, 2015.
Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
Nadeau, Martini & BryantExpires August 20, 2015 [Page 1]
Internet-Draft GAL as a VCCV Channel February 2015
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. GAL VCCV Control Channel Type . . . . . . . . . . . . . . . . 3
4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 4
6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 4
7. Manageability Considerations . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 5
9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document specifies a new Virtual Circuit Connectivity
Verification (VCCV) [RFC5085] control channel (CC) type for use with
pseudowires (PW) carried over an MPLS network that do not use the PW
Control Word (CW) [RFC4385]. This new VCCV CC type uses the Generic
Associated Channel Label (GAL) [RFC5586] to distinguish VCCV packets
from packets carrying user data. This new VCCV CC type introduces
compatibility with the method of MPLS Label Switched Path (LSP)
Operations, Administration, and Maintenance (OAM) identification,
particularly in MPLS-TP networks [RFC5921].
VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW
Control Word (CW) to distinguish VCCV packets from packets carrying
user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM
packets they carry. This was not an issue when [RFC5085] was
designed, but is in conflict with the design goals of MPLS-TP
[RFC5921] which does not otherwise require the availability of IP.
VCCV CC Type 2 is not applicable to multi-segment PWs (MS-PWs)
[RFC6073]. A MS-PW operating without the CW therefore has to use
VCCV CC Type 3 which identifies VCCV packets on the basis of TTL
expiry. Whilst less of an issue with a single segment PW (SS-PW), on
an MS-PW this need to be accurately set to cause TTL expiry at the
egress Terminating Provider Edge (T-PE) [RFC6073]. In the event of a
error in the setting of the PW LSE TTL this can result in VCCV
packets leaking into the attachment circuit which may disrupt the
operation of the PW, or the native service, and is a security risk.
The new VCCV CC type defined in this specification addresses these
problems for PWs that do not use the CW.
For reasons of network efficiency and due to hardware constraints it
is not possible to address these issue by mandating that all PWs use
the PW CW, hence the introduction of this new VCCV CC type. PWs
without the CW are widely deployed, and hence mandating that all PWs
use the CW is not a viable way to address this issue.
2. Requirements Language
Nadeau, Martini & BryantExpires August 20, 2015 [Page 2]
Internet-Draft GAL as a VCCV Channel February 2015
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].
3. GAL VCCV Control Channel Type
When the PW CW is not used, the GAL VCCV Control Channel (CC) type
defined in this section MAY be used. This is referred to as VCCV CC
Type4 throughout the rest of this of this document. VCCV Type 4 uses
the encapsulation shown in Figure 1.
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 | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VCCV Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VCCV message body is preceded by a Generic Associated Channel
Header as defined in [RFC5586], in which the Channel Type identifies
the type and format of the OAM message carried in the VCCV message
body.
The GAL LSE MUST contain the GAL reserved label as defined in
[RFC5586].
The PW LSE is constructed according to the existing procedures that
apply to the type of pseudowire that is in use.
Note that the inclusion of a GAL following the PW LSE over a label
switched path subject to Equal-Cost Multi-path (ECMP) load balancing
can cause the OAM packet to take a different path through the network
from the corresponding PW data packets. If that is not acceptable,
then an alternative VCCV type MUST be used.
4. FAT PWs
Nadeau, Martini & BryantExpires August 20, 2015 [Page 3]
Internet-Draft GAL as a VCCV Channel February 2015
[RFC6391] specifies that when the flow-aware transport (FAT) of
pseudowires over an MPLS packet switched network has been signalled
or configured, the Flow LSE MUST be present. It further specifies
that "the flow label MUST NOT be an MPLS reserved label (values in
the range 0..15) [RFC3032]", and that "If a flow LSE is present, it
MUST be checked to determine whether it carries a reserved label. If
it is a reserved label, the packet is processed according to the
rules associated with that reserved label; otherwise, the LSE is
discarded."
This document specifies that if the flow-aware transport of
pseudowires over an MPLS packet switched network has been signalled
or configured then the presence of VCCV message is indicated by the
use of a GAL in place of the flow LSE.
This is consistent with [RFC6391], and the packet structure is
identical to that shown in Figure 1.
Note that the use of a GAL in place of the flow label over a label
switched path subject to ECMP can cause the OAM packet to take a
different path through the network from the corresponding PW data
packets. If that is not acceptable, then an alternative VCCV type
MUST be used.
5. Multi-Segment Pseudowires
When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV
packet to a Switching PE (S-PE) MUST set the TTL to the appropriate
value to expire at that S-PE. An S-PE that supports this
specification MUST inspect packets PW packet that are received as a
result of TTL expiry, determine whether a GAL follows the PW LSE. If
a GAL is present the S-PE then processes the VCCV packet.
An S-PE that does not support this specification would be expected to
reject as malformed a VCCV CC Type 4 packet that was received. This
is because the S-PE would expect the PW LSE to be bottom of stack
(the non FAT case) and for the LSE at bottom of stack not to be a
reserved label (both the FAT and the non-FAT cases). An S-PE that did
not make this reserved label check would then find that the first
nibble following the label stack was 0x1 and not the expected start
of an IP packet. It would hence be expected to also reject the
packet. This update to the behaviour of S-PEs is therefore backwards
compatible.
6. VCCV Capability Advertisement
The VCCV capability advertisement MUST match the c-bit setting that
is advertised in the PW FEC element [RFC4447]. If the c-bit is set,
indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be
advertised. If the c-bit is not set, indicating that the PW CW is
not in use, then an equipment supporting this specification MUST
advertise VCCV CC Type 4. Advertisement of VCCV CC Types 1 and 4 are
therefore mutually exclusive.
Nadeau, Martini & BryantExpires August 20, 2015 [Page 4]
Internet-Draft GAL as a VCCV Channel February 2015
A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as
defined in [RFC5085] .
If the remote PE supports VCCV CC Type 4, and the PW CW is not in
use, then for cases where multiple CC Types are advertised, the
following precedence rules apply when choosing which CC Type to use:
1. Type 4: GAL VCCV Control Channel.
2. Type 2: MPLS Router Alert Label.
3. Type 3: MPLS PW Label with TTL == 1.
If the remote PE finds that VCCV CC Types 1 and 4 are both
advertised, or that c-bit is set and VCCV CC Type 4 is advertised,
then it should report the error to the operator through the
management interface in use, and send a Label Release Message with a
status code "VCCV Type Error".
7. Manageability Considerations
Whilst the introduction of this additional VCCV CC type increases the
number of VCCV CC types that the operator needs to manage, it
addresses the issues with VCCV CC Types 2 and 3 described in .
(Section 1).
In the event of a misconfiguration of this VCCV CC type, the PW is
taken out of service and the operator advised as described in Section
6.
Attention is drawn to the possible absence of fate sharing between PW
data packets and VCCV CC Type 4 packets described in Section 3 and
Section 4.
8. Security Considerations
This document does not by itself raise any new security
considerations beyond those described in [RFC5085]. It addresses the
possibility of packet leaking that can occur with VCCV CC Type 3.
9. IANA Considerations
9.1. 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, Martini & BryantExpires August 20, 2015 [Page 5]
Internet-Draft GAL as a VCCV Channel February 2015
MPLS VCCV Control Channel (CC) Types
Bit (Value) Description Reference
============ =========== ==================
Bit X (0x0Y) Type 4 This Specification
9.2. LDP Status Code
IANA is requested to assign a new Status Code from the Label
Distribution Protocol (LDP) Parameters name space:
Status Code Name Space
Range/Value E Description Reference
=========== = =============== =========
0x000000xx 0 VCCV Type Error This Specification
10. Acknowledgments
The authors wish to thank Alexander (Sasha) Vainshtein for his
proposal to make the GAL and Flow labels mutually exclusive. This
proposal let to a significant simplification of this design. They
also thank both Sasha and and Matthew Bocci for their review
comments.
11. References
11.1. Normative References
[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.
[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.
[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.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M. and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
Nadeau, Martini & BryantExpires August 20, 2015 [Page 6]
Internet-Draft GAL as a VCCV Channel February 2015
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J. and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, November
2011.
11.2. Informative References
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L. and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
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, Martini & BryantExpires August 20, 2015 [Page 7]