Internet DRAFT - draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi

draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi




MPLS Working Group                                A. Fulignoli (Ed.) 
Internet Draft                                    Ericsson                       
Intended status: Informational                    
                                                  S. Boutros (Ed.) 
                                                  Cisco Systems, Inc             
                                                   
                                                  M.Vigoureux (Ed.)  
                                                  Alcatel-Lucent   
 
Expires: January 2010                                      July 7, 2009 
                                    
 
                                    

               MPLS-TP BFD for Proactive CC-CV and RDI                          
       draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi-01.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 Statement  

   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 in effect on the date of publication of this document 
   (http://trustee.ietf.org/license-info). Please review these 
 
 
 
Fulignoli              Expires January 7, 2010                 [Page 1] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

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

    

   Abstract 

   Several documents on BFD based OAM for MPLS-TP has been put 
   forward and the dependencies between those drafts are not yet 
   fully sorted out; this document is one of these drafts. It is 
   published in now to make ideas, motivations and approaches 
   available. However we expect the final BFD based solution for 
   MPLS-TP will be a cooperation of the parties between the 
   existing drafts and that the BFD based OAM solution for MPLS-TP 
   will merge into an agreed set of drafts approved by the MEAD 
   team.  

   This document specifies the BFD extension and behaviour to meet 
   the requirements for MPLS-TP proactive Continuity Check and 
   Connectivity Verification functionality and the RDI 
   functionality as defined in [3]. 

   Table of Contents 

   1. Introduction...................................................3 
   1.1. Terminology..................................................4 
   2. Trail Termination Source Identifier (TTSI) TLV Object..........4 
   2.1. Unique ME Identifier.........................................6 
   2.1.1. LSP ME ID IPv4 Source/Destination Address Format...........7 
   2.1.2. LSP ME ID IPv6 Source/Destination Address Format...........8 
   2.1.3. Type FEC128PWv4 Format.....................................9 
   2.1.4. Type FEC128PWv6 Format.....................................9 
   2.1.5. ICC-based Format...........................................9 
   3. Two different ACH encapsulation of BFD tool...................11 
   3.1. Current BFD with only CC functionality......................11 
   3.2. New tool based on current BFD...............................12 
   4. Backward compatibility........................................13 
   5. BFD behavior specification for MPLS-TP OAM proactive CC&CV....13 
   5.1. BFD State Machine...........................................14 
   5.2. Defect conditions...........................................18 
   5.2.1. Loss of Continuity defect(dLOC)...........................18 
   5.2.2. Mis-connectivity defect (dUNME)...........................18 
   5.2.3. Unexpected MEP ID defect (dUNM)...........................18 
   5.2.4. Unexpected Period Defect (dUNP)...........................18 
   5.2.5. RDI Defect (dRDI).........................................19 
 
 
Fulignoli              Expires January 7, 2010                 [Page 2] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   5.3. Consequent action...........................................20 
   5.4. Administrative Down State...................................20 
   5.5. Timer Negotiation...........................................21 
   5.6. Demultiplexing and the Discriminator Fields.................22 
   6. Remote Defect Indication......................................22 
   7. BFD Control Packets field.....................................23 
   8. Interoperability with current BFD.............................27 
   9. Point to Multipoint transport paths...........................27 
   10. Acknowledgments..............................................28 
   11. Contributors.................................................28 
   12. IANA Considerations..........................................28 
   13. Security Considerations......................................28 
   14. References...................................................28 
   14.1. Normative References.......................................28 
   14.2. Informative References.....................................30 
    

1. Introduction 

   Several documents on BFD based OAM for MPLS-TP has been put 
   forward and the dependencies between those drafts are not yet 
   fully sorted out; this document is one of these drafts. It is 
   published in now to make ideas, motivations and approaches 
   available. 

   However we expect the final BFD based solution for MPLS-TP will 
   be a cooperation of the parties between the existing drafts and 
   that the BFD based OAM solution for MPLS-TP will merge into an 
   agreed set of drafts approved by the MEAD team.  

   This document specifies the BFD extension and behaviour to meet 
   the requirements for MPLS-TP proactive Continuity Check and 
   Connectivity Verification functionality and the RDI 
   functionality as defined in [3]. 

   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.  

   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 and unidirectional p2p and 
   unidirectional p2mp connection. 

 
 
Fulignoli              Expires January 7, 2010                 [Page 3] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   The mechanism MUST foresee the configuration of the transmit 
   frequency. 

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

    

1.1. Terminology 

   LME      LSP Maintenance Entity 

   LTCME    LSP Tandem Connection Maintenance Entity 

   ME       Maintenance Entity 

   MEP      Maintenance End Point 

   MIP      Maintenance Intermediate Point 

   PME      PW Maintenance Entity 

   PTCME    PW Tandem Connection Maintenance Entity 

   SME      Section 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. Trail Termination Source Identifier (TTSI) TLV Object  

   The MPLS Generic Associated Channel specification (see[2] 
   section 3) describes the ACH TLV structure that can be used to 
   provide additional context information to the G-ACh packet. 



 
 
Fulignoli              Expires January 7, 2010                 [Page 4] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   In this section the TLV Objects for providing the MEP Identifier 
   information and the ME Identifier information as required by[5] 
   are described.   

   [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 all ACH TLV objects. 

   The TTSI TLV Object in figure below consists of the MEP-ID 
   followed by the Unique ME identifier TLV. 

   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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
   |    TTSIAchTlvType = TBD       |           Length              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       MEP ID value            |Reserved ( fixed to all ZEROs) ! 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               |  
   ~                  Unique ME ID TLV                             ~            
   |                                                               |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
    

   Length    

   2 octets field; it specifies the number of octets which follows 
   the Length field.   

   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. 

   Unique ME ID  

      This is the ME Identifier TLV Object as described in section 
   2.1.  

    
 
 
Fulignoli              Expires January 7, 2010                 [Page 5] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

2.1. Unique ME Identifier  

   The globally unique ME Identifier ACH TLV objects have the 
   following structure : 

    

     

    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.  

   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. 



 
 
Fulignoli              Expires January 7, 2010                 [Page 6] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

2.1.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                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Tunnel Index          | TunnelInstance  Index         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

   ME ID Type 

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

   Length 

   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; 

   TunnelIndex    

   2 octets field as defined in RFC 3812 
 
 
Fulignoli              Expires January 7, 2010                 [Page 7] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   TunnelInstance Index  

   2 octets field as defined in RFC 3812 

2.1.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)                             ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |         Tunnel Index          | TunnelInstance  Index         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       

   ME ID Type 

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

   Length 

   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 


 
 
Fulignoli              Expires January 7, 2010                 [Page 8] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

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

   TunnelIndex    

   2 octets field as defined in RFC 3812 

   TunnelInstance Index  

   2 octets field as defined in RFC 3812 

    

2.1.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.1.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). 

    

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

 
 
