tweaks;

1 files changed, 168 insertions, 167 deletions

diff --git a/share/man/man4/multicast.4 b/share/man/man4/multicast.4
index 7823f0106de..1d26c56c537 100644
--- a/share/man/man4/multicast.4
+++ b/share/man/man4/multicast.4
@@ -24,7 +24,7 @@
 .\" DEALINGS IN THE SOFTWARE.
 .\"
 .\" $FreeBSD: src/share/man/man4/multicast.4,v 1.4 2004/07/09 09:22:36 ru Exp $
-.\" $OpenBSD: multicast.4,v 1.1 2005/01/14 14:53:54 mcbride Exp $
+.\" $OpenBSD: multicast.4,v 1.2 2005/01/16 01:17:15 jmc Exp $
 .\" $NetBSD: multicast.4,v 1.3 2004/09/12 13:12:26 wiz Exp $
 .\"
 .Dd September 4, 2003
@@ -67,8 +67,8 @@ The Distance Vector Multicast Routing Protocol (DVMRP)
 was the first developed multicast routing protocol.
 Later, other protocols such as Multicast Extensions to OSPF (MOSPF),
 Core Based Trees (CBT),
-Protocol Independent Multicast - Sparse Mode (PIM-SM),
-and Protocol Independent Multicast - Dense Mode (PIM-DM)
+Protocol Independent Multicast \- Sparse Mode (PIM-SM),
+and Protocol Independent Multicast \- Dense Mode (PIM-DM)
 were developed as well.
 .Pp
 To start multicast routing,
@@ -76,10 +76,12 @@ the user must enable multicast forwarding in the kernel
 (see
 .Sx SYNOPSIS
 about the kernel configuration options),
-and must run a multicast routing capable user-level process.
-From developer's point of view,
+and must run a multicast routing capable user-level process,
+such as
+.Xr mrouted 8 .
+From a developer's point of view,
 the programming guide described in the
-.Sx "Programming Guide"
+.Sx Programming Guide
 section should be used to control the multicast forwarding in the kernel.
 .\"
 .Ss Programming Guide
@@ -95,18 +97,18 @@ That socket would be used
 to control the multicast forwarding in the kernel.
 Note that most operations below require certain privilege
 (i.e., root privilege):
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv4 */
 int mrouter_s4;
 mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);
 .Ed
-.Bd -literal
+.Bd -literal -offset indent
 int mrouter_s6;
 mrouter_s6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
 .Ed
 .Pp
 Note that if the router needs to open an IGMP or ICMPv6 socket
-(in case of IPv4 and IPv6 respectively)
+(IPv4 or IPv6, respectively)
 for sending or receiving of IGMP or MLD multicast group membership messages,
 then the same
 .Va mrouter_s4
@@ -114,60 +116,59 @@ or
 .Va mrouter_s6
 sockets should be used
 for sending and receiving respectively IGMP or MLD messages.
-In case of
-.Bx Ns
--derived kernel, it may be possible to open separate sockets
+In the case of BSD-derived kernels,
+it may be possible to open separate sockets
 for IGMP or MLD messages only.
 However, some other kernels (e.g.,
 .Tn Linux )
 require that the multicast
 routing socket must be used for sending and receiving of IGMP or MLD
 messages.
-Therefore, for portability reason the multicast
+Therefore, for portability reasons, the multicast
 routing socket should be reused for IGMP and MLD messages as well.
 .Pp
 After the multicast routing socket is open, it can be used to enable
 or disable multicast forwarding in the kernel:
-.Bd -literal
+.Bd -literal -offset 5n
 /* IPv4 */
 int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, (void *)\*[Am]v, sizeof(v));
+setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, (void *)&v, sizeof(v));
 .Ed
-.Bd -literal
+.Bd -literal -offset 5n
 /* IPv6 */
 int v = 1;        /* 1 to enable, or 0 to disable */
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_INIT, (void *)\*[Am]v, sizeof(v));
+setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_INIT, (void *)&v, sizeof(v));
 \&...
 /* If necessary, filter all ICMPv6 messages */
 struct icmp6_filter filter;
