Limitations of Session Announcement Protocol (SAP)
draft-asaeda-mboned-sap-limitation-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Hitoshi Asaeda , Vincent Roca | ||
| Last updated | 2011-03-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The Session Announcement Protocol (SAP) [2] has historically been used to announce information for all available IP multicast sessions to the prospective receivers in the experimental MBone. Each receiver can then discover which sessions are available and which ones he may want to join. Although SAP is easy to use, SAP is not scalable and controlling the SAP message transmission in a wide area network is not easy. Therefore this document describes the limitations of SAP when used in the global Internet. Furthermore, SAP has recently been used as a convenient method for conveying configuration information to a set of receivers that are already interested by a multicast session (e.g., to carry FEC Framework Configuration Information [7]). This documents describes the limitations of SAP for this type of usage, since this latter is rather different from its original goals.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)