Fulignoli              Expires January 7, 2010                 [Page 9] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   Editor's note: for these reasons it is suggested to have this 
   format as a MUST and the other format as optional in the MPLS-TP 
   environment. 

   EndofEditornote 

    
    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              |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   +                                                               +             
   |                       MEG ID                                  | 
   +                     (13 bytes)                                + 
   |                                                               |     
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |               |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|       
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                                                                 

   ME ID Type 

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

   Length 

   2 octets field; set to 16; 

   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. 

   Editor's note: to decide if insert all ICC-based MEG ID format 
   (as for Figure A-2 of Y.1731 or only the MEG-ID value as 
   reported now in above figure EndofEditornote 








 
 
Fulignoli              Expires January 7, 2010                [Page 10] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

                                    

3. Two different ACH encapsulation of BFD tool 

   Among the solutions analyzed in [11], the one based on 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 based on current BFD that meet all the OAM MPLS-TP 
   requirement. 

   is proposed in this document as the solution to be standardized. 

   As all analyzed solutions reported in [11], even this one 
   implies extension of CV types, foreseen by [6] and yet extended 
   by[7], in order to include the MPLS-TP OAM mechanism too for PW 
   Fault Detection only. 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. 

   This version of the draft is focused on fault detection on the 
   transport path.  

3.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 SME, 
   LME, LTCME and PTCME. 

   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                        | 
   +                                                               +             
   :                              ...                              :  
   |                                                               |    
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             
 
 
Fulignoli              Expires January 7, 2010                [Page 11] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

    

3.2. New tool based on current BFD  

   The new tool is obtained introducing TTSI TLV , described in 
   section 2.  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                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                                                               | 
   +                    TTSI  TLV 
   :                              ...                              :  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               |             
   ~                    BFD Control packet                         ~             
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     

   The first four bytes represent the G-ACH ([2]). 

   - 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] 
   [2]; 

   - 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 G-ACH is followed by the ACH TLV Header as defined in 
   Section 3 of [2] and by one and only one TTSI ACH TLV object 
   carrying the MEP Identifier and the Unique ME Identifier 
   Information. ( see section 2. )  


 
 
