draft-ietf-mpls-mldp-hsmp-04.txt   draft-ietf-mpls-mldp-hsmp-05.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: May 30, 2014 France Telecom Expires: June 14, 2014 France Telecom
I. Wijnands I. Wijnands
Cisco Systems, Inc Cisco Systems, Inc
N. Leymann N. Leymann
Deutsche Telekom AG Deutsche Telekom AG
November 26, 2013 December 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-04.txt draft-ietf-mpls-mldp-hsmp-05.txt
Abstract Abstract
This draft introduces a hub & spoke multipoint (HSMP) Label Switched This draft introduces a hub & spoke multipoint (HSMP) Label Switched
Path (LSP), which allows traffic both from root to leaf through Path (LSP), which allows traffic both from root to leaf through
point-to-multipoint (P2MP) LSP and also leaf to root along the point-to-multipoint (P2MP) LSP and also leaf to root along the
reverse path. That means traffic entering the HSMP LSP from reverse path. That means traffic entering the HSMP LSP from
application/customer at the root node travels downstream to each leaf application/customer at the root node travels downstream to each leaf
node, exactly as if it is travelling downstream along a P2MP LSP to 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 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 node travels upstream along the tree to the root, as if it is unicast
to the root. The communication among the leaf nodes are not allowed. to the root. Direct communication among the leaf nodes is not
allowed.
Requirements Language 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 June 14, 2014.
This Internet-Draft will expire on May 30, 2014.
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. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4 3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4
3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4 3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 5
3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5 3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6
3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5 3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6
3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 6 3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 7
3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 7 3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 8
3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7 3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 8
3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 8 3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 9
3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9 3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 10
3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9 3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 10
3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9 3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 10
3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 9 3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 10
3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 10 3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 11
3.7. Determining Forwarding Interface . . . . . . . . . . . . . 10 3.7. Determining Forwarding Interface . . . . . . . . . . . . . 11
4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10 4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11
5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11 5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 12
6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11 6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12 8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 13
8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12 8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 13
8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13 8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 14
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 10.1. Normative references . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in
[RFC6388] allows traffic to transmit from root to several leaf nodes, [RFC6388] allows traffic to transmit from root to several leaf nodes,
and multipoint-to-multipoint (MP2MP) LSP allows traffic from every and multipoint-to-multipoint (MP2MP) LSP allows traffic from every
node to transmit to every other node. This draft introduces a hub & 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 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 leaf nodes. HSMP LSP allows traffic both from root to leaf through
downstream LSP and also leaf to root along the upstream LSP. That downstream LSP and also leaf to root along the upstream LSP. That
means traffic entering the HSMP LSP at the root node travels along 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 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 traffic entering the HSMP LSP at any other leaf nodes travels along
upstream LSP toward only the root node. The upstream LSP should be 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 thought of unicast LSP to the root node, except that it follows the
node of reverse downstream path of the tree, rather than routing reverse direction of the downstream LSP, rather than routing protocol
protocol based unicast path. The combination of upstream LSPs based unicast path. The combination of upstream LSPs initiated from
initiated from all leaf nodes forms a multipoint-to-point LSP. 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 Label Distribution Protocol (LDP) mLDP: Multipoint extensions for Label Distribution Protocol (LDP)
skipping to change at page 3, line 47 skipping to change at page 4, line 47
MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP
that connects a set of nodes, such that traffic sent by any node that connects a set of nodes, such that traffic sent by any node
in the LSP is delivered to all others. in the LSP is delivered to all others.
HSMP LSP: hub & spoke multipoint Label Switched Path. An LSP that HSMP LSP: hub & spoke multipoint Label Switched Path. An LSP that
has one root node and one or more leaf nodes, allows traffic from 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 to all leaf nodes along downstream P2MP LSP and also leaf to
root node along the upstream unicast LSP. root node along the upstream unicast LSP.
PTP: precise time protocol. The timing and synchronization
protocol defined by IEEE1588.
3. Setting up HSMP LSP with LDP 3. Setting up HSMP LSP with LDP
HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the
difference that, when the leaf LSRs send traffic on the LSP, 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 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 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 then distributes the traffic on the P2MP tree to all of the leaf
nodes. nodes.
HSMP LSP consists of a downstream path and upstream path. The HSMP LSP consists of a downstream path and upstream path. The
skipping to change at page 11, line 21 skipping to change at page 12, line 21
The upstream path of an HSMP LSP on a LAN is the same as the one on 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 other kind of links. That is, the upstream LSR must send Label
Mapping message that contains the LSP label for upstream HSMP FEC to Mapping message that contains the LSP label for upstream HSMP FEC to
downstream node. Packets travelling upstream need to be forwarded in downstream node. Packets travelling upstream need to be forwarded in
the direction of the root by using the label allocated for upstream the direction of the root by using the label allocated for upstream
HSMP FEC. HSMP FEC.
5. Redundancy Considerations 5. Redundancy Considerations
In some scenario, it is necessary to provide two root nodes for In some scenarios, it is necessary to provide two root nodes for
redundancy purpose. One way to implement this is to use two 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 standby HSMP LSP which takes on the 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 role as active HSMP LSP. The detail of redundancy mechanism is out
of the scope. of the scope.
6. 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 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 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 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 path on the leaf. The leaf node then sends the LSP Ping Echo Reply
along the upstream path of HSMP LSP, and end on the root that are the along the upstream path of HSMP LSP, and end on the root that are the
(intended) root node. (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 and Reverse-path Target FEC Stack TLV to define the corresponding
downstream FEC type. In order to ensure the leaf node to send the HSMP-downstream FEC type and HSMP-upstream FEC type. In order to
LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate ensure the leaf node to send the LSP Ping Echo Reply along the HSMP
Reverse Path) in Global Flags Field defined in [RFC6426] is reused upstream path, the R bit (Validate Reverse Path) in Global Flags
here. Field defined in [RFC6426] is reused here.
The node processing mechanism of LSP Ping Echo Request and Echo Reply 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: except the following:
1. The root node sending LSP Ping Echo Request message for HSMP LSP 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 MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit
to '1' in Global Flags Field. to '1' in Global Flags Field.
2. When the leaf node receiving the LSP Ping Echo Request, it MUST 2. When the leaf node receiving the LSP Ping Echo Request, it MUST
skipping to change at page 13, line 9 skipping to change at page 14, line 9
HSMP LSP Capability Parameter - requested value TBD HSMP LSP Capability Parameter - requested value TBD
The value should be allocated from the range 0x0901-0x3DFF (IETF The value should be allocated from the range 0x0901-0x3DFF (IETF
Consensus) using the first free value within this range. Consensus) using the first free value within this range.
8.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 This document requires allocation of two new sub-TLV types for
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) and Reverse-path Target FEC Stack TLV (TLV type 16).
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
The value should be allocated from the IETF Standards Action range The value should be allocated from the IETF Standards Action range
(0-16383) that is used for mandatory and optional sub-TLVs that (0-16383) that is used for mandatory and optional sub-TLVs that
requires a response if not understood. The value should be allocated requires a response if not understood. The value should be allocated
using the lowest free value within this range. using the lowest free value within this range.
skipping to change at page 14, line 16 skipping to change at page 15, line 16
S., and T. Nadeau, "Detecting Data-Plane Failures in S., and T. Nadeau, "Detecting Data-Plane Failures in
Point-to-Multipoint MPLS - Extensions to LSP Ping", Point-to-Multipoint MPLS - Extensions to LSP Ping",
RFC 6425, November 2011. RFC 6425, November 2011.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing", On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011. RFC 6426, November 2011.
10.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
Root-Initiated Point-to-Multipoint Pseudowire using LDP",
draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.
[I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-05 (work in
progress), June 2013.
[IEEE1588]
"IEEE standard for a precision clock synchronization
protocol for networked measurement and control systems",
IEEE1588v2 , March 2008.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala,
"Multipoint LDP In-Band Signaling for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths",
RFC 6826, January 2013.
Authors' Addresses 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
 End of changes. 14 change blocks. 
78 lines changed or deleted 43 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/