-ICMP6_FILTER_SETBLOCKALL(\*[Am]filter);
-setsockopt(mrouter_s6, IPPROTO_ICMPV6, ICMP6_FILTER, (void *)\*[Am]filter,
+ICMP6_FILTER_SETBLOCKALL(&filter);
+setsockopt(mrouter_s6, IPPROTO_ICMPV6, ICMP6_FILTER, (void *)&filter,
            sizeof(filter));
 .Ed
 .Pp
 After multicast forwarding is enabled, the multicast routing socket
-can be used to enable PIM processing in the kernel if we are running PIM-SM or
-PIM-DM
+can be used to enable PIM processing in the kernel if either PIM-SM or
+PIM-DM are being used
 (see
 .Xr pim 4 ) .
 .Pp
 For each network interface (e.g., physical or a virtual tunnel)
 that would be used for multicast forwarding, a corresponding
 multicast interface must be added to the kernel:
-.Bd -literal
+.Bd -literal -offset 3n
 /* IPv4 */
 struct vifctl vc;
-memset(\*[Am]vc, 0, sizeof(vc));
+memset(&vc, 0, sizeof(vc));
 /* Assign all vifctl fields as appropriate */
 vc.vifc_vifi = vif_index;
 vc.vifc_flags = vif_flags;
 vc.vifc_threshold = min_ttl_threshold;
 vc.vifc_rate_limit = max_rate_limit;
-memcpy(\*[Am]vc.vifc_lcl_addr, \*[Am]vif_local_address, sizeof(vc.vifc_lcl_addr));
-if (vc.vifc_flags \*[Am] VIFF_TUNNEL)
-    memcpy(\*[Am]vc.vifc_rmt_addr, \*[Am]vif_remote_address,
+memcpy(&vc.vifc_lcl_addr, &vif_local_address, sizeof(vc.vifc_lcl_addr));
+if (vc.vifc_flags & VIFF_TUNNEL)
+    memcpy(&vc.vifc_rmt_addr, &vif_remote_address,
            sizeof(vc.vifc_rmt_addr));
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)\*[Am]vc,
+setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc,
            sizeof(vc));
 .Ed
 .Pp
@@ -184,27 +185,27 @@ The
 .Va min_ttl_threshold
 contains the minimum TTL a multicast data packet must have to be
 forwarded on that vif.
-Typically, it would have value of 1.
+Typically, it would be 1.
 The
 .Va max_rate_limit
 contains the maximum rate (in bits/s) of the multicast data packets forwarded
 on that vif.
-Value of 0 means no limit.
+A value of 0 means no limit.
 The
 .Va vif_local_address
 contains the local IP address of the corresponding local interface.
 The
 .Va vif_remote_address
-contains the remote IP address in case of DVMRP multicast tunnels.
-.Bd -literal
+contains the remote IP address for DVMRP multicast tunnels.
+.Bd -literal -offset indent
 /* IPv6 */
 struct mif6ctl mc;
-memset(\*[Am]mc, 0, sizeof(mc));
+memset(&mc, 0, sizeof(mc));
 /* Assign all mif6ctl fields as appropriate */
 mc.mif6c_mifi = mif_index;
 mc.mif6c_flags = mif_flags;
 mc.mif6c_pifi = pif_index;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MIF, (void *)\*[Am]mc,
+setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_ADD_MIF, (void *)&mc,
            sizeof(mc));
 .Ed
 .Pp
@@ -222,61 +223,61 @@ The
 is the physical interface index of the corresponding local interface.
 .Pp
 A multicast interface is deleted by:
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv4 */
 vifi_t vifi = vif_index;
-setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_VIF, (void *)\*[Am]vifi,
+setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_VIF, (void *)&vifi,
            sizeof(vifi));
 .Ed
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv6 */
 mifi_t mifi = mif_index;
-setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DEL_MIF, (void *)\*[Am]mifi,
+setsockopt(mrouter_s6, IPPROTO_IPV6, MRT6_DEL_MIF, (void *)&mifi,
            sizeof(mifi));
 .Ed
 .Pp
-After the multicast forwarding is enabled, and the multicast virtual
-interfaces are
+After multicast forwarding is enabled, and the multicast virtual
+interfaces have been
 added, the kernel may deliver upcall messages (also called signals
 later in this text) on the multicast routing socket that was open
 earlier with
 .Dv MRT_INIT
 or
 .Dv MRT6_INIT .
-The IPv4 upcalls have
+The IPv4 upcalls have a
 .Vt "struct igmpmsg"
 header (see
 .Aq Pa netinet/ip_mroute.h )
-with field
+with the
 .Va im_mbz
-set to zero.
+field set to zero.
 Note that this header follows the structure of
 .Vt "struct ip"
 with the protocol field
 .Va ip_p
 set to zero.
-The IPv6 upcalls have
+The IPv6 upcalls have a
 .Vt "struct mrt6msg"
 header (see
 .Aq Pa netinet6/ip6_mroute.h )