Fulignoli              Expires January 7, 2010                [Page 12] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   The IP-based addressing ACH TLV objects ( see [10]) that allow 
   the usage if this tool also within an IP/MPLS environment can be 
   even present. In any case the TTSI ACH TLV object MUST be always 
   carried in the last ACH TLV object ( i.e just before the BFD 
   packet). 

    

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

   The benefit of this solution is to maintain the base behavior 
   and protocol version of BFD as defined in[8] and in [9]; 
   however, it's necessary to define some rules that specify the 
   BFD profile for MPLS-TP application as detailed in the next 
   sections. 

   The proposed solutions needs even some considerations on the 
   optional Authentication Section how described in section 10.  

   From now on this solution is referred as extended BFD. 

    

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

    

5. BFD behavior specification for MPLS-TP OAM proactive CC&CV 

   In this section some rules that specify the MPLS-TP application 
   of the extended BFD is detailed. These rules apply even for the 
   base BFD, limited to the CC functionality only, when an MPLS-TP 
   node interoperates with MPLS legacy nodes or when only the CC 
   functionality is required . 
 
 
Fulignoli              Expires January 7, 2010                [Page 13] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

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

   The extended BFD MUST operate both in bidirectional and 
   unidirectional p2p and unidirectional p2mp connection.  

   This version of the draft is focused on unidirectional and 
   bidirectional p2p connection of the MPLS-TP CC-CV proactive 
   tool.  

   Unidirectional p2mp connections are even reported but it 
   requires further analysis.  

   In this document the BFD operating mode is always Asynchronous; 
   in this mode the systems send CC/CV BFD packets, carrying a 
   unique ME identifier and sender MEP identifier, at regular 
   configurable timing rate. If a LOC defect or a mis-connectivity 
   defect or a period mis-configuration defect occurs, the BFD 
   session is declared down. For proactive CC-CV functionality 
   description please refers to [5]. 

    

5.1. BFD State Machine 

   The BFD State Machine is described in [8] for bidirectional p2p 
   connection and in [9] for p2mp unidirectional connection. 

   The main goals in defining the state machine for MPLS-TP 
   extended BFD are: 

1. to interoperate with the state machines defined in [8] and in 
   [9]; 

2. to satisfy the CC-CV proactive monitoring functionality and even 
   the RDI functionality as specified in the MPLS-TP OAM framework 
   [5]. 

   The diagram in Figure 1 provides an overview of the state 
   machine for MEP configured on p2p bidirectional transport path, 
   as defined in [8]. 

    
    
    
    
    
 
 
