CCAMP Working Group K. Shiomoto (NTT) Internet Draft V. Sharma (Metanoia, Inc.) Document: draft-shiomoto-ccamp- Y. Suemura (NEC) misconnection-analysis-00.txt Expires: December 2004 June 2004 Analysis of Misconnection Scenarios in GMPLS Networks draft-shiomoto-ccamp-misconnection-analysis-00.txt Status of this Memo 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." 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 The purpose of this memo is to describe and analyze the occurrence of misconnections in GMPLS networks. We present a problem statement, and describe some scenarios under which misconnections may happen. We then outline some common causes of misconnections and discuss some solutions to address them. Our goal is to facilitate further discussions of this issue and the associated solutions within the CCAMP Working Group. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................2 3. Problem Statement..............................................2 4. Analysis of Misconnection Scenarios............................3 4.1. Activating Backup LSPs in Shared Mesh/1:1 Restoration........3 4.2. Activating High-priority versus low-priority LSPs............5 4.3. Failure at a switch or node..................................7 Shiomoto/Sharma/Suemura Expires December 2004 1 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks 5. Common Causes of Misconnections................................8 6. Possible Solutions to Handle Misconnections....................9 7. Conclusions....................................................9 8. Security Considerations.......................................10 9. References....................................................10 9.1. Normative References..............Error! Bookmark not defined. 9.2. Informative References............Error! Bookmark not defined. 10. Author's Addresses..........................................10 11. Intellectual Property Considerations........................11 11.1. IPR Disclosure Acknowledgement..............................11 12. Full Copyright Statement....................................11 1. Introduction As providers gain experience with MPLS deployments, and begin utilizing their MPLS/GMPLS networks as a common infrastructure upon which to offer a variety of converged services (e.g., Layer 2 transport over MPLS, Layer 2 and Layer 3 MPLS VPNs, VoIP services, and critical business data transport), a number of different aspects related to MPLS/GMPLS network stability, operations, and management become increasingly important. In particular, with new restoration methods and sophisticated pre- emption schemes that are possible, providers are interested in understanding the nature and types of misconnections that may occur in GMPLS-based networks, and in developing ways to either prevent misconnections (where possible) or to detect misconnections and minimize their impact in a timely manner on the network operations and the services offered. 2. 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]. 3. Problem Statement Based on the description in Section 1, our problem can be stated as: "To analyze when and how misconnections may happen during the activation of LSPs in an GMPLS network; to identify some common causes of misconnections; and, to propose some initial solutions for avoiding or minimizing misconnections." The purpose of this document, therefore, is to focus on misconnections, and discuss when they may occur and evaluate some of their common causes. The goal is also to propose some initial solutions to address the problem of misconnections. Shiomoto/Sharma/Suemura Expires December 2004 2 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks 4. Analysis of Misconnection Scenarios Misconnections in an MPLS/GMPLS network may happen in a variety of circumstances. In the following sections, we focus on three cases of misconnections that we have identified during discussions on the CCAMP WG mailing list. These include: i) Misconnections during the activation of a backup LSP in a shared mesh or 1:1 restoration scenario. ii) Misconnections during the activation of a high-priority LSP in favor of a low-priority one. iii) Misconnections due to a failure at a node or a switch. 4.1. Activating Backup LSPs in Shared Mesh/1:1 Restoration A misconnection may occur in several ways during the activation of a backup LSP in shared mesh restoration [3], [4], [5]. We discuss three cases below with an example setup. Consider the following network scenario: A-----------B \ / C-------D / \ E F Where A-B: Path of the Primary LSP A-C-D-B: Path of the Secondary LSP E-C-D-F: Path of an Extra (preemptible) LSP Case 1: Assume that an LSP is always activated upon the receipt of a Path message, and assume that initially the primary LSP A-B, and the extra-traffic LSP E-C-D-F are active. Upon a failure in the primary LSP, it is necessary to activate the secondary LSP A-C-D-B. We consider what happens at node C upon the arrival of a Path message (that signals the secondary LSP A-C-D-B) carrying a Protection Object [2]. If node C immediately reconfigures its cross-connect to connect A-C to C-D, then, for a short period of time (until node D receives the Path message and reconfigures its cross-connect to connect C-D to D-B), it is possible for traffic from A to end-up at F via the path A-C-D-F, thus leading to a misconnection. One way to eliminate this would be to have a two-way activation scheme that makes use of both the Path and the Resv messages. For example, the extra LSP E-C-D-F is deleted upon the receipt of a Path message (that corresponds to the secondary LSP) at a node, while the secondary LSP A-C-D-B is activated upon the receipt of a Resv message (that corresponds, as before, to the secondary LSP) at a node. Thus, Shiomoto/Sharma/Suemura Expires December 2004 3 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks in the example above, upon the detection of a failure on the primary LSP A-B, a Path message with the Protection Object is sent along the secondary LSP. Upon receipt of this message, node C deletes the extra-LSP (removing state for it both from the control plane and the data plane), and activates the secondary LSP when it receives a Resv message for the secondary LSP. However, even in this case a misconnection may happen as follows. A-----------B \ / C-------D / \ E F Where A-B: Path of the Primary LSP A-C-D-B: Path of the Secondary LSP E-C-D-F: Path of an Extra (preemptible) LSP Case 2: Assume that upon the receipt of a Path message(containing the Protection Object) at node C, corresponding to the secondary LSP, the cross-connect for the extra LSP is deleted.(Recall that both Path and Resv messages must be periodically transmitted along the secondary LSP to maintain the state of the provisioned secondary LSP.) If node C now receives a Resv message from node D, it may set up the cross-connect for the secondary LSP, thus connecting A-C to C-D. This could happen, for example, when node C has no way of distinguishing a refreshing Resv message (corresponding to the provisionedsecondary LSP) whose purpose is merely to maintain state for this LSP from an activating Resv message (corresponding to the secondary LSP) whose purpose is to actually activate the secondary LSP, by causing intermediate nodes to reconfigure their cross-connects. Therefore, if the cross-connect at node C for the secondary LSP is (erroneously) made before node D has had a chance to delete the cross-connect corresponding to the extra LSP, there is a misconnection, with traffic from node A ending up at node F via the path A-C-D-F. A possible solution to this would be to also carry the Protection object in the Resv message that is sent to activate the secondary LSP, thus allowing a node to distinguish between a Resv message for activation from a refresh Resv message, say via the S bit in the Protection object. Even when the above changes to the Resv object and the processing rules are made, there remains the possibility of misconnections because the nodes may not consistently bring down the state of the extra- LSP. We explain this next. Shiomoto/Sharma/Suemura Expires December 2004 4 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks A-----------B \ / C-------D / \ E F Where A-B: Primary LSP A-C-D-B: Secondary LSP E-C-D-F: Extra (preemptible) LSP Case 3: Consider again the earlier network example, where we assume that the Resv message is enhanced to carry the Protection object, and that the cross-connections for the secondary LSP at a node are made upon the receipt of the Resv message for activation. Note that because of the way vendors interpret and implement rules for hard/soft pre-emption of LSPs, it is possible that the extra LSP is not brought down upon the receipt of the Path message for the secondary LSP. Thus, it is possible that node C, upon receipt of a Path message for the secondary LSP, does not immediately delete the extra LSP. Suppose node D, upon the receipt of a Resv message with a Protection Object for the secondary LSP, brings down the extra LSP, and activates its cross-connect for the secondary LSP, that is, it reconfigures its cross-connect to switch from C-D -> D-F to C-D -> D- B. However, since node C may not have deleted its cross-connect corresponding to the extra LSP, traffic may now be misconnected from node E to node B via the path E-C-D-B. This may be prevented by enforcing a rule that an intermediate node along the route of a secondary LSP must remove the state, in control plane and data planes, associated with the extra LSP (that uses resources required by the secondary LSP) *before* forwarding the Path message for the secondary LSP. 4.2. Activating High-priority versus low-priority LSPs The situations that lead to misconnections during the activation of LSPs with different priorities are almost analogous to those that arise in the shared mesh restoration case for activation of the secondary LSP in place of the extra LSP. In fact, we have three cases here that parallel those discussed in Section 4.1. Consider the following network scenario: A-----------B \ / Shiomoto/Sharma/Suemura Expires December 2004 5 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks C-------D / \ E F Where A-C-D-B: High-priority LSP E-C-D-F: Low-priority LSP Assume that initially LSP E-C-D-F is active, and that there is then a need to set up the higher priority LSP A-C-D-B. Case 1: Assume that an LSP is always activated upon the receipt of a Path message, and that initially the low-priority LSP E-C-D-F is active. At some time, it becomes necessary to activate the high-priority LSP A-C-D-B. We consider what happens at C upon the arrival of Path message (that signals the high-priority LSP A-C-D-B). If node C immediately reconfigures its cross-connect to connect A-C to C-D, then, for a short period of time (until node D receives the Path message and reconfigures its cross-connect to connect C-D to D-B), it is possible for traffic from A to end-up at F via the path A-C-D-F, thus leading to a misconnection. A possible solution to this is to, as before, use a two-way activation scheme that uses both the Path and the Resv messages with a way to distinguish between Resv messages that refresh the state of an LSP from Resv messages that are supposed to activate the configuration of a cross-connect for an LSP. A-----------B \ / C-------D / \ E F Where A-C-D-B: High-priority LSP E-C-D-F: Low-priority LSP Case 2: Consider again the earlier network example, where we assume that the Resv message is enhanced to distinguish a refresh Resv message from a Resv message for activation of an LSP. In other words, the cross- connections for an LSP at a node are made upon the receipt of the Resv message for its activation. Note that because of the way vendors interpret and implement rules for hard/soft pre-emption of LSPs , it is possible that the low- Shiomoto/Sharma/Suemura Expires December 2004 6 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks priority LSP is not brought down upon the receipt of the Path message for the high-priority LSP. Thus, it is possible that node C, upon receipt of a Path message for the high-priority LSP A-C-D-B, does not immediately delete the low priority LSP E-C-D-F. If node D, upon the receipt of a Resv message for the high-priority LSP, brings down the low-priority LSP, and activates its cross- connect for the high priority LSP, that is, it reconfigures its cross-connect to switch from C-D -> D-F to C-D -> D-B, then we could have a misconnection. This is because node C may not have deleted its cross-connect corresponding to the low priority LSP, so traffic may now be misconnected from E to B via the path E-C-D-B. This may be prevented by enforcing a rule that an intermediate node along the route of a high-priority LSP must remove the state, in the control plane and data planes, associated with a low-priority LSP (that uses resources required by the high-priority LSP) before forwarding the Path message for the high-priority LSP. 4.3. Failure at a switch or node Another situation when misconnections may arise is when a node or a switch malfunctions. The nature of malfunctions could span the control plane or the data plane. Let us consider again the network scenario from Section 4.1. A-----------B \ / C-------D / \ E F where A-B: Primary LSP A-C-D-B: Secondary LSP E-C-D-F: Extra (preemptible) LSP Suppose that we follow the rule of activating the secondary LSP upon the receipt of a Resv message. If there is a malfunction at node C, such that upon the receipt of a Path message for the secondary LSP, it deletes the state of the extra LSP from its control plane but fails to alter its cross-connect in the data plane, thus allowing E-C to remain connected to C-D, we can have a misconnection as follows. Node D, upon receiving a Resv message (with a Protection object) from node B, correctly switches its cross-connect from C-D -> D-F to C-D -> D-B. However, since the cross-connect at C has not been altered, traffic may now flow incorrectly from E to B via the path E-C-D-B. Shiomoto/Sharma/Suemura Expires December 2004 7 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks If the control plane at C is somehow disconnected from its data plane, with neither plane having stopped working, this situation could continue indefinitely. It would then be necessary to have a way to quickly detect and recover from such a misconnection scenario. 5. Common Causes of Misconnections When examining the common causes of misconnections, there are two issues to keep in mind: - One issue is when (in time) a cross-connection is made. - Second issue is the signaling method and rules used to drop an extra LSP and activate a secondary LSP (in the restoration case), or to activate a high-priority LSP and deactivate a low-priority LSP. - In order to analyze the common causes of misconnections, we distinguish between the logical association of an incoming port with an outgoing port from the physical association. The logical association is an association between the incoming and outgoing ports that is stored in the MPLS/GMPLS controller software. On the other hand, the physical association is the actual association between the incoming and the outgoing ports. When a physical association between two ports is made, the data traffic is immediately carried from the incoming port to the outgoing port over the cross-connection made by the physical association. The case where low-priority traffic is preempted by high-priority traffic is explained by noting the difference between the logical association and the physical one. Suppose the low-priority traffic has a logical association between an incoming port (say, port-i1) and an outgoing port (say, port-o1), while the high-priority traffic has a logical association between an incoming port (say, port-i2) and the outgoing port (say, port-o1). The outgoing port (port-o1) is shared. The logical association for the traffic is maintained by the signaling protocol. If both logical associations exist, the logical association for the high priority traffic is selected to make the cross-connection and realize a physical association between port i2 and port o1. If a logical association for only the low priority traffic exists, it is selected to make the cross-connection. That is, a physical association is made between port i1 and port o1. A common cause of misconnection lies in the situation where the priority traffic selected to make the cross-connection is inconsistently selected among the nodes along with the route. Here we define the possible states for the cross-connection as: (1) high, (2) low, and (3) null. Shiomoto/Sharma/Suemura Expires December 2004 8 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks High and low states indicate that the cross-connection is made according to the logical association of the high and low priority traffic, respectively. Null state indicates that no cross-connection is made (i.e., no input and output ports associated with low and high priority traffic are connected). If we have both high and low state for the cross-connections along with the route simultaneously, we could have a misconnection. If we have only high and/or null states for the cross-connections, we cannot have a misconnection. Similarly, if we have only low and/or null state for the cross-connections, we cannot have misconnections, either. In order to avoid misconnections, we need a mechanism to have mutually exclusive high (including null) or low (including null) state for the cross-connections along with the route. We observe, however, that the use of the null state may not always be possible in optical switches, such as MEMS switches, which do not allow for a null state. This is because a MEMS switch changes cross- connection by tilting a mirror. So, an input port is always connected to one of the output ports. This results in the same situation as described in Section 4.3. A possible solution to this for the case of LSPs with multiple priorities is explained below. The applicability of this solution to the restoration case (or the development of other solutions to address this problem in the restoration case) requires further study. 6. Possible Solutions to Handle Misconnections In order to have mutually exclusive high (including null) or low (including null) state for the cross-connections along the route, one may use a two-way activation approach. A Path message for the high priority LSP activation is used to make the cross-connection state æænullÆÆ while a Resv message for the high priority activation is used to make the cross-connection state ææhighÆÆ. In order to distinguish the refresh message from the activation one for high priority traffic, we can use the Admin Status object. Another option is to use the Protection object in the Resv message. Finally, to solve the possible misconnection problem in optical switches that do not allow for a null state, the source node must wait for the high-priority LSP to be fully established before sending out data on it. In other words, the initiator/ingress node sends out data after receiving the RESV message for activation. For triggering the terminator/egress node to send out data, a ResvConf message should be sent from the initiator/ingress, and received by the terminator/egress, before it begins transmitting data on the high- priority LSP. 7. Conclusions This document provided an initial discussion of misconnection scenarios in GMPLS networks, analyzes some common scenarios, outlines Shiomoto/Sharma/Suemura Expires December 2004 9 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks some common causes of these, and then posits some alternative ways of handling misconnections. 8. Security Considerations This document does not introduce any new security considerations in the protocols considered herein. 9. References 9.1. Normative References [1] RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] L. Berger (Ed.), "Generalize Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering Extensions" RFC 3473, January 2003. 9.2. Informative References [3] D. Papadimitriou, et al, "Analysis of Generalized Multi-Protocol Label Switching-based Recovery Mechanisms", Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-recovery-analysis-03.txt, April 2003. [4] J. P. Lang, D. Papadimitriou, Y. Rekhter (Eds.), "RSVP-TE Extensions in Support of End-to-End GMPLS-Based Recovery", Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls- recovery-e2e-signaling-02.txt, May 2003. [5] A. Farrel, "Multi-protocol Label Switching Pre-emption" Internet Draft, Work in Progress, draft-farrel-mpls-preemption-01.txt, April 2004 10. Author's Addresses Kohei Shiomoto Vishal Sharma NTT Corporation Metanoia, Inc. 9-11 Midori-Cho 3-Chome 888 Villa St., Suite 200B Musashino-Shi, Tokyo 180-8585, Japan Mountain View, CA 94041, USA Phone: +81 (422) 59 4402 Phone: +1 408 530 8313 Email: Shiomoto.Kohei@lab.ntt.co.jp Email: v.sharma@ieee.org Yoshihiko Suemura NEC Corporation 1753, Shimonumabe, Nakahara-ku Kawasaki 211-8666, Japan Phone: +81 44 396 2804 Email: y-suemura@bp.jp.nec.com Shiomoto/Sharma/Suemura Expires December 2004 10 Analysis of Misconnection Scenarios June 2004 in GMPLS Networks 11. Intellectual Property Considerations 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 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.1. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 12. Full Copyright Statement "Copyright (C) The Internet Society (2004). 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." Shiomoto/Sharma/Suemura Expires December 2004 11