INTERNET-DRAFT Kingston Smiler Selvaraj Intended Status: Standards Track Ip Infusion Expires: March 05, 2013 L. Jin ZTE Sep 06, 2012 Static MPLS-TP LSP configuration checking using Generic Associated Channel (G-ACh) Advertisement Protocol draft-smiler-mpls-tp-static-lsp-config-check-00 Abstract This draft introduces a way to check the static lsp configuration (in case of bi-directional LSP), so as to ease the trouble shooting of static configurations in the MPLS network. The idea is to use Generic Associated Channel (G-ACh) Advertisement Protocol (GAP) [I-D.ietf- mpls-gach-adv] to transfer the LSP parameters to the far-end for configuration checking. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. GAP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Static LSP Application Message . . . . . . . . . . . . . . 4 3.2. PE Procedure . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Sending LSP application Element TLV . . . . . . . . . . 7 3.2.2. Receiving LSP application Element TLV . . . . . . . . . 7 3.2.3. P Node / Transit Node message processing. . . . . . . . 8 3.2.4. LSP Configuration Check Process . . . . . . . . . . . . 10 3.2.5. Remote Label Advertisement . . . . . . . . . . . . . . 11 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1 Normative References . . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1 Introduction This draft introduces a way to check the static bidirectional lsp configurations, so as to ease the trouble shooting of static configurations in the MPLS network. The idea is to use Generic Associated Channel (G-ACh) Advertisement Protocol (GAP) [I-D.ietf-mpls-gach-adv] to transfer the LSP parameters to the next hop node for checking the configuration. The methods described in this draft will be very useful for checking the configuration of static p2mp LSPs and MPLS TP LSPs. Today once the transport path is configured statically there is no way to check the consistency of the configurations across the endpoints and transit nodes before making the status of the underlying transport path to be operationally up. 1.1 Terminology 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 [RFC2119]. 2. Motivation The manual configuration of static LSP requires configuring many parameters in all the nodes in the LSP path, and these parameters should be aligned, so as to make LSPs be operational. If one of the parameters on the nodes which carries this LSP mis-matches, then the LSP would not operate correctly. For the dynamic LSP, the parameters would be negotiated by signaling session, and easy to find out the configuration error if LSP is not operational UP. But for static LSP, there is no such kind of signaling session, it is difficult for operators to do trouble shooting, to figure out which parameters on which node mis-matches. Also in some occasions, the mis-configuration doesn't affect the data traffic which can't be identified by the operators. As the data path depends on the labels and label operations to be performed over the packet, if the labels are configured properly and the LSP configurations parameters like global ID / node ID is not matching over the nodes, then the data traffic will be successful however the OAM CV verification won't be successful. In order to identify these mis-configurations and to ease the trouble shooting of static LSP, this draft relies on GAP to transfer the configuration parameters over the section, so as to check configuration parameters automatically on each nodes to figure out parameter mis-matching. 3. GAP Extensions 3.1. Static LSP Application Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Static PW | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserve | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Static LSP FEC Element TLV + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 A new GAP application "Static LSP" is defined in this draft. The Static LSP Application ID is to be assigned by IANA, and suggested value is 0x0003. Length: as per [I-D.ietf-mpls-gach-adv]. Lifetime: as per [I-D.ietf-mpls-gach-adv], and the default value is suggested to be 120 seconds. Static LSP FEC Element TLV for "Static LSP" GAP application: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LSP Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Tunnel Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination LSP Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TX Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Label Sub-TLV(0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Label Sub-TLV(0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 The Static LSP FEC Element TLV type is to be assigned by IANA. The Length field specifies the length in octets of the Static LSP FEC Element and all Optional Interface Parameters Sub-TLVs. The Static LSP FEC element TLV value MUST include the following: o The Global ID, Node ID, Tunnel Num, LSP NUM fields MUST be set as per [RFC6370]. o TX Sequence Number: The transmitted message sequence number for the associated Static LSP FEC Element TLV. o RX Sequence Number: The last received sequence number for the associated Static LSP FEC Element TLV. o Two Generic Label TLVs as defined in [RFC5036] to encode static LSP incoming and outgoing labels in the order shown above. The GAP Suppress message defined in [I-D.ietf-mpls-gach-adv] applies to all TLVs for a given application. We define a new TLV, static LSP suppress TLV, to suppress static LSP FEC element transmission. Multiple static LSP FEC element TLVs could be included in this TLV. The format would be as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LSP Suppres TLV| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Static LSP ID FEC + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + multiple static LSP ID FECs + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 The type of static LSP suppress TLV is to be assigned by IANA. The static LSP suppress TLV could be sent by a receiving PE to request a transmitting PE to stop sending GAP messages for the static LSP FEC Element TLVs in the static LSP suppress TLV. The static LSP application MUST follow all procedures defined in [I-D.ietf-mpls-gach-adv]. 3.2. PE Procedure The mechanism defined in this draft provides a verification tool for the P2P LSP configuration information in all the nodes between the tunnel endpoints. Upon provisioning or re-provisioning of a LSP at any node, GAP messages carrying the static LSP application TLV will be sent over the outgoing as well as the incoming interface of this LSP (if any). 3.2.1. Sending LSP application Element TLV When a LSP is configured on a PE node, and the corresponding section / outgoing interface is UP, the PE node SHOULD send its local LSP configuration information through GAP with local static LSP element TLV. The transmitting node MUST set the TX sequence number to a non-zero value in Static LSP FEC Element TLV, and MUST increment the TX sequence number each time any local LSP parameters change. If the transmitting node has previously received a GAP message with the static LSP FEC Element, the transmitting node MUST verify local LSP parameters with the remote PE parameters as specified in section 3.2.4. The RX sequence number MUST be set to the previously received TX sequence number, otherwise set to zero. Whenever PE receives the GAP message with LSP suppress TLV, it SHOULD stop sending GAP message with specified LSP information. Whenever the PE updates locally LSP configuration information, PE could send GAP message with static LSP element to update information. 3.2.2. Receiving LSP application Element TLV The receiving node MUST update the remote LSP parameters associated with a static LSP FEC Element TLV, when the received TX sequence number in the GAP message is different from the last one received. If the receiving PE has been provisioned locally with the LSP parameters and has previously sent GAP message for the LSP parameters, it MUST check if the RX sequence number in the received GAP message is equal to the TX sequence number it previously sent. If the RX sequence number is equal, the receiving node MUST send GAP message with static LSP suppress TLV as a response to remote node, and then verify local static LSP parameters with the remote static LSP FEC parameters as specified in section 3.2.4. Otherwise, if the RX sequence number is not equal, the receiving PE MUST continue sending GAP message with static LSP FEC element TLV, with the RX sequence number set to the last received TX sequence number from the remote PE. If there is no local LSP configuration associated with the static LSP FEC Element TLV, the receiving PE MUST retain the remote static LSP FEC Element information. Whenever PE receives the GAP message with static LSP suppress TLV, it MUST stop sending GAP messages with the specified static LSP FEC element TLVs included in the static suppress TLV. The GAP message of static LSP application SHOULD be sent at least three times within lifetime. 3.2.3. P Node / Transit Node message processing When a LSP is configured on transit node, and the corresponding outgoing interface /section of forward and reverse component of LSP is UP, then the transit node SHOULD send its local LSP configuration information through GAP with "local static LSP element TLV". This GAP message should be sent on both side of the LSP. When the P node receives GAP message with static LSP element TLV from head-end side of the LSP, it SHOULD save the LSP parameters in "local static LSP element" TLV as head-end ingress LSP information for a period of "lifetime" which is specified in the GAP message. Similarly when the P node receives GAP message with static LSP element TLV from tail-end side of the tunnel, it SHOULD save the LSP parameters in "local static LSP element" TLV as tail-end ingress LSP information for a period of "lifetime" which is specified in the GAP message. If the transmitting node has previously received a GAP message with the static LSP FEC Element, the transmitting node MUST verify local LSP parameters with the remote PE parameters as specified in section 4.2.3. The RX sequence number MUST be set to the previously received TX sequence number, otherwise set to zero. If the receiving GAP message also has "remote static LSP element" TLV, P should check local head-end / tail-end LSP parameters with that in "remote static LSP element" TLV. If both matches, P should send GAP message with LSP suppress TLV contained the specified LSP information to either the previous / next-hop router. If not, P send GAP message with local LSP configuration information carried in "local static LSP element" TLV, and the received remote LSP configuration information carried in "remote static LSP element" TLV. Once the P node has both the local and the remote static LSP element it performs the LSP configuration verification process described in the section 3.2.4. If the verification process fails then the operational status of the tunnel should be down. , 3.2.4. LSP Configuration Check Process When the LSR / LER has both local and remote LSP parameters for one LSP, it should do parameter checking as follows: 1. For MPLS TP LSPs, in PE node, verify the LSP identifiers for the local static LSP element and remote static LSP elements are same. (i.e A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num of source LSP parameter should match with A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num of destination LSP parameters) 2. For MPLS TP Tunnel, in transit node, verify the tunnel identifiers of tail-end ingress LSP information and head-end ingress LSP information matches with the local static LSP element. (i.e A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num of source LSP parameter should match with A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num of destination LSP parameters) 3.2.5. Remote Label Advertisement The mechanism described in this draft could also be used as label advertisement, so as to avoid out_label negotiation manually between two LSRs / LERs, and to avoid mis-configuration. As such, only outgoing label will be included in the GAP message and this label will be used by the nexthop remote PE as incoming label for the LSP. 4 Security Considerations The mechanisms defined in this draft do not introduce any new threats more than what's described in [I-D.ietf-mpls-gach-adv]. 5 IANA Considerations IANA is requested to allocate a new "Static LSP" Application ID in the "G-Ach Advertisement Protocol Applications" registry. Application ID Description Reference -------------- ---------------------------- ------------ (TBD) Static LSP Application (this draft) This document requests that IANA create a new registry, "GAP Static LSP Application: TLV objects", with fields and initial value as follows: Type Name Type ID Reference ----------------------- ------- ------------ Static LSP FEC Element 0 (this draft) Static LSP suppress TLV 1 (this draft) The range of the Type ID field is 0 - 255. The allocation policy for this registry is IETF Review. 6 References 6.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1 1995. [I-D.ietf-mpls-gach-adv] Frost, D., Bocci, M., and S. Bryant, "MPLS Generic Associated Channel (G-ACh) Advertisement Protocol", draft-ietf-mpls-gach-adv-00 (work in progress), January 2012. 6.2 Informative References [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. Authors' Addresses Kingston Smiler Selvaraj IPInfusion Software Ind Pvt LTD Bangalore India Email: kingston.selvaraj@ipinfusion.com Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn