< draft-zzhang-mpls-rmr-multicast-02.txt   draft-zzhang-mpls-rmr-multicast-03.txt >
MPLS Z. Zhang MPLS Z. Zhang
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational S. Esale Intended status: Informational S. Esale
Expires: July 29, 2019 Juniper Networks, Inc. Expires: November 8, 2019 Juniper Networks, Inc.
January 25, 2019 May 7, 2019
Resilient MPLS Rings and Multicast Resilient MPLS Rings and Multicast
draft-zzhang-mpls-rmr-multicast-02 draft-zzhang-mpls-rmr-multicast-03
Abstract Abstract
With Resilient MPLS Rings (RMR), although all existing multicast With Resilient MPLS Rings (RMR), although all existing multicast
procedures and solutions can work as is, there are optimizations that procedures and solutions can work as is, there are optimizations that
could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting
for both mLDP and RSVP-TE P2MP tunnels. This document describes RMR for both mLDP and RSVP-TE P2MP tunnels. This document describes RMR
multicast on a high level, with detailed protocol procedure for RSVP- multicast on a high level, with detailed protocol procedure for RSVP-
TE P2MP optimizations specified in a separate document. This TE P2MP optimizations specified in a separate document. This
document also discusses end to end multicast when there are RMRs. document also discusses end to end multicast when there are RMRs.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 July 29, 2019. This Internet-Draft will expire on November 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. P2MP/MP2MP Tunnels on a Ring . . . . . . . . . . . . . . . . 3 2. P2MP/MP2MP Tunnels on a Ring . . . . . . . . . . . . . . . . 3
2.1. Tunnel Protection and FRR . . . . . . . . . . . . . . . . 3 2.1. Tunnel Protection and FRR . . . . . . . . . . . . . . . . 3
3. End to End Tunnels with Rings . . . . . . . . . . . . . . . . 4 3. End to End Tunnels with Rings . . . . . . . . . . . . . . . . 4
4. End to End Native Multicast with Rings . . . . . . . . . . . 5 4. End to End Native Multicast with Rings . . . . . . . . . . . 4
4.1. Native Multicast in the Global Routing Table . . . . . . 5 4.1. Native Multicast in the Global Routing Table . . . . . . 4
4.2. mLDP Inband Signaling . . . . . . . . . . . . . . . . . . 5 4.2. mLDP Inband Signaling . . . . . . . . . . . . . . . . . . 4
4.3. Overlay Multicast Services . . . . . . . . . . . . . . . 5 4.3. Overlay Multicast Services . . . . . . . . . . . . . . . 4
4.3.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . 5 4.3.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . 5
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
This document discusses how multicast works with Resilient MPLS Rings This document discusses how multicast works with Resilient MPLS Rings
[I-D.ietf-mpls-rmr]. It is expected that readers are familiar with [I-D.ietf-mpls-rmr]. It is expected that readers are familiar with
the concept and terms in [I-D.ietf-mpls-rmr]. the concept and terms in [I-D.ietf-mpls-rmr].
All existing multicast procedures and solutions can work as is. This All existing multicast procedures and solutions can work as is. This
include both mpls multicast tunnels and end-to-end multicast that include both mpls multicast tunnels and end-to-end multicast that
makes use of multicast tunnels. Ring topology is just a special case makes use of multicast tunnels. Ring topology is just a special case
of general topologies so all existing RSVP-TE P2MP [RFC4875] and mLDP of general topologies so all existing RSVP-TE P2MP [RFC4875] and mLDP
[RFC6388] tunnels can be set up using existing protocols and [RFC6388] tunnels can be set up using existing protocols and
procedures. An Ingress Replication (IR) tunnel [RFC7988] consists a procedures. An Ingress Replication (IR) tunnel [RFC7988] consists a
bunch of P2P LSPs, and it does not matter whether a component LSP is bunch of P2P LSPs, and it does not matter whether a component LSP is
a plain old LSP or a Ring LSP. a plain old LSP or a Ring LSP.
On the other hand, there are optimizations that could be done for On the other hand, there are optimizations that could be done for
RSVP-TE P2MP tunnel signaling and Fast-ReRouting (FRR) for both mLDP RSVP-TE P2MP tunnel signaling and Fast-ReRouting (FRR) for both mLDP
and RSVP-TE P2MP tunnels. This document describes that on a high and RSVP-TE P2MP tunnels. This document describes that on a high
level, with detailed protocol procedure for RSVP-TE P2MP level, and discusses end to end multicast when there are RMRs even
optimizations specified in [I-D.zzhang-teas-rmr-rsvp-p2mp]. This
document also discusses end to end multicast when there are RMRs even
though RMR could be transparent to multicast. though RMR could be transparent to multicast.
2. P2MP/MP2MP Tunnels on a Ring 2. P2MP/MP2MP Tunnels on a Ring
Because mLDP label mapping messages are merged as they propagate from Because mLDP label mapping messages are merged as they propagate from
the leaves towards the root, ring topology does not lead to any the leaves towards the root, ring topology does not lead to any
further optimization. further optimization in tunnel signaling.
For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR
discovers leaves and signals one sub-LSP for each leaf. Even though
the forwarding state is merged at each hop (i.e, one incoming label
mapping to multiple outgoing entries), the control plane maintains
individual sub-LSP state. This leads to lots of redundant state on
routers close to the ingress. With RMR, this can be optimized such
that only a single LSP is signaled, with all the leaves listed in the
PATH message. As the PATH message passes along the ring, the leaves
send RESV messages, but only one RESV message reaches the tunnel
ingress.
The ingress LSR may also send PATH messages in both directions, so
that the tunnel is set up in such a way that minimum delay is
incurred for traffic to reach all leaves. Alternatively, the ingress
may send PATH message only in one direction for best bandwidth
utilization. For example, a leaf D is three hops away from the
ingress A in clockwise direction (A,B,C,D) and four hops away in the
other direction (A,E,F,G,D), but G is also a leaf so it may be better
to just send the PATH message in the anticlockwise direction.
Each router establishes forwarding state accordingly. Transit
routers switches traffic towards downstream. A transit router could
also be a leaf router and in that case it does "drop and continue" -
sends traffic off the ring and switches traffic downstream.
MP2MP RSVP-TE tunnel can also be easily achieved. The PATH message
could carry a label for the downstream router to send traffic to its
upstream. Then the ingress and each leaf can use the same tunnel to
send traffic to each other.
The PATH message does not need to list all leaves. As long as a leaf However RSVP-TE P2MP tunnel signaling and procedures can be greatly
somehow determines that it is a leaf, it can send RESV message when optimized, as specified in [I-D.zzhang-teas-rmr-rsvp-p2mp].
it receives the PATH message. This makes it leaf-initiated like mLDP
P2MP tunnels, which may have advantages in certain situations.
2.1. Tunnel Protection and FRR 2.1. Tunnel Protection and FRR
Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to Each node on a ring signals two counter-rotating MP2P Ring LSPs to
itself. As these LSPs are self-signaled after the discovery of the itself. As these LSPs are self-signaled after the discovery of the
ring, they can be used to protect P2MP LSPs on ring. So neither mLDP ring, they can be used to protect P2MP LSPs on ring. So neither mLDP
nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node
protection. For instance, consider a ring with 8 nodes. protection. For instance, consider a ring with 8 nodes:
Root Root
R0 . . . R1 R0 . . . R1
. . . .
R7 R2 Leaf R7 R2 Leaf
| . . | | . . |
Anti- | . RingID=17 . | Anti- | . RingID=17 . |
Clockwise v . . v Clockwise Clockwise v . . v Clockwise
Leaf R6 R3 Leaf R6 R3
skipping to change at page 7, line 9 skipping to change at page 6, line 27
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.zzhang-teas-rmr-rsvp-p2mp] [I-D.zzhang-teas-rmr-rsvp-p2mp]
Zhang, Z., Deshmukh, A., and R. Singh, "RSVP-TE P2MP Zhang, Z., Deshmukh, A., and R. Singh, "RSVP-TE P2MP
Tunnels on RMR", draft-zzhang-teas-rmr-rsvp-p2mp-00 (work Tunnels on RMR", draft-zzhang-teas-rmr-rsvp-p2mp-02 (work
in progress), July 2018. in progress), January 2019.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>. <https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP) LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>. <https://www.rfc-editor.org/info/rfc4762>.
 End of changes. 12 change blocks. 
55 lines changed or deleted 21 lines changed or added

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