Network Working Group Yue.Chen
Internet-Draft Zhengzhou Institute of Information
Expires: October 8, 2011 Science and Technology
Julong.Lan
NDSC
Pengxu.Tan
Hongyong.Jia
Zhengzhou Institute of Information
Science and Technology
Dourui.Yu
NDSC
April.8, 2011
A Virtual Channel based Inter-domain Any Source Multicast Protocol
draft-ychen-vc-id-asm-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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.
This Internet-Draft will expire on April 1, 2011.
Copyright Statement
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
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
Y.Chen et al. Expires October 10, 2011 [Page 1]
Internet Draft Virtual Channel Any Source Multicast April.8
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 6.b of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
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 [RFC2119].
Abstract
This document defines VC-ID-ASM, a virtual channel based inter-
domain any source multicast protocol. Based on extended source
specific multicast, the participants join a virtual channel and a
shared tree is formed. The receivers receive the multicast traffic
along the shared tree, sense the source addresses and then initiate
the switch process from the shared tree to the source trees.
Table of Contents
Copyright Statement............................................... 1
1 Introduction.................................................... 2
2 VC-ID-ASM....................................................... 3
2.1 Many-to-many Group Communication and Group Address
Consideration..................................................... 3
2.2 Initial Shared Tree Setup by Extended PIM-SSM................. 5
2.2.1 Virtual channel selection................................... 5
2.2.2 (*,g) state................................................. 5
2.2.3 IGMP/MLD message extension and DR's processing.............. 5
2.2.4 JOIN/REQS/LEAVE message processing by extended PIM-SSM...... 6
2.2.5 Switching from the Shared Tree to the Source Trees.......... 7
2.2.6 VC-ID-ASM Packet Forwarding Rule............................ 8
3 Security Considerations......................................... 8
IANA Considerations............................................... 8
Normative References.............................................. 8
Author's Address.................................................. 9
1 Introduction
IP multicast model includes Any Source Multicast (ASM) and Source
Specific Multicast (SSM) models. ASM provides many-to-many packet
delivery, while SSM provides one-to-many packet delivery in IP
layer.
The typical intra-domain ASM protocol is Protocol Independent
Multicast Routing Protocols-Sparse Mode (PIM-SM)[1]. In PIM-SM, the
multicast traffic firstly gathers to a Rendezvous Point (RP), and
Y.Chen et al. Expires October 8, 2011 [Page 2]
Internet Draft Virtual Channel Any Source Multicast April.8
then reaches the receivers along the shared tree rooted at RP. When
the routers directly connected with the receivers (DRs) sense a
multicast source, they initiates join to the source and multicast
tree rooted at the source is formed. But PIM-SM has the following
flaws. (1) It relies on RP, and will cause heavy traffic at and
around RP. Computing and distribution the mapping of a group and a
RP will consume a great deal computing and bandwidth resource. (2)
It is complex, especially in the source registration process. (3)
It cannot support inter-domain multicast by itself. One inter-
domain scheme is MBGP[2]/PIM-SM[1]/MSDP[3]. But the scheme has
serious problems in scalability, security, and group address
management. Another inter-domain multicast schema put forward by
IETF is MASC/BGMP. Because of its complexity, it is not widely used.
The above flaws baffle the deployment of the large scale inter-
domain ASM application, and it is urgent to put forward a simple
effective inter-domain ASM protocol.
Compared with ASM, SSM is a simple. The typical protocol of SSM is
PIM-SSM[6], which is a subset of PIM-SM. The introduction of the
channel eliminates the dependency to RP and make it directly
support inter-domain single source multicast application. Inspired
by SSM, VC-ID-ASM, a virtual channel based inter-domain any source
multicast protocol, is put forward. It uses the extended PIM-SSM to
build a many-to-many inter-domain shared tree for initial group
communication and switch to the source trees when the receivers
sense the sources for the received packets' heads. Compared with
the other schemes, VC-ID-ASM is simple and can support inter-domain
ASM application by itself.
2 VC-ID-ASM
2.1 Many-to-many Group Communication and Group Address Consideration
The multi-source group communication process of VC-ID-ASM includes
two steps.
Step1: forming the initial shared tree and source discovery.
Firstly, a visual channel identifier <s,g>, including it supports a
specific ASM application, is published in certain ways (via web
pages, etc). s is an addressable IP address (commonly a address in
core network equipment, near the center of the participants) . s is
not the real multicast source, and it only tells the routers what
direction they should send the JOIN(for applying receiving the
traffic)/REQS(for applying sending the traffic) messages. g is a
multicast group identifier. Secondly, after the senders and
receivers get the channel address, they tell the DRs by sending
extended IGMPv3[5] (or MLDv2[6], for IPv6) messages that they want
Y.Chen et al. Expires October 8, 2011 [Page 3]
Internet Draft Virtual Channel Any Source Multicast April.8
to send or to receive the group traffic. The routers send the
JOIN/REQS messages to the shortest path interface towards s, hop-
by-hop. The routers along the shortest path process the messages to
create or maintain the (*,g) states, and the initial shared tree is
formed. Thirdly, the group traffic is transmitted alone the shared
tree and the receivers sense the real source set S={s1,s2,...,sm}.
Step2: forming the source specific trees.
+---+ +--+
|sr1| |r1|
+---+ +--+
| |
| |
+--+ +--+
|R1| |R2|
+--+ +--+
\ /
\ /
+--+ +--+ +------+ +--+ +--+
|r4|----|R3|----| R4 |----|R5|----|r2|
+--+ +--+ +------+ +--+ +--+
\ / | \ |
\ / | \I1 |I2
+---+ +---+ +--+ +---+ +----+ +---+ +--+
|sr3|---|R14|---|R6|--|R7-|----| R8 |----|R10|---|s1|
+---+ +---+ +--+ +---+ I4+----+I3 +---+ +--+
\ / \ /
\ / \I1 I3/
+--+ +---+ +---+ +--------+ +---+
|s2|---|R13|---|R12|----| R9 |----|R11|
+--+ +---+ +---+ I2+--------+I4 +---+
| |
| |
+--+ +---+
|r3| |sr2|
+--+ +---+
Figure1 The shared tree rooted at s and the
source tree rooted at s1
Be aware of si in S by receiving the multicast packets, the
receivers tell theirs DRs they want the traffic of channel
<si,g>(1<=i<=m) by sending IGMPv3 messages. The routers send the
PIM-SSM JOIN messages to the shortest path interface towards si,
hop-by-hop. And the source tree rooted at si is formed. Then the
group traffic from si delivers to the receivers along the source
tree. When the traffic alone the source tree reaches the receivers,
they can optionally send IGMP or MLD message to leave channel <s,g>,
and the routers send extended PIM-SSM LEAVE messages to the
Y.Chen et al. Expires October 8, 2011 [Page 4]
Internet Draft Virtual Channel Any Source Multicast April.8
shortest path interface towards s, hop by hop, to eliminate the
(*,g) on the shared tree rapidly.
The routers need to run extended PIM-SSM to process JOIN/REQS/LEAVE
messages. Considering the compatibility with standard PIM-SSM, a
group address adopted by VC-ID-ASM must be a SSM address, and
specific reserved bits need to be set to identify that it is a VC-
ID-ASM address. For IPv4 network, a special range in 232.0.0.0-
232.0.0.255 can be divided out to denote VC-ID-ASM groups. For IPv6
network, a special value of the reserved 4 flag bits can be used to
denote VC-ID-ASM groups.
Take Fig. 1 as an example, the group senders are s1 and s2,
receivers are r1,r2,r3 and r4, and senders as well as receivers are
sr1,sr2 and sr3. Router i is denoted as Ri. The broken lines with
arrows denote the shared tree rooted at s formed by extended PIM-
SSM, and the real lines with arrows denote the source tree rooted
at source s1 (the other source trees are neglected).
2.2 Initial Shared Tree Setup by Extended PIM-SSM
2.2.1 Virtual channel selection
There are two methods to select a virtual channel s. The one
is that we specify a static s which is in the core network to be
the virtual channel. The other is that a s in the core network is
choosen using a selection algorithm, such as a random core
selection algorithm.
2.2.2 (*,g) state
(*,g) state formed by extended PIM-SSM includes four fields
<*,g,ilist,olist>, where * means it can match any source, g is a
VC-ID-ASM group address, ilist is the incoming interface list, and
olist is the outgoing interface list. In Fig. 1, for (*,g) of R8,
ilist is {I4}, and olist is {I2}. For (*,g) of R9, the ilist is
{I1,I3,I4}, and olist is {I1,I2,I4}. Also, the (*,g) states are
soft states. The expirations of the interface timer and the state
timer will eliminate corresponding interface in ilist or olist, or
the whole state.
2.2.3 IGMP/MLD message extension and DR's processing
In VC-ID-ASM, a host needs to tell its DR that it applies to
send/receive group traffic or leave a group. The value of "Type"
field in IGMP/MLD message can be extended to fulfill this. Take
MLDv2 message for example. Its "Type" field includes 8 bits. Its
value is 130,131 or 132 represents the message is a Multicast
Listener Query, a Multicast Listener Report or a Multicast Listener
Done message. The field value can be extended as: when its value is
133, the message is a "Multicast Sender Report" message which
represents the host applies to send the group traffic.
When a DR receives a extended IGMP/MLD message, it creates or
maintains its (*,g) state. Diffident with standard PIM-SSM, when
receiving a Multicast Sender Report message from a host, it adds
the interface receiving the message to ilist of its (*,g) state;
Y.Chen et al. Expires October 8, 2011 [Page 5]
Internet Draft Virtual Channel Any Source Multicast April.8
when receiving a Multicast Listener Done message from a host, it
removes the interface receiving the message from olist and ilist of
its (*,g).
Then, according the different requests from the host, the DR sends
JOIN/REQS/LEAVE message towards s. When sending JOIN message, it
adds the sending interface to ilist of its (*,g) state. When
sending REQS message, it adds the sending interface to olist of its
(*,g) state. When sending LEAVE message, it removes the sending
interface from ilist and olist of its (*,g) state.
2.2.4 JOIN/REQS/LEAVE message processing by extended PIM-SSM
In control plane, VC-ID-ASM uses extended PIM-SSM JOIN/REQS/LEAVE
messages to create and maintain (*,g) states. The type of extended
PIM-SSM message includes JOIN (for applying receiving the traffic),
REQS (for applying sending the traffic) and LEAVE (for applying
leaving the group). JOIN and REQS can be combined in one message,
and LEAVE must be used separately. The highest 3 bits in
"reversed1" field of SSM message specifies the type of the messages.
In the 3 bits, the bit from the highest to the lowest represents
whether or not ('1' or '0') expecting to receive the group traffic,
whether or not ('1' or '0') expecting to send the group traffic and
whether or not ('1' or '0') expecting to leave the group
respectively.
When a router r receives a JOIN/REQS/LEAVE message sent from a
downstream router on interface I, it processes the message as
follows.
1. If the message type is '100', '010' or '110', and r does not has
(*,g) state, r generates a (*,g) state, with its ilist and olist
be set {}.
2. If the message type is '1?0' (where ? represents '1' or '0'), r
adds I to the olist of its (*,g) state.
3. If the message type is '?10', r adds I to the ilist of its (*,g)
state.
4. If the message type is '??1', r removes I from the ilist and the
olist of its (*,g) state.
After that, suppose the shortest path interface from r to s is I',
r processes as follows.
1. If the set of the ilist and olist without {I'} is null,
indicating there is neither sender nor receiver downstream, r
Y.Chen et al. Expires October 8, 2011 [Page 6]
Internet Draft Virtual Channel Any Source Multicast April.8
immediately sends LEAVE message (whose type is '??1') to I', and
eliminates its (*,g) state;
2. If the set of the ilist and olist without {I'} is null and r's
(*,g) state is a newly generated one, r immediately sends
JOIN/REQS message to I', or else, r sends JOIN/REQS message to
I' when JOIN/REQS timer expires;
3. If the set of ilist without {I'} is null and the set of olist
without {I'} is not null, indicating there is receiver and no
sender downstream, r sends the message with type '100' and adds
I' to the ilist of its (*,g) state;
4. If the set of olist without {I'} is null and the set of ilist
without {I'} is not null, indicating there is sender and no
receiver downstream, r sends the message with type '010' and
adds I' to the olist of its (*,g) state;
5. If the set of olist without {I'} is not null and the set of
ilist without {I'} is also not null, indicating there is sender
and receiver downstream, r sends the message with type '110' and
adds I' to the ilist and olist of its (*,g) state.
2.2.5 Switching from the Shared Tree to the Source Trees
After forming the shared tree, the group traffic will reach the
receivers along it. Being aware of a source address si from the
multicast packet header, the receiving hosts apply to join <si,g>
channel using IGMPv3 or MLDv2 messages, and the routers send
JOIN(si,g) messages to the shortest path interface towards si, hop
by hop, to establish the source tree rooted at si.
In VC-ID-ASM, the participants of ASM application can begin to
apply to send or receive the group traffic at a time point t1, and
should let the group traffic from all sources reaches all receivers
in a time period t2 after t1. That is, at the time point t1+t2, the
receivers should be aware of the source set S={s1,s2, ...,sm }.
After t1+t2, the receivers will send extended IGMP or MLD message
to leave <s,g> channel, and then the routers send extended PIM-SSM
LEAVE messages towards s to eliminate the (*,g) on the shared tree.
According to above rule, after t1+t2, a new participant can not
take part in the group communication. While, the switching process
is initiated by the user's host; and the value of t1 and t2 can be
set in the terminal programs to meet the needs of the ASM
application. For example, in a video conference application, t1 is
set to 9:00 a.m. and t2 is set to 30 minutes, which means the
conference begin at 8:00, and after 8:30 a user can not take part
in the conference. For the application that anyone can take part in
Y.Chen et al. Expires October 8, 2011 [Page 7]
Internet Draft Virtual Channel Any Source Multicast April.8
the whole group application process, t2 should be equal to or
greater than the whole application duration.
2.2.6 VC-ID-ASM Packet Forwarding Rule
When a router r receivers a VC-ID-ASM packet P, whose source
address is si and destination address is g, on a interface iif, it
will forward the packet according to the following rule (related
functions can be found in [1], only PIM-SSM functions are
considered and the assert mechanics is ignored).
o-list = NULL;
if ((si,g) state exists) and (RPF check succeeds)
o-list= olist(si,g);
else if ((*,g) state exists) and (iif is in ilist of (*,g))
{o-list = olist(*,g);
o-list = o-list (-) iif};
Forwards P on each interface in o-list;
Above process shows that if a router is the intersection of the
shared tree and the source tree, it will firstly forward the packet
along the source tree. Take R8 for example. It has (s1,g) and (*,g)
state. When R8 receives a VC-ID-ASM packet, whose source address is
s1 and destination address is g, on interface I3, It will firstly
matches the (s1,g) state, and forwards the packet on I1 and I2,
which are in the olist of the (s1,g) state.
3 Security Considerations
All of the VC-ID-ASM protocol messages (Join/Prune and Hello etc.)
are identical, both in format and functionality, to the respective
messages used in PIM-SM. Security considerations for these
messages are to be found in [1].
It is recommended that IPsec authentication be applied to all VC-
ID-ASM protocol messages. The specification on how this is done is
found in [1]. Specifically, the authentication of PIM-SM link-
local messages, described in [1], applies to all VC-ID-ASM messages
as well.
The denial-of-service attack based on forged Join messages,
described in [1], also applies to VC-ID-ASM.
IANA Considerations
This document makes no request of IANA.
Normative References
Y.Chen et al. Expires October 8, 2011 [Page 8]
Internet Draft Virtual Channel Any Source Multicast April.8
[1] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised), RFC4601, August 2006.
[2] T. Bates, Y. Rekhter, R. Chandra, and D. katz, Multiprotocol
Extensions for BGP-4, RFC4760. January 2007.
[3] M. McBride, J. Meylor, Multicast Source Discovery Protocol
(MSDP) Deployment, RFC4611, August 2006.
[4] H. Holbrook, B. Cain, Source-specific multicast for IP, RFC4607,
Augest 2006.
[5] B Cain, S. Deering, Internet Group Management Protocol Version
3, RFC3376, October 2002.
[6] R.Vida, Ed.r, Multicast Listerner Discovery Version 2(MLDV2)
for IPv6, RFC3810, June 2004.
Author's Address
Yue Chen
Zhengzhou Institute of Information Science and Technology
12 Shangcheng Road
Zhengzhou 450004
P.R.China
EMail: cyue2008@yahoo.com.cn
Julong Lan
National Digital Switching System Engneering Technological Reserch
Center, P.R.China(NDSC)
Lianxue Road
Zhengzhou 450004
P.R.China
Email: ndscljl@163.com
Pengxu Tan
Zhengzhou Institute of Information Science and Technology
12 Shangcheng Road
Zhengzhou 450004
P.R.China
EMail: tanpengxu@gmail.com
Hongyong.Jia
Zhengzhou Institute of Information Science and Technology
12 Shangcheng Road
Zhengzhou 450004
P.R.China
Y.Chen et al. Expires October 8, 2011 [Page 9]
Internet Draft Virtual Channel Any Source Multicast April.8
EMail: Jiahy_pla@126.com
Dourui.Yu
National Digital Switching System Engneering Technological Reserch
Center, P.R.China(NDSC)
Lianxue Road
Zhengzhou 450004
P.R.China
EMail: ly_dry@126.com
Y.Chen et al. Expires October 8, 2011 [Page 10]