Fulignoli              Expires January 7, 2010                [Page 14] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

    
    
    
    
    
    
    
    
    
    
    
                               +--+ 
                               |  | UP, ADMIN DOWN, Defects, 
                               |  V 
                       DOWN  +------+  INIT 
                +------------|      |------------+ 
                |            | DOWN |            | 
                |  +-------->|      |<--------+  | 
                |  |         +------+         |  | 
                |  |                          |  | 
                |  |               ADMIN DOWN,|  | 
                |  |ADMIN DOWN,          DOWN,|  | 
                |  |Defects           Defects |  | 
                V  |                          |  V 
              +------+                      +------+ 
         +----|      |                      |      |----+ 
     DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP 
         +--->|      | INIT, UP             |      |<---+ 
              +------+                      +------+ 
    

   Figure 1: State Machine for p2p bidirectional connection 

   The diagram in Figure 2 provides an overview of the state 
   machine for MEP Sink of unidirectional p2p unidirectional 
   transport path based on the state machine defined in [9]; 

    

    

    

    
 
 
Fulignoli              Expires January 7, 2010                [Page 15] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

                               (DOWN), ADMIN DOWN, 
                    +------+   Defects            +------+ 
               +----|      |<---------------------|      |----+ 
         (DOWN)|    | DOWN |                      |  UP  |    |UP 
    ADMIN DOWN,+--->|      |--------------------->|      |<---+ 
         Defects    +------+          UP          +------+ 
    

      Figure 2: State Machine for p2p unidirectional connection 

   State transitions on MEP Source on unidirectional p2p path are 
   administratively driven. 

   In both diagram, each arc represents the state of the remote 
   system (as received in the State field in the BFD Control 
   packet) or indicates the expiration of the Detection Timer, here 
   extended to general defect raising and clearing conditions as 
   reported in Table 1. 

   As reported in [8], another state (AdminDown) exists so that a 
   session can be administratively put down indefinitely. In the 
   above diagram Transitions involving AdminDown state are deleted 
   for clarity; further considerations are reported in section 5.4.  

   Editor's note: 

. It is suggested to introduce the following new bfd.SessionType 
  in [9]: 

       o  MPLS-TP bidirectional p2p: Transport Profile of the 
          Classic point-to-point BFD .  

       o  MPLS-TP unidirectional Sink  

       o  MPLS-TP unidirectional Source  

. In [9] DOWN State in received BFD is even reported. It is 
  suggested to remove it from [9] as well as from Figure 3 as 
  State transitions on MEP Source on unidirectional p2p and p2mp 
  path are administratively driven . 

. If in Figure 1 we assume that  

       o  a MPLS-TP node transits from DOWN to UP State even when 
          receiving UP State and not only INIT State and that 

 
 
Fulignoli              Expires January 7, 2010                [Page 16] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

       o  a Source MEP of a unidirectional path only transmits BFD 
          packets in UP state or AdminDown State, the diagram in 
          Figure 2 becomes a ''sub-branch'' of state machine reported 
          in Figure 1 

EndofEditor's note 

. The ''Defects Raise'' and ''Defects Clear'' Event in Figure 1 and 
  Figure 2 occurs when: 

       o Defect Raise Event = dLOC or dUNME or dUNM or dUNP; 

       o Defect Clear Event = (not dLOC)and(not dUNME)and(not 
          dUNM)and (not dUNP);          

       o See section 5.2. for defect conditions description.                     

. When on a configured bidirectional MEP the proactive CC-CV 
  monitoring is enabled, the MEP sends the CC/CV BFD packet with 
  frequency of the configured transmission period and it also 
  expects to receive the CC/CV BFD packets from its peer MEP with 
  the same transmission period (see [5]). 

. In a unidirectional (point-to-point or point-to-multipoint) 
  transport path , where the proactive CC-CV monitoring is 
  enabled, only the Source MEP is enabled to generate  CC/CV BFD 
  packets with frequency of the configured transmission period and 
  always with UP State information . This MEP does not expect to 
  receive any CC/CV BFD packets from its peer MEP in the ME  

. a MEP Sink, configured on a unidirectional transport path where 
  the proactive CC-CV monitoring is enabled, expects to receive 
  the CC/CV BFD packets from its peer MEP at the configured 
  period; the defects detection procedure is the same as the 
  bidirectional MEP; no CC/CV BFD packets are sent on the ME. 

