| # $QuaggaId: $Format:%an, %ai, %h$ $ |
| |
| C1 IGMPv3 backward compatibility with IGMPv1 and IGMPv2 is not |
| implemented. See RFC 3376, 7.3. Multicast Router Behavior. That's |
| because only Source-Specific Multicast is currently targeted. |
| |
| C2 IGMPv3 support for forwarding any-source groups is not |
| implemented. Traffic for groups in mode EXCLUDE {empty} won't be |
| forwarded. See RFC 3376, 6.3. Source-Specific Forwarding |
| Rules. That's because only Source-Specific Multicast is currently |
| targeted. |
| |
| C3 Load Splitting of IP Multicast Traffic over ECMP is not supported. |
| See also: RFC 2991 |
| Multipath Issues in Unicast and Multicast Next-Hop Selection |
| http://www.rfc-editor.org/rfc/rfc2991.txt |
| |
| C4 IPSec AH authentication is not supported (RFC 4601: |
| 6.3. Authentication Using IPsec). |
| |
| C5 PIM support is limited to SSM mode as defined in section 4.8.2 |
| (PIM-SSM-Only Routers) of RFC4601. That's because only |
| Source-Specific Multicast is currently targeted. |
| |
| C6 PIM implementation currently does not support IPv6. PIM-SSM |
| requires IGMPv3 for IPv4 and MLDv2 for IPv6. MLDv2 is currently |
| missing. See also CAVEAT C9. |
| |
| C7 (S,G) Assert state machine (RFC 4601, section 4.6.1) is not |
| implemented. See also TODO T6. See also CAVEAT C10. |
| |
| C8 It is not possible to disable join suppression in order to |
| explicitly track the join membership of individual downstream |
| routers. |
| - IGMPv3 Explicit Membership Tracking is not supported. |
| When explicit tracking is enabled on a router, the router can |
| individually track the Internet Group Management Protocol (IGMP) |
| membership state of all reporting hosts. This feature allows the |
| router to achieve minimal leave latencies when hosts leave a |
| multicast group or channel. Example: |
| conf t |
| interface eth0 |
| ip igmp explicit-tracking |
| |
| C9 Only IPv4 Address Family (number=1) is supported in the PIM Address |
| Family field. |
| See also RFC 4601: 5.1. PIM Address Family |
| See also CAVEAT C6. |
| See also http://www.iana.org/assignments/address-family-numbers |
| |
| C10 FIXED Assert metric depends on metric_preference and |
| route_metric. Those parameters should be fetched from RIB |
| (zebra). See also pim_rpf.c, pim_rpf_update(). |
| |
| C11 SSM Mapping is not supported |
| |
| SSM Mapping Overview: |
| |
| SSM mapping introduces a means for the last hop router to discover |
| sources sending to groups. When SSM mapping is configured, if a |
| router receives an IGMPv1 or IGMPv2 membership report for a |
| particular group G, the router translates this report into one or |
| more (S, G) channel memberships for the well-known sources |
| associated with this group. |
| |
| When the router receives an IGMPv1 or IGMPv2 membership report for |
| a group G, the router uses SSM mapping to determine one or more |
| source IP addresses for the group G. SSM mapping then translates |
| the membership report as an IGMPv3 report INCLUDE (G, [S1, G], |
| [S2, G]...[Sn, G] and continues as if it had received an IGMPv3 |
| report. The router then sends out PIM joins toward (S1, G) to (Sn, |
| G) and continues to be joined to these groups as long as it |
| continues to receive the IGMPv1 or IGMPv2 membership reports and |
| as long as the SSM mapping for the group remains the same. SSM |
| mapping, thus, enables you to leverage SSM for video delivery to |
| legacy STBs that do not support IGMPv3 or for applications that do |
| not take advantage of the IGMPv3 host stack. |
| |
| SSM mapping enables the last hop router to determine the source |
| addresses either by a statically configured table on the router or |
| by consulting a DNS server. When the statically configured table |
| is changed, or when the DNS mapping changes, the router will leave |
| the current sources associated with the joined groups. |
| |
| C12 MRIB for incongruent unicast/multicast topologies is not supported. |
| RPF mechanism currently just looks up the information in the |
| unicast routing table. |
| |
| See also: |
| RFC5110: 2.2.3. Issue: Overlapping Unicast/Multicast Topology |
| |
| Sometimes, multicast RPF mechanisms first look up the multicast |
| routing table, or M-RIB ("topology database") with a longest |
| prefix match algorithm, and if they find any entry (including a |
| default route), that is used; if no match is found, the unicast |
| routing table is used instead. |
| |
| C13 Can't detect change of primary address before the actual change. |
| Possible approach is to craft old interface address into ip source |
| address by using raw ip socket. |
| |
| See also: |
| |
| RFC 4601: 4.3.1. Sending Hello Messages |
| |
| Before an interface goes down or changes primary IP address, a |
| Hello message with a zero HoldTime should be sent immediately |
| (with the old IP address if the IP address changed). |
| |
| See also pim_sock_delete(). |
| |
| C14 Detection of interface primary address changes may fail when there |
| are multiple addresses. |
| See also TODO T32. |
| |
| C15 Changes in interface secondary address list are not immediately |
| detected. |
| See also TODO T31. |
| |
| C16 AMT Draft (mboned-auto-multicast) is not supported. |
| AMT = Automatic IP Multicast Without Explicit Tunnels |
| |
| See also: |
| |
| Draft |
| http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast |
| http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09 |
| |
| AMT gateway implementation for Linux |
| http://cs.utdallas.edu/amt/ |
| |
| AMT for Streaming (IPTV) on Global IP Multicast by Greg Shepherd (Cisco) |
| http://nznog.miniconf.org/nznog-2008-sysadmin-miniconf-greg-shepherd-iptv.pdf |
| |
| C17 SNMP / RFC 5060 (PIM MIB) is not supported. |
| |
| -x- |