-with field
+with the
 .Va im6_mbz
-set to zero.
+field set to zero.
 Note that this header follows the structure of
 .Vt "struct ip6_hdr"
 with the next header field
 .Va ip6_nxt
 set to zero.
 .Pp
-The upcall header contains field
+The upcall header contains the
 .Va im_msgtype
 and
 .Va im6_msgtype
-with the type of the upcall
+fields, with the type of the upcall
 .Dv IGMPMSG_*
 and
 .Dv MRT6MSG_*
-for IPv4 and IPv6 respectively.
+for IPv4 and IPv6, respectively.
 The values of the rest of the upcall header fields
 and the body of the upcall message depend on the particular upcall type.
 .Pp
@@ -291,37 +292,37 @@ user-level process to install the appropriate Multicast Forwarding
 Cache (MFC) entry in the kernel.
 .Pp
 An MFC entry is added by:
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv4 */
 struct mfcctl mc;
-memset(\*[Am]mc, 0, sizeof(mc));
-memcpy(\*[Am]mc.mfcc_origin, \*[Am]source_addr, sizeof(mc.mfcc_origin));
-memcpy(\*[Am]mc.mfcc_mcastgrp, \*[Am]group_addr, sizeof(mc.mfcc_mcastgrp));
+memset(&mc, 0, sizeof(mc));
+memcpy(&mc.mfcc_origin, &source_addr, sizeof(mc.mfcc_origin));
+memcpy(&mc.mfcc_mcastgrp, &group_addr, sizeof(mc.mfcc_mcastgrp));
 mc.mfcc_parent = iif_index;
-for (i = 0; i \*[Lt] maxvifs; i++)
+for (i = 0; i \*(Lt maxvifs; i++)
     mc.mfcc_ttls[i] = oifs_ttl[i];
 setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_MFC,
-           (void *)\*[Am]mc, sizeof(mc));
+           (void *)&mc, sizeof(mc));
 .Ed
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv6 */
 struct mf6cctl mc;
-memset(\*[Am]mc, 0, sizeof(mc));
-memcpy(\*[Am]mc.mf6cc_origin, \*[Am]source_addr, sizeof(mc.mf6cc_origin));
-memcpy(\*[Am]mc.mf6cc_mcastgrp, \*[Am]group_addr, sizeof(mf6cc_mcastgrp));
+memset(&mc, 0, sizeof(mc));
+memcpy(&mc.mf6cc_origin, &source_addr, sizeof(mc.mf6cc_origin));
+memcpy(&mc.mf6cc_mcastgrp, &group_addr, sizeof(mf6cc_mcastgrp));
 mc.mf6cc_parent = iif_index;
-for (i = 0; i \*[Lt] maxvifs; i++)
-    if (oifs_ttl[i] \*[Gt] 0)
-        IF_SET(i, \*[Am]mc.mf6cc_ifset);
+for (i = 0; i \*(Lt maxvifs; i++)
+    if (oifs_ttl[i] \*(Gt 0)
+        IF_SET(i, &mc.mf6cc_ifset);
 setsockopt(mrouter_s4, IPPROTO_IPV6, MRT6_ADD_MFC,
-           (void *)\*[Am]mc, sizeof(mc));
+           (void *)&mc, sizeof(mc));
 .Ed
 .Pp
 The
 .Va source_addr
 and
 .Va group_addr
-are the source and group address of the multicast packet (as set
+fields are the source and group address of the multicast packet (as set
 in the upcall message).
 The
 .Va iif_index
@@ -333,73 +334,73 @@ array contains the minimum TTL (per interface) a multicast packet
 should have to be forwarded on an outgoing interface.
 If the TTL value is zero, the corresponding interface is not included
 in the set of outgoing interfaces.
-Note that in case of IPv6 only the set of outgoing interfaces can
+Note that for IPv6 only the set of outgoing interfaces can
 be specified.
 .Pp
 An MFC entry is deleted by:
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv4 */
 struct mfcctl mc;
-memset(\*[Am]mc, 0, sizeof(mc));
-memcpy(\*[Am]mc.mfcc_origin, \*[Am]source_addr, sizeof(mc.mfcc_origin));
-memcpy(\*[Am]mc.mfcc_mcastgrp, \*[Am]group_addr, sizeof(mc.mfcc_mcastgrp));
+memset(&mc, 0, sizeof(mc));
+memcpy(&mc.mfcc_origin, &source_addr, sizeof(mc.mfcc_origin));
+memcpy(&mc.mfcc_mcastgrp, &group_addr, sizeof(mc.mfcc_mcastgrp));
 setsockopt(mrouter_s4, IPPROTO_IP, MRT_DEL_MFC,
-           (void *)\*[Am]mc, sizeof(mc));
+           (void *)&mc, sizeof(mc));
 .Ed
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv6 */
 struct mf6cctl mc;
-memset(\*[Am]mc, 0, sizeof(mc));
-memcpy(\*[Am]mc.mf6cc_origin, \*[Am]source_addr, sizeof(mc.mf6cc_origin));
-memcpy(\*[Am]mc.mf6cc_mcastgrp, \*[Am]group_addr, sizeof(mf6cc_mcastgrp));
+memset(&mc, 0, sizeof(mc));
+memcpy(&mc.mf6cc_origin, &source_addr, sizeof(mc.mf6cc_origin));
+memcpy(&mc.mf6cc_mcastgrp, &group_addr, sizeof(mf6cc_mcastgrp));
 setsockopt(mrouter_s4, IPPROTO_IPV6, MRT6_DEL_MFC,
-           (void *)\*[Am]mc, sizeof(mc));
+           (void *)&mc, sizeof(mc));
 .Ed
 .Pp
 The following method can be used to get various statistics per
 installed MFC entry in the kernel (e.g., the number of forwarded
 packets per source and group address):
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv4 */
 struct sioc_sg_req sgreq;
