Local Scope multicast addresses are in the range of 224.0.0.0 to 224.0.0.255 and are reserved for network protocol use. This address range is also known as the local network control block. Packets destined for multicast addresses in this range are never forwarded out from the local network broadcast domain regardless of the Time to Live (TTL) field in the IP packet header. The TTL is usually set to 1. Below lists some examples of local scope multicast IP addresses:
| 224.0.0.1 | All multicast systems on the subnet |
| 224.0.0.2 | All multicast routers on the subnet |
| 224.0.0.4 | All Distance Vector Multicast Routing Protocol (DVMRP) routers on the subnet |
| 224.0.0.5 | All Open Shortest Path First (OSPF) routers on the subnet |
| 224.0.0.6 | All Open Shortest Path First (OSPF) designated routers (DRs) on the subnet |
| 224.0.0.9 | All Routing Information Protocol Version 2 (RIPv2) routers on the subnet |
| 224.0.0.10 | All Enhanced Interior Gateway Routing Protocol (EIGRP) routers on the subnet |
Transient multicast IP addresses are dynamically assigned for multicast applications and then returned for others to use when no longer needed. Transient multicast IP addresses are assigned from the remainder of the IP multicast address space and are divided into the following 2 types:
- Globally-scoped multicast addresses, in the range of 224.0.1.0 to 238.255.255.255, are to be allocated dynamically throughout the Internet. Ex: The 224.2.0.0/16 range may be used for Multicast Backbone (MBone) applications. MBone consists of Internet routers that support IP multicasting and form a virtual network (multicast channel) for delivering various public and private audio and video programs. MBone was originally created by the IETF to multicast audio and video meetings.
- Limited-scoped or Administratively-scoped multicast addresses, in the range of 239.0.0.0 to 239.255.255.255. RFC 2365 – Administratively Scoped IP Multicast defines that these multicast addresses are reserved for use inside the private domains. The Administratively-scoped multicast address space includes the following scopes:
- Site-Local Scope – 239.252.0.0/16, 239.253.0.0/16, 239.254.0.0/16, 239.255.0.0/16.
- Organization-Local Scope – 239.192.0.0 to 239.251.255.255
The IEEE 802.3 LAN specification defines that the bits 0 and 1 (most significant bits) of the 1st octet indicate a broadcast or multicast frame and a locally administrated frame respectively. A universally administered address is uniquely assigned to a device by its manufacturer – burned-in address (BIA). A locally administered address is assigned to a device by an admin.
IEEE 802.3 MAC Address Format
Take note upon the location of the most significant byte and most significant bit in each byte. IEEE documentation specifies Ethernet MAC addresses with the most significant byte on the left; inside each byte, the leftmost and rightmost bits are the least and most significant bits respectively.
This bit order is referred to as canonical or little-endian.
Note: When overriding the MAC address to use a local address, the device or device driver often does not enforce the setting of the U/L bit to a value of 1.
The IANA owns a block of Ethernet MAC addresses that start with hexadecimal 01:00:5E. The lower half of this block (0100.5E00.0000 – 0100.5E7F.FFFF) is allocated for multicast MAC addresses. The translation between L3 IP multicast and L2 MAC multicast addresses is achieved by mapping the low-order 23 bits of the L3 IP multicast address into the low-order 23 bits of the L2 MAC address.
IP Multicast to Ethernet MAC Multicast Address Mapping
As there are 28 bits (32 – 4 Class D prefix) of unique address space for an IP multicast address and only 23 bits are mapped into the IEEE MAC address, there are 5 bits of overlap (28 – 23). These 5 bits represent 25 = 32 addresses. Therefore, there is a 32:1 overlap of IP addresses to MAC addresses – 32 IP multicast addresses are mapped to the same MAC multicast address. As an example, below lists all the IP multicast addresses that are mapped to the same MAC multicast address 01-00-5E-7F-00-01.| 224.127.0.1 | 225.127.0.1 | 226.127.0.1 | 227.127.0.1 | 228.127.0.1 |
| 229.127.0.1 | 230.127.0.1 | 231.127.0.1 | 232.127.0.1 | 233.127.0.1 |
| 234.127.0.1 | 235.127.0.1 | 236.127.0.1 | 237.127.0.1 | 238.127.0.1 |
| 239.127.0.1 | 224.255.0.1 | 225.255.0.1 | 226.255.0.1 | 227.255.0.1 |
| 228.255.0.1 | 229.255.0.1 | 230.255.0.1 | 231.255.0.1 | 232.255.0.1 |
| 233.255.0.1 | 234.255.0.1 | 235.255.0.1 | 236.255.0.1 | 237.255.0.1 |
| 238.255.0.1 | 239.255.0.1 |
Since one multicast MAC address can actually representing 32 multicast IP addresses, a host must receive and examine every frame destined for the multicast group that it has joined, regardless of the destination multicast IP address that the frame is destined for; followed by examine the IP address in the frame to verify the multicast group that the frame is destined for.
Note: Switches forward frames based on MAC addresses. If a switch is configured for Layer 2 multicast snooping, it will forward frames to all members belong to other multicast groups with the same MAC address mapping, even if the frames belong to a different multicast group. Most Layer 2 switches flood all multicast frames that falls within the MAC address range of 0100.5E00.00xx out to all switch ports even if IGMP snooping is enabled.
Whenever a multicast application is started on a receiver, the application must learn about the available multicast sessions or streams, which are mapped to one or more IP multicast group. The application may then request to join the corresponding multicast groups.
Below lists the available methods for multicast applications to learn about the multicast sessions:
- The application may join a well-known, predefined group in which another application sends announcements about the available sessions.
- The application may contact the appropriate directory servers if they are available.
- The application may be launched from a web page on which the sessions are listed as URLs.
- The application may join a session upon clicking the email link that announced the session.
Another option is the use of the application which called Session Discovery (sd) that acts like a TV program guide to display the multicast contents. A client directory application uses either the Session Description Protocol (SDP) or Session Announcement Protocol (SAP) to learn about the available contents. Note: SDP/SAP is referred to as sdr in Cisco documentation.
The initial sd tool was revised and become the sdr session directory application that provides functions that announce available sessions along with their descriptions, and create new sessions. When SDR is used at the sender side, it creates new sessions and avoids address conflicts. Senders consult their SDR caches upon session creation to choose an unused multicast address. When a new session is created, the sender announces it with all the information that is necessary for receivers to join the session. When SDR is used at the receiver side, it learns about the available sessions. A join to a particular multicast group is initiated when the user selects a multicast channel listed in SDR.
RFC 4566 – Session Description Protocol (SDP) defines the variables that describe the sessions. Most of the variables were inherited from the sdr tool. The RFC does not define the transport of the SDP packets. Below lists the mechanisms to transmit the packets that describe the sessions:
- RFC 2974 – Session Announcement Protocol (SAP) that broadcasts multicast session info.
- RFC 3261 – Session Initiation Protocol (SIP) that defines a signaling protocol for Internet conferencing, telephony, telepresence, event notification, instant messaging, etc.
- RFC 2326 – Real Time Streaming Protocol (RTSP) that serves mainly as a control protocol in multimedia environments. RTSP allows videocassette recorder (VCR)-like controls, eg: select, forward, rewind, pause, stop; and also carries the info of a session.
- Multipurpose Internet Mail Exchange (MIME)-format emails that may carry SDR packets describing multicast sessions.
- Web pages that may provide session descriptions in standardized SDR format.
Cisco IP/TV is an example of IP multicast applications. Cisco IP/TV generally has 3 components – the server (the source), the content manager (the directory server), and the viewer (the receiver). Viewers may contact the content manager directly via unicast and request the list of available programs (sessions or streams) from it. Viewers may also listen to periodic SAP announcements. Cisco IP/TV uses SAP to transport the SDR sessions to the viewers using standard SDR formation.
The term Internet Protocol Television (IPTV) first appeared in 1995 with the founding of Precept Software, which was acquired by Cisco Systems in 1998. The IP/TV technology was then integrated into various Cisco product lines, eg: Cisco IP/TV Software, Cisco Application and Content Networking System (ACNS) Software, Cisco Content Delivery Engine (CDE), Cisco Wide Area Application Engine (WAE), etc.
No comments:
Post a Comment