It is worth noticing that CC-CV proactive monitoring can be 
enabled/disabled by an operator on a configured ME and this MUST be 
not traffic affecting. Please refers to [5] for hitless 
enable/disable CC-CV proactive monitoring procedure.  

When a BFD session transits from one state to another, the traffic 
MUST not be affected. The blocking of traffic as consequent action 
MUST be driven only by a defect's consequent action as specified in 
the consequent action section 5.3.  


 
 
Fulignoli              Expires January 7, 2010                [Page 17] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

When the CC-CV proactive monitoring is disabled on a ME no CC/CV 
BFD packets are sent on the ME neither defects are monitored; 
however, the MEP must terminate all OAM packets it receives and in 
case of CC-CV proactive packets it must recognize a mis-
connectivity even if the CC-CV proactive monitoring is disabled on 
the MEP. 

    

5.2. Defect conditions 

   Defect triggered at the MPLS-TP layer by the CC-CV proactive 
   tool are reported in this section. 

5.2.1. Loss of Continuity defect(dLOC)  

   If no CC/CV BFD packets from a peer MEP are received within the 
   interval equal to K times (see Table 1) the receiving MEP's 
   configured CC-CV transmission period, loss of continuity with 
   peer MEP is detected. 

    

5.2.2. Mis-connectivity defect (dUNME) 

   If an extended BFD with a ME ID different than the configured 
   expected one is received , mis-connectivity defect is detected. 

    

5.2.3. Unexpected MEP ID defect (dUNM) 

   If a CC-CV BFD packet with expected ME ID but with an incorrect 
   MEP ID, including the receiving MEP's own MEP ID, is received, 
   Unexpected MEP is detected.  

    

5.2.4. Unexpected Period Defect (dUNP) 

   If a CC-CV BFD packet is received with a correct ME ID, a 
   correct MEP ID, but with a period field value different than the 
   receiving MEP's own CC-CV transmission period, Unexpected Period 
   is detected.  

    

 
 
Fulignoli              Expires January 7, 2010                [Page 18] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

5.2.5. RDI Defect (dRDI) 
    

   The Remote Defect Indicator defect monitors the presence of an 
   RDI maintenance signal. A MEP detects RDI defect when it 
   receives a CC/CV BFD packet with the RDI field set.  

   The following Table summarizes the defect raising and clearing 
   conditions 

    

    

    

    

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |Defect |Raising Condition        |Clearing Condition           |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |dLOC   |#Rx BFD==0 (K*CV_Period) |#Rx BFD >= N (K*CV_Period)   |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |dUNME  |Unexpected ME Identifier |#UnexpMEId==0 (K*CV_Period)  |      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |dUNM   |Unexpected MEP Id        |#UnexpMEPId==0 (K*CV_Period) |      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |dUNP   |Unexpected Period        |#UnexpPeriod==0 (K*CV_Period)|      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |dRDI   | Rx RDI == 1             | Rx RDI ==0                  |      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   Table 1: Table of Raising Clearing Defect Conditions 

   In Table 1, N and K are protocol constants to be defined; the 
   CV_Period corresponds to the configured transmission period; 

   K value is stored in bfd.DetectMult variable while the CV_Period 
   is stored bfd.DesiredMinTxInterval variable and carried in the 
   relative BFD packet fields. 

    





 
 
Fulignoli              Expires January 7, 2010                [Page 19] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

5.3. Consequent action 

. If a MEP detects an unexpected ME Identifier, or an unexpected 
  MEP, it MUST block (BLK) all the traffic (including also the 
  user data packets) that it receives from the misconnected 
  transport path. 

. If a MEP detects LOC defect and the CC-CV monitoring is enabled 
  it MUST block (BLK) all the traffic (including also the user 
  data packets) that it receives from the misconnected transport 
  path. This consequent action is configurable (see [5]) 

. If a MEP detects an unexpected ME Identifier, or an unexpected 
  MEP it MUST declare a Transport Path Fail (TSF). 

. If a MEP detects LOC defect and the CC-CV monitoring is enabled 
  it MUST declare a Transport Path Fail (TSF). 