-memset(\*[Am]sgreq, 0, sizeof(sgreq));
-memcpy(\*[Am]sgreq.src, \*[Am]source_addr, sizeof(sgreq.src));
-memcpy(\*[Am]sgreq.grp, \*[Am]group_addr, sizeof(sgreq.grp));
-ioctl(mrouter_s4, SIOCGETSGCNT, \*[Am]sgreq);
+memset(&sgreq, 0, sizeof(sgreq));
+memcpy(&sgreq.src, &source_addr, sizeof(sgreq.src));
+memcpy(&sgreq.grp, &group_addr, sizeof(sgreq.grp));
+ioctl(mrouter_s4, SIOCGETSGCNT, &sgreq);
 .Ed
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv6 */
 struct sioc_sg_req6 sgreq;
-memset(\*[Am]sgreq, 0, sizeof(sgreq));
-memcpy(\*[Am]sgreq.src, \*[Am]source_addr, sizeof(sgreq.src));
-memcpy(\*[Am]sgreq.grp, \*[Am]group_addr, sizeof(sgreq.grp));
-ioctl(mrouter_s6, SIOCGETSGCNT_IN6, \*[Am]sgreq);
+memset(&sgreq, 0, sizeof(sgreq));
+memcpy(&sgreq.src, &source_addr, sizeof(sgreq.src));
+memcpy(&sgreq.grp, &group_addr, sizeof(sgreq.grp));
+ioctl(mrouter_s6, SIOCGETSGCNT_IN6, &sgreq);
 .Ed
 .Pp
 The following method can be used to get various statistics per
 multicast virtual interface in the kernel (e.g., the number of forwarded
 packets per interface):
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv4 */
 struct sioc_vif_req vreq;
-memset(\*[Am]vreq, 0, sizeof(vreq));
+memset(&vreq, 0, sizeof(vreq));
 vreq.vifi = vif_index;
-ioctl(mrouter_s4, SIOCGETVIFCNT, \*[Am]vreq);
+ioctl(mrouter_s4, SIOCGETVIFCNT, &vreq);
 .Ed
-.Bd -literal
+.Bd -literal -offset indent
 /* IPv6 */
 struct sioc_mif_req6 mreq;
-memset(\*[Am]mreq, 0, sizeof(mreq));
+memset(&mreq, 0, sizeof(mreq));
 mreq.mifi = vif_index;
-ioctl(mrouter_s6, SIOCGETMIFCNT_IN6, \*[Am]mreq);
+ioctl(mrouter_s6, SIOCGETMIFCNT_IN6, &mreq);
 .Ed
 .Ss Advanced Multicast API Programming Guide
-If we want to add new features in the kernel, it becomes difficult
+Adding new features to the kernel makes it difficult
 to preserve backward compatibility (binary and API),
 and at the same time to allow user-level processes to take advantage of
 the new features (if the kernel supports them).
 .Pp
-One of the mechanisms that allows us to preserve the backward
+One of the mechanisms that allows preserving the backward
 compatibility is a sort of negotiation
 between the user-level process and the kernel:
 .Bl -enum
