IP multicast offers a more efficient use of network resources, as compared to unicast and multicast technologies, for certain applications (for example, streaming video out to multiple receivers in a network). This chapter reviews the funda-mentals of IP multicast technology, provides design guidance, and discusses security considerations.
Fundamentals of IP Multicast
Consider a video stream that needs to be sent to multiple recipients in a company. One approach is to unicast the traffic.
The source server sends a copy of every packet to every receiver, as illustrated in Figure 10-1. Obviously, this approach has serious scalability limitations.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
Multicast
An alternative approach is to broadcast the video stream, so that the source server only has to send each packet once.
However, everyone in the network receives the packet, in that scenario, even if they do not want it, as shown in Figure 10-2.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
IP multicast technologies provide the best of both worlds. With IP multicast, the source server only sends one copy of each packet, and the packets are only sent to intended recipients, as demonstrated in Figure 10-3.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
Multicast
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
IP Multicast Design Considerations
Specifically, receivers join a multicast group, denoted by a Class D IP address (that is, in the range 224.0.0.0 through 239.255.255.255). The source sends traffic to the Class D address, and through switch and router protocols, packets are forwarded only to intended stations. These multicast packets are sent via User Datagram Protocol (UDP; that is, best effort). Therefore, congestion avoidance mechanisms such as weighted random early detection (WRED), which causes TCP flows to go into TCP slow start, are not effective for multicast. As you do your multicast design, also be aware of the potential for duplicate packets being received and the potential for packets arriving out of order.
In addition to Layer 3 addresses, multicast applications must have Layer 2 addresses (that is, MAC addresses).
Fortunately, these Layer 2 addresses can be constructed directly from the Layer 3 multicast addresses. A MAC address is a 48 bit address, and the first half (that is, 24 bits) of a multicast MAC address (in hex) is 01-00-5e. The 25 bit is always 0. The last 23 bits in the multicast MAC address come directly from the last 23 bits of the multicast IP address.
Consider the following example:
n Given a multicast IP address of 224.1.10.10, calculate the corresponding multicast MAC address.
1.First, convert the last three octets to binary.
0000.0001.0000.1010.0000.1010
2. If the leftmost bit isn’t already 0, it should be changed to 0, because the 25 bit of a multicast MAC address is always 0.
0000.0001.0000.1010.0000.1010
3. Convert each nibble (that is, 4-bit section) into its hexadecimal equivalent.
01-0a-0a
4. Prepend 01-00-5e to the calculated address to produce the multicast MAC address.
01-00-5e-01-0a-0a
n Interestingly, multiple other multicast IP addresses (for example, 224.129.10.10) yield an identical multicast MAC address. This overlap issue permits 32 Layer 3 multicast addresses to map to the same Layer 2 multicast MAC address. Therefore, care must be taken when selecting Layer 3 multicast addresses to avoid this overlap.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
As previously mentioned, in a multicast network, the source sends multicast packets with a Class D destination address.
The 224.0.0.0 through 239.255.255.255 address range is the Class D address range, because the first four bits in the first octet of a Class D address are 1110.
Some ranges of addresses in the Class D address space are dedicated for special purposes:
224.0.0.0 – 224.0.0.255 – Reserved link local addresses 224.0.1.0 – 238.255.255.255 – Globally scoped addresses 232.0.0.0 – 232.255.255.255 – Source-specific multicast 233.0.0.0 – 233.255.255.255 – GLOP addresses 239.0.0.0 – 239.255.255.255 – Limited-scope addresses
n Reserved link local addresses are used, for example, by many network protocols. Open Shortest Path First (OSPF) Protocol uses 224.0.0.5 and 224.0.0.6. Routing Information Protocol Version 2 (RIPv2) uses 224.0.0.9, and Enhanced Interior Gateway Routing Protocol (EIGRP) uses 224.0.0.10. Other “well-known” addresses in this range include 224.0.0.1, which addresses all multicast hosts, and 224.0.0.2, which addresses all multicast routers.
n Globally scoped addresses are used for general purpose multicast applications, and they have the ability to extend beyond the local autonomous system.
n Source-specific multicast (SSM) addresses are used in conjunction with Internet Group Management Protocol Version 3 (IGMPv3), to allow a multicast receiver request, not only membership in a group, but also to request specific sources to receive traffic from. Therefore, in an SSM environment, multiple sources with different content can all be sending to the same multicast destination address.
n GLOP addresses provide a globally unique multicast address range, based on autonomous system numbers. As an example, if a company had an autonomous system number of 65000, its globally unique range of multicast IP addresses would be 233.253.232.0 through 233.253.232.255. The autonomous system number is used to calculate
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
IP Multicast Design Considerations
the second and third octets in this address range. First, convert the autonomous system number to hexadecimal (that is, 65000 in decimal equals FD-E8 in hexadecimal). FD in hexadecimal equals 253 in decimal, and E8 in hexadeci-mal equals 232 in decihexadeci-mal. The first octet of a GLOP address is always 233.
n Limited-scope addresses are used for internal multicast applications (that is, traffic that doesn’t leave its autonomous system), much like the 10.x.x.x/8 address space is a “private” address space.
The protocol used between clients (for example, PCs) and routers let routers know which of their interfaces have multi-cast receivers attached is IGMP. There are three version of IGMP:
n IGMP Version 1: When a PC wants to join a multicast group, it sends an IGMP Report message to the router, letting the router know it wants to receive traffic for a specific group. Every 60 seconds, by default, the router sends an IGMP Query message to determine whether the PC still wants to belong to the group. There can be up to a three-minute delay before a router realizes that a receiver left the group. The destination address of this router query is 224.0.0.1, which addresses all IP multicast hosts.
n IGMP Version 2: Similar to IGMP Version 1, except that IGMP Version 2 can send queries to a specific group, and a “leave” message is supported. Specifically, a receiver can proactively send a leave message when it no longer wants to participate in a multicast group, allowing the router to prune its interface earlier.
n IGMP Version 3: Offering the same features of IGMP Version 2, except that IGMP Version 3 supports SSM, which allows a multicast group member to request traffic from a specific host’s IP address.
Only members of a multicast group receive packets destined for that group. However, the sender does not need to be a member of the group. Multicast traffic flows from a source to a destination over a “distribution tree,” which is a loop-free path. The two types of distribution trees are as follows:
n Source distribution tree: A source distribution tree creates an optimal path between each source router and each last-hop router (that is, a router connected to a receiver), at the expense of increased memory usage, as shown in Figure 10-4.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
n Shared distribution tree: A shared distribution tree creates a shared tree from a central rendezvous point (RP) router to all last-hop routers, with source distribution trees being created from all sources to the RP, at the expense of increased delay, as shown in Figure 10-5.
To combat the issue of receiving duplicate packets, Cisco routers perform an RPF (reverse path forwarding) check, to determine whether a multicast packet is entering a router on the correct interface. An RPF check examines the source address of an incoming packet and checks it against the router’s unicast routing table to see what interface should be used to get back to the source network. If the incoming multicast packet is using that interface, the RPF check passes, and the packet is forwarded. If the multicast packet is coming in on a different interface, the RPF check fails, and the packet is discarded, as illustrated in Figure 10-6.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
Source
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
IP Multicast Design Considerations
FIGURE 10-5 Shared Distribution Tree
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
Source
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
When a Layer 2 switch receives a multicast frame on an interface, by default, the switch floods the frame out all other interfaces. To prevent this behavior, the switch needs awareness of what interfaces are connected to receivers for specific multicast groups. One approach to training the switch is IGMP snooping. IGMP Snooping allows a switch to
autonomously determine which interfaces are connected to receivers for specific multicast groups by eavesdropping on the IGMP traffic being exchanged between clients and routers.
Protocol Independent Multicast Design
The Protocol Independent Multicast (PIM) protocol is a router-to-router protocol used by Cisco routers to achieve a loop-free topology. The three main types of PIM are as follows:
n PIM Any-Source Multicast (ASM): ASM is a new name for the classic PIM Sparse Mode (PIM-SM) technology, and is the most popular multicast type deployed today. Specifically, ASM allows routers to explicitly request to join a tree using a shared distribution tree approach, and then performs SPT switchover, allowing receiver routers to form a shortest path tree with the source routers, thus creating optimal pathing.
n Bidirectional PIM (Bidir PIM): Bidir PIM uses shared distribution trees to more efficiently support many-to-many applications.
n Source Specific Multicast (SSM): Supported by IGMP Version 3, SSM uses source distribution trees and allows a multicast group member to request a specific host IP address from which it wants to receive traffic. This approach eliminates the need for an RP.
When an RP is required (that is, when ASP or Bidir PIM is being used), designers can select from among the following four technologies for deploying an RP:
n Anycast RP: Uses multiple routers in a PIM-SM network to offer RP load sharing and redundancy, where two RPs act as hot backups to each other
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
IP Multicast Design Considerations
n Static RP addressing: Requires that all routers pointing to an RP be statically configured with the RP’s IP address n Auto RP: Uses a multicast address of 224.0.1.39 to dynamically announce an RP’s IP address to routers n BSR: Uses PIM Version 2 to offer a vendor-independent solution for dynamically selecting an RP
Securing IP Multicast Networks
When designing IP multicast networks, additional security considerations apply. Whereas unicast routing maintains a unicast routing table, IP multicast routing relies on multicast state information, which is maintained in the multicast routing table, in addition to the unicast routing table.
Unicast routing can use technologies such as access control lists (ACL) or firewalls to protect traffic. These technologies can prevent one device from sending traffic to another device. However, with IP multicast routing, traffic is sent to a multicast group rather than a specific device. Therefore, a major IP multicast security consideration is to protect multicast receivers from unknown senders.
Fortunately, SSM prevents an unknown host from sending to a multicast receiver, because with SSM a multicast receiver joins to a specific host. Also, with Any-Source Multicast, a receiver would only be susceptible to a multicast attack if it joined a multicast group.
To limit IP multicast traffic from being propagated too far within a network, scopes can be used to set boundaries for the traffic. In addition, IP multicast traffic can be constrained using time-to-live (TTL) thresholds.
In addition, consider the following approaches for securing IP multicast networks:
n Packet filter based access control: Typically used for inbound traffic, packet filter based access control can filter traffic before IP multicast routing occurs.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
n Host receiver side access control: Individual IP multicast groups can be filtered out of IGMP membership report messages using host receiver side access control.
n PIM-SM source control: PIM-SM source control denies unauthorized sources from registering with an RP.
n Disabling multicast groups: Individual IP multicast groups or a range of IP multicast groups can be administra-tively enabled, and traffic for other groups can be dropped.
© 2008 Cisco Systems Inc. All rights reserved. This publication is protected by copyright. Please see page 98 for more details.
CCDP ARCH Quick Reference
CCDP ARCH Quick Reference By Kevin Wallace, Michael Watkins ISBN: 9781587054990 Publisher: Cisco Press
Prepared for Kevin Kem, Safari ID: [email protected] Licensed by Kevin Kem
Print Publication Date: 2007/10/26 User number: 1023945 Copyright 2007, Safari Books Online, LLC.
This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the prior written permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or that otherwise violates the Safari Terms of Service is strictly prohibited.
Designing Voice over WLAN Networks