Network Working Group Feng Guo
Internet Draft Huawei Technologies Co., Ltd.
Expires: December 2007 June 28, 2007
Multicast Forwarding Equivalence Class [MFEC]
draft-guo-mboned-mfec-framework-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
At present, the multimedia services such as IPTV are gaining
importance. Multicast technologies play an inevitable role in these
multimedia services.
The main factors affecting the multicast technologies are the
convergence speed and the capacity of the multicast routing table.
One of the easiest and the most commonly practiced methods in
nowadays multicast deployment is to push the data to the end router
by static configurations (igmp static group). This will reduce the
delay in channel switching. The data flow of multiple channels from
Guo Expires December 28, 2007 [Page 1]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
one or several servers are transmitted along the distribution tree.
The distribution tree for multiple channels may be composed of only
one same distribution tree. A router, however, maintains separate
protocol-status and provides separate protocol-packets content for
each channel. This prolongs the route convergence, increases the
status-space and reduces the exchange rate of protocol-packets.
This document proposes a solution to speed up the route convergence,
reduce the states in the multicast forwarding table and increase the
exchange rate of packets. This can be achieved by using the same
state for the data flows that passes the same path in the
distribution tree. This same state is called Multicast Forwarding
Equivalent Class (MFEC). In other words, MFEC is a group of multicast
packets that are forwarded over the same path with the same traffic
handling treatment. This solution extends various multicast protocols
such as PIM- SSM, PIM-SM, Bidir-PIM, PIM-DM and DVMRP, and perfects
application of multicast.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119
.
Table of Contents
1. Introduction................................................3
1.1. Background.............................................3
1.2. Purpose................................................3
2. Definitions and Abbreviations...............................4
3. Framework for MFEC..........................................4
3.1. MFEC defining..........................................5
3.2. Rules of MFEC..........................................6
3.2.1. Dynamic MFEC Rule.................................6
3.2.2. Static MFEC Rule..................................7
3.3. Procedure of Application...............................7
4. Security Considerations....................................10
5. IANA Considerations........................................10
6. Acknowledgments............................................10
7. References.................................................10
7.1. Normative References..................................10
7.2. Informative References................................10
Author's Addresses............................................11
Intellectual Property Statement...............................11
Disclaimer of Validity........................................11
Guo Expires December 28, 2007 [Page 2]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
Copyright Statement...........................................11
1. Introduction
1.1. Background
The current multicast routing protocols, such as PIM-SSM, PIM-SM,
Bidir-PIM, PIM-DM and DVMRP, take (S/*, G) as the minimum unit. Even
though the data flow of multiple channels is transmitted along the
same path in the distribution tree, it is maintained by a router as
different (S/*, G)s. These different (S/*, G)s are expressed by
different segments of protocol-packets.
But in real applications some bundles of multicast sources and
groups are normally centralized to deploy, and most of multicast
traffic have to share the same path in the distribution tree.
The router maintains many (S/*, G)s and each (S/*, G) corresponds to
a distribution tree. This prolongs the route convergence and reduces
the efficiency for packet generation and exchange , and also may
occupy too much memory under general conditions.
Moreover, the terminal device needs to notify the router about the
address pair (source address and group address) of the interested
program. This requires the router to create and maintain a (S/*, G)
for each address pair. As a result, the router can be easily attacked
by the terminal device(if the environment is unsecured).
In the existing multicast deployments like IPTV we try to push all of
the programs to the edge-network by configuring igmp static join, or
at least push to the end of core network. Here the core or the
intermediate routers are also burdened with the entire multicast (S/*,
G) states.
1.2. Purpose
The purpose of this memo is to provide a generalized framework for
merging these redundant states. Thus we can reduce the state
information and maintenance cost in the core or intermediate routers.
By reducing the state information we can also increase the state
scalability of the multicast and prevent it from easy attacks.
This framework can also be a basis for future work to enhance
multicast expansibility and stability.
Guo Expires December 28, 2007 [Page 3]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
The scope of this document is not to propose a detailed protocol
instead we propose the idea of MFEC at an abstract level.
2. Definitions and Abbreviations
The document introduces the following definitions:
Multicast Forwarding Equivalent Class (MFEC): is a set of multicast
data packets that are forwarded in the same way, for example, a set
of the data packets that pass the same multicast distribution tree or
sub-tree and receive the same forwarding processing. By forwarding
processing also includes QoS treatment.
MFEC distribution tree: is the distribution tree that the MFEC passes.
It may be a traditional multicast distribution tree that takes the
source or RP as the root and takes receivers as leaves, a sub-tree or
a branch.
Egress router of MFEC distribution tree: is the leaf router of the
MFEC distribution tree. It is called Egress router for short.
Ingress router of MFEC distribution tree: is the root router of the
MFEC distribution tree. It is called Ingress router for short.
Transit router of MFEC distribution tree: is the router that exists
between the root router and the leaf router of the MFEC distribution
tree. It is called Transit router for short.
Abbreviations:
PIM Protocol Independent Multicast
PIM SM Protocol Independent Multicasts Sparse Mode
PIM SSM Protocol Independent Multicast Source-Specific
Multicast
MLD Multicast Listener Discovery
IGMP Internet Group Management Protocol
(S/*, G) (S, G) or (*, G) state as defined in PIM
MFIB Multicast Forwarding Information Base
3. Framework for MFEC
The basic idea for MFEC is to make data flow that passes through the
same distribution tree or sub-tree to use the same status. This speeds
up route convergence and reduces space occupation. Moreover, the
protocol state machine and protocol packets take MFEC rather than (S,
G) or (*, G) as the minimum unit. This improves the processing
Guo Expires December 28, 2007 [Page 4]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
efficiency of the state machine and the exchange rate of protocol-
packets.
The multicast based on MFEC can be applied to general multicast
network or VPN network.
A general high-level framework can be represented as follows.
--------------------------
/ MFEC \
| NETWORK |
+-------+ +-------+ +---------+ +-------+ +-------+
|Server |--|Ingress|<===>| Transit |<===>|Egress |--|Host |
| | |Router | | Router | |Router | | |
+-------+ +-------+ +---------+ +-------+ +-------+
| |
\ /
-------------------------
Figure 1.Basic Model of a MFEC network
Take the application of Multicast in IPTV as an example. As shown in
Figure 1, multiple programs of different channels are sent by the
same source (a server or multiple servers) to the router nearest to
receivers. The multiple multicast data flows, therefore, are
transmitted along the same path. The set of these data packets is
considered as an MFEC. The protocol status and protocol packet
exchange takes MFEC as the minimum unit.
By configuring the MFEC on the edge routers, we achieve to
reduce the forwarding state information maintained by the
transit core routers. An added advantage is that we need not
configure any extra tunnels. MFEC itself will take care of sending
joins in MFEC range and forwarding data between the edge routers
based on the multicast forwarding table maintain by the transit
routers. Operators need not bother about the tunneling configurations.
3.1. MFEC defining
MFEC can either be defined explicitly or implicitly. The data that
belongs to the same MFEC is forwarded by using the same forwarding
entry and corresponds to the same MFEC status.
Examples of MFEC are (source address, group address/mask), (source
address/mask, group address), (source address/mask, group
address/mask) etc.
MFEC is divided into dynamic MFEC and static MFEC accordingly. They
can be applied to multicast network or VPN network.
Dynamic MFEC: refers to the MFEC distribution tree that is
dynamically generated by the modified protocols. That is, MFEC status
can be switched from (S/*, G) automatically. According to the MFEC
mapping, once receiving IGMP/MLD Report or PIM join/prune packets,
the routers switch the (S/*, G) status to MFEC status. The multicast
distribution tree of MFEC is then established.
Static MFEC: refers to the MFEC distribution tree formed by the
statically configured MFEC routing entries or forwarding entries. The
static MFEC can be used to directly guide the data forwarding. That
Guo Expires December 28, 2007 [Page 5]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
is, the Egress router that runs IGMP/MLD can be statically configured
to receive (S, G/M). MFEC routing entries or forwarding entries can
be statically configured on routers to forward (S, G/M).
Both the dynamic MFEC and the static MFEC can co-exist. Edge nodes in
the network can be configured with static MFECs and at the same time
Learn dynamic MFECs.
3.2. Rules of MFEC
Following are the set of rules to be considered for MFEC. The
state machine takes the MFEC instead of (S, G) or (*, G) as the
minimum unit. For example, if the data of (S, G/M) belongs to an MFEC,
the state machine is downstream per-interface (S, G/M). The "M" in
the (S, G/M) indicates the mask.
3.2.1. Dynamic MFEC Rule
The application of dynamic MFEC refers to MFEC status that is
switched from (S/*, G). According to the MFEC mapping, once receiving
IGMP/MLD Report or PIM packets, the routers switch the (S/*, G)
status to MFEC status, or, Egress router that runs IGMP/MLD is
statically configured to receive (S, G/M). The multicast distribution
tree of MFEC is then established.
Rules 1 to 4 are schemes for modifying existing multicast
protocols.
1) Downstream per-interface (S, G/M) state machine: In the protocol-
packets, MFEC is used to replace (S, G) or (*, G). If the data of (S,
G/M) belongs to an MFEC, the G segment in (S, G) Join/Prune message
is filled in with M.
2) Multicast routing table: MFEC is used to replace (S, G) or (*, G)
in multicast routing table. If the data of (S, G/M) belongs to an
MFEC, the routing entry is expressed as (S, G/M, GE1/0/1, {GE 2/0/0,
GE 3/0/0}).
3) Multicast forwarding table: MFEC is used to replace (S, G) or (*,
G) in multicast forwarding table. If the data of (S, G/M) belongs to
an MFEC, the forwarding entry is expressed as (S, G/M, GE 1/0/1, {GE
2/0/0, GE 3/0/0}). Therefore the data forwarding is based on longest
prefix match lookup table (multicast forwarding table).
Guo Expires December 28, 2007 [Page 6]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
4) Mapping from (S/*, G) to MFEC: Ingress router defines the mapping
from (S/*, G) to MFEC. If the data of (S, G) belongs to an MFEC, the
multicast flow of (S, G) is mapped to the multicast flow of (S, G/M).
When a router receives the data of (S, G), it directly creates the (S,
G/M) status for the data. The mapping can be explicitly or implicitly
defined, or implemented by the dynamic extension of protocols.
Rules 5, 6 and 7 can be used separately or in combination as
required.
5) Mapping of MFEC to (S/*, G): Egress router defines the mapping
from MFEC to (S/*, G). If the data of (S, G/M) or (*, G/M) belongs to
an MFEC, the (S, G) or (*, G) PIM Join/Prune messages or that of the
IGMP/MLD Report messages is mapped from (S, G/M) or (*, G/M), and the
(S, G/M) or (*, G/M) status is created. The mapping can be explicitly
or implicitly defined, or implemented by the dynamic extension of
protocols.
3.2.2. Static MFEC Rule
The application of the static MFEC refers to the MFEC distribution
tree formed by the statically configuring MFEC routing entries or
forwarding entries. The static MFEC can be used to directly guide the
data forwarding. Moreover, you can set an active incoming interface
and a standby incoming interface for each MFEC status to enhance the
robustness of the multicast forwarding.
6) Statically joining the MFEC distribution tree: Configure Egress
router that runs IGMP/MLD to receive MFEC. The data of (S, G/M) or (*,
G/M) belongs to the same MFEC, the router creates (S, G/M) or (*, G/M)
status when configured to receive the data of (S, G/M) or (*, G/M).
7) Configure the status of the static MFEC to generate the multicast
routing table and forwarding table: If (S, G/M) belongs to an MFEC,
the routing entry and forwarding entry of static (S, G/M) can be
directly configured. The same MFEC can import data flow to the same
physical interface or tunnel interface (can be either multi-point
tunnel or single-point tunnel) such as the MTI in multicast VPN.
8) Statically configured MFEC-based MROUTE and MFIB: The outgoing
interface can be a tunnel (e.g. mvpn, p2mp) or a normal interface.
3.3. Procedure of Application
To be understood clearly, the following is a detailed procedure for
MFEC, taking PIM-SSM protocol with dynamic MFEC as example:
Guo Expires December 28, 2007 [Page 7]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
The basic procedures are applicable to IP multicast, including IPv4
multicast and IPv6 multicast, and also most multicast protocols, such
as the PIM-SM, PIM-DM, IGMP, and MLD etc.
+------+
|Source|
+------+
|
|DATA (S,G/M)
V
+-----------------+ <-- +-----------------+
|INGRESS ROUTER | PIM JOIN |TRANSIT ROUTER |
|6.Creates (S,G/M)| (S,G/M) |5.Creates (S,G/M)|
|add outgoing |------------|with downstream |---------+
|interface | 7.DATA |interface | |
+-----------------+ (S,G/M) +-----------------+ |
--> |
|
|
|
+-------------+ <-- +----------------+ <-- |
|HOST | DATA |EGRESS ROUTER | 8.DATA |
|1.needs to | (S,G/M) |3.MFEC switches | (S,G/M) |
|receive (S,G)|--------------|(S,G) to (S,G/M)|------------+
|information | 2.IGMPV3 | | 4.PIM JOIN
+-------------+ IS_IN(S,G) +----------------+ (S,G/M)
--> -->
Figure 2. logistic procedure of PIM-SSM MFEC
1) Egress router and Ingress router define the mapping from (*, G) or
(S, G) to (*, G/M) or (S, G/M) in advance (Static MFEC).
2) The receiver wants to receive the multicast flow of (S, G).
3) The receiver sends the IGMPv3/MLDv2 (S, G) Report message.
4) According to rule 6, Egress router receives the IGMPv3/MLDv2
(S, G) and switches it to (S, G/M). Or, according to rule 7,
Egress router that runs IGMP/MLD is statically configured to receive
(S, G/M). The outgoing interface is then added to (S, G/M).
Establishment of PIM-SSM multicast distribution tree is triggered.
Guo Expires December 28, 2007 [Page 8]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
5) According to rule 1, Egress router calculates the state
machine of (S, G/M) and sends PIM Join message of (S, G/M) to the
source according to rule 2.
6) The Transit router creates (S, G/M) status according to rule
1, 3 and 4, adds the outgoing interface and then sends the PIM-Join
message of (S, G/M) to the source according to rule 2.
7) Ingress router creates (S, G/M) status according to rule 1, 3
and 4 and adds the outgoing-interface. If no Layer 3 device exists
between Ingress router and the multicast source, the data flow sent
by the multicast source is forwarded in accordance with the MFEC
status.
If routers which do not support MFEC exist between the Ingress router
and the multicast source, do as follows:
(1) Configure the upstream router to forward data to Ingress
router according to rule 8.
(2) According to rule 5, configure Ingress router to switch
MFEC to multiple (S, G)s based on the mapping and then to send PIM-
Join message to the upstream router.
8) According to rule 4, after the multicast source sends the
data flow, Ingress router forwards the data based on the (S, G/M)
status.
9) According to rule 4, after receiving the multicast data flow,
Transit router forwards the data to the downstream router based on
the (S, G/M) status. Finally, the data is forwarded to the Egress
router that forwards the data to the receiver.
From above procedure, we can also observe the following significant
points:
The original protocols or implementations are described with (S/*, G)
as the minimum unit and this document extends the minimum unit to
MFEC. The improved protocol takes the MFEC as the minimum unit. The
data that belongs to the same MFEC corresponds to the same protocol
status and routing forwarding entry. Therefore, the running of a
protocol is not for a single address pair (source address, group
address) but for a set of multiple address pairs.
Exchange of protocol packets is based on MFEC. So the number of
protocol packets exchanged between MFEC enabled routers will be
reduced.
Guo Expires December 28, 2007 [Page 9]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
The data packets of the same MFEC are forwarded by the same multicast
forwarding entry.
Multicast protocol state machine and protocol-packets take MFEC
instead of (S, G) or (*, G) as the minimum unit. The multicast
routing table and forwarding table use MFEC to replace (*, G) or (S,
G) status.
The same MFEC can be imported to the same physical interface or
tunnel interface (multi-point tunnel or one-point tunnel) such as
Multicast Tunnel Interface (MTI) in multicast VPN.
4. Security Considerations
MFEC do not have any added impact on the security issues. At the same
MFEC is not adding any security improvements to the existing
multicast protocols. But due to the reduced state information storage,
the attack by the terminal devices on intermediate routers is reduced.
5. IANA Considerations
This document has no IANA considerations.
6. Acknowledgments
I would like to express special thanks to Muhammad Yaaseen and
Liangru for their inputs to this work.
7. References
7.1. Normative References
i Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A.Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
ii Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
iii P. Savola, R. Lehtonen, D. Meyer, "Protocol Independent
Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
Issues and Enhancements", RFC 4609, October 2006.
Guo Expires December 28, 2007 [Page 10]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
7.2. Informative References
Author's Addresses
Feng Guo
Huawei Technologies Co., Ltd.
No.3 Xinxi Rd.
Shang-Di Information Industry Base, Beijing P.R.China
Phone: 8610-82836841
Email: guofeng@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Guo Expires December 28, 2007 [Page 11]
Internet-Draft Multicast Forwarding Equivalence Class June 2007
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Guo Expires December 28, 2007 [Page 12]