[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

MPLS Working Group                                A. Fulignoli (Ed)
Internet Draft                                    Ericsson
Intended status: Informational                    H. van Helvoort (Ed)
                                                  Huawei
                                                  I. Busi (Ed)
                                                  Alcatel-Lucent
                                                  N.Sprecher (Ed)
                                                  Nokia Siemens Networks

Expires: August 2009                                  February 9, 2009





         MPLS-TP Proactive Continuity and Connectivity Verification
                  draft-fhbs-mpls-tp-cv-proactive-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (c) 2009 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



Fulignoli and al.      Expires August 9, 2009                 [Page 1]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   The aim of this draft is to define an MPLS-TP OAM mechanism to meet
   the requirements for proactive Continuity Check and Connectivity
   Verification functionality as defined in [3].

   Note: this version of the draft is focused on analyzing possible
   solutions and evaluating their pros&cons as well as issues. In the
   next version of the draft the solution to be standardized will be
   proposed using the analysis done in this version to motivate the
   selection.

Table of Contents

   1. Introduction.................................................3
      1.1. Terminology.............................................3
   2. Unique ME Identifier.........................................4
      2.1. LSP ME ID IPv4 Source/Destination Address Format........5
      2.2. LSP ME ID IPv6 Source/Destination Address Format........6
      2.3. Type FEC128PWv4 Format..................................7
      2.4. Type FEC128PWv6 Format..................................7
      2.5. ICC-based Format........................................7
   3. Possible Solution............................................8
      3.1. Backward compatibility..................................9
   4. Definition of BFDv2.........................................10
      4.1. New semantic for Discriminator fields..................10
      4.2. New ME ID field........................................12
   5. Two different ACH encapsulation of OAM tool.................13
      5.1. Current BFD with only CC functionality.................13
      5.2. ACH encapsulation of the new tool......................13
         5.2.1. New tool based on current BFD.....................14
         5.2.2. New tool based on the extended BFD................15
         5.2.3. New tool like Y.1731 CCM..........................15
   6. Remote Defect Indication....................................18
   7. Point to Multipoint transport paths.........................18
   8. Conclusion..................................................18
   9. Security Considerations.....................................19
   10. IANA Considerations........................................19
   11. Acknowledgments............................................19
   12. References.................................................19
      12.1. Normative References..................................19
      12.2. Informative References................................20




Fulignoli and al.      Expires August 9, 2009                 [Page 2]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009




1. Introduction

   The aim of this draft is to define an MPLS-TP OAM mechanism to meet
   the requirements for proactive Continuity Check and Connectivity
   Verification functionality required in [3].

   Note: this version of the draft is focused on analyzing possible
   solutions and evaluating their pros&cons as well as issues. In the
   next version of the draft the solution to be standardized will be
   proposed using the analysis done in this version to motivate the
   selection.

   As recommended in [4], the BFD tool needs to be extended for the CV
   functionality by the addition of a unique identifier in order to meet
   the requirements. This document further expands the analysis of
   possible solutions.

   As described in [5], the Proactive Continuity Check (CC) and
   Continuity Verification (CV) function are used together to detect
   loss of continuity (LOC), unintended connectivity between two MEs
   (e.g. mismerging or misconnection) as well as unintended connectivity
   within the ME with an unexpected MEP. It MUST operate both in
   bidirectional p2p and in unidirectional p2mp connection.

   The mechanism MUST foresee the configuration of the transmit
   frequency.

   The mechanism MUST be the same for LSP, (MS-)PW and Section.



      1.1. Terminology

   LME    LSP Maintenance Entity

   ME     Maintenance Entity

   MEP    Maintenance End Point

   MIP    Maintenance Intermediate Point

   PME    PW Maintenance Entity

   SME    Section Maintenance Entity



Fulignoli and al.      Expires August 9, 2009                 [Page 3]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   TCME    Tandem Connection Maintenance Entity

   TPME    Tandem PW Maintenance Entity

   TLV     Type Length Value





   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].



2.  Unique ME Identifier

   The globally unique ME Identifier can use some of the ACH TLV objects
   defined in Section 3 of [10]:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ME ID Type                 |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     ME ID Value                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ME ID Type

    2 octet field; it identifies the format of the ME Identifier;

Length

   2 octets field; it identifies the length in octets of the ME ID
   Section that follows the length field.

