MPLS Working Group F. Zhang Internet-Draft L. Jin Intended status: Standards Track B. Wu Expires: January 6, 2011 ZTE Corporation July 05, 2010 The Analysis of MPLS-TP Path Segment Monitoring draft-zhang-mpls-tp-path-segment-monitoring-00 Abstract This specification describes 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 January 6, 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 January 6, 2011 [Page 1] Internet-Draft Path Segment Monitoring July 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 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative references . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Zhang, et al. Expires January 6, 2011 [Page 2] Internet-Draft Path Segment Monitoring July 2010 1. Introduction In order to monitor, protect and manage a portion (i.e. segment orconcatenated 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). There are different ways to realize path segment monitoring in MPLS-TP network. Here we will discuss their advantages and disadvantages. 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 [I-D.ietf-mpls-tp-framework]. A SPME can be defined corresponding to one or more end-to-end LSPs. New end-to-end LSPs which are tunneled within the SPME can be set up, which may require coordination across administrative boundaries. Traffic of the existing LSPs is switched over to the new end-to-end tunneled LSPs. The old end-to-end LSPs can then be torn down. See the figure below: |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 Zhang, et al. Expires January 6, 2011 [Page 3] Internet-Draft Path Segment Monitoring July 2010 However, LER1 needs to tell the old LSPs's ingress nodes (for expample, LERx and LERa) that a SPME has been setup to monitor the segment between LER1 and LER2. The coordination procedure is not described clearly. [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")). When SPME is setup for path segment monitoring, it can be seen as a new link, "preferable path exists" is appliable also. But in order to differentiate the cases between monitoring and reopitimization, a new vale "preferable SPME exists" can be assigned. MBB needs to tear down the old LSP and setup new LSP, which needs LSPs ingress and egress nodes to switch user traffic from old LSPto new LSP, furthermore it will change the address management of all MEPs and MIPs newly configured for new LSP. In order to restrict that the operation happens just on SPME's ingress and egress nodes, we will give another solution described below. 3.2. Local rerouting Assuming that bidirectional LSP1(LERx-LSRy-LER1-LSR3-LSR4-LER2-LSRz- LERt) needs to be tunneled into SPME1 (LER1-LSR1-LSR2- LER2), The corresponding label values (from LERx to LERt direction) are (Lyx- L1y-L31-L43-L24-Lz2-Ltz), which are carried in the Resv message of LSP1. The corresponding label values (from LERt to LERx direction) are (Lxy-Ly1-L13-L34-L42-L2z-Lzt), which are carried in the Path message of LSP1. LER1 uses the label L24 as the inner label and push it into SPME1, LER2 uses the label L13 as the inner label and push it into SPME1. But LER1 (LER2) needs to learn L24 (L13), this can be done as follow: LER1 push LSP1's Path message into SPME1, the next hop is changed from LSR3 to LER2, Upsteam-Label unchanged (L13 is allocated to LER2). Similarly, LER2 push LSP1's Resv message inot SPME1, the next hop is changed from LSR4 to LER1, and Label unchanged (L24 is allocated to LER1). After LER1 (LER2) has learned the label value L24 (L13), it can push the user traffic into SPME1. The monitoring of unidirectional LSP is similar, the only difference is that the Resv message frome LER2 to LER1 needs to be transmitted hop by hop. Although this scheme is more optimized compared to MBB, it can not Zhang, et al. Expires January 6, 2011 [Page 4] Internet-Draft Path Segment Monitoring July 2010 solve the inherited limitation like all label stack based methods. For example, a) increasing the bandwidth by stacking MPLS headers, b) changing the condition of original transport path by changing the length of the MPLS frame (Delay measurement and loss measurement can be sensitive). 3.3. TTL TLV According the inherited disadvantages of label stack, here we give another solution for option. +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | A +------| B +------+ C +------+ D +------+ E | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ TTL=3 Figure 2: TTL for transport path Segment monitoring TTL TLV, as one of the optional ACH TLV objects, is defined in [draft-boutros-mpls-lsp-ping-ttl-tlv-01]. Here we use this TLV to realize path segment monitoring. See the figure above, the path segment (B-C-D) of LSP1 (A-B-C-D-E) needs to be monitored. Node B, as the MEP node of path segment needs to be monitored. Node B sends OAM message (like CC/CV, PM loss/dely, etc.) to node D, MUST insert the TTL TLV as one of the ACH TLV objects. TTL value is set to the hop counts from B to D, here it is 3. In this way, node D can differentiate the OAM message sent by different MEP nodes. The TTL value can be configured staticly or learn by traceroute procedure. [I-D.ietf-mpls-tp-identifiers] describes the MEP-ID of Pseudowire Segments, here we suggest to add the MEP configuration of LSP segments. The MEP_ID can be formed by a combination of a LSP MEP_ID and the identification of the local node. 4. IANA Considerations TBD. 5. Security Considerations TBD. Zhang, et al. Expires January 6, 2011 [Page 5] Internet-Draft Path Segment Monitoring July 2010 6. Acknowledgement TBD. 7. Normative references [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf-mpls-tp-identifiers-01 (work in progress), March 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Authors' Addresses Fei Zhang 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 Zhang, et al. Expires January 6, 2011 [Page 6] Internet-Draft Path Segment Monitoring July 2010 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 January 6, 2011 [Page 7]