draft-ietf-mpls-mldp-hsmp-01.txt   draft-ietf-mpls-mldp-hsmp-02.txt 
Network Working Group L. Jin Network Working Group L. Jin
Internet-Draft Internet-Draft
Intended status: Standards Track F. Jounay Intended status: Standards Track F. Jounay
Expires: October 20, 2013 France Telecom Expires: April 14, 2014 France Telecom
I. Wijnands I. Wijnands
Cisco Systems, Inc Cisco Systems
N. Leymann N. Leymann
Deutsche Telekom AG Deutsche Telekom
April 18, 2013 October 11, 2013
LDP Extensions for Hub & Spoke Multipoint Label Switched Path LDP Extensions for Hub & Spoke Multipoint Label Switched Path
draft-ietf-mpls-mldp-hsmp-01.txt draft-ietf-mpls-mldp-hsmp-02.txt
Abstract Abstract
This draft introduces a hub & spoke multipoint LSP (short for HSMP This draft introduces a hub & spoke multipoint LSP (or HSMP LSP for
LSP), which allows traffic both from root to leaf through P2MP LSP 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 and also leaf to root along the co-routed reverse path. That means
traffic entering the HSMP LSP from application/customer at the root traffic entering the HSMP LSP from application/customer at the root
node travels downstream, exactly as if it was traveling downstream node travels downstream to each leaf node, exactly as if it is
along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP travelling downstream along a P2MP LSP to each leaf node. Upstream
at any leaf node travels upstream along the tree to the root as if it traffic entering the HSMP LSP at any leaf node travels upstream along
is unicast to the root, except that it follows the path of the tree the tree to the root, as if it is unicast to the root, and strictly
rather than ordinary unicast to the root. follows the downstream path of the tree rather than routing protocol
based unicast path to the root.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2014.
This Internet-Draft will expire on October 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Time synchronization scenario . . . . . . . . . . . . . . 4 3.1. Time Synchronization Scenario . . . . . . . . . . . . . . 5
3.2. VPMS scenario . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Virtual Private Multicast Service Scenario . . . . . . . . 5
3.3. IPTV scenario . . . . . . . . . . . . . . . . . . . . . . 4 3.3. IPTV Scenario . . . . . . . . . . . . . . . . . . . . . . 5
4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5 4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 6
4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5 4.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 6
4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6 4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 7
4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6 4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 7
4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6 4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 8
4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8 4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 10
4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 9 4.3.3. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . 10
5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9 5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10
6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9 6. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9 7. Co-routed Path Exceptions . . . . . . . . . . . . . . . . . . 11
8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 10 8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative references . . . . . . . . . . . . . . . . . . . 11 12.1. Normative references . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The point-to-multipoint LSP defined in [RFC6388] allows traffic to The point-to-multipoint LSP defined in [RFC6388] allows traffic to
transmit from root to several leaf nodes, and multipoint-to- transmit from root to several leaf nodes, and multipoint-to-
multipoint LSP allows traffic from every node to transmit to every multipoint LSP allows traffic from every node to transmit to every
other node. This draft introduces a hub & spoke multipoint LSP other node. This draft introduces a hub & spoke multipoint LSP (or
(short for HSMP LSP), which allows traffic both from root to leaf 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 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 path. That means traffic entering the HSMP LSP at the root node
travels downstream, exactly as if it was traveling downstream along a travels downstream, exactly as if it is travelling downstream along a
P2MP LSP, and traffic entering the HSMP LSP at any other node travels P2MP LSP, and traffic entering the HSMP LSP at any other node travels
upstream along the tree to the root. A packet traveling upstream upstream along the tree to the root. A packet travelling upstream
should be thought of as being unicast to the root, except that it should be thought of as being unicast to the root, except that it
follows the path of the tree rather than ordinary unicast to the follows the path of the tree rather than routing protocol based
root. unicast path to the root. The combination of upstream LSPs initiated
from all leaf nodes forms a multipoint-to-point LSP.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses some terms and acronyms as follows: This document uses some terms and acronyms as follows:
mLDP: Multipoint extensions for LDP 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.
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress mLDP: Multipoint extensions for LDP
LSRs.
MP2MP LSP: An LSP that connects a set of nodes, such that traffic 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. sent by any node in the LSP is delivered to all others.
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.
PTP: The timing and synchronization protocol used by IEEE1588 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 3. Applications
In some cases, the P2MP LSP may not have a reply path for the OAM In some cases, the P2MP LSP may not have a reply path for OAM
message (e.g, LSP Ping). If P2MP LSP is provided by HSMP LSP, then messages (e.g, LSP Ping Echo Request). If P2MP LSP is provided by
the upstream path could be exactly used as the OAM message reply HSMP LSP instead, then the upstream path could be used as the OAM
path. This is especially useful in the case of P2MP LSP fault message reply path. This is especially useful in the case of P2MP
detection, performance measurement, root node redundancy and etc. LSP fault detection, performance measurement, root node redundancy
There are several other applications that could take advantage of and etc. There are several other applications that could take
such kind of LDP based HSMP LSP as described below. advantage of a LDP based HSMP LSP as described below.
3.1. Time synchronization scenario 3.1. Time Synchronization Scenario
[IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls].
It is required that the LSP used to transport PTP event message 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 between a Master Clock and a Slave Clock, and the LSP between the
same Slave Clock and Master Clock must be co-routed. By using point- same Slave Clock and Master Clock must be co-routed. Using point-to-
to-multipoint technology to transmit PTP event messages from Master multipoint technology to transmit PTP event messages from Master
Clock at root side to Slave Clock at leaf side will greatly improve Clock at root side to Slave Clock at leaf side will greatly improve
the bandwidth usage. Unfortunately current point-to-multipoint LSP the bandwidth usage. Unfortunately current point-to-multipoint LSP
only provides unidirectional path from root to leaf, which cannot only provides unidirectional path from root to leaf, which cannot
provide a co-routed reverse path for the PTP event messages. LDP provides a co-routed reverse path for the PTP event messages. LDP
based HSMP LSP described in this draft provides unidirectional point- based HSMP LSP described in this draft provides unidirectional point-
to-multipoint LSP from root to leaf and co-routed reverse path from to-multipoint LSP from root to leaf and co-routed reverse LSP from
leaf to root. leaf to root.
3.2. VPMS scenario 3.2. Virtual Private Multicast Service Scenario
Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires
to setup reverse path from leaf node (referred as egress PE) to root 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 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 PW, the reverse path can also be multiplexed to HSMP upstream path to
avoid setup independent reverse path. In that case, the operational avoid setup independent reverse path. In that case, the operational
cost will be reduced for maintaining only one HSMP LSP, instead of 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 and n (number of leaf nodes) P2P reverse LSPs.
The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires 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 reverse path from leaf to root node. The P2MP PW multiplexed to HSMP
LSP can provide VPMS with reverse path, without introducing LSP can provide VPMS with reverse path, without introducing
independent reverse path from each leaf to root. independent reverse path from each leaf to root.
3.3. IPTV scenario 3.3. IPTV Scenario
The mLDP based HSMP LSP can also be applied in a typical IPTV The mLDP based HSMP LSP can also be applied in a typical IPTV
scenario. There is usually only one location with senders but there scenario. There is usually only one location with senders but there
are many receiver locations. If IGMP is used for signaling between are many receiver locations. If IGMP is used for signalling between
senders as IGMP querier and receivers, the IGMP messages from the senders as IGMP querier [RFC3376] and receivers, the IGMP messages
receivers are travelling only from the leaves to the root (and from from the receivers are travelling only from the leaves to the root
root towards leaves) but not from leaf to leaf. In addition traffic (and from root towards leaves) but not from leaf to leaf. In
from the root is only replicated towards the leaves. Then leaf node addition traffic from the root is only replicated towards the leaves.
receiving IGMP message (for SSM case) will join HSMP LSP, and then Then leaf node receiving IGMP report message (for source specific
send IGMP message upstream to root along HSMP LSP. Note that in multicast case) will join HSMP LSP(use similar mechanism in [RFC6826]
above case, there is no node redundancy for IGMP querier. And the section 2), and then send IGMP report message upstream to root along
node redundancy for IGMP querier could be provided by two independent HSMP upstream LSP. Note that in above case, there is no node
VPMS instances with HSMP applied. redundancy for IGMP querier. And the node redundancy for IGMP
querier[RFC3376] could be provided by two independent VPMS instances
with HSMP applied.
4. Setting up HSMP LSP with LDP 4. Setting up HSMP LSP with LDP
HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the
difference that the leaf LSRs can only send traffic to root node difference that the leaf LSRs can only send traffic to root node
along the same path of traffic from root node to leaf node. along the same path of traffic from root node to leaf node.
HSMP LSP consists of a downstream path and upstream path. The 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 MP2MP LSP, while the upstream path is only
from leaf to root node, without communication between leaf and leaf from leaf to root node, without communication between leaf and leaf
nodes. The transmission of packets from the root node of a HSMP LSP 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 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 the leaf node follows the upstream path toward the root node, along a
identical path of downstream path. path that traverse the same nodes as the downstream node, but in
reverse order.
For setting up the upstream path of a HSMP LSP, ordered mode MUST be 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 used which is same as MP2MP. Ordered mode can guarantee a leaf to
start sending packets to root immediately after the upstream path is start sending packets to root immediately after the upstream path is
installed, without being dropped due to an incomplete LSP. installed, without being dropped due to an incomplete LSP.
Due to much of same behavior between HSMP LSP and MP2MP LSP, the Due to much of similar behaviors between HSMP LSP and MP2MP LSP, the
following sections only describe the difference between the two following sections only describe the difference between the two
entities. entities.
4.1. Support for HSMP LSP setup with LDP 4.1. Support for HSMP LSP Setup with LDP
HSMP LSP also needs the LDP capabilities [RFC5561] to indicate the HSMP LSP requires the LDP capabilities [RFC5561] for nodes to
supporting for the setup of HSMP LSPs. An implementation supporting indicate that they support setup of HSMP LSPs. An implementation
the HSMP LSP procedures specified in this document MUST implement the supporting the HSMP LSP procedures specified in this document MUST
procedures for Capability Parameters in Initialization Messages. implement the procedures for Capability Parameters in Initialization
Advertisement of the HSMP LSP Capability indicates support of the Messages. Advertisement of the HSMP LSP Capability indicates support
procedures for HSMP LSP setup. of the procedures for HSMP LSP setup.
A new Capability Parameter TLV is defined, the HSMP LSP Capability. A new Capability Parameter TLV is defined, the HSMP LSP Capability
Following is the format of the HSMP LSP Capability Parameter. Parameter. Following is the format of the HSMP LSP Capability
Parameter.
0 1 2 3 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 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 (= 1) | |1|0| HSMP LSP Cap(TBD IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1. HSMP LSP Capability Parameter encoding Figure 1. HSMP LSP Capability Parameter encoding
The HSMP LSP capability type is to be assigned by IANA. 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 4.2. HSMP FEC Elements
Similar as MP2MP LSP, we define two new protocol entities, the HSMP Similar as MP2MP LSP, we define two new protocol entities, the HSMP
downstream FEC and upstream FEC Element. If a FEC TLV contains an Downstream FEC Element and Upstream FEC Element. If a FEC TLV
HSMP FEC Element, the HSMP FEC Element MUST be the only FEC Element contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be
in the FEC TLV. The structure, encoding and error handling for the the only FEC Element in the FEC TLV. The structure, encoding and
HSMP downstream and upstream FEC Elements are the same as for the error handling for the HSMP Downstream FEC Element and Upstream FEC
MP2MP FEC Element described in [RFC6388] Section 4.2. The difference Element are the same as for the MP2MP FEC Element described in
is that two additional new FEC types are used: HSMP downstream type [RFC6388] Section 3.2. The difference is that two additional new FEC
(TBD, IANA) and HSMP upstream type (TBD, IANA). types are defined: HSMP Downstream FEC (TBD, IANA) and HSMP Upstream
FEC(TBD, IANA).
4.3. Using the HSMP FEC Elements 4.3. Using the HSMP FEC Elements
In order to describe the message processing clearly, following In order to describe the message processing clearly, the entries in
defines the processing of the HSMP FEC Elements, which is inherited the list below define the processing of the HSMP FEC Elements.
from [RFC6388] section 4.3. Additionally, the entries defined in [RFC6388] section 3.3 are also
reused in the following sections.
1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): a HSMP 1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP
LSP downstream path with root node address X and opaque value Y. LSP downstream path with root node address X and opaque value Y.
2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): a HSMP LSP 2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP
upstream path for root node address X and opaque value Y which will upstream path for root node address X and opaque value Y which will
be used by any of downstream node to send traffic upstream to root be used by any of downstream node to send traffic upstream to root
node. node.
3. HSMP downstream FEC Element <X, Y>: a FEC Element with root node 3. HSMP downstream FEC Element <X, Y>: a FEC Element with root node
address X and opaque value Y used for a downstream HSMP LSP. address X and opaque value Y used for a downstream HSMP LSP.
4. HSMP upstream FEC Element <X, Y>: a FEC Element with root node 4. HSMP upstream FEC Element <X, Y>: a FEC Element with root node
address X and opaque value Y used for an upstream HSMP LSP. address X and opaque value Y used for an upstream HSMP LSP.
5. HSMP-D Label Map <X, Y, L>: A Label Map message with a single 5. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a
HSMP downstream FEC Element <X, Y> and label TLV with label L. Label single HSMP downstream FEC Element <X, Y> and label TLV with label L.
L MUST be allocated from the per-platform label space of the LSR Label L MUST be allocated from the per-platform label space of the
sending the Label Map Message. LSR sending the Label Mapping Message.
6. HSMP-U Label Map <X, Y, Lu>: A Label Map message with a single 6. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a
HSMP upstream FEC Element <X, Y> and label TLV with label Lu. Label single HSMP upstream FEC Element <X, Y> and label TLV with label Lu.
Lu MUST be allocated from the per-platform label space of the LSR Label Lu MUST be allocated from the per-platform label space of the
sending the Label Map Message. LSR sending the Label Mapping Message.
4.3.1. HSMP LSP Label Map 4.3.1. HSMP LSP Label Map
This section specifies the procedures for originating HSMP Label Map This section specifies the procedures for originating HSMP Label
messages and processing received HSMP label map messages for a Mapping messages and processing received HSMP Label Mapping messages
particular HSMP LSP. The procedure of downstream HSMP LSP is same as for a particular HSMP LSP. The procedure of downstream HSMP LSP is
that of downstream MP2MP LSP described in [RFC6388]. Under the same as that of downstream MP2MP LSP described in [RFC6388]. When
operation of ordered mode, the upstream LSP will be setup by sending LDP operates in Ordered Label Distribution Control mode [RFC5036],
HSMP LSP mapping message with label which is allocated by upstream the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping
LSR to its downstream LSR one by one from root to leaf node, message with a label which is allocated by upstream LSR to its
installing the upstream forwarding table by every node along the LSP. downstream LSR hop by hop from root to leaf node, installing the
Detail procedure of upstream HSMP LSP is different with that of 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. upstream MP2MP LSP, and is specified in below section.
All labels discussed here are downstream-assigned [RFC5332] except 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 5.
Determining the upstream LSR for a HSMP LSP <X, Y> follows the Determining the upstream LSR for the HSMP LSP <X, Y> follows the
procedure for a MP2MP LSP described in [RFC6388] Section 4.3.1.1. procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1.
Determining one's downstream HSMP LSR procedure is much same as Determining one's HSMP downstream LSR follows the procedure defined
defined in [RFC6388] section 4.3.1.2. A LDP peer U which receives a in [RFC6388] section 3.3.1.2. That is, an upstream LDP peer which
HSMP-D Label Map from a LDP peer D will treat D as downstream HSMP receives a Label Mapping with HSMP downstream FEC Element from an LDP
LSR. peer D will treat D as HSMP downstream LDP peer.
Determining the forwarding interface to an LSR has same procedure as Determining the forwarding interface to an LSR follows the procedure
defined in [RFC6388] section 2.4.1.2. as defined in [RFC6388] section 2.4.1.2.
4.3.1.1. HSMP LSP leaf node operation 4.3.1.1. HSMP LSP Leaf Node Operation
The leaf node operation is same as the operation of MP2MP LSP defined The leaf node operation is same as the operation of MP2MP LSP defined
in [RFC6388] section 4.3.1.4, only with different FEC element in [RFC6388] section 3.3.1.4. The only difference is the FEC
processing and specified below. elements as specified below.
A leaf node Z will send a HSMP-D Label Map <X, Y, L> to U, instead of A leaf node Z will send an HSMP-D Label Mapping <X, Y, L> to U,
MP2MP-D Label Map <X, Y, L>. and expects a HSMP-U Label Map <X, Y, instead of MP2MP-D Label Mapping <X, Y, L>, and expects an HSMP-U
Lu> from node U and checks whether it already has forwarding state Label Mapping <X, Y, Lu> from node U and checks whether it already
for upstream <X, Y>. The created forwarding state on leaf node Z is has forwarding state for upstream <X, Y>. The created forwarding
same as the leaf node of MP2MP LSP. Z will push label Lu onto the state on leaf node Z is same as the leaf node of MP2MP LSP. Z will
traffic that Z wants to forward over the HSMP LSP. push label Lu onto the traffic that Z wants to forward over the HSMP
LSP.
4.3.1.2. HSMP LSP transit node operation 4.3.1.2. HSMP LSP Transit Node Operation
Suppose node Z receives a HSMP-D Label Map <X, Y, L> from LSR D, the Suppose node Z receives an HSMP-D Label Mapping <X, Y, L> from LSR D,
procedure is same as processing MP2MP-D Label Mapping message defined the procedure is much the same as processing MP2MP-D Label Mapping
in [RFC6388] section 4.3.1.5, and the processing protocol entity is message defined in [RFC6388] section 3.3.1.5, and the processing
HSMP-D label mapping message. The different procedure is specified protocol entity is HSMP-D Label Mapping message. The only difference
below. is specified below.
Node Z checks if upstream LSR U already assigned a label Lu to Node Z checks if upstream LSR U already has assigned a label Lu to
upstream <X, Y>. If not, transit node Z waits until it receives a upstream <X, Y>. If not, transit node Z waits until it receives an
HSMP-U Label Map <X, Y, Lu> from LSR U. Once the HSMP-U Label Map is HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label
received from LSR U, node Z checks whether it already has forwarding Mapping is received from LSR U, node Z checks whether it already has
state upstream <X, Y> with incoming label Lu' and outgoing label Lu. forwarding state upstream <X, Y> with incoming label Lu' and outgoing
If it does, Z sends a HSMP-U Label Map <X, Y, Lu'> to downstream label Lu. If it does, Z sends an HSMP-U Label Mapping <X, Y, Lu'> to
node. If it does not, it allocates a label Lu' and creates a new downstream node. If it does not, it allocates a label Lu' and
label swap for Lu' with Label Lu over interface Iu. Interface Iu is creates a new label swap for Lu' with Label Lu over interface Iu.
determined via the procedures in Section 4.3.1. Node Z determines Interface Iu is determined via the procedures in section 4.3.1. Node
the downstream HSMP LSR as per Section 4.3.1, and sends a HSMP-U Z determines the downstream HSMP LSR as per section 4.3.1, and sends
Label Map <X, Y, Lu'> to node D. an HSMP-U Label Mapping <X, Y, Lu'> to node D.
Since a packet from any downstream node is forwarded only to the Since a packet from any downstream node is forwarded only to the
upstream node, the same label (representing the upstream path) can be upstream node, the same label (representing the upstream path) SHOULD
distributed to all downstream nodes. This differs from the be distributed to all downstream nodes. This differs from the
procedures for MPMP LSPs [RFC6388], where a distinct label must be procedures for MP2MP LSPs [RFC6388], where a distinct label must be
distributed to each downstream node. The forwarding state upstream distributed to each downstream node. The forwarding state upstream
<X, Y> on node Z will be like this {<Lu'>, <Iu Lu>}. Iu means the <X, Y> on node Z will be like this {<Lu'>, <Iu Lu>}. Iu means the
upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu> upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu>
from LSR U. Packets from any downstream interface over which Z send from LSR U. Packets from any downstream interface over which Z sends
HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu
with label Lu' swap to Lu. with label Lu' swap to Lu.
4.3.1.3. HSMP LSP root node operation 4.3.1.3. HSMP LSP Root Node Operation
Suppose root node Z receives a HSMP-D Label Map <X, Y, L> from node Suppose root node Z receives an HSMP-D Label Mapping <X, Y, L> from
D, the procedure is much same as processing MP2MP-D Label Mapping node D, the procedure is much the same as processing MP2MP-D Label
message defined in [RFC6388] section 4.3.1.6, and the processing Mapping message defined in [RFC6388] section 3.3.1.6, and the
protocol entity is HSMP-D label mapping message. The different processing protocol entity is HSMP-D Label Mapping message. The only
procedure is specified below. difference is specified below.
Node Z checks if it has forwarding state for upstream <X, Y>. If Node Z checks if it has forwarding state for upstream <X, Y>. If
not, Z creates a forwarding state for incoming label Lu' that not, Z creates a forwarding state for incoming label Lu' that
indicates that Z is the LSP egress. E.g., the forwarding state might 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 specify that the label stack is popped and the packet passed to some
specific application. Node Z determines the downstream HSMP LSR as specific application. Node Z determines the downstream HSMP LSR as
per section 4.3.1, and sends a HSMP-U Label Map <X, Y, Lu'> to node per section 4.3.1, and sends an HSMP-U Label Map <X, Y, Lu'> to node
D. D.
Since Z is the root of the tree, Z will not send a HSMP-D Label Map Since Z is the root of the tree, Z will not send an HSMP-D Label Map
and will not receive a HSMP-U Label Map. and will not receive an HSMP-U Label Mapping.
4.3.2. HSMP LSP Label Withdraw 4.3.2. HSMP LSP Label Withdraw
The HSMP Label Withdraw procedure is much same as MP2MP leaf The HSMP Label Withdraw procedure is much the same as MP2MP leaf
operation defined in [RFC6388] section 4.3.2, and the processing operation defined in [RFC6388] section 3.3.2, and the processing FEC
protocol entities are HSMP FECs. The only difference is process of Elements are HSMP FEC Elements. The only difference is the process
HSMP-U label release message, which is specified below. of HSMP-U Label Release message, which is specified below.
When a transit node Z receives a HSMP-U label release message from 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 downstream node D, Z should check if there are any incoming interface
in forwarding state upstream <X, Y>. If all downstream nodes are in forwarding state upstream <X, Y>. If all downstream nodes are
released and there is no incoming interface, Z should delete the released and there is no incoming interface, Z should delete the
forwarding state upstream <X, Y> and send HSMP-U label release forwarding state upstream <X, Y> and send HSMP-U Label Release
message to its upstream node. message to its upstream node. Otherwise, no HSMP-U Label Release
message will be sent to the upstream node.
4.3.3. HSMP LSP upstream LSR change 4.3.3. HSMP LSP Upstream LSR Change
The procedure for changing the upstream LSR is the same as defined in The procedure for changing the upstream LSR is the same as defined in
[RFC6388] section 4.3.3, except it is applied to HSMP FECs. [RFC6388] section 3.3.3, only with different processing FEC Element,
the HSMP FEC Element.
5. HSMP LSP on a LAN 5. HSMP LSP on a LAN
The procedure to process P2MP LSP on a LAN has been described in The procedure to process the downstream HSMP LSP on a LAN is much the
[RFC6388]. When the LSR forwards a packet downstream on one of those same as downstream MP2MP LSP described in [RFC6388] section 6.1.1.
LSPs, the packet's top label must be the "upstream LSR label", and
the packet's second label is "LSP label".
When establishing the downstream path of a HSMP LSP, as defined in When establishing the downstream path of an HSMP LSP, as defined in
[RFC6389], a label request for a LSP label is send to the upstream [RFC6389], a Label Request message for an LSP label is sent to the
LSR. The upstream LSR should send label mapping that contains the upstream LSR. The upstream LSR should send Label Mapping message
LSP label for the downstream HSMP FEC and the upstream LSR context that contains the LSP label for the downstream HSMP FEC and the
label. At the same time, it must also send label mapping for upstream LSR context label defined in [RFC5331]. When the LSR
upstream HSMP FEC to downstream node. Packets sent by the upstream forwards a packet downstream on one of those LSPs, the packet's top
router can be forwarded downstream using this forwarding state based label must be the "upstream LSR context label", and the packet's
on a two label lookup. Packets traveling upstream need to be second label is "LSP label". The HSMP downstream path will be
forwarded in the direction of the root by using the label allocated installed in the context-specific forwarding table corresponding to
by upstream LSR. the upstream LSR label. Packets sent by the upstream LSR can be
forwarded downstream using this forwarding state based on a two-label
lookup.
6. Redundancy considerations 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
In some scenario, it is necessary to provide two root nodes for In some scenario, it is necessary to provide two root nodes for
redundancy purpose. One way to implement this is to use two redundancy purpose. One way to implement this is to use two
independent HSMP LSPs acting as active/standby. At one time, only independent HSMP LSPs acting as active/standby. At one time, only
one HSMP LSP will be active, and the other will be standby. After 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 detecting the failure of active HSMP LSP, the root and leaf nodes
will switch the traffic to the new active HSMP LSP which is switched will switch the traffic to the standby HSMP LSP which takes on the
from former standby LSP. The detail of redundancy mechanism will be role as active HSMP LSP. The detail of redundancy mechanism is out
for future study. of the scope.
7. Co-routed path exceptions 7. Co-routed Path Exceptions
There are some exceptional cases that mLDP based HSMP LSP could not There are some exceptional cases when mLDP based HSMP LSP could not
achieve co-routed path. One possible case is using static routing achieve co-routed path. One possible case is using static routing
between LDP neighbors; another possible case is IGP cost asymmetric between LDP neighbors; another possible case is IGP cost asymmetric
generated by physical link cost asymmetric, or TE-Tunnels used generated by physical link cost asymmetric, or TE-Tunnels used
between LDP neighbors. The LSR/LER in HSMP LSP could detect if the between LDP neighbors. The LSR/LER in HSMP LSP should detect if the
path is co-routed or not, if not co-routed, an indication could be path is co-routed or not. If not co-routed, an alarm indication
generated to the management system. should be generated to the management system.
8. Failure Detection of HSMP LSP 8. Failure Detection of HSMP LSP
The idea of LSP ping for HSMP LSPs could be expressed as an intention The idea of LSP ping for HSMP LSPs could be expressed as an intention
to test the packets that enter at the root along a particular to test the LSP Ping Echo Request packets that enter at the root
downstream path of HSMP LSP, and end their MPLS path on the leaf. along a particular downstream path of HSMP LSP, and end their MPLS
The leaf node then sends the LSP ping response along the co-routed path on the leaf. The leaf node then sends the LSP Ping Echo Reply
upstream path of HSMP LSP, and end on the root that are the along the co-routed upstream path of HSMP LSP, and end on the root
(intended) root node. that are the (intended) root node.
New sub-TLVs are required to be assigned by IANA in Target FEC Stack 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- TLV to define the corresponding HSMP-upstream FEC type and HSMP-
downstream FEC type. In order to ensure the leaf node to send the downstream FEC type. In order to ensure the leaf node to send the
LSP ping response along the HSMP upstream path, the R bit (Validate LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate
Reverse Path) in Global Flags Field defined in [RFC6426] is reused Reverse Path) in Global Flags Field defined in [RFC6426] is reused
here. here.
The node processing mechanism of LSP ping for HSMP LSP is inherited The node processing mechanism of LSP Ping Echo Request and Echo Reply
from [RFC6425] and [RFC6426] section 3.4, except the following: for HSMP LSP is inherited from [RFC6425] and [RFC6426] section 3.4,
except the following:
1. The root node sending LSP ping message for HSMP LSP MUST attach 1. The root node sending LSP Ping Echo Request message for HSMP LSP
Target FEC Stack with HSMP downstream FEC, and set R bit to '1' in MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit
Global Flags Field. to '1' in Global Flags Field.
2. When the leaf node receiving the LSP ping, it MUST send the LSP 2. When the leaf node receiving the LSP Ping Echo Request, it MUST
ping response to the associated HSMP upstream path. The Reverse-path send the LSP Ping Echo Reply to the associated HSMP upstream path.
Target FEC Stack TLV attached by leaf node in reply message SHOULD The Reverse-path Target FEC Stack TLV attached by leaf node in Echo
contain the sub-TLV of associated HSMP upstream FEC. Reply message SHOULD contain the sub-TLV of associated HSMP upstream
FEC.
9. Security Considerations 9. Security Considerations
The same security considerations apply as for the MP2MP LSP described The same security considerations apply as for the MP2MP LSP described
in [RFC6388] and [RFC6425]. 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 10. IANA Considerations
This document requires allocation of two 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 from the "Label Distribution Protocol (LDP) Parameters registry" the
"Forwarding Equivalence Class (FEC) Type Name Space": "Forwarding Equivalence Class (FEC) Type Name Space":
1. the HSMP-upstream FEC type - requested value TBD 1. the HSMP-upstream FEC type - requested value TBD
2. the HSMP-downstream FEC type - requested value TBD 2. the HSMP-downstream FEC type - requested value TBD
skipping to change at page 11, line 18 skipping to change at page 13, line 8
inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV
type 1). type 1).
1. the HSMP-upstream LDP FEC Stack - requested value TBD 1. the HSMP-upstream LDP FEC Stack - requested value TBD
2. the HSMP-downstream LDP FEC Stack - requested value TBD 2. the HSMP-downstream LDP FEC Stack - requested value TBD
11. Acknowledgement 11. Acknowledgement
The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su,
Edward, Mach Chen, Thomas Morin for their valuable comments. Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable
comments.
12. References 12. References
12.1. Normative references 12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
skipping to change at page 12, line 22 skipping to change at page 14, line 14
progress), October 2012. progress), October 2012.
[I-D.ietf-pwe3-p2mp-pw] [I-D.ietf-pwe3-p2mp-pw]
Sivabalan, S., Boutros, S., and L. Martini, "Signaling Sivabalan, S., Boutros, S., and L. Martini, "Signaling
Root-Initiated Point-to-Multipoint Pseudowire using LDP", Root-Initiated Point-to-Multipoint Pseudowire using LDP",
draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-04 (work in Networks", draft-ietf-tictoc-1588overmpls-05 (work in
progress), February 2013. progress), June 2013.
[IEEE1588] [IEEE1588]
"IEEE standard for a precision clock synchronization "IEEE standard for a precision clock synchronization
protocol for networked measurement and control systems", protocol for networked measurement and control systems",
IEEE1588v2 , March 2008. 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 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
[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 Authors' Addresses
Lizhong Jin Lizhong Jin
Shanghai, China Shanghai, China
Email: lizho.jin@gmail.com Email: lizho.jin@gmail.com
Frederic Jounay Frederic Jounay
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE 22307 Lannion Cedex, FRANCE
Email: frederic.jounay@orange.ch Email: frederic.jounay@orange.ch
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc Cisco Systems, Inc
De kleetlaan 6a De kleetlaan 6a
 End of changes. 82 change blocks. 
219 lines changed or deleted 264 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/