. If a MEP declare a Transport Path Fail it MUST insert an RDI 
  information towards its peer MEP in a bidirectional connection 

   Consequent actions are identified by abbreviation prefixed with 
   an 'a': aXXX, e.g. aTSF.  The consequent actions detailed above 
   can be so summarized :  

   aBLK  <--   (dUNME or dUNM) or (dLOC and CC-
   CV_Monitoring_Enabled and LOC_cons_action_Enabled) 

   aTSF  <--   (dLOC and CC-CV_Monitoring_Enabled)or dUNME or dUNM 
   or Server_SF 

   aRDI <-- aTSF 

    

5.4. Administrative Down State 

   As reported in[8]: ''a session MAY be kept administratively down 
   by entering the AdminDown state and sending an explanatory 
   diagnostic code in the Diagnostic field. AdminDown state means 
   that the session is being held administratively down. This 
   causes the remote system to enter Down state, and remain there 
   until the local system exits AdminDown state. AdminDown state 
   has no semantic implications for the availability of the 
   forwarding path.''  


 
 
Fulignoli              Expires January 7, 2010                [Page 20] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   Please not that the AdminDown state semantic MUST be not 
   confused with the LOCK functionality as reported in [3]. In this 
   document the AdminDown state semantic is equivalent to disabling 
   on a MEP the CC-CV proactive monitoring; in this case the source 
   MEP SHOULD send BFD Control packets in AdminDown state for a 
   period equal to(bfd.DesiredMinTxInterval * bfd.DetectMult) in 
   order to ensure that the remote system is aware of the state 
   change.  

   An MPLS-TP MEP receiving a BFD packet with AdminDown State MUST 
   transit to the DOWN State and report the event to the operator. 
   Editor's note: 

   In this case the operator should disable the functionality even 
   on the other node. Should the node still report the LOC defect ? 
   If Yes the AdminDown State received can be a simple 
   report/warning to the operator.  

   End editor's note 

                                                       

5.5. Timer Negotiation 

   The negotiation of time value foreseen by the base BFD (see [8]) 
   MUST be disabled on the MPLS-TP extended BFD. The timer 
   negotiation should be even disabled on an MPLS-TP node that runs 
   only the CC functionality as well as on a node that 
   interoperates with current BFD. It's up to the operator 
   configure the BFD transmission period on the MPLS-TP node in a 
   way that is suitable for the MPLS legacy node. 

   The configured BFD packet transmission period MUST be stored 
   into the bfd.DesiredMinTxInterval variable and carried into the 
   ''Desired Min TX Interval field'' of the transmitted BFD  

   For a bidirectional point-to-point transport path the same 
   bfd.DesiredMinTxInterval value MUST be stored even in 
   bfd.RequiredMinRxInterval; source MEP of unidirectional session 
   MUST set the bfd.RequiredMinRxInterval to 0. 

   The bfd.DesiredMinRxInterval value is carried into the ''Required 
   Min RX Interval field '' of the transmitted BFD. 

   If BFD packets are received with the ''Desired Min TX Interval 
   field '' different from than expected and stored in the local  

 
 
Fulignoli              Expires January 7, 2010                [Page 21] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   bfd.DesiredMinTxInterval variable the Unexpected Period defect 
   is detected.  

   Please note that this behavior doesn't preclude the base BFD 
   session running on a MPLS legacy node to adapt to the BFD timers 
   transmitted by an MPLS-TP node. 

   The configured transmission period MUST be one of the following 
   values, both for the extended BFD and current BFD running on a 
   MPLS-TP node:              

. 3.33 ms: Default transmission period for protection switching 
  application (transmission rate of 300 packets/second); 

. 10 ms: (Transmission rate is 100 packets/second); 

. 100 ms: Default transmission period for performance monitoring 
  application (transmission rate of 10 packets/second); 

. 1 s: Default transmission period for fault management 
  application (transmission rate of 1 packets/second). 

    

5.6. Demultiplexing and the Discriminator Fields 

   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 interoperates with a base BFD can apply the 
   same discriminator field semantic as described in [8] or:  

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

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

