arding [RFC 2598] and assured for- warding [RFC 2597]. The former imitates the behavior of a circuit-switched network and the latter provides drop precedence. DiffServ scales better than integrated services because it releases routers from the requirement to maintain per-flow state. Even with Diff- Serv, however, networks still need admission control mechanisms. Other- wise nothing would prevent end systems from tagging all traffic as high priority and swamping the network. RSVP can be used for admission con- trol, SO expect to see RSVP and DiffServ used together for maximum scala- bility, as shown in Figure 3-22. Figure 3-22 DiffServ and RSVP working together. Differentiated services The Internet Multimedia Conferencing Architecture Session Announcement Protocol (SAP) When I decide to watch TV, I usually check the program guide to see which channels are broadcasting something of interest. Once I've made a selec- tion, I turn on the TV and turn to the correct channel. The program guide contains information about the contents of available programs, the channel they are on and the broadcast schedule. The Internet utilizes a similar procedure. I need to select the most interesting multicast session from among all those available. I also need to know how to configure multimedia tools to receive the session chosen. It is important to know, for instance, whether a session consists of just audio or contains video as well. The Session Announcement Protocol (SAP) [RFC 2974] comes into play to distribute information about multicast sessions among potential receivers. SAP undertakes the task of multicasting session descriptions on a well- known multicast address and port (Figure 3-23). Because multicast tech- nology does not provide reliability, SAP announcements are unreliable and must be retransmitted periodically. SAP announcements use a fixed amount of bandwidth, SO a SAP host can afford to listen to all the announcements sent by other hosts on the same address and port. Depending on the number of announcements, the hos