Network Working Group L. Jin
Internet-Draft ZTE
Intended status: Standards Track F. Jounay
Expires: April 19, 2011 France Telecom
I. Wijnands
Cisco Systems
October 16, 2010
Multicast LDP extension for hub & spoke multipoint LSP
draft-jin-jounay-mpls-mldp-hsmp-00.txt
Abstract
This draft introduces a hub & spoke multipoint LSP (short for HSMP
LSP), 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, exactly as if it was traveling downstream
along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP
at any leaf node travels upstream along the tree to the root. A
packet traveling upstream should be thought of as being unicast to
the root, except that it follows the path of the tree rather than
ordinary unicast path.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2011.
Copyright Notice
Copyright (c) 2010 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
Jin, et al. Expires April 19, 2011 [Page 1]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
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. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4
4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 4
4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5
4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5
4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6
4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8
4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 8
5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative references . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Jin, et al. Expires April 19, 2011 [Page 2]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
1. Introduction
The point-to-multipoint LSP defined in [I-D.
draft-ietf-mpls-ldp-p2mp] 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 (short for HSMP LSP), 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 was traveling 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 traveling upstream should be thought of as being
unicast to the root, except that it follows the path of the tree
rather than ordinary unicast path.
2. Applications
There are applications that require such kind of LDP based HSMP LSP.
According to time synchronization described in [IEEE1588v2], the sync
packet and delay request should follow the same path, so as to
provide same transmission delay for the two kinds of packets. By
using point-to-multipoint technology to transmit these packets will
greatly improve the bandwidth usage for above applications.
Unfortunately current point-to-multipoint LSP only provides
unidirectional path from source to leaf, which cannot fulfill the
above new requirement. The main motivation of this draft is to solve
the new problem. LDP based HSMP LSP described in this draft provides
co-routed reverse path from leaf to root based on current
unidirectional point-to-multipoint LSP.
There are two main specific scenarios for timing synchronization
based on [IEEE1588v2]: 1. HSMP for phase/time delivery with TCKs. 2.
HSMP for phase/time delivery with BCKs. The benefit of using mLDP
based HSMP LSP here is to provision dynamically the topology.
Time synchronization is required for accurate quantification of one-
way delay as described in [I-D. draft-ietf-mpls-tp-loss-delay]. HSMP
LSP can be used to do time synchronization based on [IEEE1588v2] for
P2MP LSP or P2MP PW.
Point to multipoint PW described in [I-D. draft-ietf-pwe3-p2mp-pw]
requires to setup 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
Jin, et al. Expires April 19, 2011 [Page 3]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
LSP, instead of P2MP LSP and n (number of leaf nodes) P2P reverse
LSPs.
3. Terminology
mLDP: Multicast LDP.
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
LSRs.
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.
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.
4. Setting up HSMP LSP with LDP
HSMP LSP is similar with MP2MP LSP described in [I-D.
draft-ietf-mpls-ldp-p2mp], 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 consists of a downstream path and upstream path. The
downstream path is same as MP2MP 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 a 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 the
identical path of downstream path.
For setting up the upstream path of a 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.
Due to much of same behavior between HSMP LSP and MP2MP LSP, the
following sections only describe the difference between the two
entities.
4.1. Support for HSMP LSP setup with LDP
HSMP LSP also needs the LDP capabilities [RFC5561] to indicate the
supporting for the setup of HSMP LSPs. An implementation supporting
the HSMP LSP procedures specified in this document MUST implement the
Jin, et al. Expires April 19, 2011 [Page 4]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
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.
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 (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1
The HSMP LSP capability type is to be assigned by IANA.
4.2. HSMP FEC Elements
Similar as MP2MP LSP, we define two new protocol entities, the HSMP
downstream FEC and upstream FEC Element. Both elements will be used
as FEC Elements in the FEC TLV. The structure, encoding and error
handling for the HSMP downstream and upstream FEC Elements are the
same as for the MP2MP FEC Element described in [I-D.
draft-ietf-mpls-ldp-p2mp] Section 4.2. The difference is that two
additional new FEC types are used: HSMP downstream type (TBD, IANA)
and HSMP upstream type (TBD, IANA).
4.3. Using the HSMP FEC Elements
In order to describe the message processing clearly, following
defines the processing of the HSMP FEC Elements, which is inherited
from [I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.
1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): a HSMP
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
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
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.
Jin, et al. Expires April 19, 2011 [Page 5]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
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.
5. HSMP-D Label Map <X, Y, L>: A Label Map message with a single
HSMP downstream FEC Element <X, Y> and label TLV with label L. Label
L MUST be allocated from the per-platform label space of the LSR
sending the Label Map Message.
6. HSMP-U Label Map <X, Y, Lu>: A Label Map message with a single
HSMP upstream FEC Element <X, Y> and label TLV with label Lu. Label
Lu MUST be allocated from the per-platform label space of the LSR
sending the Label Map Message.
4.3.1. HSMP LSP Label Map
This section specifies the procedures for originating HSMP Label Map
messages and processing received HSMP label map messages for a
particular HSMP LSP. The procedure of downstream HSMP LSP is same as
that of downstream MP2MP LSP described in [I-D.
draft-ietf-mpls-ldp-p2mp]. Under the operation of ordered mode, the
upstream LSP will be setup by sending HSMP LSP mapping message with
label which is allocated by upstream LSR to its downstream LSR one by
one from root to leaf node, installing the upstream forwarding table
by every node along the LSP. Detail procedure of 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.
Determining the upstream LSR for a HSMP LSP <X, Y> follows the
procedure for a MP2MP LSP described in [I-D.
draft-ietf-mpls-ldp-p2mp] Section 4.3.1.1.
Determining one's downstream HSMP LSR procedure is much same as
defined in [I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.1.2. A LDP
peer U which receives a HSMP-D Label Map from a LDP peer D will treat
D as downstream HSMP LSR.
Determining the forwarding interface to an LSR has same procedure as
defined in [I-D. draft-ietf-mpls-ldp-p2mp] section 2.4.1.2.
4.3.1.1. HSMP LSP leaf node operation
The leaf node operation is same as the operation of MP2MP LSP defined
in [I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.1.4, only with
different FEC element processing and specified below.
Jin, et al. Expires April 19, 2011 [Page 6]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
A leaf node Z will send a HSMP-D Label Map <X, Y, L> to U, instead of
MP2MP-D Label Map <X, Y, L>. and expects a HSMP-U Label Map <X, Y,
Lu> from node U and checks whether it already has forwarding state
for upstream <X, Y>. 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.
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
procedure is same as processing MP2MP-D Label Mapping message defined
in [I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.1.5, and the
processing protocol entity is HSMP-D label mapping message. The
different procedure is specified below.
Node Z checks if upstream LSR U already assigned a label Lu to
upstream <X, Y>. If not, transit node Z waits until it receives a
HSMP-U Label Map <X, Y, Lu> from LSR U. Once the HSMP-U Label Map is
received from LSR U, node Z checks whether it already has forwarding
state upstream <X, Y> with incoming label Lu' and outgoing label Lu.
If it does, Z sends a HSMP-U Label Map <X, Y, Lu'> 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 a HSMP-U
Label Map <X, Y, Lu'> to node D.
Since a packet from any downstream node is forwarded only to the
upstream node, the same label (representing the upstream path) can be
distributed to all downstream nodes. This differs from the
procedures for MPMP LSPs [I-D. draft-ietf-mpls-ldp-p2mp], where a
distinct label must be distributed to each downstream node. The
forwarding state upstream <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> from LSR U. Packets from any downstream
interface over which Z send HSMP-U Label Map <X, Y, Lu'> with label
Lu' will be forwarded to Iu with label Lu' swap to Lu.
4.3.1.3. HSMP LSP root node operation
Suppose root node Z receives a HSMP-D Label Map <X, Y, L> from node
D, the procedure is much same as processing MP2MP-D Label Mapping
message defined in [I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.1.6,
and the processing protocol entity is HSMP-D label mapping message.
The different procedure is specified below.
Node Z checks if it has forwarding state for upstream <X, Y>. If
not, Z creates a forwarding state for incoming label Lu' that
Jin, et al. Expires April 19, 2011 [Page 7]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
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 a HSMP-U Label Map <X, Y, Lu'> to node
D.
Since Z is the root of the tree, Z will not send a HSMP-D Label Map
and will not receive a HSMP-U Label Map.
4.3.2. HSMP LSP Label Withdraw
The HSMP Label Withdraw procedure is much same as MP2MP leaf
operation defined in [I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.2,
and the processing protocol entities are HSMP FECs. The only
difference is process of HSMP-U label release message, which is
specified below.
When a transit node Z receives a HSMP-U label release message from
downstream node D, Z should check if there are any incoming interface
in forwarding state upstream <X, Y>. If all downstream nodes are
released and there is no incoming interface, Z should delete the
forwarding state upstream <X, Y> and send HSMP-U label release
message to its upstream node.
4.3.3. HSMP LSP upstream LSR change
The procedure for changing the upstream LSR is the same as defined in
[I-D. draft-ietf-mpls-ldp-p2mp] section 4.3.3, except it is applied
to HSMP FECs.
5. HSMP LSP on a LAN
The procedure to process P2MP LSP on a LAN has been described in
[I-D. draft-ietf-mpls-ldp-p2mp]. When the LSR forwards a packet
downstream on one of those 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
[I-D.ietf-mpls-ldp-upstream], a label request for a LSP label is send
to the upstream LSR. The upstream LSR should send label mapping that
contains the LSP label for the downstream HSMP FEC and the upstream
LSR context label. At the same time, it must also send label mapping
for upstream HSMP FEC to downstream node. Packets sent by the
upstream router can be forwarded downstream using this forwarding
state based on a two label lookup. Packets traveling upstream need
to be forwarded in the direction of the root by using the label
allocated by upstream LSR.
Jin, et al. Expires April 19, 2011 [Page 8]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
6. Security Considerations
The same security considerations apply as for the MP2MP LSP described
in [I-D. draft-ietf-mpls-ldp-p2mp].
7. IANA Considerations
This document requires allocation of two new LDP FEC Element types:
1. the HSMP-upstream FEC type - requested value 0x09
2. the HSMP-downstream FEC type - requested value 0x10
This document requires the assignment of new code points for the
Capability Parameter TLVs, corresponding to the advertisement of the
HSMP LSP capabilities. The values requested are:
HSMP LSP Capability Parameter - requested value 0x050B
8. Acknowledgement
The author would like to thank Eric Rosen, Fei Su for their valuable
comments.
9. References
9.1. Normative references
[I-D. draft-ietf-mpls-ldp-p2mp]
Minei, I., Kompella, K., and I. Wijnands, "Label
Distribution Protocol Extensions for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp (work in progress), October 2009.
[I-D.ietf-mpls-ldp-upstream]
Aggarwal, R. and J. Le Roux, "MPLS Upstream Label
Assignment for LDP", draft-ietf-mpls-ldp-upstream-08 (work
in progress), July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036 , October 2007.
Jin, et al. Expires April 19, 2011 [Page 9]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
[RFC5332] Rosen, E. and R. Aggarwal, "MPLS Multicast
Encapsulations", RFC5332 , June 2008.
[RFC5561] Thomas, B., Raza, K., and S. Aggarwal, "LDP Capabilities",
RFC5561 , July 2009.
9.2. Informative References
[I-D. draft-ietf-mpls-tp-loss-delay]
Frost, D. and S. Bryant, "Signaling Root-Initiated Point-
to-Multipoint Pseudowires using LDP",
draft-ietf-mpls-tp-loss-delay-00 (work in progress),
July 2010.
[I-D. draft-ietf-pwe3-p2mp-pw]
Martini, L., Jounay, F., Vecchio, G., Delord, S., Jin, L.,
and L. Ciavaglia, "Signaling Root-Initiated Point-to-
Multipoint Pseudowires using LDP",
draft-ietf-pwe3-p2mp-pw-00 (work in progress), July 2010.
[IEEE1588v2]
"IEEE standard for a precision clock synchronization
protocol for networked measurement and control systems",
IEEE1588v2 , March 2008.
Authors' Addresses
Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
Email: frederic.jounay@orange-ftgroup.com
Jin, et al. Expires April 19, 2011 [Page 10]
Internet-Draft draft-jin-jounay-mpls-mldp-hsmp October 2010
IJsbrand Wijnands
Cisco Systems, Inc
De kleetlaan 6a
Diegem 1831, Belgium
Email: ice@cisco.com
Jin, et al. Expires April 19, 2011 [Page 11]