Network Working Group E. Chen Internet-Draft Q. Zhao Intended status: Standards Track Huawei Technology Expires: April 27, 2012 October 25, 2011 Deploying mLDP through p2p LSP Tunnels draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00.txt Abstract Label Distribution Protocol (LDP) can be used to set up Point-to- Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a pair of LDP neighbors which support the P2MP/MP2MP capability are directly connected. However, the real deployment may not have all the nodes along the LSP path to be P2MP/MP2MP capable so that the CapEx of the deployment can be reduced or the deployment of the LDP P2MP/MP2MP can be in phases instead of updating the whole network. This document provides a solution for finding the first upstream node which supports the LDP P2MP/MP2MP along the path from the current node to the root node. 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 27, 2012. Copyright Notice Copyright (c) 2011 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 April 27, 2012 [Page 1] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 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 April 27, 2012 [Page 2] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification of requirements . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. mLDP deployment through p2p tunnels . . . . . . . . . . . . . 6 2.1. The signaling procedures for deploying mLDP through p2p tunnels . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Protocol extensions for deploying mLDP through p2p tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Chen & Zhao Expires April 27, 2012 [Page 3] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 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 This document provides a solution to setup LDP's P2MP and MP2MP LSPs in a network where where the mLDP LSP passes through nodes which is not mLDP capable. The Label Distribution Protocol (LDP) extensions for setting up Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This set of extensions is generally known as "Multipoint LDP" (mLDP). The term "Multipoint" means "either P2MP or MP2MP" normmally. In the deployment scenarios where the service providers wish to upgrade their network gradually by only making certain nodes of the existing network to be upgraded both on the control plane and forwarding plane and for the rest of the network nodes, they only require a minor signaling plan change while keeping the forwarding plan as same as before. This will reduce the CapEx for the users who doesn't need to update every nodes of their network to support the mLDP. The base specification for mLDP does not explicitly cover the case where the LDP multipoint extensions are used for over a path where the transit nodes along path to the root node don't support the mLDP capability. If LSR D is setting up the MP-LSP , D needs to determine the "upstream LSR" for . In [mLDP], the upstream LSR for , U, is defined to be the "next hop" on D's path to root R, and "next hop" is tacitly assumed to mean "IGP next hop". It is thus assumed that there is a direct LDP session between D and U. In the deployment scenario where the "IGP next hop" may not support the mLLDP fearure. In this specification, we specify a p2p tunnel through method which identifies an "upstream LSR" which is doesn't have the direct session with LSR D, but it is the first node on D's path to root R. Chen & Zhao Expires April 27, 2012 [Page 4] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 1.3. Overview +------------+ | R1 | mLDP node +------------+ / \ +-----------+ +-----------+ mLDP node | R2 | | R3 | p2p node +-----------+ +-----------+ \ +-----------+ | R4 | mLDP node +-----------+ / \ +-----------+ +-----------+ mLDP node | R5 | | R6 | mLDP node +-----------+ +-----------+ mLDP deployment issue when some nodes without mLDP capability Figure 1 In the figure above, the R4 nodes finds out that the upstream route R3 doesn't support mLDP, and there is no other upstream node which R4 can use as the upstream node to go to Root, then this mLDP LSP shown the picture above can not be setup. 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 dont support the mLDP but can propagate the notification 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. Chen & Zhao Expires April 27, 2012 [Page 5] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 2. mLDP deployment through p2p tunnels +------------+ | R1 | mLDP node +------------+ / \ +-----------+ +-----------+ mLDP node | R2 | | R3 | p2p node with mLDP +-----------+ +-----------+ tunnel through support \ +-----------+ | R4 | mLDP node +-----------+ / \ +-----------+ +-----------+ mLDP node | R5 | | R6 | mLDP node +-----------+ +-----------+ mLDP deployment through p2p tunnels Figure 2 In the figure above, when the R4 find out that the upstream route R3 support the mLDP in a p2p tunneled mode, and the R4 sends out the lapping mapping in a p2p tunnel format, and when the R3 receives this label mapping message, it will pass up this message to is upstream router R1. When R1 receives this able mapping message, it will setup one p2p tunnels which will make the R4 to chose R1 as the next hop to root for mLDP LSP setup. Chen & Zhao Expires April 27, 2012 [Page 6] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 +------------+ | R1 | mLDP node +------------+ / \ +-----------+ +-----------+ mLDP node | R2 | | R3 | mLDP node +-----------+ +-----------+ \ +-----------+ | R4 | p2p node with mLDP +-----------+ tunnel through support / \ +-----------+ +-----------+ mLDP node | R5 | | R6 | mLDP node +-----------+ +-----------+ mLDP deployment through p2p tunnels for branch node Figure 3 In the figure above, when the R6 and find out that the upstream router R4 supports the mLDP in a p2p tunneled mode, and the R4 is already in the tunnel mode for the mLDP LSP, then R6 will setup another p2p 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 using two p2p tunnels. 2.1. The signaling procedures for deploying mLDP through p2p tunnels o If LSR D is setting up the MP-LSP , D finds out that the direct connected "upstream LSR" for is not supporting mLDP. o The node D find the upstream node supporting mLDP in p2p tunneling-through mode capability from the upstream node for mLDP capability advertisement. o The node D send 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 sends an notification message to its upstream node until it reaches the node which support the full mLDP capability. o The fist node which has mLDP full capability receives this notification will setup LDP target LDP sessions with the the node D identified by the LSR-ID in the notification message. And at the same time, this first node tells that the node D identified by Chen & Zhao Expires April 27, 2012 [Page 7] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 the LSR-ID to chose this first node as the upstream router for the mLDP LSP setup. 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. 2.2. Protocol extensions for deploying mLDP through p2p tunnels A new type of LDP MP Status Value Element is introduced, for notifying upstream LSRs and about the LSR-ID and the root of the mLDP. The MP status element can use what defined in the draft of draft-mpls-ldp-p2mp-15 by adding two more element types, one of them is used to identify the root node address of the mLDP and another is used for identifying the LSR which needs the p2p tunnel to setup the mLDP lsp. It is encoded 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 | Length |capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mLDP LSP Through P2P Tunnel Status Code for LSR-ID Figure 4 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 | Length |capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | root-address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ mLDP LSP Through P2P Tunnel Status Code for root address Figure 5 Chen & Zhao Expires April 27, 2012 [Page 8] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 3. Acknowledgements We would like to thank authors of draft-ietf-mpls-mp-ldp-reqs and the authors of draft-ietf-mpls-ldp-multi-topology from which some text of this document has been inspired. 4. IANA Considerations This memo includes the following requests to IANA: o mLDP P2P Encapsulation type for LDP MP Status Value Element. 5. Security Considerations The same security considerations apply as for the base LDP specification, as described in [RFC5036]. 6. References 6.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. [I-D.ietf-mpls-ldp-p2mp] Minei, I., Wijnands, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-15 (work in progress), August 2011. [I-D.ietf-mpls-ldp-multi-topology] Chen & Zhao Expires April 27, 2012 [Page 9] Internet-Draft Deploying mLDP through p2p LSP Tunnels October 2011 Zhao, Q., Fang, L., Zhou, C., Li, L., So, N., and R. Torvi, "LDP Extension for Multi Topology Support", draft-ietf-mpls-ldp-multi-topology-00 (work in progress), October 2011. 6.2. Informative References [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003. Authors' Addresses Emily Chen Huawei Technology 2330 Central Expressway Santa Clara, CA 95050 US Email: emily.chenying@huawei.com Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: quintin.zhao@huawei.com Chen & Zhao Expires April 27, 2012 [Page 10]