@@ -441,7 +442,7 @@ This negotiation must be performed right after the multicast routing
 socket is open.
 The set of desired/allowed features is stored in a bitset
 (currently, in
-.Vt uint32_t ;
+.Vt uint32_t
 i.e., maximum of 32 new features).
 The new
 .Fn getsockopt Ns / Ns Fn setsockopt
@@ -449,18 +450,18 @@ options are
 .Dv MRT_API_SUPPORT
 and
 .Dv MRT_API_CONFIG .
-Example:
-.Bd -literal
+An example:
+.Bd -literal -offset 3n
 uint32_t v;
-getsockopt(sock, IPPROTO_IP, MRT_API_SUPPORT, (void *)\*[Am]v, sizeof(v));
+getsockopt(sock, IPPROTO_IP, MRT_API_SUPPORT, (void *)&v, sizeof(v));
 .Ed
 .Pp
-would set in
+This would set
 .Va v
-the pre-defined bits that the kernel API supports.
+to the pre-defined bits that the kernel API supports.
 The eight least significant bits in
 .Vt uint32_t
-are same as the
+are the same as the
 eight possible flags
 .Dv MRT_MFC_FLAGS_*
 that can be used in
@@ -475,13 +476,13 @@ is read-only; in other words,
 would fail.
 .Pp
 To modify the API, and to set some specific feature in the kernel, then:
-.Bd -literal
+.Bd -literal -offset 3n
 uint32_t v = MRT_MFC_FLAGS_DISABLE_WRONGVIF;
-if (setsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)\*[Am]v, sizeof(v))
+if (setsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)&v, sizeof(v))
     != 0) {
     return (ERROR);
 }
-if (v \*[Am] MRT_MFC_FLAGS_DISABLE_WRONGVIF)
+if (v & MRT_MFC_FLAGS_DISABLE_WRONGVIF)
     return (OK);	/* Success */
 else
     return (ERROR);
@@ -495,9 +496,9 @@ be enabled in the API and the kernel.
 The return value in
 .Va v
 is the actual (sub)set of features that were enabled in the kernel.
-To obtain later the same set of features that were enabled, then:
-.Bd -literal
-getsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)\*[Am]v, sizeof(v));
+To obtain later the same set of features that were enabled, use:
+.Bd -literal -offset indent
+getsockopt(sock, IPPROTO_IP, MRT_API_CONFIG, (void *)&v, sizeof(v));
 .Ed
 .Pp
 The set of enabled features is global.
@@ -508,15 +509,15 @@ should be called right after
 .Pp
 Currently, the following set of new features is defined:
 .Bd -literal
-#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 \*[Lt]\*[Lt] 0) /* disable WRONGVIF signals */
-#define	MRT_MFC_FLAGS_BORDER_VIF   (1 \*[Lt]\*[Lt] 1)  /* border vif              */
-#define MRT_MFC_RP                 (1 \*[Lt]\*[Lt] 8)  /* enable RP address	*/
-#define MRT_MFC_BW_UPCALL          (1 \*[Lt]\*[Lt] 9)  /* enable bw upcalls	*/
+#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 \*(Lt\*(Lt 0)/*disable WRONGVIF signals*/
+#define	MRT_MFC_FLAGS_BORDER_VIF   (1 \*(Lt\*(Lt 1)  /* border vif              */
+#define MRT_MFC_RP                 (1 \*(Lt\*(Lt 8)  /* enable RP address	*/
+#define MRT_MFC_BW_UPCALL          (1 \*(Lt\*(Lt 9)  /* enable bw upcalls	*/
 .Ed
 .\" .Pp
 .\" In the future there might be:
 .\" .Bd -literal
-.\" #define MRT_MFC_GROUP_SPECIFIC     (1 \*[Lt]\*[Lt] 10) /* allow (*,G) MFC entries */
+.\" #define MRT_MFC_GROUP_SPECIFIC     (1 \*(Lt\*(Lt 10) /* allow (*,G) MFC entries */
 .\" .Ed
 .\" .Pp
 .\" to allow (*,G) MFC entries (i.e., group-specific entries) in the kernel.
@@ -567,8 +568,8 @@ field is used to set various flags per
 interface per (S,G) entry.
 Currently, the defined flags are:
 .Bd -literal
-#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 \*[Lt]\*[Lt] 0) /* disable WRONGVIF signals */
-#define	MRT_MFC_FLAGS_BORDER_VIF       (1 \*[Lt]\*[Lt] 1) /* border vif          */
+#define	MRT_MFC_FLAGS_DISABLE_WRONGVIF (1 \*(Lt\*(Lt 0)/*disable WRONGVIF signals*/
+#define	MRT_MFC_FLAGS_BORDER_VIF       (1 \*(Lt\*(Lt 1) /* border vif          */
 .Ed
 .Pp
 The