ME ID payload

   value of the ME identifier; its semantic depends on the format.



Fulignoli and al.      Expires August 9, 2009                 [Page 4]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   [Editor's note - Some ACH TLV objects defined in this section can be
   moved in future versions of [10] and referenced by future versions of
   this draft]

   Note: in order to simply implementations (e.g. planning processing
   resources), especially when BFD implementation is hardware-assisted,
   it would be desirable to define the maximum possible length for the
   CV TLV.

   The ME Identifier Type transmitted and expected MUST be the same at
   both MEPs. For statically provisioned connections, the ME Identifier
   transmitted and expected is statically configured at both MEPs. For
   dynamically established connections, the ME Identifier transmitted
   and expected is signaled via the control plane. The extension of ME
   identifier signaling is outside the scope of this document.


   Some possible ME Identifier formats are reported in the following
   sections.



      2.1. LSP ME ID IPv4 Source/Destination Address Format

   This ME ID format MAY be used to identify an LME (as defined in [5])
   where IPv4 addresses are used to identify the LERs terminating the
   LSP.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ME ID Type                 |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 source address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 destination address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           LSP ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ME ID Type

   2 octet field; it identifies the specific format, value = TBD;

Length



Fulignoli and al.      Expires August 9, 2009                 [Page 5]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   2 octets field; set to 12 (octets);

IPv4 source address

   4 octets field; set to the IPv4 address of the LSP source port/node;

IPv4 destination address

   4 octets field; set to the IPv4 address of the LSP destination
   port/node;

LSP ID

  4 octets field; set to the LSP identifier.



      2.2. LSP ME ID IPv6 Source/Destination Address Format


   This ME ID format MAY be used to identify an LME (as defined in [5])
   where IPv6 addresses are used to identify the LERs terminating the
   LSP.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ME ID Type                 |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv6 source address                       |
      ~                        (16 bytes)                             ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv6 destination address                  |
      ~                        (16 bytes)                             ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           LSP ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ME ID Type

   2 octet field; it identifies the specific format, value = TBD;

Length


Fulignoli and al.      Expires August 9, 2009                 [Page 6]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   2 octets field; set to 36 (octets);

IPv6 source address

   4 octets field; set to the IPv6 address of the LSP source port/node;

IPv6 destination address

   4 octets field; set to the IPv6 address of the LSP destination
   port/node;

LSP ID

  4 octets field; set to the LSP identifier.



      2.3. Type FEC128PWv4 Format

   This TLV is defined in [10]. It contains a PW ID that terminates on a
   PE identified by an IPv4 address.

   This ME ID format MAY be used to identify a PME (as defined in [5])
   where IPv4 addresses are used to identify the T-PEs terminating the
   PW and FEC128 is used to identify the PW.



      2.4. Type FEC128PWv6 Format

   This TLV is defined in [10]. It contains a PW ID that terminates on a
   PE identified by an IPv6 address.

   This ME ID format MAY be used to identify a PME (as defined in [5])
   where IPv6 addresses are used to identify the T-PEs terminating the
   PW and FEC128 is used to identify the PW.

   Editor's note: implementation impacts of FEC129PWv4 and FEC129PWv6 (
   as defined in [10])when used as ME Identifier in a cc-cv proactive
   tool needs further study (see note in section 2 regarding length of
   ME ID).








Fulignoli and al.      Expires August 9, 2009                 [Page 7]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


      2.5. ICC-based Format

   This ME ID format MAY be used to identify SME, LME, LTCME, PME and
   PTCME(as defined in [5]) independently on LER/T-PE addressing schemes
   as well as of the FECs used to identify the PW.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ME ID Type             |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       MEP ID value            |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                       MEG ID                                  |
      +                     (13 bytes)                                +
      |                                                               |
      +                                               +-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



ME ID Type

   2 octet field; it identifies the specific format, value = TBD;

Length

   2 octets field; set to 15;

MEP ID value

   13-bit integer value field, identifying the transmitting MEP within
   the ME. The three MSBs of the first octet are not used and set to
   ZERO.

MEG ID value

   13-octet field. Refer to Annex A of ITU-T Recommendation Y.1731 for
   the format used for the MEG ID field with ICC-based format.








Fulignoli and al.      Expires August 9, 2009                 [Page 8]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009