6. Remote Defect Indication  

   The Remote Defect Indication (RDI) is an indicator that is 
   transmitted by a MEP to communicate to its peer MEP that a 
   signal fail condition exists.  RDI is only used for 
   bidirectional connections and is associated with proactive CC & 
   CV packet generation.[5] 
 
 
Fulignoli              Expires January 7, 2010                [Page 22] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   Editor's note: in last version of MPLS-TP OAM requirement 
   ([3])the RDI functionality is now even for unidirectional 
   connection if a return path exist. However this implies a 
   further analysis  

   End of Editor's note 

   The Diagnostic (Diag) field of base 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 applies for the extended BFD and for the base BFD when a 
   MPLS-TP  node runs only the CC functionality  

    

7. BFD Control Packets field  

   As defined in [8], the mandatory Section of a BFD Control 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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |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                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    


 
 
Fulignoli              Expires January 7, 2010                [Page 23] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   The contents of transmitted and expected BFD Control packets on 
   a MPLS-TP node for the mechanism proposed in this document are 
   detailed below both for extended BFD as well as current BFD: 

   Version 

   Set to the current version number (1). If version number is not 
   correct the packet is discarded.  

   Diagnostic (Diag) 

   The following value are requested to be supported among the 
   value reported in [8]: 

   0 -- No Diagnostic 

   1 -- Remote Defects Indication 

   3 -- Neighbor Signaled Session Down 

   7 -- Administratively Down 

   Different values are ignored in receipt.  

    

   State (Sta) 

   The current BFD session state as seen by the transmitting 
   system.  Values are: 

           0 -- AdminDown 

           1 -- Down 

           2 -- Init 

           3 -- Up 

   Poll (P) 

   If set, the transmitting system is requesting verification of 
   connectivity, or of a parameter change, and is expecting a 
   packet with the Final (F) bit in reply.  If clear, the 
   transmitting system is not requesting verification. 

    
 
 
Fulignoli              Expires January 7, 2010                [Page 24] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

   Final (F) 

   If set, the transmitting system is responding to a received BFD    
   Control packet that had the Poll (P) bit set. If clear, the    
   transmitting system is not responding to a Poll. 

    

   Control Plane Independent (C) 

   Is not required to be supported on a MPLS-TP node. Set to 1 on 
   transmit and ignored in receipt. 

    

   Authentication Present (A) 

   Set to 1 if authentication is in use on this session 
   (bfd.AuthType is nonzero), or 0 if not. 

   Demand (D) 

   Set to 0 in asynchronous mode.  

    

   Multipoint (M) 

   Set to 1 if bfd.SessionType is MultipointHead (Source MEP of a 
   point to multipoint connection). Otherwise it is set to 0. 

    

   Detect Mult 

   Detection time multiplier. The configured transmit interval,      
   multiplied by this value, provides the Detection Time for the      
   transmitting system in Asynchronous mode. This is the K protocol 
   constants as defined in Table 1.  

    

   Length  

   Set to the appropriate length, in bytes, of the only BFD Control 
   packet, based on the fixed header length (24) plus any 
   Authentication Section. 
 
 
Fulignoli              Expires January 7, 2010                [Page 25] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

    

   My Discriminator 

   A unique, nonzero discriminator value generated by the 
   transmitting system. See section 5.6.  

    

   Your Discriminator 

   The discriminator received from the corresponding remote system.      
   This field reflects back the received value of My Discriminator,     
   or is zero if that value is unknown. See section 5.6.  

    

   Desired Min TX Interval 

   This is the configured BFD packet transmission period, in 
   microseconds and stored into the bfd.DesiredMinTxInterval 
   variable. See section 5.5.  

    

   Required Min RX Interval 

   This is the configured BFD packet period, in microseconds and  
   stored into the bfd.RequiredMinRxInterval variable. Source MEP 
   of unidirectional session MUST set it to 0 See section 5.5.  

    

   Required Min Echo RX Interval 

   Is not required to be supported on a MPLS-TP node; set to 0.  

    

   An optional Authentication Section MAY be present. For details 
   see section 10.  

    




 
 
