PALS                                                           T. Nadeau
Internet-Draft                                               lucidvision
Intended status: Standards Track                              L. Martini
Expires: November 27, 2015                                     S. Bryant
                                                           Cisco Systems
                                                            May 26, 2015


     Using A Generic Associated Channel Label as a Virtual Circuit
              Connectivity Verification Channel Indicator
                    draft-ietf-pals-vccv-for-gal-04

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 November 27, 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



Nadeau, et al.          Expires November 27, 2015               [Page 1]


Internet-Draft            GAL as a VCCV Channel                 May 2015


   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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . .   3
   4.  FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . .   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
     9.2.  LDP Status Code . . . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Virtual Circuit Connectivity Verification (VCCV) protocol is
   specified in RFC 5085 [RFC5085].  This document specifies a new VCCV
   control channel (VCCV CC) type to be used 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 Transport Profile (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 Time to
   Live (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



Nadeau, et al.          Expires November 27, 2015               [Page 2]


Internet-Draft            GAL as a VCCV Channel                 May 2015


   the event of an error in the setting of the PW Label Stack Entry
   (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.

   Note that mandating that all PWs to use the PW CW is not a viable way
   to address this issue.  This is because:

   o  PWs without the CW are already widely deployed.

   o  There is a significant deployment of existing hardware that does
      not support usage of the PW CW for some PW types.

   o  Some operators are concerned that the inclusion of the PW CW will
      increase the PW packet size.

2.  Requirements Language

   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.  Type 4 MPLS VCCV Control Channel Type

   When the PW CW is not used, the Type 4 MPLS 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 in which the presence
   of a GAL at the end of the MPLS label stack indicates that the packet
   carries a VCCV message.


















Nadeau, et al.          Expires November 27, 2015               [Page 3]


Internet-Draft            GAL as a VCCV Channel                 May 2015


    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                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   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 needs to be used.

4.  FAT PWs

   [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



Nadeau, et al.          Expires November 27, 2015               [Page 4]


Internet-Draft            GAL as a VCCV Channel                 May 2015


   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.

   Flow LSEs are inserted into a PW label stack in order to enable the
   distribution of the PW traffic among multiple equal cost MPLS paths.
   The use of GAL in place of the flow label will cause all OAM packets
   to take exactly one of these paths, and this path may be different
   from the paths taken by any of traffic flows.  If this is not
   acceptable, then an alternative VCCV type needs 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 PW packets that are received as a result
   of TTL expiry, and 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.

   A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as
   defined in [RFC5085] .






Nadeau, et al.          Expires November 27, 2015               [Page 5]


Internet-Draft            GAL as a VCCV Channel                 May 2015


   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 requested that Bit 3 be
   assigned to this purpose which would have a value of 0x08.






Nadeau, et al.          Expires November 27, 2015               [Page 6]


Internet-Draft            GAL as a VCCV Channel                 May 2015


   MPLS VCCV Control Channel (CC) Types

         Bit (Value)    Description   Reference
         ============   ===========   ==================
         Bit X (0x0Y)   Type 4: GAL   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 led to a significant simplification of this design.  The
   authors also thank Sasha, Matthew Bocci and Loa Andersson 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.




Nadeau, et al.          Expires November 27, 2015               [Page 7]


Internet-Draft            GAL as a VCCV Channel                 May 2015


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

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, et al.          Expires November 27, 2015               [Page 8]