Network Working Group Emily Chen Internet-Draft Quintin Zhao Intended status: Standards Track Huawei Technology Expires: January 14, 2013 July 13, 2012 Deploying mLDP Through P2P LSP Tunnels draft-chen-mpls-mldp-deployment-via-p2p-tunnels-01.txt Abstract The existing specification for Multipoint Label Distribution Protocol (mLDP) functionality assumes that a pair of LDP speakers which support the P2MP/MP2MP capability are directly connected, or they can reach each other through targeted LDP session and transparent tunnel(s). However, the real deployment may not satisfy these assumptions, especially in the case where the targeted LDP session and the transparent tunnel(s) have to be pre-established. This document provides an automatic solution for finding the nearest upstream node which supports the LDP P2MP/MP2MP along the path from the current node to the root node, and triggering the targeted LDP session and transparent tunnel(s) when needed. 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 14, 2013. Copyright 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 Chen & Zhao Expires January 14, 2013 [Page 1] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Chen & Zhao Expires January 14, 2013 [Page 2] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. mLDP Deployment Through Transparent Tunnels . . . . . . . . . 5 2.1. Signaling Procedures . . . . . . . . . . . . . . . . . . . 6 2.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 7 3. mLDP Tunnel Through Capability . . . . . . . . . . . . . . . . 8 4. Handling Route Change Or Failure Event . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Chen & Zhao Expires January 14, 2013 [Page 3] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 1. Introduction 1.1. Specification of Requirements 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]. 1.2. Motivation In practical world, it is extremely hard to synchronously upgrade all the nodes in a huge network, especially upgrading all the hardware at the same time. Thus, unless users choose to deploy mLDP by building a completely new network, otherwise there must be a migration period from non-mLDP to mLDP capable. During this period, in order to setup Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and Multipoint-to-Multipoint (MP2MP) LSPs through the non-mLDP node(s), a common solution is to make mLDP LSPs going through targeted LDP sessions and transparent tunnels. The motivation of this draft is to trigger such kind of mLDP LSP automatically, so that several benefits can be brought in. First of all, the manual configuration of the targeted LDP sessions and transparent tunnels can be waived, correspondingly the network operation cost can be reduced. Secondly, users don't need to worry about traffic lost, because no matter whether the necessary targeted LDP sessions and transparent tunnels are correctly predicted and pre- configured, they will be automatically triggered when needed. Besides, because the targeted LDP sessions and transparent tunnels are built on demand, the resource consumption of system can be minimal. 1.3. Overview As specified by [RFC6388], mLDP Label Mapping message would be stopped when there is no mLDP-capable upstream node. Take the following scenario as an example, where the R4 node finds out that its upstream node R3 doesn't support mLDP, and there is no other node which R4 can use as its upstream node towards Root node, then this mLDP LSP establishment would fail. Chen & Zhao Expires January 14, 2013 [Page 4] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 +------------+ | R1 | mLDP node +------------+ / \ +-----------+ +-----------+ mLDP node | R2 | | R3 | non-mLDP node +-----------+ +-----------+ \ +-----------+ | R4 | mLDP node +-----------+ / \ +-----------+ +-----------+ mLDP node | R5 | | R6 | mLDP node +-----------+ +-----------+ This document specifies a mechanism for deploying the mLDP with the nodes supporting mLDP completely in the control plane and also in the forwarding plan, mixed with the nodes which do not support the mLDP but can propagate the mLDP mapping message toward the root until it finds the node which supports the mLDP. Both the protocol extensions and processing procedures are specified in this documents. 2. mLDP Deployment Through Transparent Tunnels +------------+ | R1 | mLDP node +------------+ / \ +-----------+ +-----------+ non-mLDP node with mLDP mLDP node | R2 | | R3 | Tunnel Through capability +-----------+ +-----------+ \ +-----------+ | R4 | mLDP node +-----------+ / \ +-----------+ +-----------+ mLDP node | R5 | | R6 | mLDP node +-----------+ +-----------+ mLDP Deployment Through Transparent Tunnels Chen & Zhao Expires January 14, 2013 [Page 5] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 Figure 1 In the figure above, when the R4 finds out that the upstream router R3 doesn't support mLDP completely but it supports the mLDP Tunnel Through capability, R4 will send out a notification message with its LSR-ID. When the R3 receives this notification message, it will propagate the notification message to is upstream router until arriving the nearest mLDP capable router, such as R1 in this case. When R1 receives the notification message, it will trigger the establishment of targeted LDP session and transparent tunnel to R4. When finished, R1 will notify R4 to consider it as an upstream router. Then mLDP advertisement is able to continue. +------------+ | R1 | mLDP node +------------+ / \ +-----------+ +-----------+ mLDP node | R2 | | R3 | mLDP node +-----------+ +-----------+ \ +-----------+ non-mLDP node with mLDP | R4 | Tunnel Through capability +-----------+ / \ +-----------+ +-----------+ mLDP node | R5 | | R6 | mLDP node +-----------+ +-----------+ mLDP Deployment Through Transparent Tunnels for Branch Node Figure 2 In the figure above, assume that R5 has already setup targeted LDP session and transparent tunnel with R3. When the R6 joins this mLDP LSP and finds out that the upstream router R4 doesn't support mLDP completely but it supports the mLDP Tunnel Through capability, R6 will trigger another targeted LDP session and transparent tunnel between R6 and R3. In this case, R3 will become the branch node for this mLDP LSP, where the outgoing two branches are implemented by using two tranparent tunnels. 2.1. Signaling Procedures Chen & Zhao Expires January 14, 2013 [Page 6] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 o LDP speakers advertise their capabilities in Initialization message or Capability message. o Assume that the node D is setting up the MP-LSP , D finds out that the direct connected "upstream LSR" for does not support mLDP, but it supports mLDP Tunnel Through capability. o The node D sends an notification message to this upstream node with its local LSR-ID and mLDP LSP's root node IP address. o The next hop node propagate the notification message to its upstream node until it reaches the node which supports the full mLDP capability. o When the first node which has mLDP full capability receives this notification, it will trigger LDP target session(s) and transparent tunnel(s) with the node D identified by the LSR-ID in the notification message. When finished, this first node will tell the node D identified by the LSR-ID to chose it as the upstream router for the mLDP LSP establishment. o Once the node with the LSR-ID receives this notification from the first node, it will setup the mLDP LSP as its upstream node to the root of the mLDP using the method superficies in draft-napierala-mpls-targeted-mldp. 2.2. Protocol Extensions Two new types of LDP MP Status Value Element are defined, following the MP Status TLV specification in [RFC6388]. One of them is used to identify the root node address of the mLDP, the other is used for identifying the LSR which needs the p2p tunnel to setup the mLDP LSP. Their encoding are 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type 1 (TBD) | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chen & Zhao Expires January 14, 2013 [Page 7] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 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 2 (TBD) | Length |C|S| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Capability (C) Flag : 0 = Setting up P2MP LSP 1 = Setting up MP2MP LSP Signaling (S) Flag : 0 = Advertising the mLDP LSP 1 = Withdrawing the mLDP LSP 3. mLDP Tunnel Through Capability The mLDP Tunnel Through Capability is advertised among the LDP peers. The encoding of mLDP Tunnel Through Capability Parameter TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| mLDP Tunnel Through (TBD) | Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+ S: As specified in [RFC5561] If one router does not received the mLDP Tunnel Through Capability advertisement from its neighbor, it should not send the mLDP Tunnel Through related messages to this neighbor. If one router receives the mLDP capability annoucement with the mLDP Tunnel Through capbility, it will silently ignore the mLDP Tunnel Through capability and consider the sender supports fully mLDP capability. Also if the router has not advertised the mLDP Tunnel Through Capability, and it receives the mLDP Tunnel Through related messages, then the receiver of the message will treat this error as same as it treats for other unrecognized messages. 4. Handling Route Change Or Failure Event Assume that the targeted LDP session between the two LSRs with the Chen & Zhao Expires January 14, 2013 [Page 8] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 mLDP capabilities is established, if there is a route change event and as the result of this, the downstream router of these two LSR will have a new upstream router to the root for a specific mLDP LSP, then the downstream router will treat this similar as the normal re- route cases. If there is no Make Before Break (MBB) supported, then the downstream router will delete the LSP setup through targeted session, then delete the useless targeted session and transparent tunnel(s). If there is MBB deployed, then the downstream router will setup the new LSP first and then delete the existing LSP using the MBB procedures. If the route from mLDP node to Root node doesn't change, but the route from the lightweight mLDP node to Root node changes, this lightweight mLDP node needs to withdraw the previous notification and advertise a new one to the new upstream node. 5. Acknowledgements We would like to thank authors of draft-ietf-mpls-mp-ldp-reqs and the authors of draft-napierala-mpls-targeted-mldp from which some text of this document has been inspired. 6. IANA Considerations This memo includes the following requests to IANA: o mLDP Tunnel Through Capability. o mLDP LSP Through Transparent Tunnel Status Code for LSR Identifier. o mLDP LSP Through Transparent Tunnel Status Code for Root IP Address. 7. Security Considerations The same security considerations apply as for the base LDP specification, as described in [RFC5036]. 8. References Chen & Zhao Expires January 14, 2013 [Page 9] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009. [RFC6348] Le Roux, JL. and T. Morin, "Requirements for Point-to- Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011. [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011. 8.2. Informative References [I-D.napierala-mpls-targeted-mldp] Napierala, M. and E. Rosen, "Using LDP Multipoint Extensions on Targeted LDP Sessions", draft-napierala-mpls-targeted-mldp-02 (work in progress), October 2011. Authors' Addresses Emily Chen Huawei Technology 2330 Central Expressway Santa Clara, CA 95050 US Email: emily.chenying@huawei.com Chen & Zhao Expires January 14, 2013 [Page 10] Internet-Draft Deploying mLDP Through P2P LSP Tunnels July 2012 Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: quintin.zhao@huawei.com Chen & Zhao Expires January 14, 2013 [Page 11]