3. Possible Solution

   Several solutions have been analyzed:

   1. Define a new BFD version (BFDv2) that extends the current BFD
      (BFDv1) to support also CV functionality. The new BFD version can
      be obtained by:

     1. changing the semantic of MY discriminator and Your discriminator
        fields ([8]);

     2. adding a new ME ID field in the BFD packet for the CV
        functionality to the existing session identifier;



   2. two separate tools, running with two different ACH encapsulations
      (i.e. two different ACH channel types):

   o the current BFD with only CC functionality;

   o a new tool that meet all the OAM MPLS-TP requirement.

   The new tool can be:

     1. based on current BFD;

     2. an extension of the ACH encapsulation for the current BFD;

     3. a new tool like Y.1731 CCM;



   All analyzed solutions imply extension of CV types, foreseen by [6]
   and yet extended by[7], in order to include the MPLS-TP OAM mechanism
   too. This is due to the fact that VCCV also includes mechanisms for
   negotiating the control channel and connectivity verification (i.e.
   OAM functions) between PEs.



      3.1. Backward compatibility

   For backward compatibility, it is still possible to run the current
   BFD that supports only CC functionality on some transport paths and
   the new tool that supports CC and CV functionality on other transport


Fulignoli and al.      Expires August 9, 2009                 [Page 9]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   paths. In any case only one tool for OAM instance at time,
   configurable by operator, can run.

   A MEP that is configured to support CC and CV functionality, as
   required by MPLS-TP, MUST be capable to receive existing BFD packets
   (encapsulated with GAL/G-ACH or PW-ACH) that supports only CC
   functionality and MUST consider them as an unexpected packet, i.e.
   detect a misconnection defect.

   The context of MPLS-TP OAM packets is based on MPLS label and G-ACH,
   eliminating in the BFD the need to exchange Discriminator values. An
   MPLS-TP node that desires to interoperate with a current BFD can
   apply the same discriminator field semantic as described in [8] or:

   o It MUST set the My discriminator field to a nonzero value (it can
      be a fixed value);

   o It MUST reflect back the received value of My discriminator field
      into the transmitted Your discriminator field, or set it to zero
      if that value is unknown.





4. Definition of BFDv2

   Common to both solutions detailed in this section are the following
   considerations:

   o The Channel Type field of the G-ACH is the one proposed by [7]
      i.e. 0x0007 indicating the raw BFD control packet;

   o The version number of the protocol needs to be updated to protocol
      version 2 respect to protocol version 1 defined in [8]



      4.1. New semantic for Discriminator fields

   As defined in [8], the mandatory Section of a BFD Control packet has
   the following format:






Fulignoli and al.      Expires August 9, 2009                [Page 10]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Vers |  Diag   |Sta|P|F|C|A|D|M|  Detect Mult  |    Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       My Discriminator                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Your Discriminator                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Desired Min TX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Required Min RX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Required Min Echo RX Interval                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   A possible BFD extension can be obtained changing the semantic of the
   two 32 bit fields, My Discriminator and Your Discriminator, to form a
   one 64 bit field carrying the globally unique ME Identifier as shown
   in figure below:


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Vers |  Diag   |Sta|P|F|C|A|D|M|  Detect Mult  |    Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                           ME ID                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Desired Min TX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Required Min RX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Required Min Echo RX Interval                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   One of the disadvantages of this solution is on the too limited
   number of octets available for the globally unique ME ID field: that



Fulignoli and al.      Expires August 9, 2009                [Page 11]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   doesn't allow the possibility to have different format of ME
   identifier.



      4.2. New ME ID field

   This solution adds the new field required for the CV functionality,
   i.e. a globally unique ME Identifier section, after the mandatory
   section of a BFD control packet and before the optional
   Authentication section as the figure below shows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Vers |  Diag   |Sta|P|F|C|A|D|M|  Detect Mult  |    Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       My Discriminator                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Your Discriminator                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Desired Min TX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Required Min RX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Required Min Echo RX Interval                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         ME ID Section                         +
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                 Optional Authentication Section               +
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The advantages of this solution are that the behavior of the current
   BFD protocol as defined in [8] is unchanged and on the variable
   length of the ME ID Section.









Fulignoli and al.      Expires August 9, 2009                [Page 12]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


