draft-ietf-softwire-mesh-multicast-06.txt   draft-ietf-softwire-mesh-multicast-07.txt 
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: July 19, 2014 J. Wu Expires: January 19, 2015 J. Wu
S. Yang S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
January 15, 2014 July 18, 2014
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-06 draft-ietf-softwire-mesh-multicast-07
Abstract Abstract
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their attendant protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. As part of the transition to
IPv6, there will be scenarios where a backbone network running one IP IPv6, there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). It is IP address family (referred to as external IP or E-IP). It is
expected that the I-IP backbone will offer unicast and multicast expected that the I-IP backbone will offer unicast and multicast
transit services to the client E-IP networks. transit services to the client E-IP networks.
Softwire Mesh is a solution to E-IP unicast and multicast support Softwire Mesh is a solution to E-IP unicast and multicast support
across an I-IP backbone. This document describes the mechanisms for across an I-IP backbone. This document describes the mechanisms for
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 July 19, 2014. This Internet-Draft will expire on January 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their attendant protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. As part of the transition to
IPv6, there will be scenarios where a backbone network running one IP IPv6, there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). IP address family (referred to as external IP or E-IP).
The preferred solution is to leverage the multicast functions The preferred solution is to leverage the multicast functions
inherent in the I-IP backbone, to efficiently and scalably forward inherent in the I-IP backbone, to efficiently and scalably forward
client E-IP multicast packets inside an I-IP core tree, which roots client E-IP multicast packets inside an I-IP core tree, which roots
at one or more ingress AFBR nodes and branches out to one or more at one or more ingress AFBR nodes and branches out to one or more
skipping to change at page 4, line 4 skipping to change at page 4, line 4
requires that the client E-IP source-rooted or shared tree should requires that the client E-IP source-rooted or shared tree should
traverse the I-IP backbone network. traverse the I-IP backbone network.
One method to accomplish this is to re-use the multicast VPN approach One method to accomplish this is to re-use the multicast VPN approach
outlined in [RFC6513]. MVPN-like schemes can support the softwire outlined in [RFC6513]. MVPN-like schemes can support the softwire
mesh scenario and achieve a "many-to-one" mapping between the E-IP mesh scenario and achieve a "many-to-one" mapping between the E-IP
client multicast trees and the transit core multicast trees. The client multicast trees and the transit core multicast trees. The
advantage of this approach is that the number of trees in the I-IP advantage of this approach is that the number of trees in the I-IP
backbone network scales less than linearly with the number of E-IP backbone network scales less than linearly with the number of E-IP
client trees. Corporate enterprise networks and by extension client trees. Corporate enterprise networks and by extension
multicast VPNs have been known to run applications that create a multicast VPNs have been known to run applications that create too
large amount of (S,G) states. Aggregation at the edge contains the many (S,G) states. Aggregation at the edge contains the (S,G) states
(S,G) states that need to be maintained by the network operator that need to be maintained by the network operator supporting the
supporting the customer VPNs. The disadvantage of this approach is customer VPNs. The disadvantage of this approach is the possible
the possible inefficient bandwidth and resource utilization when inefficient bandwidth and resource utilization when multicast packets
multicast packets are delivered to a receiver AFBR with no attached are delivered to a receiver AFBR with no attached E-IP receivers.
E-IP receivers.
Internet-style multicast is somewhat different in that the trees tend Internet-style multicast is somewhat different in that the trees are
to be relatively sparse and source-rooted. The need for multicast relatively sparse and source-rooted. The need for multicast
aggregation at the edge (where many customer multicast trees are aggregation at the edge (where many customer multicast trees are
mapped into a few or one backbone multicast trees) does not exist and mapped into a few or one backbone multicast trees) does not exist and
to date has not been identified. Thus the need for a basic or closer to date has not been identified. Thus the need for a basic or closer
alignment with E-IP and I-IP multicast procedures emerges. alignment with E-IP and I-IP multicast procedures emerges.
A framework on how to support such methods is described in [RFC5565]. A framework on how to support such methods is described in [RFC5565].
In this document, a more detailed discussion supporting the "one-to- In this document, a more detailed discussion supporting the "one-to-
one" mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6 one" mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6
scenarios will be discussed. scenarios will be discussed.
skipping to change at page 10, line 41 skipping to change at page 10, line 41
|<------------------uPrefix64------------------>| |<------------------uPrefix64------------------>|
Figure 5: IPv4-Embedded IPv6 Virtual Source Address Format Figure 5: IPv4-Embedded IPv6 Virtual Source Address Format
In this address format, the "prefix" field contains a "Well-Known" In this address format, the "prefix" field contains a "Well-Known"
prefix or an ISP-defined prefix. An existing "Well-Known" prefix prefix or an ISP-defined prefix. An existing "Well-Known" prefix
is 64:ff9b, which is defined in [RFC6052]; "v4" field is the IP is 64:ff9b, which is defined in [RFC6052]; "v4" field is the IP
address of one of upstream AFBR's E-IPv4 interfaces; "u" field is address of one of upstream AFBR's E-IPv4 interfaces; "u" field is
defined in [RFC4291], and MUST be set to zero; "suffix" field is defined in [RFC4291], and MUST be set to zero; "suffix" field is
reserved for future extensions and SHOULD be set to zero; "source reserved for future extensions and SHOULD be set to zero; "source
address" field stores the original S. We call the overall /96 address" field stores the original S. We call the overall /96
prefix ("prefix" field and "v4" field and "u" field and "suffix" prefix ("prefix" field and "v4" field and "u" field and "suffix"
field altogether) "uPrefix64". field altogether) "uPrefix64".
o E-IP network supports ASM o E-IP network supports ASM
The (S,G) source list entry and the (*,G) source list entry only The (S,G) source list entry and the (*,G) source list entry only
differ in that the latter have both the WC and RPT bits of the differ in that the latter have both the WC and RPT bits of the
Encoded-Source-Address set, while the former all cleared (See Encoded-Source-Address set, while the former all cleared (See
Section 4.9.5.1 of [RFC4601]). So we can translate source list Section 4.9.5.1 of [RFC4601]). So we can translate source list
entries in (*,G) messages into source list entries in (S'G') entries in (*,G) messages into source list entries in (S'G')
messages by applying the format specified in Figure 5 and clearing messages by applying the format specified in Figure 5 and clearing
skipping to change at page 14, line 17 skipping to change at page 14, line 17
follow the format specified in Figure 6, and the corresponding follow the format specified in Figure 6, and the corresponding
upstream AFBR of this source should announce the I-IPv4 address in upstream AFBR of this source should announce the I-IPv4 address in
"source address" field of this source's IPv6 address to the I-IPv4 "source address" field of this source's IPv6 address to the I-IPv4
network. Since uPrefix64 is static and unique in IPv6-over-IPv4 network. Since uPrefix64 is static and unique in IPv6-over-IPv4
scenario, there is no need to distribute it using BGP. The scenario, there is no need to distribute it using BGP. The
distribution of "source address" field of multicast source addresses distribution of "source address" field of multicast source addresses
is a pure I-IPv4 process and no more specification is needed. is a pure I-IPv4 process and no more specification is needed.
In this way, when a downstream AFBR receives a (S,G) message, it can In this way, when a downstream AFBR receives a (S,G) message, it can
translate the message into (S',G') by simply taking off the prefix in translate the message into (S',G') by simply taking off the prefix in
S. Since S' is known to every router in I-IPv4 network, the S. Since S' is known to every router in I-IPv4 network, the
translated message will eventually arrive at the corresponding translated message will eventually arrive at the corresponding
upstream AFBR, and the upstream AFBR can translate the message back upstream AFBR, and the upstream AFBR can translate the message back
to (S,G) by appending the prefix to S'. When a downstream AFBR to (S,G) by appending the prefix to S'. When a downstream AFBR
receives a (*,G) message, it can translate it into (S',G') by simply receives a (*,G) message, it can translate it into (S',G') by simply
taking off the prefix in *(the E-IPv6 address of RP). Since S' is taking off the prefix in *(the E-IPv6 address of RP). Since S' is
known to every router in I-IPv4 network, the translated message will known to every router in I-IPv4 network, the translated message will
eventually arrive at RP'. And since every PIM router within a PIM eventually arrive at RP'. And since every PIM router within a PIM
domain must be able to map a particular multicast group address to domain must be able to map a particular multicast group address to
the same RP (see Section 4.7 of [RFC4601]), RP' knows that S' is the the same RP (see Section 4.7 of [RFC4601]), RP' knows that S' is the
mapped I-IPv4 address of RP, so RP' will translate the message back mapped I-IPv4 address of RP, so RP' will translate the message back
skipping to change at page 16, line 43 skipping to change at page 16, line 43
In this example, the interface agent has two responsibilities: In the In this example, the interface agent has two responsibilities: In the
control plane, it should work as a real interface that has joined control plane, it should work as a real interface that has joined
(*,G) in representative of all the I-IP interfaces who should have (*,G) in representative of all the I-IP interfaces who should have
been outgoing interfaces of (*,G) state machine, and process the been outgoing interfaces of (*,G) state machine, and process the
(S,G,rpt) messages received from all the I-IP interfaces. The (S,G,rpt) messages received from all the I-IP interfaces. The
interface agent maintains downstream (S,G,rpt) state machines of interface agent maintains downstream (S,G,rpt) state machines of
every downstream AFBR, and submits Prune(S,G,rpt) messages to the every downstream AFBR, and submits Prune(S,G,rpt) messages to the
PIM-SM module only when every (S,G,rpt) state machine is at Prune(P) PIM-SM module only when every (S,G,rpt) state machine is at Prune(P)
or PruneTmp(P') state, which means that no downstream AFBR wants to or PruneTmp(P') state, which means that no downstream AFBR wants to
receive multicast data of (S,G) along the RPT of G. Once a (S,G,rpt) receive multicast data of (S,G) along the RPT of G. Once a (S,G,rpt)
state machine changes to NoInfo(NI) state, which means that the state machine changes to NoInfo(NI) state, which means that the
corresponding downstream AFBR has changed it mind to receive corresponding downstream AFBR has changed it mind to receive
multicast data of (S,G) along the RPT again, the interface agent multicast data of (S,G) along the RPT again, the interface agent
should send a Join(S,G,rpt) to PIM-SM module immediately; In the data should send a Join(S,G,rpt) to PIM-SM module immediately; In the data
plane, upon receiving a multicast data packet, the interface agent plane, upon receiving a multicast data packet, the interface agent
should encapsulate it at first, then propagate the encapsulated should encapsulate it at first, then propagate the encapsulated
packet onto every I-IP interface. packet onto every I-IP interface.
NOTICE: There may exist an E-IP neighbor of RP' that has joined the NOTICE: There may exist an E-IP neighbor of RP' that has joined the
RPT of G, so the per-interface state machine for receiving E-IP Join/ RPT of G, so the per-interface state machine for receiving E-IP Join/
skipping to change at page 18, line 38 skipping to change at page 18, line 38
operators to increase the MTU of every link. Fragmentation and operators to increase the MTU of every link. Fragmentation and
reassembling of encapsulated packets MUST be supported by AFBRs. reassembling of encapsulated packets MUST be supported by AFBRs.
8. Security Considerations 8. Security Considerations
The AFBR routers could maintain secure communications within Security The AFBR routers could maintain secure communications within Security
Architecture for the Internet Protocol as described in [RFC4301]. To Architecture for the Internet Protocol as described in [RFC4301]. To
protect against unwanted forged PIM protocol messages, the PIM protect against unwanted forged PIM protocol messages, the PIM
messages can be authenticated using IPsec as described in [RFC4601]. messages can be authenticated using IPsec as described in [RFC4601].
But when adopting some schemes that will cause heavy burden on But some schemes, which will cause heavy burden on routers, may be
routers, some attacker may use it as a tool for DDoS attack. used by attackers as a tool for DDoS attack. Compared with
Compared with [RFC4301], the security concerns should be more [RFC4301], the security concerns should be more carefully considered.
carefully considered. The attackers can set up many multicast trees The attackers can set up many multicast trees in the edge networks,
in the edge networks, causing too many multicast trees to get set up causing too many multicast trees to get set up in the core network.
in the core network.
9. IANA Considerations 9. IANA Considerations
When AFBRs perform address mapping, they should follow some When AFBRs perform address mapping, they should follow some
predefined rules, especially the IPv6 prefix for source address predefined rules, especially the IPv6 prefix for source address
mapping should be predefined, such that ingress AFBRs and egress mapping should be predefined, such that ingress AFBRs and egress
AFBRs can finish the mapping procedure correctly. The IPv6 prefix AFBRs can finish the mapping procedure correctly. The IPv6 prefix
for translation can be unified within only the transit core, or for translation can be unified within only the transit core, or
within global area. In the later condition, the prefix should be within global area. In the later condition, the prefix should be
assigned by IANA. assigned by IANA.
 End of changes. 12 change blocks. 
24 lines changed or deleted 22 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/