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