Network Working Group L. Jin Internet-Draft ZTE Intended status: Standards Track L. Liu Expires: September 2, 2010 Nokia Siemens March 1, 2010 Leaf discovery mechanism for mLDP based P2MP/MP2MP LSP draft-jin-mpls-mldp-leaf-discovery-00.txt Abstract This document describes a mechanism for an mLDP based P2MP/MP2MP LSP root node to discover the leaf nodes information. This allows the root node gets the full information of the leaf node for one specified P2MP/MP2MP LSP. Such kind of function provides a general method for mLDP based P2MP/MP2MP LSP leaf node discovery, which will be used for multiplexing/aggregation by various mLDP applications, e.g, P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast] and etc. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Jin et al. Expires September 2, 2010 [Page 1] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Leaf discovery mechanism . . . . . . . . . . . . . . . . . . . 5 4.1. Leaf node identifier encoding . . . . . . . . . . . . . . . 5 4.2. Leaf operation status TLV encoding . . . . . . . . . . . . 6 4.3. Node operation . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative references . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Jin et al. Expires September 2, 2010 [Page 2] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 1. Introduction This document proposes a general mechanism for the mLDP based P2MP/ MP2MP LSP root node to discover the leaf nodes information. Such a general mechanism can be used for multiplexing/aggregation by various mLDP applications, e.g, P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast] and etc. In order to impact the mLDP scalability as little as possible, this draft provides a discovery mechanism based on a singling session between each leaf and root node. Each leaf node will report the leaf node information to root node through this signaling session. There will be two signaling protocols to be used for leaf node discovery, target LDP [RFC5036] or BGP auto-discovery using BGP Multiprotocol Extensions [RFC4760]. In order to make the solution simple and clear without introducing other protocol to mLDP, this draft will only focuses on the singling protocol based on target LDP. Other signaling protocol solutions are out of the scope of this draft. 2. Motivation [I-D.draft-ietf-mpls-ldp-p2mp] describes the mechanism of setting up mLDP based P2MP/MP2MP LSP. There is a management limitation for mLDP that none of the members belong to P2MP/MP2MP LSP topology does not know all the members of the P2MP/MP2MP LSP. That means the root node can not get the whole P2MP/MP2MP LSP member information from any of node. This problem will cause some multiplexing/aggregation limitation for mLDP applications. [I-D.draft-ietf-l2vpn-vpls-mcast] describes the mechanism of setting up multicast tree in VPLS. When setting up a inclusive P-Multicast tunnel, BGP A-D is used to do the VPLS membership auto-discovery. The mLDP based P2MP/MP2MP LSP will be set up when receiving auto- discovery routes through BGP A-D. The root node will only know the mLDP LSP leaf node information which is triggered by the specific BGP A-D mechanism. If there does already exist an mLDP based P2MP/MP2MP LSP_a (this LSP is not set up by BGP A-D, but maybe by static configuration) on root node, and the mLDP based LSP_a has same leaf nodes as the LSP that above VPLS multicast BGP A-D tries to set up. But the root node does not know the original mLDP based LSP_a leaf node information, and it will set up mLDP based LSP_b triggered by BGP A-D with same root and leaf nodes . This causes mLDP based LSP resources waste in the network. It is not necessary to setup two non-TE LSPs with same root and leaves at the same time in one network. Then multicast VPLS can only aggregate to mLDP P2MP/MP2MP LSP which is triggered by its own BGP A-D mechanism. There is a similar problem for [I-D.draft-ietf-l3vpn-2547bis-mcast], and L3VPN Jin et al. Expires September 2, 2010 [Page 3] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 multicast can only aggregate to mLDP P2MP/MP2MP LSP which is triggered by its own BGP A-D mechanism. [I-D.draft-martini-pwe3-p2mp-pw] describes the P2MP PW setup and signaling mechanism. P2MP PW needs P2MP LSP to do multiplexing/ demultiplexing [I-D.draft-ietf-pwe3-p2mp-pw-requirements], then root node should determine whether this P2MP PW can multiplex to one of the already existing P2MP LSP. If mLDP is used to setup P2MP LSP, the root node is required to know leaf node information of mLDP based P2MP LSP, then it can determine if there is some leaf overlap between P2MP PW and P2MP LSP. According to the draft, the mLDP based P2MP LSP will be triggered by label mapping message on leaf node, hence root node will get the mLDP based P2MP LSP leaf nodes information through LDP label mapping message. However, root node of mLDP based P2MP LSP does not know any of the leaf node information if the P2MP LSP is setup by other application, e.g, static configuration. Then P2MP PW can only multiplex to mLDP P2MP/MP2MP LSP which is triggered by LDP label mapping message. According to the above analysis, the mLDP based P2MP/MP2MP LSP setup by various applications can not be shared for multiplexing/ aggregation with each other. The introduced general leaf discovery mechanism for mLDP based P2MP/MP2MP LSP will assist various applications to share one P2MP/MP2MP LSP for multiplexing/ aggregation. 3. Terminology mLDP: Multicast LDP. T-LDP: Target LDP. P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs. MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR. MP2MP LSP: An LSP that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others. Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs. Ingress LSR: Source of the P2MP LSP, also referred to as root node. Egress LSR: One of potentially many destinations of an LSP, also Jin et al. Expires September 2, 2010 [Page 4] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 referred to as leaf node in the case of P2MP and MP2MP LSPs. Transit LSR: An LSR that has one or more directly connected downstream LSRs. Leaf node: A Leaf node can be either an Egress or Bud LSR when referred in the context of a P2MP LSP. In the context of a MP2MP LSP, an LSR is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR. P2MP FEC: The P2MP FEC Element consists of the address of the root of the P2MP LSP and an opaque value. MP2MP FEC: MP2MP FEC consists of MP2MP downstream FEC and upstream FEC Element. MP FEC: Includes both P2MP FEC and MP2MP FEC. 4. Leaf discovery mechanism This section will introduce the discovery mechanism based on T-LDP session. Each leaf node will report the leaf node information to root through this T-LDP session. Each leaf node will setup a T-LDP session with root node if there is no LDP session between leaf node and root node. 4.1. Leaf node identifier encoding A leaf node identifier will uniquely identify a leaf node in the MPLS network. A new opaque value can be defined in P2MP/MP2MP FEC Element to identify the leaf node, see the figure below. 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(TBD) | Length | Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Family |Address Length | Leaf Node Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Leaf Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Type: this type of opaque value is to be assigned by IANA. Jin et al. Expires September 2, 2010 [Page 5] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 Length: The length of address value, determined by the address type. Address Family: two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC 3232] that encodes the address family. Address Length: Length of the Leaf Node Address in octets. Leaf Node Address: A host address encoded according to the Address Family field. To be noted that the type means that it is the leaf node address for this P2MP/MP2MP FEC. The leaf node identifier MUST be attached together with P2MP/MP2MP FEC Element if leaf discovery mechanism described in this draft is required. 4.2. Leaf operation status TLV encoding There will be two operations for leaf node, add and delete. It is necessary to define a new "leaf node identifier" operation status TLV for LDP notification messages. The operation status TLV is defined from the LDP MP Status Value Element, see the figure below. 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(TBD) | Length | add/delete | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Type: this type of LDP MP status value element is to be assigned by IANA. Length: 1 octet for the value. Value: 0x01 (to be assigned by IANA): means add operation of "leaf node identifier"; 0x02 (to be assigned by IANA): means delete operation of "leaf node identifier"; When the notification message contains the "leaf node identifier" operation status TLV, the LDP MP FEC TLV MUST also be included in the message. When the node receives the notification with "leaf node identifier" operation status TLV, but without LDP MP FEC TLV, an LDP notification with "missing message parameters" status (code 0x16) should be generated. The format of Notification message is same as Jin et al. Expires September 2, 2010 [Page 6] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 section 6.2 of [I-D.draft-ietf-mpls-ldp-p2mp-08]. 4.3. Node operation The mLDP based P2MP/MP2MP LSP leaf discovery mechanism can be operated as follows. For every leaf node, there will be a T-LDP session to be setup between root and leaf node. This T-LDP session can be setup automatically or manually, which depends on specific implememtation. The leaf node can automatically initiate T-LDP session with root node. When root node receives target-hello, it can actively send target-hello to leaf node, so as to setup T-LDP session automatically. When the leaf node is triggered to join one P2MP LSP, by various applications, the leaf node sends label mapping message to its upstream node (root or transit node). At the same time, the leaf node sends LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "add" to its root node. When the root node receives the LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "add", it will store the leaf node information associated with the specified P2MP/MP2MP LSP locally. When the leaf node is triggered to leave one P2MP/MP2MP LSP, by various applications, the leaf node sends label withdraw message to its upstream node (root or transit node). At the same time, the leaf node sends LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "delete" to its root node. When the root node receives the LDP notification message with MP FEC attached with "leaf node identifiers" and operation status TLV "delete", it will delete the leaf node information associated with the specified P2MP/MP2MP LSP locally. If the LSR receives the label mapping/withdraw message with "leaf node identifiers", it will ignore this opaque value or send an LDP notification message to the downstream node with "Unknown TLV" status (code 0x06). 5. Security Considerations The same security considerations apply as for the multicast LDP specification, as described in [I-D. draft-ietf-mpls-ldp-p2mp]. Jin et al. Expires September 2, 2010 [Page 7] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 6. IANA Considerations This document creates a new name space (the LDP MP Opaque Value Element type) that is to be managed by IANA, and the allocation of the value for leaf operation status "add/delete". This document requires allocation of one opaque value type: 1. Leaf node identifier type "C requested value 0x03 This document requires allocation of one LDP MP status TLV type: 1. Leaf operation status TLV "C requested value 0x01 7. Acknowledgement The author would like to thank IJsbrand Wijnands, Sandeep Bishnoi and Frederic Jounay for there valuable comments. 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232 , January 2002. [RFC4760] Bates, T., "Multiprotocol Extensions for BGP-4", RFC4760 , January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036 , October 2007. 8.2. Informative References [I-D. draft-ietf-l2vpn-vpls-mcast] Aggarwal, R., Kamite, Y., and L. Fang, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-05 (work in progress), July 2009. [I-D. draft-ietf-l3vpn-2547bis-mcast] Rosen, E. and R. Aggarwal, "Multicast in 2547 VPNs", draft-ietf-l3vpn-2547bis-mcast-08 (work in progress), November 2009. [I-D. draft-ietf-mpls-ldp-p2mp] Jin et al. Expires September 2, 2010 [Page 8] Internet-Draft draft-jin-mpls-mldp-leaf-discovery March 2010 Minei, I., Kompella, K., and I. Wijnands, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp (work in progress), October 2009. [I-D. draft-ietf-pwe3-p2mp-pw-requirements] Jounay, F., Kamite, Y., Martini, L., Aggarwal, R., Delord, S., Bocci, M., Wang, L., Jin, L., and G. Heron, "Requirements for Point to Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-02.txt (work in progress), January 2009. [I-D. draft-martini-pwe3-p2mp-pw] Martini, L., Jounay, F., Vecchio, G., Delord, S., Jin, L., and L. Ciavaglia, "Signaling Root-Initiated Point-to- Multipoint Pseudowires using LDP", draft-martini-pwe3-p2mp-pw-01 (work in progress), October 2009. Authors' Addresses Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Kebo Liu Nokia Siemens Networks 1122 North Qinzhou Road Shanghai, 200233, China Email: kebo.liu@nsn.com Jin et al. Expires September 2, 2010 [Page 9]