MPLS Working Group F. Zhang, Ed. Internet-Draft L. Jin Intended status: Standards Track B. Wu Expires: April 28, 2011 ZTE Corporation October 25, 2010 The Analysis of MPLS-TP Path Segment Monitoring draft-zhang-mpls-tp-path-segment-monitoring-01 Abstract This specification analyzes the different schemes to realize path segment monitoring in MPLS-TP network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 Internet-Draft will expire on April 28, 2011. Copyright Notice Copyright (c) 2010 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. Zhang, et al. Expires April 28, 2011 [Page 1] Internet-Draft Path Segment Monitoring October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Path Segment Monitoring Analysis . . . . . . . . . . . . . . . 3 3.1. MBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Local Rerouting . . . . . . . . . . . . . . . . . . . . . . 4 3.3. TTL TLV . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. The scaling Analysis . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative references . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Zhang, et al. Expires April 28, 2011 [Page 2] Internet-Draft Path Segment Monitoring October 2010 1. Introduction In order to monitor, protect and manage a portion (i.e. segment or concatenated segment) of a transport path, a path segment is defined between the edges of the portion of the LSP that needs to be monitored, protected or managed. If this path segment is created as a hierarchical LSP, it is called SPME (Sub-Path Maintenance Element). SPMEs are usually instantiated when the transport path is created by either the management plane or control plane for proactive monitoring. However, pre-design and pre-configuration of all the considered patterns of SPME are not sometimes preferable in real operation due to the burden of design works, a number of header consumptions, bandwidth consumption and so on, as described in setion 3.8 of [I-D.ietf-mpls-tp-oam-framework]. There are different schemes to configure SPMEs after the transport path has been created, and two network objectives SHOULD be met: 1. The monitoring and maintenance of existing transport paths has to be conducted in service without traffic disruption. 2. The monitored or managed transport path condition has to be exactly the same irrespective of any configurations necessary for maintenance. Here we will discuss the the advantages and disadvantages of different potential schemes. 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 RFC2119. 3. Path Segment Monitoring Analysis 3.1. MBB The make-before-break (MBB) procedures which are supported by MPLS allow the creation of a SPME on existing LSPs in-service without traffic disruption, as described in [RFC5921]. An SPME can be defined corresponding to one or more end-to-end LSPs at firt, then new end-to-end LSPsthat are tunneled within the SPME can be set up, which may require coordination across administrative boundaries, finally traffic of the existing LSPs is switched over to the new end- Zhang, et al. Expires April 28, 2011 [Page 3] Internet-Draft Path Segment Monitoring October 2010 to-end tunneled LSPs. The old end-to-end LSPs can then be torn down. See the figure below, copied from [RFC5921]: |LERx|--|LSRy|-+ +-|LSRz|--|LERt| | | | |----------- Carrier 1 ------------| | | +-----+ +----+ +----+ +-----+ | +--| |---| |---| |----| |--+ |LER1 | |LSR3| |LSR4| |LER2 | +--| |---| |---| |----| |--+ | +-----+ +----+ +----+ +-----+ | | |============ SPME ================| | |LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd| Figure 1: SPME for a set of transport path segments In the MBB schemes, LER1 needs to inform the old LSPs's ingress nodes (for example, LERx and LERa) that a SPME has been setup to monitor the segment between LER1 and LER2, so that LERx/LERa can instantiate the new LSPs. However, the coordination schemes across administrative boundaries are not explicitly described in [RFC5921]. [RFC4736] gives the RSVP-TE extension to realize reoptimization of MPLS TE Loosely Routed LSP. It is said that when a mid-point LSR whose next hop is a loose hop or an abstract node canlocally trigger a path re-evaluation when a configurable timer expires, some specific events occur (e.g., link-up event), or the user explicitly requests it. If a preferable path is found, the LSR sends an RSVP PathErr to the head-end LSR (Error code 25 (Notify), Error sub-code=6 ("preferable path exists")). Although SPME can be seen as a new link, the ingress nodes do know that they need to be triggered to establish new LSPs. In order to differentiate the cases between SPME and reoptimization, the new value "SPME up" is suggested to be assigned. As we can see, network objective (1) can be met, but network objective (2) can not be met due to the new assignment of MPLS labels. 3.2. Local Rerouting A bidirectional LSP1(LERx-LSRy-LER1-LSR3-LSR4-LER2-LSRz-LERt)exists between LERx and LERt, the forwarding label values along LERx->LERt direction are Lyx-L1y-L31-L43-L24-Lz2-Ltz, and the forwarding label values along LERt->LERx direction are Lxy-Ly1-L13-L34-L42-L2z-Lzt. Assuming that SPME1 (LER1-LSR3-LSR4- LER2) is established to monitor this LSP, in order to restrict the operation in the scope of Carrier Zhang, et al. Expires April 28, 2011 [Page 4] Internet-Draft Path Segment Monitoring October 2010 1, local rerouting technology described in [RFC4090] can be used here. LER1 uses the label L24 as the inner label and pushes it into SPME1, LER2 uses the label L13 as the inner label and pushes it into SPME1. But LER1 (LER2) needs to learn L24 (L13), which can be learned by the following procedures: When SPME1 is up, LER1 pushes LSP1's Path message into SPME1, the next hop is changed from LSR3 to LER2, upstream label unchanged (L13 is allocated to LER2). Similarly, LER2 pushes LSP1's Resv message into SPME1, the next hop is changed from LSR4 to LER1, and Label unchanged (L24 is allocated to LER1). After LER1 (LER2) has learned the inner label value L24 (L13), it can push the user traffic into SPME1. If LSP1 is unidirectional, LER1 pushes LSP1's Path message into SPME1, the next hop is changed from LSR3 to LER2. But for Resv message, the next of LER2 is changed from LSR4 to LER1, and it needs to be transmitted hop by hop. Local rerouting is more optimized compared to MBB, for the new assigned labels just exist in the scope of Carrier 1, but it still can not fully math the requirements of network objective (2). 3.3. TTL TLV In order to totally meet the requirements of network objective (2), the schemes based on non-label stack are needed. TTL TLV, as one of the optional ACH TLV objects, is defined in [I-D.boutros-mpls-lsp-ping-ttl-tlv], which is used to inform the receiver how many hops away the originator is on the path of the MS-PW or Bidirectional LSP. It can be used to realize path segment monitoring also, see the figure below. F--------G / \ A-----B-----C--*----D------E------Z Figure 2: TTL TLV for PSM The path segment PS1 (C-D-E) of LSP1 (A-B-C-D-E-Z) needs to be provisioned. Node C, as the MEP node of PS1, sends OAM message (like CC/CV, PM loss/dely, etc.) to node D, the TTL TLV MUST be inserted. TTL value is set to the hop counts from E to C, here it is 2 (if LSP1 is an associated bidirectional LSP, the hops form E to C maybe not be Zhang, et al. Expires April 28, 2011 [Page 5] Internet-Draft Path Segment Monitoring October 2010 2). In this way, node E can use the hops carried in TTL TLV to response the OAM message. The TTL values can be configured by NMS, or learned by control plane. [I-D.ietf-mpls-tp-identifiers] describes the MEP-ID of Pseudowire Segments, and the MEP configuration of path Segments can be defined similarly. That is to say, the MEP_ID of path segment can be formed by a combination of a LSP MEP_ID and the identification of the local node, such as "Src-Global_ID::Src-Node_ID::Src- Tunnel_Num::LSP_Num::PS-Global_ID::PS-Node_ID". 3.3.1. The scaling Analysis Assuming there is another path segment PS2 that exists between node B and E, proactive and on-demand OAM messages are running between B and E also. Just like PS1, the TTL TLV MUST be inserted, and the value is the hop counts from E to B (here it is 3). At some time, a defect happens between node C and D, the customer traffic would be switched from PS1 to the backup path(C---F---G---E). However, node B may not know that node C has switched all the traffic to the backup path, and in this case, node E can not receive the OAM message sent by node B and may make wrong decision. In conclusion, TTL TLV scheme can meet both the two network objectives. But it can not be used if two or more path segments are nested. 4. IANA Considerations A new error sub-code values for the RSVP PathErr Notify message (Error code=25) is required in this document: Error sub-code=TBD by IANA: "SPME up". 5. Security Considerations TBD. 6. Acknowledgement The authors would like to thank Hui Su for the discussion, thank Alexander Vainshtein, Kannan KV Sampath, Nurit Sprecher, Yoshinori Koike for their valuable comments. Zhang, et al. Expires April 28, 2011 [Page 6] Internet-Draft Path Segment Monitoring October 2010 7. Normative references [I-D.boutros-mpls-lsp-ping-ttl-tlv] Manral, V., Boutros, S., Sivabalan, S., Saxena, S., and G. Swallow, "Definition of Time-to-Live TLV for LSP-Ping Mechanisms", draft-boutros-mpls-lsp-ping-ttl-tlv-01 (work in progress), June 2010. [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf-mpls-tp-identifiers-02 (work in progress), July 2010. [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, "Operations, Administration and Maintenance Framework for MPLS- based Transport Networks", draft-ietf-mpls-tp-oam-framework-09 (work in progress), October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC4736] Vasseur, JP., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. Zhang, et al. Expires April 28, 2011 [Page 7] Internet-Draft Path Segment Monitoring October 2010 Authors' Addresses Fei Zhang (editor) ZTE Corporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877612 Email: zhang.fei3@zte.com.cn LZ Jin ZTE Corporation 889, Bibo Road, Zijinghua Road Pudong District, Shanghai 201203 P.R.China Phone: +86 021 68896273 Email: lizhong.jin@zte.com.cn Bo Wu ZTE Corporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877276 Email: wu.bo@zte.com.cn Zhang, et al. Expires April 28, 2011 [Page 8]