CCAMP Working Group Z. Ali (Cisco Systems, Inc.) Internet Draft T. Otani(KDDI R&D Laboratories, Inc.) Intended status: Standards Track Expires: May 2008 Ping and Traceroute for GMPLS LSPs in Non-Packet Switched Networks draft-ali-ccamp-gmpls-lsp-ping-traceroute-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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) The IETF Trust (2007). Abstract "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures," RFC4379, describes procedures for ping and traceroute for LSPs that traverse a Packet Switch Capable (PSC) network. These procedures are known as Label Switched Path Ping (LSP Ping). Z. Ali Expires May 11, 2008 [Page 1] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt An important implication of using non-PSC nodes in a Generalized MPLS (GMPLS) network is that the LSP Ping solution described in RFC4379 is not applicable to LSPs traversing a non-PSC network. Another important feature introduced by GMPLS is the potential for data and control plane separation with the consequence that LSP Ping procedures for ping and traceroute that rely on in-band propagation of messages cannot be applied. This document describes mechanisms that can be used to detect and isolate data plane failures in non-PSC GMPLS LSPs. The document also proposes a method to traceroute a GMPLS LSP in PSC or non-PSC networks where the data and control planes are separated. The proposed solutions are based on the Link Management Protocol (LMP) described in RFC4204 and on MPLS LSP Ping [RFC4379]. The document is particularly applicable to data plane technologies where the data plane does not otherwise provide the OAM functions (e.g., pre-OTH photonic cross-connects). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. Table of Contents 1. Introduction..............................................3 2. Connectivity Verification and Isolating Faults............4 2.1. Control Channel Management...........................5 2.2. LSP Verification Procedure...........................6 3. Fault Isolation...........................................7 4. Tracerouting..............................................7 5. Security Considerations...................................9 6. IANA Considerations.......................................9 7. Acknowledgments...........................................9 8. References...............................................10 8.1. Normative References................................10 8.2. Informative References..............................10 9. Author's Addresses.......................................10 Z. Ali, et al Expires May 11, 2008 [Page 2] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 10. Intellectual Property Statement.........................10 11. Copyright Statement.....................................11 1. Introduction When a Generalized Multiprotocol Label Switching (GMPLS) label Switched Path (LSP) fails to deliver user traffic, the failure cannot always be detected by the GMPLS control plane. There is a need to provide a tool that enables users to detect such traffic "black holes" or misrouting within a reasonable period of time, and a mechanism to isolate faults [GMPLS-OAM-REQ]. Similarly, the ability to trace the route of GMPLS LSPs in networks where data and control planes are separated is a requirement [GMPLS-OAM-REQ]. This document provides solution to these requirements. [RFC4379] describes procedures for LSP Ping for LSPs with Packet Switch Capable (PSC) endpoints and transit switching capabilities. However, the LSP Ping solution is not applicable to LSPs crossing or terminating at non-PSC devices. This is because the solution described in [RFC4379] requires all transit and end point nodes along the LSP path to be able to intercept the MPLS OAM (Operation and Maintenance) packets traveling in the data plane and identify the target Forwarding Equivalence Class (FEC) Stack being tested. Such operations cannot be realized at nodes that are non PSC-capable. Moreover, the LSP Ping mechanism described in [RFC4379] may be inadequate even when the end points of the GMPLS LSP are PSC- capable. This is because the GMPLS LSP may appear as a single hop for procedures described in [RFC4379]. In such cases, mechanisms in [RFC4379] are able to detect data plane failure in the GMPLS LSP but are still not able to isolate failures in underlying switching layers. Similarly, in this scenario, the GMPLS LSP appears as a single hop during traceroute procedures. This document describes a mechanism that can be used to detect and isolate data plane failures in GMPLS LSPs with non-PSC transit switching capability. As mentioned above, the Echo Request [RFC4379] follows the same path as data packets, i.e., they are not control plane messages. This is also a limitation when tracing a GMPLS LSP with non-PSC transit nodes. This is because non-PSC devices are incapable of intercepting the MPLS echo request packets, and hence, cannot process these packets, e.g., check or update TTL values needed for traceroute functionality. A consequence of this is that traceroute for GMPLS LSPs has to be performed Z. Ali, et al Expires May 11, 2008 [Page 3] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt out-of-band in the control network, probing entities that control the non-PSC devices (e.g. optical cross-connects). This draft also proposes extensions to LSP traceroute procedures that can be implemented in GMPLS networks with data and control plane separation. The proposed solutions are based on the Link Management Protocol (LMP) [RFC4204] and Multiprotocol Label Switching (MPLS) Operations and Management (OAM) solutions [RFC4379]. In the following sections, we outline how existing LMP and MPLS OAM procedures needs to be modified to provide ping and tracerouting functionality in GMPLS networks. Recall the scope of this draft is cases where data plane does not provide the OAM functions addressed by this draft (e.g., pre-OTH photonic cross-connects). Use of OAM functionality provided by the data planes is RECOMMENDED and procedures described in this draft are only assumed to be applied when OAM mechanisms are not supported by the data plane or are deficient. 2. Connectivity Verification and Isolating Faults LMP fault isolation mechanism [RFC4204] can be used to detect and isolate failures along a GMPLS LSP. The requirement is to be able to check the health of an LSP before carrying traffic over it. Consequently, the ability to use LMP fault isolation mechanism for this purpose largely depends on the transport technology. Specifically, in technologies where a signal is (constantly) carried even without data, LMP fault isolation procedure can be applied as soon as LSP is setup. This draft addresses technologies where this is not possible (e.g., pre- OTH cross-connects) by extending the use LMP "Test" message for connectivity verification and fault isolation. For this purpose, the draft proposes an extended LMP model as shown below. +------+ +------+ +------+ +------+ | | ----- | | ===== | | ----- | | | OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 | | | ----- | | ----- | | ===== | | +------+ +------+ +------+ +------+ ^ ^ ^ ^ ^ ^ ^ ^ Z. Ali, et al Expires May 11, 2008 [Page 4] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt | | | | | | | | | +----LMP1----+ +----LMP2---+ +-----LMP3----+ | | | +----------------------LMP4----------------------+ Figure 1 Extended LMP Model. In this model, the Ingress and Egress nodes of the LSP under verification may establish and maintain LMP session. The nodes continue to maintain hop-by-hop LMP sessions to build traffic engineering (TE) links for GMPLS signaling and routing, as described in [RFC4204]. For example in Figure 1, OXC1-OXC2 (LMP1), OXC2-OXC3 (LMP2), and OXC3-OXC4 (LMP3) LMP sessions are used to build traffic-engineering (TE) links for GMPLS signaling and routing, while the LMP session between OXC1-OXC4 (LMP4) is used to monitor health of GMPLS LSP(s) with OXC1 and OXC4 as end-points. Existing signaling mechanism (e.g., LSP_TUNNEL_INTERFACE_ID object for RSVP-TE signaling [RFC3477], [) are used to discover remote link properties, i.e., the LMP session between LSP end-point nodes is only used for OAM purposes. Once an LMP session between LSP end-point nodes comes up, Link connectivity verification can be used to perform LSP connectivity verification. This is done by sending Test messages over the GMPLS LSP and TestStatus messages back over the control channel. For this purpose, LMP connectivity verification procedure as described in [RFC4204] is used. It is important to note LMP link verification procedure [RFC4204] applies to equally to PSC and non-PSC TE links. Similarly, in order to send Test messages over the GMPLS LSP, the end-point of the LSP does not have to be PSC. 2.1. Control Channel Management The control channel management for LSP ingress-node-to-egress- node is the same as described in [RFC4204]. To distinguish between an LSP ingress-node-to-egress-node LMP session and a peer node-to-peer node LMP session, or LMP-WDM session, a new bit for LMP-WDM_CONFIG object [RFC4209] is defined as follows: Class = 6, C-Type = 2, LMP-WDM_CONFIG [RFC4209]. 0 1 2 3 Z. Ali, et al Expires May 11, 2008 [Page 5] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+ |W|O|L| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+ The Reserved field should be sent as zero and ignored on receipt. W and O bits are defined in [RFC4209]. The draft defined the "L" bit, where "L" stands for LMP peering for "LSP". L : 1 bit This bit indicates that the peer node wants to establish an LMP session to test LSP(s). The L bit is defined to distinguish LSP-ingress-node-to-LSP-egress-node LMP sessions from other types of LMP sessions as defined in [RFC4204]and [RFC4209]. To establish an ingress-node-to-egress-node LMP session, the Ingress node sets "L" bit in the LMP-WDM_CONFIG message and sends it to the peering Egress node for LSP(s) under test. The Egress nodes can also initiate LMP session by sending LMP- WDM_CONFIG message with L = 1. [RFC4209] requires a node that does not support LMP-WDM_CONFIG message to MUST reply with a ConfigNack message. If a node supports LMP-WDM_CONFIG message but does not support L bit, it MUST reply to the LMP- WDM_CONFIG message with a ConfigNack message. The rest of the details for control channel management follow [RFC4204]. 2.2. LSP Verification Procedure The link verification procedure described in [RFC4204] has been adapted for LSP verification. Specifically, once a control channel has been established between the ingress and egress nodes of an LSP, LSP connectivity can be verified by exchanging Test messages between nodes along the GMPLS LSP's path. Since the LSP's health can be tested along the forwarding transmit path, both endpoints nodes can (independently and simultaneously) initiate the exchange of Test messages in each direction to test for the health of bidirectional LSPs. Z. Ali, et al Expires May 11, 2008 [Page 6] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt To initiate the link verification procedure, the Ingress (Egress) node MUST send a BeginVerify message over a control channel with IP address of the destination (source) node of the LSP. To limit the scope of LSP Verification to a particular LSP, LSP-id is used in LOCAL_LINK_ID or REMOTE_LINK_ID fields of the LMP message exchanges during verification. If the LINK_ID field is zero, the verification can span multiple LSPs between the set of Ingress/Egress nodes involved in the verification process. The rest of the details for LSP verification follow the LMP link verification procedure [RFC4204]. 3. Fault Isolation If LSP verification fails, the LMP fault isolation procedure [RFC4204] can be applied. For this purpose, the Ingress (Egress) node initiating the LSP fault localization procedure starts the LSP verification procedure by setting VerifyInterval to a time interval large enough to perform fault isolation procedure. Actual selection of the interval is a local decision, but the requirement is that LMP link verification procedure should not time out before the fault is localized. The node initiating the LSP fault localization procedure then starts sending the Test message over the LSP under test. This enables a downstream node (downstream in terms Test message flow) to detect data link failure where the LSP may be broken. This downstream node then sends a ChannelStatus message to its upstream neighbor indicating that a failure has been detected. The rest of details for the LSP fault isolation procedure follows LMP fault isolation procedure [RFC4204]. 4. Tracerouting As mentioned above, one of the consequences of transparent nature of optical cross-connects is that traceroute for GMPLS LSPs has to be performed out-of-band in the control network, probing entities that control the non-PSC devices (e.g., optical cross-connects). This also requires control entities to be in-sync with the forwarding states of the device. How control entities achieves this goal is beyond the scope of this document. When the route of a GMPLS LSP is traced in the control network, MPLS Echo Request packets are dispatched toward each transit LSR of the LSP while including the LSP's tested FEC, and setting the appropriate value of the TTL in the MPLS echo Z. Ali, et al Expires May 11, 2008 [Page 7] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt request. The main issue with probing GMPLS flows in the control plane is that the control network topology is entirely independent of the data network topology; For example, an MPLS echo request probe packet may travel multiple hops in the control plane to reach an LSR that is only 1 hop away in the data plane. This draft proposes use of GRE encapsulation of MPLS Echo request messages and a method to force Echo requests to follow the data plane's topology, while flowing through the control network. Other tunneling techniques, like IP-in-IP are equally applicable. The sender of the MPLS echo packets encapsulate the IP/UDP MPLS echo request packet using GRE. The GRE packet can then be routed inside the control network to the next hop transit LSR in the control plane. The receiver control entity decapsulates the GRE header and then processes the echo request by looking up the FEC for the data LSP and sending the echo reply with the appropriate downstream mappings. Both Ingress and Egress LSRs can start LSP tracing operations. The Ingress (Egress) LSR follows the following steps: 1. The Ingress (Egress) LSR finds optical nodes that are one hop away in data plane. The exact details on how Ingress (Egress) LSR finds optical nodes that are one hop away in data plane is beyond the scope of this document but using the control plane state of the LSP under trace, the ingress LSP can determine the IP address of the control plane node that is one hop downstream (upstream), even when RRO is not used. 2. The Ingress LSR sends MPLS echo Request packet with TTL=1 and encapsulates it using GRE to the node that it finds in the last steps. 3. When the control entities at the optical node that is assumed to be one hop away in data plane, receives the MPLS echo request message from the ingress (Egress) LSR via GRE tunnel, it examines the tested FEC contained in the MPLS Echo request, and sends an echo reply back to the ingress (Egress) LSR if it has a crossconnect for the FEC under test. If the receiving control node has a crossconnect for the FEC under test, the node also returns the control plane address of the next hop node (obtained in fashion mentioned in step 1). This will allow the ingress to tunnel to the next control plane node. Details for how MPLS Echo response Z. Ali, et al Expires May 11, 2008 [Page 8] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt needs to be modified is to be added in a later version of the document. 4. Upon receiving the Echo reply, Ingress (Egress) nodes prepares a Echo Request packet with TTL = 1 and encapsulates it using GRE to the node that it learned via Echo reply in step 3. 5. The Ingress (Egress) LSR repeats the same procedure for nodes that it learns from step 4 until it learns destination (source) node and repeats step 4 for destination (source) node. 5. Security Considerations Security considerations and requirements form [RFC4204] and [RFC4379] apply equally to this document. Furthermore, there are some additional security considerations that may be induced by extended LMP model proposed by this draft. These security considerations will be added in a later version of the draft. 6. IANA Considerations TBA 7. Acknowledgments The authors would like to acknowledge comments from Adrian Farrel , Tarek Saad, and David Ward. Z. Ali, et al Expires May 11, 2008 [Page 9] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 8. References 8.1. Normative References [RFC4204] "Link Management Protocol (LMP)", J. Lang, et al., http://tools.ietf.org/html/rfc4204. [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", K. Kompella, G. Swallow, et al., http://tools.ietf.org/html/rfc4379. [GMPLS-OAM-REQ] "OAM Requirements for Generalized Multi- Protocol Label Switching (GMPLS) Networks", T. Otani, et al., draft-ietf-ccamp-gmpls-oam-requirements-00.txt. [RFC4209] "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", J. Lang, et al., http://tools.ietf.org/html/rfc4209. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, http://tools.ietf.org/html/rfc2119. 8.2. Informative References [RFC3477] "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", K. Kompella, Y. Rekhter, et al, http://tools.ietf.org/html/rfc3477. 9. Author's Addresses Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Tomohiro Otani KDDI R&D Laboratories, Inc. Email: otani@kddilabs.jp 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort Z. Ali, et al Expires May 11, 2008 [Page 10] Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on- line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 11. Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Z. Ali, et al Expires May 11, 2008 [Page 11]