Fulignoli              Expires January 7, 2010                [Page 26] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

8. Interoperability with current BFD  

   There's no interoperability issue among a MPLS-TP node running 
   the current BFD, with the rules defined in previous sections, 
   and legacy MPLS node at PW layer network level as the use of the 
   CC Type 1 was previously defined and limited to PWs. (See [7]) 

   Instead, any Network Partitioning scenario with LSP Stitching 
   present interoperability issues as LSP Ping is designated to 
   bootstrap the BFD session in an MPLS environment and the session 
   BFD messages for MPLS are transmitted using a IP/UDP 
   encapsulation (see [12] and [4]); the IWF requires further 
   analysis. 

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

    

9. Point to Multipoint transport paths  

   Solution described in section 3.2. is also valid for p2mp 
   connections. The extended multipoint BFD packets are explicitly 
   marked as such, via the setting of the M bit (see [9]). 

   The diagrams reported Figure 2 provides also an overview of the 
   state machine for MEP Sink configured on each tail of a p2mp 
   path.  

   MEP Source, head of unidirectional p2mp, will never receive 
   packets and have no Detection Timer, and as such all state 
   transitions are administratively driven. 

   The MEP Source sends the extended multipoint BFD packet in the 
   multicast tree at a configured transmission period. 

   A unidirectional point-to-multipoint connection containing n 
   end-points contains (n-1) MEs, each one independently monitored 
   by MEP Sink configured on each tail as described in section 5.    

   Editor's note: 

. It is suggested to introduce the following new bfd.SessionType 
  in [9]: 

        oMPLS-TP MultipointHead: Transport Profile of 
          MultipointHead 

 
 
Fulignoli              Expires January 7, 2010                [Page 27] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

        oMPLS-TP MultipointTail: Transport Profile of 
          MultipointTail 

   EndofEditor's note 

   This section requires further analysis.  

    

10. Acknowledgments 

   <Add any acknowledgements> 

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

11. Contributors 

12. IANA Considerations 

   <Add any IANA considerations> 

13. 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 this document: 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.  

 

14. References 

14.1. Normative References 

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

  [2]   Bocci, et al., " MPLS Generic Associated Channel ", RFC 
        5586 , June 2009  
 
 
Fulignoli              Expires January 7, 2010                [Page 28] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

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

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

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

  [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-04.txt, Work in Progress,  May 2009 

  [8]   Katz, D. and D. Ward, "Bidirectional Forwarding 
        Detection", draft-ietf-bfd-base-09.txt (work in progress), 
        February 2009. 

  [9]   Katz, D. and D. Ward, "BFD for Multipoint Networks",              
        ID draft-katz-ward-bfd-multipoint-02.txt, February 2009 

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

  [11]  A. Fulignoli, et. al.,''MPLS-TP Proactive Continuity and 
        Connectivity Verification'', draft-fhbs-mpls-tp-cv-
        proactive-00.txt (work in progress), February 2009 

  [12]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 
        "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work 
        in progress),     June 2008. 

  [13]  Martini, L.and M.Morrow, ''Pseudo Wire (PW) OAM Message 
        Mapping'', draft-eitd-pwe3-oam-msg-map-10 (work in 
        progress), April 2009 

   


 
 
Fulignoli              Expires January 7, 2010                [Page 29] 

Internet-Draft         MPLS-TP Proactive CC&CV                July 2009 
    

14.2. Informative References 

    

   Authors' Addresses 

   Annamaria Fulignoli (Editor)     
   Ericsson 
   Email: annamaria.fulignoli@ericsson.com 
    
   Sami Boutros 
   Cisco Systems, Inc.  
   Email: sboutros@cisco.com 
    
   Martin Vigoureux 
   Alcatel-Lucent 
   Email: martin.vigoureux@alcatel-lucent.com 






























 
 
Fulignoli              Expires January 7, 2010                [Page 30]