--- 1/draft-ietf-mpls-mldp-hsmp-04.txt 2013-12-11 07:14:28.352793333 -0800 +++ 2/draft-ietf-mpls-mldp-hsmp-05.txt 2013-12-11 07:14:28.384794188 -0800 @@ -1,35 +1,36 @@ Network Working Group L. Jin Internet-Draft Intended status: Standards Track F. Jounay -Expires: May 30, 2014 France Telecom +Expires: June 14, 2014 France Telecom I. Wijnands Cisco Systems, Inc N. Leymann Deutsche Telekom AG - November 26, 2013 + December 11, 2013 LDP Extensions for Hub & Spoke Multipoint Label Switched Path - draft-ietf-mpls-mldp-hsmp-04.txt + draft-ietf-mpls-mldp-hsmp-05.txt Abstract This draft introduces a hub & spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic both from root to leaf through point-to-multipoint (P2MP) LSP and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream to each leaf node, exactly as if it is travelling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it is unicast - to the root. The communication among the leaf nodes are not allowed. + to the root. Direct communication among the leaf nodes is not + allowed. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -37,87 +38,86 @@ 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 May 30, 2014. + This Internet-Draft will expire on June 14, 2014. Copyright Notice Copyright (c) 2013 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4 - 3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4 - 3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5 - 3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 6 - 3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 7 - 3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7 - 3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 8 - 3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9 - 3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9 - 3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9 - 3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 9 - 3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 10 - 3.7. Determining Forwarding Interface . . . . . . . . . . . . . 10 - 4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11 - 6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12 - 8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12 - 8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13 - 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 + 3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 5 + 3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6 + 3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6 + 3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 7 + 3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 8 + 3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 8 + 3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 9 + 3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 10 + 3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 10 + 3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 10 + 3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 10 + 3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 11 + 3.7. Determining Forwarding Interface . . . . . . . . . . . . . 11 + 4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 12 + 6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 13 + 8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 13 + 8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 14 + 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 10.1. Normative references . . . . . . . . . . . . . . . . . . . 14 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in [RFC6388] allows traffic to transmit from root to several leaf nodes, and multipoint-to-multipoint (MP2MP) LSP allows traffic from every node to transmit to every other node. This draft introduces a hub & spoke multipoint (HSMP) LSP, which has one root node and one or more leaf nodes. HSMP LSP allows traffic both from root to leaf through downstream LSP and also leaf to root along the upstream LSP. That means traffic entering the HSMP LSP at the root node travels along downstream LSP, exactly as if it is travelling along a P2MP LSP, and traffic entering the HSMP LSP at any other leaf nodes travels along upstream LSP toward only the root node. The upstream LSP should be thought of unicast LSP to the root node, except that it follows the - node of reverse downstream path of the tree, rather than routing - protocol based unicast path. The combination of upstream LSPs - initiated from all leaf nodes forms a multipoint-to-point LSP. + reverse direction of the downstream LSP, rather than routing protocol + based unicast path. The combination of upstream LSPs initiated from + all leaf nodes forms a multipoint-to-point LSP. 2. Terminology 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]. This document uses some terms and acronyms as follows: mLDP: Multipoint extensions for Label Distribution Protocol (LDP) @@ -129,23 +129,20 @@ MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others. HSMP LSP: hub & spoke multipoint Label Switched Path. An LSP that has one root node and one or more leaf nodes, allows traffic from root to all leaf nodes along downstream P2MP LSP and also leaf to root node along the upstream unicast LSP. - PTP: precise time protocol. The timing and synchronization - protocol defined by IEEE1588. - 3. Setting up HSMP LSP with LDP HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the difference that, when the leaf LSRs send traffic on the LSP, the traffic is first delivered only to the root node and follows the upstream path from the leaf node to the root node. The root node then distributes the traffic on the P2MP tree to all of the leaf nodes. HSMP LSP consists of a downstream path and upstream path. The @@ -485,44 +481,44 @@ The upstream path of an HSMP LSP on a LAN is the same as the one on other kind of links. That is, the upstream LSR must send Label Mapping message that contains the LSP label for upstream HSMP FEC to downstream node. Packets travelling upstream need to be forwarded in the direction of the root by using the label allocated for upstream HSMP FEC. 5. Redundancy Considerations - In some scenario, it is necessary to provide two root nodes for + In some scenarios, it is necessary to provide two root nodes for redundancy purpose. One way to implement this is to use two independent HSMP LSPs acting as active/standby. At one time, only one HSMP LSP will be active, and the other will be standby. After detecting the failure of active HSMP LSP, the root and leaf nodes will switch the traffic to the standby HSMP LSP which takes on the role as active HSMP LSP. The detail of redundancy mechanism is out of the scope. 6. Failure Detection of HSMP LSP The idea of LSP ping for HSMP LSPs could be expressed as an intention to test the LSP Ping Echo Request packets that enter at the root along a particular downstream path of HSMP LSP, and end their MPLS path on the leaf. The leaf node then sends the LSP Ping Echo Reply along the upstream path of HSMP LSP, and end on the root that are the (intended) root node. New sub-TLVs are required to be assigned by IANA in Target FEC Stack - TLV to define the corresponding HSMP-upstream FEC type and HSMP- - downstream FEC type. In order to ensure the leaf node to send the - LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate - Reverse Path) in Global Flags Field defined in [RFC6426] is reused - here. + TLV and Reverse-path Target FEC Stack TLV to define the corresponding + HSMP-downstream FEC type and HSMP-upstream FEC type. In order to + ensure the leaf node to send the LSP Ping Echo Reply along the HSMP + upstream path, the R bit (Validate Reverse Path) in Global Flags + Field defined in [RFC6426] is reused here. The node processing mechanism of LSP Ping Echo Request and Echo Reply for HSMP LSP is inherited from [RFC6425] and [RFC6426] Section 3.4, except the following: 1. The root node sending LSP Ping Echo Request message for HSMP LSP MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit to '1' in Global Flags Field. 2. When the leaf node receiving the LSP Ping Echo Request, it MUST @@ -563,21 +559,21 @@ HSMP LSP Capability Parameter - requested value TBD The value should be allocated from the range 0x0901-0x3DFF (IETF Consensus) using the first free value within this range. 8.3. New sub-TLVs for the Target Stack TLV This document requires allocation of two new sub-TLV types for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV - type 1). + type 1) and Reverse-path Target FEC Stack TLV (TLV type 16). 1. the HSMP-upstream LDP FEC Stack - requested value TBD 2. the HSMP-downstream LDP FEC Stack - requested value TBD The value should be allocated from the IETF Standards Action range (0-16383) that is used for mandatory and optional sub-TLVs that requires a response if not understood. The value should be allocated using the lowest free value within this range. @@ -616,59 +612,27 @@ S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011. [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. 10.2. Informative References - [I-D.ietf-l2vpn-vpms-frmwk-requirements] - Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., - and L. Jin, "Framework and Requirements for Virtual - Private Multicast Service (VPMS)", - draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in - progress), October 2012. - - [I-D.ietf-pwe3-p2mp-pw] - Sivabalan, S., Boutros, S., and L. Martini, "Signaling - Root-Initiated Point-to-Multipoint Pseudowire using LDP", - draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. - - [I-D.ietf-tictoc-1588overmpls] - Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. - Montini, "Transporting Timing messages over MPLS - Networks", draft-ietf-tictoc-1588overmpls-05 (work in - progress), June 2013. - - [IEEE1588] - "IEEE standard for a precision clock synchronization - protocol for networked measurement and control systems", - IEEE1588v2 , March 2008. - - [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. - Thyagarajan, "Internet Group Management Protocol, Version - 3", RFC 3376, October 2002. - [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. - [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, - "Multipoint LDP In-Band Signaling for Point-to-Multipoint - and Multipoint-to-Multipoint Label Switched Paths", - RFC 6826, January 2013. - Authors' Addresses Lizhong Jin Shanghai, China Email: lizho.jin@gmail.com Frederic Jounay France Telecom 2, avenue Pierre-Marzin