[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-pwe3-vccv-for-gal) 00 01 02 03 04 05 06 RFC 7708

PWE3                                                           T. Nadeau
Internet-Draft                                               lucidvision
Updates: 4447, 5085 (if approved)                             L. Martini
Intended status: Standards Track                               S. Bryant
Expires: June 20, 2015                                     Cisco Systems
                                                       December 17, 2014


                         VCCV Default CC Types
                    draft-ietf-pals-vccv-for-gal-00

Abstract

   This document specifies the default Virtual Circuit Connectivity
   Verification (VCCV) (RFC5085) control channel type to be used when
   the pseudowire control word is present and when it is not present.  A
   new VCCV control channel type using the Generic Associated Channel
   Label (RFC5586) is specified for use when the control word not
   present.

   This document updates RFC4447 and RFC5085.

   Note to be removed at publication: this document started out as
   draft-ietf-pwe3-vccv-for-gal and got to version -02.  When PWE3 was
   absorbed into PALS the next version published was draft-ietf-pals-
   vccv-for-gal-00

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 June 20, 2015.








Nadeau, et al.            Expires June 20, 2015                 [Page 1]


Internet-Draft            VCCV Default CC Types            December 2014


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
   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  . . . . .   4
   4.  VCCV Control Channel When The Control Word is Not Used  . . .   4
   5.  FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  VCCV Capability Advertisement . . . . . . . . . . . . . . . .   5
   7.  Manageability Considerations  . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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].

   ACH            Associated Channel Header [RFC4385]

   CC             Control Channel (used as CC Type).

   CV             Connectivity Verification (used as CV Type).

   CW             Control Word [RFC3985].

   GAL            Generic Associated Channel Label [RFC5586]



Nadeau, et al.            Expires June 20, 2015                 [Page 2]


Internet-Draft            VCCV Default CC Types            December 2014


   OAM            Operation and Maintenance.

   PSN            Packet Switched Network [RFC3985].

   PW             Pseudowire [RFC3985].

   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 specifies that there are two default modes of operation
   of VCCV: 1) with a control word or 2) without a control word, both
   with a ACH encapsulation [RFC4385] 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.

   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



Nadeau, et al.            Expires June 20, 2015                 [Page 3]


Internet-Draft            VCCV Default CC Types            December 2014


   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 of [RFC5085]), and VCCV type to use has been chosen.

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.

4.  VCCV Control Channel When The Control Word is Not Used

   When the PWE3 Control Word is not used, the new VCCV CC Type 4
   defined in this section MUST be used.  VCCV CC 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    |  Associated Channel Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        VCCV Message Body                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   When the PW is a single segment PW, the TTL field of the PW Label
   Stack Entry (LSE) MUST be set to 2.  TTL=2, rather than the more
   obvious TTL=1, is used because of legacy hardware considerations.  In
   the case of multi-segment pseudo-wires, the PW LSE TTL MUST 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].





Nadeau, et al.            Expires June 20, 2015                 [Page 4]


Internet-Draft            VCCV Default CC Types            December 2014


   As defined in [RFC4385] and [RFC4446] the first nibble of the next
   field is set to 0001b to indicate an ACH is being carried 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.

5.  FAT PWs

   When the flow-aware transport of pseudowires over an MPLS packet
   switched network [RFC6391] has been signalled or configured, the Flow
   LSE MUST always be present.  When VCCV CC Type 4 is in use the Flow
   LSE MUST be immediately below the PW LSE in the label stack, and the
   GAL MUST be at the bottom of the label stack.  This is shown in
   Figure 2.

   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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Flow LSE                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           GAL LSE                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    |  Associated Channel Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        VCCV Message Body                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   The ELI mechanism [RFC6790] applies to the MPLS LSP that carries the
   PW and is therefore out of scope of this specification.

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 control word, VCCV CC Type 1 MUST be
   advertised and VCCV CC Type 4 MUST NOT be advertised.  If the c-bit




Nadeau, et al.            Expires June 20, 2015                 [Page 5]


Internet-Draft            VCCV Default CC Types            December 2014


   is not set, indicating that the control word is not in use, VCCV CC
   Type 4 MUST be advertised, and VCCV CC Type 1 MUST NOT be advertised.

   A PE supporting VCCV CC Type 4 MAY advertise other CC types as
   defined in [RFC5085] . If the remote PE also supports VCCV CC Type 4,
   then VCCV CC Type 4 MUST be used superseding the Capability
   Advertisement Selection rules of Section 7 from [RFC5085] . If a
   remote PE does not support VCCV CC Type 4, then the rules from
   Section 7 of [RFC5085] apply.  If a CW is in use, then VCCV CC Type 4
   is not applicable, and therefore the normal capability advertisement
   selection rules of Section 7 from [RFC5085] apply.

7.  Manageability Considerations

   By introducing default VCCV CC types, and improving the compatibility
   with MPLS-TP, the compatibility of implementations is improved and
   management and configuration of the network becomes simpler.

   Network operators should note that the presence of the GAL may cause
   the PW packet and associated VCCV packets to be subjected to
   different ECMP choices and thus not fate share.  This effect is not
   present in networks that support [RFC6790] since reserved labels are
   ignored during ECMP path selection.

8.  Security Considerations

   This document does not by itself raise any new security
   considerations beyond those described in [RFC5085].

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.

   MPLS VCCV Control Channel (CC) Types

         Bit (Value)    Description   Reference
         ============   ===========   ====================
         Bit X (0x0Y)   Type 4        [This Specification]








Nadeau, et al.            Expires June 20, 2015                 [Page 6]


Internet-Draft            VCCV Default CC Types            December 2014


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.

   [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.

   [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.

   [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.

   [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.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, November 2012.







Nadeau, et al.            Expires June 20, 2015                 [Page 7]


Internet-Draft            VCCV Default CC Types            December 2014


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.

   [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.

   [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 June 20, 2015                 [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/