5. Two different ACH encapsulation of OAM tool

      5.1.  Current BFD with only CC functionality

   The current BFD, with only CC functionality, is encapsulated in the
   G-ACH using as Channel type code point the 0x0007 value as described
   in [7]. This mechanism can be even extended to Section OAM and LSP
   OAM.

   Figure below shows G-ACH encapsulation of current BFD as in [7]

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                     BFD control packet                        |
      +                                                               +
      :                              ...                              :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




      5.2. ACH encapsulation of the new tool

   In order to meet the MPLS-TP OAM requirement, a new tool has to be
   introduced, encapsulated into the G-ACH with a new channel type code
   point. Common to all solutions detailed below are the following G-ACH
   format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   - first nibble: set to 0001b to indicate a channel associated with a
   PW, a LSP or a Section;

   - Version and Reserved fields are set to 0, as specified in [2];




Fulignoli and al.      Expires August 9, 2009                [Page 13]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   - G-ACH Channel Type field with a new TBD code point meaning "MPLS-TP
   CC-CV proactive" indicating that the message is an MPLS-TP OAM CC-CV
   proactive message. The value MUST be assigned


   The sections below describe the format of the different possible new
   tool.



5.2.1. New tool based on current BFD

   A new tool can be obtained introducing a globally unique ME
   Identifier TLV between the ACH and the current BFD (defined in [8])
   as detailed below.



      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|  MPLS-TP CC-CV proactive      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    ACH TLV Header                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    ME ID TLV
      :                              ...                              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                    BFD Control packet                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The first 4 bytes represent the G-ACH as described in section 5.2.

   The G-ACH is followed by the ACH TLV Header as defined in Section 2.1
   of [10] and by one ACH TLV object carrying the Unique ME Identifier
   Section as described in section 2.

   The BFD control packet is the base BFD as described [8].






Fulignoli and al.      Expires August 9, 2009                [Page 14]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   The benefit of this solution is to maintain the behavior and protocol
   version of BFD as defined in[8]; however it needs some considerations
   on the optional Authentication Section how described in section 9.



5.2.2. New tool based on the extended BFD

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|  MPLS-TP CC-CV proactive      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Vers |    Diag |Sta|P|F|C|A|D|M|  Detect Mult  |    Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       My Discriminator                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Your Discriminator                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Desired Min TX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Required Min RX Interval                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Required Min Echo RX Interval                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         ME ID Section                         +
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                 Optional Authentication Section               +
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The solutions and considerations are the same of what described in
   section 4.2.  except the G-ACH Channel type code, rather than the
   Version field, distinguishes between existing BFD (supporting CC) and
   the new tools (supporting both CC&CV).

   The Version field in this case is set to 0 (this is the first version
   for this tool).







Fulignoli and al.      Expires August 9, 2009                [Page 15]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


5.2.3. New tool like Y.1731 CCM

   The Mandatory Section of the CC/CV packet has the following format:



        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|  MPLS-TP CC-CV proactive      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  | Res1  |     Res2    |A|R| Res3  | Per |  Length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                                                               |
       +                         ME ID Section                         +
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





      An optional Authentication Section may be present:


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Auth Type   |   Auth Len    |    Authentication Data...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is inherited and described in [8].



Version (Vers)

   4 bit field, version number of the protocol; this document defines
   protocol version 0;

Reserved (Res1)

   4 bit field, reserved for future use; set to all ZEROes;

Reserved (Res2)



Fulignoli and al.      Expires August 9, 2009                [Page 16]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


   7 bit field; reserved for future use; set to all ZEROes;

Authentication Present (A)

   1 bit field; if set, the Authentication Section is present and the
   session is to be authenticated;

RDI (R)

   1 bit field; it is set to 1 to indicate Remote Defect Indication
   otherwise it is set to 0.

Reserved (Res3)

   4 bit field reserved for future use; set to all ZEROes;

Period (Per)

   3 bit field; it indicates the transmission period with the encoding
   shown in the following table:

                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0 0 0|  Invalid value    | Invalid value for CCM PDU |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0 0 1|    3.33 ms        | 300 frames per second     |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0 1 0|      10 ms        | 100 frames per second     |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |0 1 1|     100 ms        | 10 frames per second      |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1 0 0|       1 s         | 1 frame per second        |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1 0 1|      10 s         | 6 frames per minute       |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1 1 0|       1 min       | 1 frame per minute        |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1 1 1|      10 min       | 6 frame per hour          |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length

     1 octet field; it is the total CC/CV packet length in octet,
     excluded the G-ACH header;

   ME ID Section




