One document matched: draft-xu-softwire-4over6multicast-00.txt
Network Working Group M. Xu
Internet-Draft Y. Cui
Expires: March 17, 2007 F. Meng
Tsinghua University
C. Metz
Cisco Systems, Inc.
September 13, 2006
IPv4 over IPv6 multicast
draft-xu-softwire-4over6multicast-00
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.
This Internet-Draft will expire on March 17, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The 4over6 mechanism is a mechanism to interconnect IPv4 networks
over IPv6 backbones and provide IPv4-to-IPv6 transparent routing.
The 4over6 unicast has been described in
draft-wu-softwire-mesh-framework-00.txt.
Xu, et al. Expires March 17, 2007 [Page 1]
Internet-Draft 4over6 September 2006
This memo provides the 4over6 multicast mechanism. We use BGP for
discovering and maintaining the membership among all the Provider
Edges (PE), and use IPv6 and IPv4 PIM-SM to construct the
distribution tree. In the IPv6 backbone, static PIM-SSM trees are
initially constructed for every PE. All the multicast traffic from
the same PE are forwarded through only one PIM-SSM tree to avoid P
routers maintaining too much state information. The process of
encapsulation and decapsulation is the same as 4over6 unicast.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constructing the RPT . . . . . . . . . . . . . . . . . . . . . 4
3. Forwarding data . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Normative References . . . . . . . . . . . . . . . . . . . 8
6.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 10
Xu, et al. Expires March 17, 2007 [Page 2]
Internet-Draft 4over6 September 2006
1. Introduction
This document gives the protocols and procedures that enable a SP
(Service Provider) to provide multicast service for 4over6 which is
based on the BGP MP attribute. Using multicast distribution tree is
the most efficient way to forward multicast data. In 4over6
multicast, the distribution tree comes through both the IPv4 and IPv6
networks.
We employ PIM-SM to construct the distribution tree. Sub-trees in
IPv4 customers and IPv6 backbone compose the whole RPT. Common
PIM-SM requires that the backbone maintain one or more source-trees
which are specific for a particular group. Each such tree requires
that state be maintained in all the routers that are in the tree.
This may bring too much overload to the backbone. To avoid this, for
every PE we construct only one source-tree whose leaves are all the
other PEs. All the multicast traffic from the same PE are forwarded
through this tree. This may cause some PE receives packets that they
do not need. This method is just a trade-off between maintaining a
lot of states in P routers and the optimality of the multicast
routing.
Xu, et al. Expires March 17, 2007 [Page 3]
Internet-Draft 4over6 September 2006
2. Constructing the RPT
The 4over6 unicast uses BGP to discover a new PE automatically and
carry the IPv4 routes behind the PE and the corresponding IPv6
address of the PE's virtual interface. We can use the automatic PE
discovery mechanism to construct an IPv6 PIM-SSM tree whose source is
a PE, and leaves are all the other PEs. All multicast traffic from
the PE are forwarded through this tree in the IPv6 backbone. We must
construct such an IPv6 PIM-SSM tree for each PE. For example, as
soon as a new PE1 is founded by PE2, PE2 will send Join message to
register to the PIM-SSM tree whose source is PE1. The group
addresses for these trees are:
ff18:aaaa:aaaa::x
Where a is the IPv4 address of the source PE's virtual interface, and
it is carried by BGP updates to other PES.
After all the IPv6 PIM-SSM trees are constructed, once a host in an
IPv4 customer network wants to register to a multicast group whose RP
is in another IPv4 customer network, the IPv4 Join message will be
delivered to the PE which connects the IPv4 network to IPv6 the back
bone. Then the PE lookups the IPv6 address of the PE connecting to
the IPv4 customer network which the RP belongs to, and encapsulates
the IPv4 Join message into an IPv6 unicast packet like a common
4over6 packet. When the encapsulated Join message arrives at the
egress PE, it will be decapsulated, and will continue to register to
the RP in IPv4 customer network.
If an ISP does not care to maintain the whole state information,
constructing PIM-SSM tree for every multicast group in the IPv6
backbone may also be adopted. Obviously, this option is optimistic
because no PE receives redundant packets. In this way, the PIM-SM
message will be translated in the ingress and egress PEs respectively
to construct the PIM-SSM tree in the IPv6 backbone, and the IPv4 (S,
G) can be mapped to the IPv6 (S', G'), where S' is the IPv6 virtual
interface address of the PE which is connected to the RP, G' is
ff18:ssss:ssss:gggg:gggg::x
If the source is in the same IPv4 network with the RP, its
registration procedure is the same as that of IPv4.
Xu, et al. Expires March 17, 2007 [Page 4]
Internet-Draft 4over6 September 2006
3. Forwarding data
When a source wants to send data to the whole group, it first sends
the unicast packets to the RP in IPv4 network as PIM-SM specified.
If the source is in the same IPv4 network with the RP, the data
forwarding is the same as that of IPv4 network, otherwise the data
must traverse through the IPv6 backbone and be encapsulated and
decapsulated as a common IPv4 unicast packet.
Then the RP hands the packets out to all the members by multicast.
When the IPv4 multicast packets arrive at the ingress PE, they are
encapsulated into IPv6 multicast packets with the IPv6 address of PE
virtual interface as source and the mapping group address as IPv6
group address. The encapsulated multicast packets are delivered as
common IPv6 multicast packets until arriving at the egress PE, where
they are decapsulated and forwarded along the IPv4 PIM-SM RPT.
If the IPv4 multicast data rate exceeds the configured threshold, the
RPT should switch to shortest path tree (SPT) as the PIM-SM
specified. Receivers in IPv4 must register to the source as they
register to the RP. When using static PIM-SSM trees, there is
nothing modified in the IPv6 backbone. In contrast, when using a
PIM-SSM tree for every group, a new PIM-SSM tree may be initialized
in the IPv6 backbone whose source is the PE which is connected to the
same IPv4 customer network with the source.
Xu, et al. Expires March 17, 2007 [Page 5]
Internet-Draft 4over6 September 2006
4. Security Considerations
The PE routers could maintain secure communications through the use
of Security Architecture for the Internet Protocol as described in
[RFC4301].
Xu, et al. Expires March 17, 2007 [Page 6]
Internet-Draft 4over6 September 2006
5. IANA Considerations
To be supplied.
Xu, et al. Expires March 17, 2007 [Page 7]
Internet-Draft 4over6 September 2006
6. References
6.1 Normative References
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., and V. Jacobson, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, June 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
6.2 Informative References
[I-D.ietf-l3vpn-2547bis-mcast-bgp]
Aggarwal, R., "BGP Encodings for Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-00 (work in
progress), August 2006.
[I-D.ietf-softwire-4over6vpns]
Shepherd, G., "IPv4 unicast/multicast VPNs over an IPv6
core", draft-ietf-softwire-4over6vpns-00 (work in
progress), June 2006.
Authors' Addresses
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785822
Email: xmw@tsinghua.edu.cn
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: cuiyong@tsinghua.edu.cn
Xu, et al. Expires March 17, 2007 [Page 8]
Internet-Draft 4over6 September 2006
Fanqi Meng
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785822
Email: mfq@mails.tsinghua.edu.cn
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
America
Email: Email: chmetz@cisco.com
Xu, et al. Expires March 17, 2007 [Page 9]
Internet-Draft 4over6 September 2006
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Xu, et al. Expires March 17, 2007 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 10:38:33 |