One document matched: draft-perkins-manet-using-rfc6621-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- ?rfc subcompact="no" ? -->
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
<rfc category="std" docName="draft-perkins-manet-using-rfc6621-00.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historichttp://umeeting.huawei.com/Portal/business.action?BMECID=1474233&BMETimestamp=1426658395147
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Using RFC6621">
Using Layer 3 Multicast Suppression Protocols Above Layer 3</title>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc. </organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
</address>
</author>
<date/> <!-- day="25" month="October" year="2010" /> -->
<area>Routing</area>
<workgroup>Mobile Ad Hoc Networks [manet]</workgroup>
<keyword>Mobility</keyword>
<keyword>Multicast Suppression</keyword>
<abstract>
<t>
This document specifies how protocols operating at layers above
layer 3 can use the multicast suppression algorithms, for instance
the algorithms specified in RFC 6621.
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t>
Limiting the number of multicast forwarders provides performance
benefits when used with a protocol that relies on flooding messages
throughout a network. Some good multicast suppression methods for
limiting the number of multicast forwarders while maintaining complete
network coverage are specified in RFC 6621 <xref target="RFC6621"/>.
Routing protocols that use multicast can offer much greater
performance using multicast suppression algorithms. Such algorithms
do not affect the origination of multicast messages, but only determine
whether a node needs to forward incoming multicast messages that are
intended to flood the network. Enabling performance benefits for
reactive manet routing protocols was a strong motivating factor in
the development and publication of RFC 6621.
</t>
<t>
RFC 6621 multicast suppression algorithms are specified to operate at
layer 3. Manet routing protocols use RFC 5444 <xref target="RFC5444"/>
as a message bundling layer; they operate above layer 3. Such
protocols specify that incoming multicast control messages have to be
processed before regeneration; in other words, the incoming multicast
message is not forwarded at all.
Manet control messages are sent with the IP destination address
set to the link-local multicast address LL-MANET-Routers
<xref target="RFC5498" /> unless otherwise specified.
This document specifies a way to use layer 3 multicast suppression
algorithms at a layer above layer 3 so that algorithms that
require network-wide flooding can reap the benefits of layer-3
multicast suppression algorithms.
</t>
</section>
<section title="Terminology">
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119" />.</t>
<t>This document also uses some terminology from <xref
target="RFC5444" />.</t>
-->
<t>This document defines the following terminology:</t>
<t><list style="hanging">
<t hangText="Forwarding Node"><vspace /> A node that
currently forwards incoming multicast messages to its neighbors, based on the results of running a multicast suppression
algorithm.</t>
<t><vspace /></t>
<t hangText="Multicast Suppression Algorithm"><vspace /> An algorithm
that determines which multicast routers are required for
complete coverage of a multicast group; retransmission by other
multicast routers for the multicast group is unnecessary. </t>
<t><vspace /></t>
<t hangText="Regeneration"><vspace />Transmission of a message
formed by processing and modification of an incoming
message for an operation requiring the attention of
members of a multicast group.</t>
</list></t>
<!-- <t><vspace blankLines="19" /></t> -->
</section>
<section anchor='def'
title='Use of multicast suppression algorithms above Layer 3'>
<t>
If the node is not currently a multicast forwarding node,
then the node does not regenerate multicast messages even
if the conditions for regeneration are satisfied.
</t>
<t>
For example, if an AODVv2 <xref target="I-D.ietf-manet-aodvv2"/>
router is not currently a multicast forwarding node, then it does
not regenerate multicast messages
(e.g., RREQ or RERR) even if the conditions for regeneration are
satisfied. This restriction only applies for regeneration, and does
not apply for multicast RREQ or RERR messages originated by the node.
</t>
<!--
<t>
<list style="symbols">
<t> IPv6 Address <xref target="RFC2373"/> </t>
</list>
</t>
-->
</section>
<section anchor='sec'
title='Security Considerations'>
<t>
This document does not introduce any security mechanisms,
and does not have any impact on existing security mechanisms.
</t>
</section>
<section anchor='iana' title='IANA Considerations'>
<t>
This document does not specify any IANA actions.
</t>
</section>
</middle>
<back>
<!--
<references title='Normative References'>
<?rfc include='reference.RFC.2119.xml'?>
</references>
-->
<references title="Informative References">
<?rfc include="reference.I-D.ietf-manet-aodvv2" ?>
<?rfc include='reference.RFC.5444.xml'?>
<?rfc include='reference.RFC.5498.xml'?>
<?rfc include='reference.RFC.6621.xml'?>
<!--
<?rfc include='reference.RFC.3588.xml'?>
<reference anchor="ThreeGPP-IDS">
<front>
<title>3GPP Technical Specification 23.003 V8.4.0: Technical
Specification Group Core Network and Terminals; Numbering,
addressing and identification (Release 8)</title>
<author surname="3rd Generation Partnership Project">
<organization>
</organization>
</author>
<date month="March" year="2009"/>
</front>
</reference>
<reference anchor="EPC-Tag-Data">
<front>
<title>
EPC(TM) Generation 1 Tag Data Standards Version 1.1 Rev.1.27
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf
</title>
<author surname="EPCglobal Inc.">
<organization>
</organization>
</author>
<date day='10' month="January" year="2005"/>
</front>
</reference>
<reference anchor="RFID-DoD-96">
<front>
<title>United States Department of Defense Suppliers Passive RFID
Information Guide (Version 15.0)</title>
<author surname="Department of Defense">
<organization>
</organization>
</author>
<date month="January" year="2010"/>
</front>
</reference>
<reference anchor="IEEE802">
<front>
<title>IEEE Std 802: IEEE Standards for Local and
Metropolitan Networks: Overview and Architecture</title>
<author surname="IEEE">
<organization>
</organization>
</author>
<date year="2001"/>
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:50 |