--- 1/draft-ietf-mpls-mldp-hsmp-03.txt 2013-11-26 08:14:26.821068845 -0800 +++ 2/draft-ietf-mpls-mldp-hsmp-04.txt 2013-11-26 08:14:26.853069600 -0800 @@ -1,36 +1,35 @@ Network Working Group L. Jin Internet-Draft Intended status: Standards Track F. Jounay -Expires: April 19, 2014 France Telecom +Expires: May 30, 2014 France Telecom I. Wijnands - Cisco Systems + Cisco Systems, Inc N. Leymann - Deutsche Telekom - October 16, 2013 + Deutsche Telekom AG + November 26, 2013 LDP Extensions for Hub & Spoke Multipoint Label Switched Path - draft-ietf-mpls-mldp-hsmp-03.txt + draft-ietf-mpls-mldp-hsmp-04.txt Abstract - This draft introduces a hub & spoke multipoint LSP (or HSMP LSP for - short), which allows traffic both from root to leaf through P2MP LSP - and also leaf to root along the co-routed 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, and strictly - follows the downstream path of the tree rather than routing protocol - based unicast path to the root. + 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. 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 @@ -38,227 +37,194 @@ 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 19, 2014. + + This Internet-Draft will expire on May 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Time Synchronization Scenario . . . . . . . . . . . . . . 5 - 3.2. Virtual Private Multicast Service Scenario . . . . . . . . 5 - 3.3. IPTV Scenario . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 6 - 4.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 6 - 4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 7 - 4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 7 - 4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 8 - 4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 10 - 4.3.3. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . 10 - 5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11 - 7. Co-routed Path Exceptions . . . . . . . . . . . . . . . . . . 11 - 8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12 - 10.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12 - 10.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13 - 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 12.1. Normative references . . . . . . . . . . . . . . . . . . . 13 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction - The point-to-multipoint LSP defined in [RFC6388] allows traffic to - transmit from root to several leaf nodes, and multipoint-to- - multipoint LSP allows traffic from every node to transmit to every - other node. This draft introduces a hub & spoke multipoint LSP (or - HSMP LSP for short), which allows traffic both from root to leaf - through P2MP LSP and also leaf to root along the co-routed reverse - path. That means traffic entering the HSMP LSP at the root node - travels downstream, exactly as if it is travelling downstream along a - P2MP LSP, and traffic entering the HSMP LSP at any other node travels - upstream along the tree to the root. A packet travelling upstream - should be thought of as being unicast to the root, except that it - follows the path of the tree rather than routing protocol based - unicast path to the root. The combination of upstream LSPs initiated - from all leaf nodes forms a multipoint-to-point LSP. + 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. 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: - HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both - from root to leaf through P2MP LSP and also leaf to root along the - co-routed reverse path. - - mLDP: Multipoint extensions for LDP - - 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. - - PTP: The timing and synchronization protocol used by IEEE1588 - - P2MP LSP: An LSP that has one Ingress LSR and one or more Egress - LSRs. - -3. Applications - - In some cases, the P2MP LSP may not have a reply path for OAM - messages (e.g, LSP Ping Echo Request). If P2MP LSP is provided by - HSMP LSP instead, then the upstream path could be used as the OAM - message reply path. This is especially useful in the case of P2MP - LSP fault detection, performance measurement, root node redundancy - and etc. There are several other applications that could take - advantage of a LDP based HSMP LSP as described below. - -3.1. Time Synchronization Scenario - - [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. - It is required that the LSP used to transport PTP event message - between a Master Clock and a Slave Clock, and the LSP between the - same Slave Clock and Master Clock must be co-routed. Using point-to- - multipoint technology to transmit PTP event messages from Master - Clock at root side to Slave Clock at leaf side will greatly improve - the bandwidth usage. Unfortunately current point-to-multipoint LSP - only provides unidirectional path from root to leaf, which cannot - provides a co-routed reverse path for the PTP event messages. LDP - based HSMP LSP described in this draft provides unidirectional point- - to-multipoint LSP from root to leaf and co-routed reverse LSP from - leaf to root. - -3.2. Virtual Private Multicast Service Scenario + mLDP: Multipoint extensions for Label Distribution Protocol (LDP) + defined in [RFC6388]. - Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires - to set up reverse path from leaf node (referred as egress PE) to root - node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP - PW, the reverse path can also be multiplexed to HSMP upstream path to - avoid setup independent reverse path. In that case, the operational - cost will be reduced for maintaining only one HSMP LSP, instead of - P2MP LSP and n (number of leaf nodes) P2P reverse LSPs. + P2MP LSP: point-to-multipoint Label Switched Path. An LSP that + has one Ingress Label Switching Router (LSR) and one or more + Egress LSRs. - The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires - reverse path from leaf to root node. The P2MP PW multiplexed to HSMP - LSP can provide VPMS with reverse path, without introducing - independent reverse path from each leaf to root. + 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. -3.3. IPTV Scenario + 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. - The mLDP based HSMP LSP can also be applied in a typical IPTV - scenario. There is usually only one location with senders but there - are many receiver locations. If IGMP is used for signalling between - senders as IGMP querier [RFC3376] and receivers, the IGMP messages - from the receivers are travelling only from the leaves to the root - (and from root towards leaves) but not from leaf to leaf. In - addition traffic from the root is only replicated towards the leaves. - Then leaf node receiving IGMP report message (for source specific - multicast case) will join HSMP LSP(use similar mechanism in [RFC6826] - section 2), and then send IGMP report message upstream to root along - HSMP upstream LSP. Note that in above case, there is no node - redundancy for IGMP querier. And the node redundancy for IGMP - querier[RFC3376] could be provided by two independent VPMS instances - with HSMP applied. + PTP: precise time protocol. The timing and synchronization + protocol defined by IEEE1588. -4. Setting up HSMP LSP with LDP +3. Setting up HSMP LSP with LDP - HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the - difference that the leaf LSRs can only send traffic to root node - along the same path of traffic from root node to leaf node. + 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 - downstream path is same as MP2MP LSP, while the upstream path is only + downstream path is same as P2MP LSP, while the upstream path is only from leaf to root node, without communication between leaf and leaf nodes. The transmission of packets from the root node of an HSMP LSP - to the receivers is identical to that of a P2MP LSP. Traffic from a - leaf node follows the upstream path toward the root node, along a - path that traverse the same nodes as the downstream node, but in - reverse order. - - For setting up the upstream path of an HSMP LSP, ordered mode MUST be - used which is same as MP2MP. Ordered mode can guarantee a leaf to - start sending packets to root immediately after the upstream path is - installed, without being dropped due to an incomplete LSP. + to the receivers (the leaf nodes) is identical to that of a P2MP LSP. + Traffic from a leaf node to the root follows the upstream path that + is the reverse of the path from the root to the leaf. Unlike an + MP2MP LSP, traffic from a leaf node does not branch toward other leaf + nodes, but is sent direct to the root where it is placed on the P2MP + path and distributed to all leaf nodes including the original sender. - Due to much of similar behaviors between HSMP LSP and MP2MP LSP, the - following sections only describe the difference between the two - entities. + To set up the upstream path of an HSMP LSP, ordered mode MUST be + used. Ordered mode can guarantee a leaf to start sending packets to + root immediately after the upstream path is installed, without being + dropped due to an incomplete LSP. -4.1. Support for HSMP LSP Setup with LDP +3.1. Support for HSMP LSP Setup with LDP HSMP LSP requires the LDP capabilities [RFC5561] for nodes to indicate that they support setup of HSMP LSPs. An implementation supporting the HSMP LSP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization Messages. Advertisement of the HSMP LSP Capability indicates support of the procedures for HSMP LSP setup. A new Capability Parameter TLV is defined, the HSMP LSP Capability Parameter. Following is the format of the HSMP LSP Capability Parameter. 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| HSMP LSP Cap(TBD IANA) | Length | + |U|F| HSMP LSP Cap(TBD IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+ Figure 1. HSMP LSP Capability Parameter encoding + U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be + 1. The unknown TLV MUST be silently ignored and the rest of the + message processed as if the unknown TLV did not exist. + + F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value + of this bit MUST be 0 since a Capability Parameter TLV is sent only + in Initialization and Capability messages, which are not forwarded. + The length SHOULD be 1, and the S bit and reserved bits are defined in [RFC5561] section 3. The HSMP LSP Capability Parameter type is to be assigned by IANA. -4.2. HSMP FEC Elements + If the peer has not advertised the corresponding capability, then + label messages using the HSMP FEC Element SHOULD NOT be sent to the + peer. Since ordered mode is applied for HSMP LSP signalling, the + label message break would ensure that the initiating leaf node is + unable to establish the upstream path to root node. + +3.2. HSMP FEC Elements Similar as MP2MP LSP, we define two new protocol entities, the HSMP Downstream FEC Element and Upstream FEC Element. If a FEC TLV contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be the only FEC Element in the FEC TLV. The structure, encoding and error handling for the HSMP Downstream FEC Element and Upstream FEC - Element are the same as for the MP2MP FEC Element described in - [RFC6388] Section 3.2. The difference is that two additional new FEC - types are defined: HSMP Downstream FEC (TBD, IANA) and HSMP Upstream - FEC(TBD, IANA). + Element are the same as for the P2MP FEC Element described in + [RFC6388] Section 2.2. The difference is that two additional new FEC + types are defined: HSMP Downstream FEC (to be assigned by IANA) and + HSMP Upstream FEC (to be assigned by IANA). -4.3. Using the HSMP FEC Elements +3.3. Using the HSMP FEC Elements In order to describe the message processing clearly, the entries in the list below define the processing of the HSMP FEC Elements. Additionally, the entries defined in [RFC6388] section 3.3 are also reused in the following sections. 1. HSMP downstream LSP (or simply downstream ): an HSMP LSP downstream path with root node address X and opaque value Y. 2. HSMP upstream LSP (or simply upstream ): an HSMP LSP @@ -275,134 +241,238 @@ 5. HSMP-D Label Mapping : A Label Mapping message with a single HSMP downstream FEC Element and label TLV with label L. Label L MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message. 6. HSMP-U Label Mapping : A Label Mapping message with a single HSMP upstream FEC Element and label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message. -4.3.1. HSMP LSP Label Map + 7. HSMP-D Label Withdraw : a Label Withdraw message with a + FEC TLV with a single HSMP downstream FEC Element and label + TLV with label L. + + 8. HSMP-U Label Withdraw : a Label Withdraw message with a + FEC TLV with a single HSMP upstream FEC Element and label TLV + with label Lu. + + 9. HSMP-D Label Release : a Label Release message with a + FEC TLV with a single HSMP downstream FEC Element and Label + TLV with label L. + + 10. HSMP-U Label Release : a Label Release message with a + FEC TLV with a single HSMP upstream FEC Element and label TLV + with label Lu. + +3.4. HSMP LSP Label Map This section specifies the procedures for originating HSMP Label Mapping messages and processing received HSMP Label Mapping messages for a particular HSMP LSP. The procedure of downstream HSMP LSP is - same as that of downstream MP2MP LSP described in [RFC6388]. When + similar as that of downstream MP2MP LSP described in [RFC6388]. When LDP operates in Ordered Label Distribution Control mode [RFC5036], the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping message with a label which is allocated by upstream LSR to its downstream LSR hop by hop from root to leaf node, installing the upstream forwarding table by every node along the LSP. The detail procedure of setting up upstream HSMP LSP is different with that of upstream MP2MP LSP, and is specified in below section. All labels discussed here are downstream-assigned [RFC5332] except - those which are assigned using the procedures described in section 5. + those which are assigned using the procedures described in Section 4. Determining the upstream LSR for the HSMP LSP follows the - procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. + procedure for a P2MP LSP described in [RFC6388] Section 2.4.1.1. - Determining one's HSMP downstream LSR follows the procedure defined - in [RFC6388] section 3.3.1.2. That is, an upstream LDP peer which + That is, a node Z that wants to join an HSMP LSP determines + the LDP peer U that is Z's next-hop on the best path from Z to the + root node X. If there are multiple upstream LSRs, local algorithm + should be applied to ensure that there is a single upstream LSRs for + a particular LSP. + + To determining one's HSMP downstream LSR, an upstream LDP peer which receives a Label Mapping with HSMP downstream FEC Element from an LDP peer D will treat D as HSMP downstream LDP peer. - Determining the forwarding interface to an LSR follows the procedure - as defined in [RFC6388] section 2.4.1.2. +3.4.1. HSMP LSP Leaf Node Operation -4.3.1.1. HSMP LSP Leaf Node Operation + The leaf node operation is much the same as the operation of MP2MP + LSP defined in [RFC6388] Section 3.3.1.4. The only difference is the + FEC elements as specified below. - The leaf node operation is same as the operation of MP2MP LSP defined - in [RFC6388] section 3.3.1.4. The only difference is the FEC - elements as specified below. + A leaf node Z of an HSMP LSP determines its upstream LSR U for + as per Section 3.3, allocates a label L, and sends an HSMP-D + Label Mapping to U. Leaf node Z expects an HSMP-U Label + Mapping from node U and checks whether it already has + forwarding state for upstream . If not, Z creates forwarding + state to push label Lu onto the traffic that Z wants to forward over + the HSMP LSP. How it determines what traffic to forward on this HSMP + LSP is outside the scope of this document. - A leaf node Z will send an HSMP-D Label Mapping to U, - instead of MP2MP-D Label Mapping , and expects an HSMP-U - Label Mapping from node U and checks whether it already - has forwarding state for upstream . The created forwarding - state on leaf node Z is same as the leaf node of MP2MP LSP. Z will - push label Lu onto the traffic that Z wants to forward over the HSMP - LSP. +3.4.2. HSMP LSP Transit Node Operation -4.3.1.2. HSMP LSP Transit Node Operation + The procedure of HSMP-D Label Mapping message is much the same as + processing MP2MP-D Label Mapping message defined in [RFC6388] Section + 3.3.1.5. The processing of HSMP-U Label Mapping message is different + with that of MP2MP-U Label Mapping message as specified below. - Suppose node Z receives an HSMP-D Label Mapping from LSR D, - the procedure is much the same as processing MP2MP-D Label Mapping - message defined in [RFC6388] section 3.3.1.5, and the processing - protocol entity is HSMP-D Label Mapping message. The only difference - is specified below. + Suppose node Z receives an HSMP-D Label Mapping from LSR D. + Z checks whether it has forwarding state for downstream . If + not, Z determines its upstream LSR U for as per Section 3.3. + Using this Label Mapping to update the label forwarding table MUST + NOT be done as long as LSR D is equal to LSR U. If LSR U is different + from LSR D, Z will allocate a label L' and install downstream + forwarding state to swap label L' with label L over interface I + associated with LSR D and send an HSMP-D Label Mapping to + U. Interface I is determined via the procedures in Section 3.7. + + If Z already has forwarding state for downstream , all that Z + needs to do in this case is check that LSR D is not equal to the + upstream LSR of and update its forwarding state. Assuming its + old forwarding state was L'-> { ..., }, its + new forwarding state becomes L'-> { ..., , + }. If the LSR D is equal to the installed upstream LSR, the + Label Mapping from LSR D MUST be retained and MUST NOT update the + label forwarding table. Node Z checks if upstream LSR U already has assigned a label Lu to upstream . If not, transit node Z waits until it receives an HSMP-U Label Mapping from LSR U. Once the HSMP-U Label Mapping is received from LSR U, node Z checks whether it already has forwarding state upstream with incoming label Lu' and outgoing - label Lu. If it does, Z sends an HSMP-U Label Mapping to - downstream node. If it does not, it allocates a label Lu' and - creates a new label swap for Lu' with Label Lu over interface Iu. - Interface Iu is determined via the procedures in section 4.3.1. Node - Z determines the downstream HSMP LSR as per section 4.3.1, and sends - an HSMP-U Label Mapping to node D. + label Lu. If it does not, it allocates a label Lu' and creates a new + label swap for Lu' with Label Lu over interface Iu. Interface Iu is + determined via the procedures in Section 3.7. Node Z determines the + downstream HSMP LSR as per Section 4.3.1, and sends an HSMP-U Label + Mapping to node D. Since a packet from any downstream node is forwarded only to the upstream node, the same label (representing the upstream path) SHOULD be distributed to all downstream nodes. This differs from the procedures for MP2MP LSPs [RFC6388], where a distinct label must be distributed to each downstream node. The forwarding state upstream on node Z will be like this {, }. Iu means the upstream interface over which Z receives HSMP-U Label Map from LSR U. Packets from any downstream interface over which Z sends HSMP-U Label Map with label Lu' will be forwarded to Iu with label Lu' swap to Lu. -4.3.1.3. HSMP LSP Root Node Operation +3.4.3. HSMP LSP Root Node Operation - Suppose root node Z receives an HSMP-D Label Mapping from - node D, the procedure is much the same as processing MP2MP-D Label - Mapping message defined in [RFC6388] section 3.3.1.6, and the - processing protocol entity is HSMP-D Label Mapping message. The only - difference is specified below. + The procedure of HSMP-D Label Mapping message is much the same as + processing MP2MP-D Label Mapping message defined in [RFC6388] Section + 3.3.1.6. The processing of HSMP-U Label Mapping message is different + with that of MP2MP-U Label Mapping message as specified below. + + Suppose the root node Z receives an HSMP-D Label Mapping + from node D. Z checks whether it already has forwarding state for + downstream . If not, Z creates downstream forwarding state and + installs a outgoing label L over interface I. Interface I is + determined via the procedures in Section 3.7. If Z already has + forwarding state for downstream , then Z will add label L over + interface I to the existing state. Node Z checks if it has forwarding state for upstream . If not, Z creates a forwarding state for incoming label Lu' that - indicates that Z is the LSP egress. E.g., the forwarding state might - specify that the label stack is popped and the packet passed to some - specific application. Node Z determines the downstream HSMP LSR as - per section 4.3.1, and sends an HSMP-U Label Map to node - D. + indicates that Z is the HSMP LSP egress LER. E.g., the forwarding + state might specify that the label stack is popped and the packet + passed to some specific application. Node Z determines the + downstream HSMP LSR as per Section 3.3, and sends an HSMP-U Label Map + to node D. Since Z is the root of the tree, Z will not send an HSMP-D Label Map and will not receive an HSMP-U Label Mapping. -4.3.2. HSMP LSP Label Withdraw + Root node could also be a leaf node, and it is able to determine what + traffic to forward on this HSMP LSP which is outside the scope of + this document. - The HSMP Label Withdraw procedure is much the same as MP2MP leaf - operation defined in [RFC6388] section 3.3.2, and the processing FEC - Elements are HSMP FEC Elements. The only difference is the process - of HSMP-U Label Release message, which is specified below. +3.5. HSMP LSP Label Withdraw - When a transit node Z receives an HSMP-U Label Release message from - downstream node D, Z should check if there are any incoming interface - in forwarding state upstream . If all downstream nodes are - released and there is no incoming interface, Z should delete the - forwarding state upstream and send HSMP-U Label Release - message to its upstream node. Otherwise, no HSMP-U Label Release - message will be sent to the upstream node. +3.5.1. HSMP Leaf Operation -4.3.3. HSMP LSP Upstream LSR Change + If a leaf node Z discovers that it has no need to be an Egress LSR + for that LSP (by means outside the scope of this document), then it + SHOULD send an HSMP-D Label Withdraw to its upstream LSR U + for , where L is the label it had previously advertised to U + for . Leaf node Z will also send an unsolicited HSMP-U Label + Release to U to indicate that the upstream path is no + longer used and that label Lu can be removed. + + Leaf node Z expects the upstream router U to respond by sending a + downstream Label Release for L. + +3.5.2. HSMP Transit Node Operation + + If a transit node Z receives an HSMP-D Label Withdraw message from node D, it deletes label L from its forwarding state + downstream . Node Z sends an HSMP-D Label Release message with + label L to D. There is no need to send an HSMP-U Label Withdraw to D because node D already removed Lu and sent a label + release for Lu to Z. + + If deleting L from Z's forwarding state for downstream results + in no state remaining for , then Z propagates the HSMP-D Label + Withdraw to its upstream node U for . Z should also + check if there are any incoming interface in forwarding state + upstream . If all downstream nodes are released and there is + no incoming interface, Z should delete the forwarding state upstream + and send HSMP-U Label Release message to its upstream node. + Otherwise, no HSMP-U Label Release message will be sent to the + upstream node. + +3.5.3. HSMP Root Node Operation + + When the root node of an HSMP LSP receives an HSMP-D Label Withdraw + and HSMP-U Label Release message, the procedure is the same as that + for transit nodes, except that the root node will not propagate the + Label Withdraw and Label Release upstream (as it has no upstream). + +3.6. HSMP LSP Upstream LSR Change The procedure for changing the upstream LSR is the same as defined in - [RFC6388] section 3.3.3, only with different processing FEC Element, - the HSMP FEC Element. + [RFC6388] Section 2.4.3, only with different processing FEC Element. -5. HSMP LSP on a LAN + When the upstream LSR changes from U to U', node Z should set up the + HSMP LSP to U' by applying procedures in Section 3.4. Z will + also remove HSMP LSP to U by applying procedure in Section + 3.5. + + To set up HSMP LSP to U' before/after removing HSMP LSP to U is a + local matter, and the recommended default behavior is to remove + before adding. + +3.7. Determining Forwarding Interface + + The co-routed path between upstream and downstream LSP would be + achieved for HSMP LSP. Both LSR U and LSR D would ensure the same + interface to send traffic by applying some procedures. For a network + with symmetric IGP cost configuration, the following procedure MAY be + used. To determine the downstream interface, LSR U MUST do a lookup + in the unicast routing table to find the best interface and next-hop + to reach LSR D. If the next-hop and interface are also advertised by + LSR D via the LDP session, it should be used to transmit the packet + to LSR D. Determine the upstream interface mechanism is same as + determining the downstream interface by exchanging the role of LSR U + and LSR D. If symmetric IGP cost could not be ensured, static route + configuration on LSR U and D could also be a possible way to ensure + co-routed path. + + If co-routed is not required for HSMP LSP, the procedure defined in + [RFC6388] Section 2.4.1.2 could be applied. LSR U is free to + transmit the packet on any of the interfaces to LSR D. The algorithm + it uses to choose a particular interface is a local matter. + Determine the upstream interface mechanism is the same as determining + the downstream interface. + +4. HSMP LSP on a LAN The procedure to process the downstream HSMP LSP on a LAN is much the same as downstream MP2MP LSP described in [RFC6388] section 6.1.1. When establishing the downstream path of an HSMP LSP, as defined in [RFC6389], a Label Request message for an LSP label is sent to the upstream LSR. The upstream LSR should send Label Mapping message that contains the LSP label for the downstream HSMP FEC and the upstream LSR context label defined in [RFC5331]. When the LSR forwards a packet downstream on one of those LSPs, the packet's top @@ -413,130 +483,120 @@ forwarded downstream using this forwarding state based on a two-label lookup. 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. -6. Redundancy Considerations +5. Redundancy Considerations In some scenario, 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. -7. Co-routed Path Exceptions - - There are some exceptional cases when mLDP based HSMP LSP could not - achieve co-routed path. One possible case is using static routing - between LDP neighbors; another possible case is IGP cost asymmetric - generated by physical link cost asymmetric, or TE-Tunnels used - between LDP neighbors. The LSR/LER in HSMP LSP should detect if the - path is co-routed or not. If not co-routed, an alarm indication - should be generated to the management system. - -8. Failure Detection of HSMP LSP +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 co-routed upstream path of HSMP LSP, and end on the root - that are the (intended) root node. + 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. The node processing mechanism of LSP Ping Echo Request and Echo Reply - for HSMP LSP is inherited from [RFC6425] and [RFC6426] section 3.4, + 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 send the LSP Ping Echo Reply to the associated HSMP upstream path. The Reverse-path Target FEC Stack TLV attached by leaf node in Echo Reply message SHOULD contain the sub-TLV of associated HSMP upstream FEC. -9. Security Considerations +7. Security Considerations The same security considerations apply as for the MP2MP LSP described in [RFC6388] and [RFC6425]. Although this document introduces new FEC Elements and corresponding procedures, the protocol does not bring any new security issues compared to [RFC6388] and [RFC6425]. -10. IANA Considerations +8. IANA Considerations -10.1. New LDP FEC Element types +8.1. New LDP FEC Element types This document requires allocation of two new LDP FEC Element types from the "Label Distribution Protocol (LDP) Parameters registry" the "Forwarding Equivalence Class (FEC) Type Name Space": 1. the HSMP-upstream FEC type - requested value TBD 2. the HSMP-downstream FEC type - requested value TBD The values should be allocated using the lowest free values from the "IETF Consensus"-range (0-127). -10.2. HSMP LSP capability TLV +8.2. HSMP LSP capability TLV This document requires allocation of one new code points for the HSMP LSP capability TLV from "Label Distribution Protocol (LDP) Parameters registry" the "TLV Type Name Space": 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. -10.3. New sub-TLVs for the Target Stack TLV +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). 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. -11. Acknowledgement +9. Acknowledgement The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable comments. -12. References +10. References -12.1. Normative references +10.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. @@ -554,21 +614,21 @@ [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 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. -12.2. Informative References +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