Internet Draft Document zhai suping BFD Working Group Huawei Techonology Co., Ltd draft-suping-bfd-mpls-fecmismatch-00.txt Expires: September 2005 March 2005 BFD Extensions for MPLS FEC mismatch detection draft-suping-bfd-mpls-fecmismatch-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." This document may only be posted in an Internet-Draft. 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. Abstract BFD mechanism [BFD] was original designed to detect failures in communication with a forwarding plane next hop. BFD operates on top of any data protocol being forwarded between two systems. This document describes how to use the BFD mechanism for detecting the MPLS FEC mismatch. The proposal is based on the FEC mismatch mechanism of ITU-T Y.1713. The proposed solution covers the mpls network when use BFD as the fault detection mechanism. suping March 2005 [Page 1] Internet Draft draft-suping-bfd-mpls-fecmismatch-01.txt The proposed extensions for BFD do not change the overall scope of BFD as a lightweight detection protocol, but have a trivial change to both the BFD Control packet format and the BFD state machine described in [BFD] draft. Conventions 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. Table of Contents 1. Introduction....................................................2 2. What problem we want to solve...................................2 3. FEC connectivity verification...................................3 3.1 BFD control packet.............................................3 3.2 Diagnostic codepoints..........................................4 3.3 The process overview...........................................4 3.3.1 Coding rules for ingress.....................................5 3.3.2 Coding rules for egress......................................5 3.3.3 Egress processing............................................5 3.3.4 Limitations..................................................5 3.3.5 FEC filter setup.............................................5 4. Security Considerations.........................................5 5. Intellectual Property Considerations............................5 6. Full Copyright Statement........................................5 7. References......................................................6 8. Authors' Addresses..............................................6 1. Introduction This document describes how to use the BFD mechanism [BFD] for detecting the LSP FEC mismatch in the MPLS network between LSRs. The LSP can be setup and signaled in LDP, RSVP-TE or CR-LDP. This method is based on the ITU-T Y.1713 and introduce the detecting mechanism to BFD. As such, the BFD mechanism can be used for LSP FEC mismatch detecting. The proposed solution covers the mpls networks when use BFD as the fault detection mechanism. The proposed extensions for BFD do not change the overall scope of BFD as a lightweight detection protocol, but have a trivial change to both the BFD Control packet format and the BFD state machine described in [BFD] draft. 2. What problem we want to solve The problem that we want to solve is to develop a capability of detecting LSP FEC mismatch in the MPLS application. Such capability suping March 2005 [Page 2] Internet Draft draft-suping-bfd-mpls-fecmismatch-01.txt should be provisioned in the MPLS OAM application. In addition to the potential of forwarding problems misdirecting traffic within a specific MPLS level, MPLS provides the ability to define arbitrary hierarchy, but does not necessarily provide for synchronization mechanisms to ensure all hierarchical dependencies are satisfied prior to insertion of traffic into an LSP. A common example would be any overlay on an LDP network that used independent label distribution mode. In independent mode an LSR in the core of the network may advertise a label binding for an FEC immediately upon learning of the FEC via any means (typically via an IGP advertisement) and this may be prior to having a viable downstream label binding or having LDP properly configured on all links that would be expected to be traversed by the LSP. This means that MPLS connectivity to the network egress for the FEC that applications of the MPLS level may depend on does not necessarily exist. The result is that the LDP label is popped in the core of the network, and the popping LSR may attempt to forward the application label. This may be a transient situation but is indicative of the types of problems that may occur.Therefore the ability to ubiquitously detect problems in the network requires the ability to detect misbranching independent of the specific application. Currently, ITU-T Y.1713 has proposed to detect the FEC mismatch through the FEC filter check in the egress LSP. And in this document we use the way discribed in Y.1713 to solve the problem in BFD. 3. FEC connectivity verification 3.1 BFD control packet Based on the original BFD Control packets, there need to add the FEC filter field as the following: 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 |H|D|P|F|C|A|Rsv| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC filter(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC filter(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ suping March 2005 [Page 3] Internet Draft draft-suping-bfd-mpls-fecmismatch.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | FEC filter(2) | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | FEC filter(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An optional Authentication field is the same as the original BFD control packet, and this document doesn't concern. 3.2 Diagnostic codepoints A diagnostic code specifying the local system's reason for the last transition of the session from Up to some other state. in the [BFD], there are following codepoints defined. 0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset 5 -- Path Down 6 -- Concatenated Path Down 7 -- Administratively Down 8-31 -- Reserved for future use To add the FEC mismatch error, Diagnostic codepoint 8 is tentatively used for the purpose. 3.3 The process overview A filter entry is a filter representation of a single token of information. A filter entry is specified as an application specific number of filter offsets that correspond to specific bits in the FEC filter. Filter offsets are expressed as a single value in the range 0-127. Each filter offset represents a single bit in the 16 byte FEC filter. The upper 4 bits of the offset constitute an octet offset from the first byte of the filter, and the lower 3 bits of the offset constitute a bit offset in the octet, zero referring to the LSB and 7 referring to the MSB. A filter is initially zeroed, and the bit corresponding to each filter offset is ORed with the filter. The egress will directly compare the received ingress filter with the egress filter. A not-equal result indicates either dFECfilter_Mismatch defect or a recent change has not propagated to the ingress. If the egress has changed the FEC filter, it may tolerate a mismatch for an unspecified amount of time. It MAY further perform filter testing to determine if the ingress filter is a subset of the current egress filter or cumulative egress filter in order to more quickly ascertain whether a suping March 2005 [Page 4] Internet Draft draft-suping-bfd-mpls-fecmismatch-01.txt genuine mismatch has occurred or is simply an artifact of hysteresis in the control plane. It indicates that the mismatch is not related to the withdrawal of the FEC element and dFECfilter_Mismatch defect state may be entered immediately. The following description take the LDP LSP for example, as to the RSVP-TE, or CR-LDP, please refer to the reference ITU-T Y.1713. 3.3.1 Coding rules for ingress Each FEC element (as encoded per RFC 3036 [5] section 3.4.1) that is instantiated in the FTN table for the LSP is encoded as a filter entry consisting of three filter offsets. ++++++++++++++++++++++++++ | FEC element | ++++++++++++++++++++++++++ Filter entry for RFC 3036 LSPs(3 filter offset) 3.3.2 Coding rules for the egress Each FEC element (as encoded per RFC 3036 section 3.4.1) that is offered to LDP peers for the LSP is encoded as a filter entry consisting of three (3) filter offsets. 3.3.3 Egress processing The egress will perform "reasonable subset" filter processing. 3.3.4 Limitations Using these coding rules, an upper limit of 10 FEC elements in a FEC filter is required to ensure greater than 99% probability of detecting all misbranching defects in a network supporting all of the applications outlined in this draft. 3.3.5 FEC filter setup The FEC mismatch verification is only valid in the BFD UP state. When in the BFD setup session, the peer LSRs will determin the respective FEC filter entry according to the above provision. Because the BFD session is per FEC, so there is only one FEC filter entry not considering the ECMP. All the BFD sessions running between two LSRs share the common FEC filter entry. 4. Security Considerations This document is not concerning the extra security problem. Any other security vulnerabilities are as per the [BFD]. 5. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 6. Full Copyright Statement suping March 2005 [Page 5] Internet Draft draft-suping-bfd-mpls-fecmismatch-01.txt Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7. References [BFD] draft-katz-ward-bfd-00.txt [ITU-T 1710] ITU-T Recommendation Y.1710 (2002), "Requirements for OAM Functionality In MPLS Networks" [LDP] RFC3036 LDP Specification, January 2001 8. Authors' Addresses zhai suping Huawei techonology Co., Ltd. No.3 XinXi Road, Haidian District, BeiJing 100085 The P.R.C Email: zhaisuping@huawei.com suping March 2005 [Page 6]