Fulignoli and al.      Expires August 9, 2009                [Page 17]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


     Variable length field containing the Unique Path Identifier as
     detailed in section 2.

   This solution has the advantage of an easier peer interworking with
   the ETH OAM.



6. Remote Defect Indication

   Remote Defect Indication (RDI) is used by a MEP to notify its peer
   MEP that a defect is detected on a bi-directional connection between
   them([4]). RDI is only used for bidirectional connections and is
   associated with proactive CC & CV packet generation.[5]


   The Diagnostic (Diag) field of the Current BFD ([8]) can be used for
   this functionality. However, there isn't a total correspondence among
   the values foreseen by [8] and the defect conditions detected by the
   proactive CC-CV tool that require the RDI function.

   A solution could be that any defect that requires the RDI information
   being sent to the peer MEP is encoded in the Diagnostic (Diag) field
   with the value 1 (corresponding to the ''Control Detection Time
   Expired'' in [8]). The value 0 indicates RDI condition has been
   cleared.

   This section will be completed in the next version of the draft.

   For the solution in section 5.2.3. , RDI is foreseen in the packet
   format with a single bit.



7. Point to Multipoint transport paths

   Solution described in section 5.2.3. is valid for both bidirectional
   and unidirectional connection: in unidirectional connection only
   source MEP is enabled only to generate CC/CV OAM packets and sink MEP
   is enabled only to receive CC/CV OAM packets.

   The BFD tool has a straightforward state machine for bidirectional
   path. Anyway the behavior and state machine need to be modified for
   the unidirectional connection; this is described in [9].

   This section will be completed in the next version of the draft.



Fulignoli and al.      Expires August 9, 2009                [Page 18]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009




8. Conclusion

   CC and CV functionality are required to be used always together for
   MPLS-TP OAM (see [3] and [5]).

   For interoperability issue, a MPLS-TP node MAY support even the
   current BFD tool; anyway only one tool, configurable by operator, for
   OAM instance MUST run at time.



   This section will be completed in the next version of the draft.



9. Security Considerations

   Base BFD [8] foresees an optional authentication section; that can be
   extended even to the tool proposed in this document.

   Authentication methods that require checksum calculation on the
   outgoing packet must extend the checksum even on the ME Identifier
   Section. This is possible but seems uncorrelated with the solution
   proposed in section 5.2.1. in this case it could be better to use the
   simple password authentication method.

   It is also worth noticing that the interactions between
   authentication and connectivity verification need further analysis.



10. IANA Considerations

   <Add any IANA considerations>

11. Acknowledgments

   <Add any acknowledgements>

   This document was prepared using 2-Word-v2.0.template.dot.







Fulignoli and al.      Expires August 9, 2009                [Page 19]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


12. References

      12.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]  Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
         " MPLS Generic Associated Channel ", draft-ietf-mpls-tp-gach-
         gal-01 (work in progress), January 2009

   [3]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
         00 (work in progress), November 2008

   [4]  Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., "
         MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02
         (work in progress), September 2008

   [5]  Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and
         Overview", draft-busi-mpls-tp-oam-framework-00(work in
         progress), October 2008

   [6]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007

   [7]  Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
         Detection (BFD) for the Pseudowire Virtual Circuit
         Connectivity Verification (VCCV)",ID draft-ietf-pwe3-vccv-bfd-
         02.txt, February 2008.

   [8]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection",
         draft-ietf-bfd-base-08 (work in progress), March 2008.

   [9]  Katz, D. and D. Ward, "BFD for Multipoint Networks",
         ID draft-katz-ward-bfd-multipoint-01.txt, December 2007

   [10] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
         bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009.









Fulignoli and al.      Expires August 9, 2009                [Page 20]


Internet-Draft         MPLS-TP Proactive CC&CV           February 2009


      12.2. Informative References









Authors' Addresses



   Italo Busi (Editor)
   Alcatel-Lucent
   Email: italo.busi@alcatel-lucent.it


   Annamaria Fulignoli (Editor)
   Ericsson
   Email: annamaria.fulignoli@ericsson.com


   Huub van Helvoort (Editor)
   Huawei Technologies
   Email: hhelvoort@huawei.com


   Nurit Sprecher
   Nokia Siemens Networks
   Email: nurit.sprecher@nsn.com
















Fulignoli and al.      Expires August 9, 2009                [Page 21]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/