@@ -577,11 +578,11 @@ flag is used to explicitly disable the
 .Dv IGMPMSG_WRONGVIF
 kernel signal at the (S,G) granularity if a multicast data packet
 arrives on the wrong interface.
-Usually, this signal is used to
-complete the shortest-path switch in case of PIM-SM multicast routing,
+Usually this signal is used to
+complete the shortest-path switch for PIM-SM multicast routing,
 or to trigger a PIM assert message.
-However, it should not be delivered for interfaces that are not in
-the outgoing interface set, and that are not expecting to
+However, it should not be delivered for interfaces that are not set in
+the outgoing interface, and that are not expecting to
 become an incoming interface.
 Hence, if the
 .Dv MRT_MFC_FLAGS_DISABLE_WRONGVIF
@@ -593,7 +594,7 @@ If that flag is not set, then a signal is triggered (the default action).
 The
 .Dv MRT_MFC_FLAGS_BORDER_VIF
 flag is used to specify whether the Border-bit in PIM
-Register messages should be set (in case when the Register encapsulation
+Register messages should be set (when the Register encapsulation
 is performed inside the kernel).
 If it is set for the special PIM Register kernel virtual interface
 (see
@@ -604,7 +605,7 @@ The remaining six bits are reserved for future usage.
 .Pp
 The
 .Va mfcc_rp
-field is used to specify the RP address (in case of PIM-SM multicast routing)
+field is used to specify the RP address (for PIM-SM multicast routing)
 for a multicast
 group G if we want to perform kernel-level PIM Register encapsulation.
 The
@@ -669,8 +670,8 @@ fragmented it into much smaller pieces.
 .Pp
 Typically, a multicast routing user-level process would need to know the
 forwarding bandwidth for some data flow.
-For example, the multicast routing process may want to timeout idle MFC
-entries, or in case of PIM-SM it can initiate (S,G) shortest-path switch if
+For example, the multicast routing process may want to time out idle MFC
+entries, or for PIM-SM it can initiate (S,G) shortest-path switch if
 the bandwidth rate is above a threshold for example.
 .Pp
 The original solution for measuring the bandwidth of a dataflow was
@@ -694,14 +695,14 @@ There can be
 more than one filter per (S,G).
 .It
 Instead of supporting all possible comparison operations
-(i.e., \*[Lt] \*[Lt]= == != \*[Gt] \*[Gt]= ), there is support only for the
-\*[Lt]= and \*[Gt]= operations,
+(i.e., \*(Lt \*(Lt= == != \*(Gt \*(Gt= ), there is support only for the
+\*(Lt= and \*(Gt= operations,
 because this makes the kernel-level implementation simpler,
 and because practically we need only those two.
-Further, the missing operations can be simulated by secondary
-user-level filtering of those \*[Lt]= and \*[Gt]= filters.
+Furthermore, the missing operations can be simulated by secondary
+user-level filtering of those \*(Lt= and \*(Gt= filters.
 For example, to simulate !=, then we need to install filter
-.Dq bw \*[Lt]= 0xffffffff ,
+.Dq bw \*(Lt= 0xffffffff ,
 and after an
 upcall is received, we need to check whether
 .Dq measured_bw != expected_bw .
@@ -721,7 +722,7 @@ respectively (with the appropriate
 argument of course).
 .El
 .Pp
-From application point of view, a developer needs to know about
+From an application point of view, a developer needs to know about
 the following:
 .Bd -literal
 /*
@@ -736,19 +737,19 @@ the following:
  * At the moment the code is only used for multicast destinations
  * but there is nothing that prevents its use for unicast.
  *
- * The measurement interval cannot be shorter than some Tmin (currently, 3s).
+ * The measurement interval cannot be shorter than some Tmin (3s).
  * The threshold is set in packets and/or bytes per_interval.
  *
  * Measurement works as follows:
  *
- * For \*[Gt]= measurements:
+ * For \*(Gt= measurements:
  * The first packet marks the start of a measurement interval.
  * During an interval we count packets and bytes, and when we
  * pass the threshold we deliver an upcall and we are done.
  * The first packet after the end of the interval resets the
  * count and restarts the measurement.
  *
- * For \*[Lt]= measurement:
+ * For \*(Lt= measurement:
  * We start a timer to fire at the end of the interval, and
  * then for each incoming packet we count packets and bytes.
  * When the timer fires, we compare the value with the threshold,
@@ -766,11 +767,11 @@ struct bw_upcall {
         struct in_addr  bu_src;         /* source address            */
         struct in_addr  bu_dst;         /* destination address       */
         uint32_t        bu_flags;       /* misc flags (see below)    */
-#define BW_UPCALL_UNIT_PACKETS (1 \*[Lt]\*[Lt] 0) /* threshold (in packets)    */
-#define BW_UPCALL_UNIT_BYTES   (1 \*[Lt]\*[Lt] 1) /* threshold (in bytes)      */
-#define BW_UPCALL_GEQ          (1 \*[Lt]\*[Lt] 2) /* upcall if bw \*[Gt]= threshold */
-#define BW_UPCALL_LEQ          (1 \*[Lt]\*[Lt] 3) /* upcall if bw \*[Lt]= threshold */
-#define BW_UPCALL_DELETE_ALL   (1 \*[Lt]\*[Lt] 4) /* delete all upcalls for s,d*/
+#define BW_UPCALL_UNIT_PACKETS (1 \*(Lt\*(Lt 0) /* threshold (in packets)    */
+#define BW_UPCALL_UNIT_BYTES   (1 \*(Lt\*(Lt 1) /* threshold (in bytes)      */
+#define BW_UPCALL_GEQ          (1 \*(Lt\*(Lt 2) /* upcall if bw \*(Gt= threshold */
+#define BW_UPCALL_LEQ          (1 \*(Lt\*(Lt 3) /* upcall if bw \*(Lt= threshold */
+#define BW_UPCALL_DELETE_ALL   (1 \*(Lt\*(Lt 4) /* delete all upcalls for s,d*/
         struct bw_data  bu_threshold;   /* the bw threshold          */
         struct bw_data  bu_measured;    /* the measured bw           */
 };
@@ -797,48 +798,47 @@ argument,
 and that filter will trigger an upcall according to the following
 pseudo-algorithm:
 .Bd -literal
- if (bw_upcall_oper IS "\*[Gt]=") {
-    if (((bw_upcall_unit \*[Am] PACKETS == PACKETS) \*[Am]\*[Am]
-         (measured_packets \*[Gt]= threshold_packets)) ||
-        ((bw_upcall_unit \*[Am] BYTES == BYTES) \*[Am]\*[Am]
-         (measured_bytes \*[Gt]= threshold_bytes)))
-       SEND_UPCALL("measured bandwidth is \*[Gt]= threshold");
+ if (bw_upcall_oper IS "\*(Gt=") {
+    if (((bw_upcall_unit & PACKETS == PACKETS) &&
+         (measured_packets \*(Gt= threshold_packets)) ||
+        ((bw_upcall_unit & BYTES == BYTES) &&
+         (measured_bytes \*(Gt= threshold_bytes)))
+       SEND_UPCALL("measured bandwidth is \*(Gt= threshold");
   }
-  if (bw_upcall_oper IS "\*[Lt]=" \*[Am]\*[Am] measured_interval \*[Gt]= threshold_interval) {
-    if (((bw_upcall_unit \*[Am] PACKETS == PACKETS) \*[Am]\*[Am]
-         (measured_packets \*[Lt]= threshold_packets)) ||
-        ((bw_upcall_unit \*[Am] BYTES == BYTES) \*[Am]\*[Am]
-         (measured_bytes \*[Lt]= threshold_bytes)))
-       SEND_UPCALL("measured bandwidth is \*[Lt]= threshold");
+  if (bw_upcall_oper IS "\*(Lt=" && measured_interval \*(Gt= threshold_interval) {
+    if (((bw_upcall_unit & PACKETS == PACKETS) &&
+         (measured_packets \*(Lt= threshold_packets)) ||
+        ((bw_upcall_unit & BYTES == BYTES) &&
+         (measured_bytes \*(Lt= threshold_bytes)))
+       SEND_UPCALL("measured bandwidth is \*(Lt= threshold");
   }
 .Ed
 .Pp
 In the same
-.Vt bw_upcall
+.Vt bw_upcall ,
 the unit can be specified in both BYTES and PACKETS.
 However, the GEQ and LEQ flags are mutually exclusive.
 .Pp
-Basically, an upcall is delivered if the measured bandwidth is \*[Gt]= or
-\*[Lt]= the threshold bandwidth (within the specified measurement
+Basically, an upcall is delivered if the measured bandwidth is \*(Gt= or
+\*(Lt= the threshold bandwidth (within the specified measurement
 interval).
 For practical reasons, the smallest value for the measurement
 interval is 3 seconds.
 If smaller values are allowed, then the bandwidth
 estimation may be less accurate, or the potentially very high frequency
 of the generated upcalls may introduce too much overhead.
-For the \*[Gt]= operation, the answer may be known before the end of
+For the \*(Gt= operation, the answer may be known before the end of
 .Va threshold_interval ,
 therefore the upcall may be delivered earlier.
-For the \*[Lt]= operation however, we must wait
+For the \*(Lt= operation however, we must wait
 until the threshold interval has expired to know the answer.
-.Pp
-Example of usage:
-.Bd -literal
+.Sh EXAMPLES
+.Bd -literal -offset indent
 struct bw_upcall bw_upcall;
 /* Assign all bw_upcall fields as appropriate */
-memset(\*[Am]bw_upcall, 0, sizeof(bw_upcall));
-memcpy(\*[Am]bw_upcall.bu_src, \*[Am]source, sizeof(bw_upcall.bu_src));
-memcpy(\*[Am]bw_upcall.bu_dst, \*[Am]group, sizeof(bw_upcall.bu_dst));
+memset(&bw_upcall, 0, sizeof(bw_upcall));
+memcpy(&bw_upcall.bu_src, &source, sizeof(bw_upcall.bu_src));
+memcpy(&bw_upcall.bu_dst, &group, sizeof(bw_upcall.bu_dst));
 bw_upcall.bu_threshold.b_data = threshold_interval;
 bw_upcall.bu_threshold.b_packets = threshold_packets;
 bw_upcall.bu_threshold.b_bytes = threshold_bytes;
@@ -858,12 +858,12 @@ do {
     return (ERROR);
 } while (0);
 setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_BW_UPCALL,
-          (void *)\*[Am]bw_upcall, sizeof(bw_upcall));
+          (void *)&bw_upcall, sizeof(bw_upcall));
 .Ed
 .Pp
-To delete a single filter, then use
+To delete a single filter, use
 .Dv MRT_DEL_BW_UPCALL ,
-and the fields of bw_upcall must be set
+and the fields of bw_upcall must be set to
 exactly same as when
 .Dv MRT_ADD_BW_UPCALL
 was called.
@@ -882,7 +882,7 @@ flag inside field
 .Pp
 The bandwidth upcalls are received by aggregating them in the new upcall
 message:
-.Bd -literal
+.Bd -literal -offset indent
 #define IGMPMSG_BW_UPCALL  4  /* BW monitoring upcall */
 .Ed
 .Pp
@@ -898,7 +898,7 @@ In an
 .Vt "struct upcall"
 element, the
 .Va bu_measured
-field is filled-in to
+field is filled in to
 indicate the particular measured values.
 However, because of the way
 the particular intervals are measured, the user should be careful how
@@ -906,10 +906,10 @@ the particular intervals are measured, the user should be careful how
 is used.
 For example, if the
 filter is installed to trigger an upcall if the number of packets
-is \*[Gt]= 1, then
+is \*(Gt= 1, then
 .Va bu_measured
 may have a value of zero in the upcalls after the
-first one, because the measured interval for \*[Gt]= filters is
+first one, because the measured interval for \*(Gt= filters is
 .Dq clocked
 by the forwarded packets.
 Hence, this upcall mechanism should not be used for measuring
@@ -926,7 +926,7 @@ Note that the upcalls for a filter are delivered until the specific
 filter is deleted, but no more frequently than once per
 .Va bu_threshold.b_time .
 For example, if the filter is specified to
-deliver a signal if bw \*[Gt]= 1 packet, the first packet will trigger a
+deliver a signal if bw \*(Gt= 1 packet, the first packet will trigger a
 signal, but the next upcall will be triggered no earlier than
 .Va bu_threshold.b_time
 after the previous upcall.
@@ -943,10 +943,10 @@ after the previous upcall.
 .Xr intro 4 ,
 .Xr ip 4 ,
 .Xr ip6 4 ,
-.Xr pim 4
+.Xr pim 4 ,
+.Xr mrouted 8
 .\"
 .Sh AUTHORS
-.An -nosplit
 The original multicast code was written by
 .An David Waitzman
 (BBN Labs),
@@ -961,6 +961,7 @@ and later modified by the following individuals:
 (PARC),
 .An Bill Fenner
 (PARC).
+.Pp
 The IPv6 multicast support was implemented by the KAME project
 .Pq Pa http://www.kame.net ,
 and was based on the IPv4 multicast code.