Протоколы SAP
Протокол оповещения о сервисах (Service Adertisement Protocol, SAP) рекламирует, почти в буквальном смысле этого слова, сетевые устройства и ресурсы, SAP выдает информацию о серверах, маршрутизаторах, интеллектуальных принтерах и т.д. Хотя SAP, в принципе, протокол прикладного уровня, он обращается к IPX напрямую. Информацию у SAP получают и другие подпрограммы, в частности NCP и SPX.
Поскольку NetWare – это есть сеть в которой для адресации используются номера устройств, должен быть какой-то способ перевода установленных человеком имен устройств в «реальные» числовые адреса этих устройств. SАР предоставляет эту услугу. Когда появляется эта программа или сервис, SАР замечает ее и создает соответствующий элемент у себя в таблицах. Хотя такой динамический реестр имен и облегчает жизнь пользователям, на постоянное обновление информации может быть «истрачена» вся полоса пропускания сети, потому что каждое SАР-устройство имеет свои таблицы рассылки. Для пользователей глобальной сети фильтрация SАР-пакетов на маршрутизаторах — хороший способ освобождения солидной части полосы пропускания. SАР можно также имитировать на маршрутизаторах:сервис объявляется, но линии глобальной сети не занимаются передачей SАР-пакетов — передаются только «образы» сервисов.
Выводы
— Стек Novell состоит из четырех уровней: канального, который собственно стеком Novell не определяется; сетевого, представленного протоколом дейтаграммного типа IPX; транспортного, на котором работает протокол надежной передачи данных SPX; прикладного, на котором работает протокол NCP, поддерживающий файловую службу и службу печати, а также протоколы SAP и NDS, выполняющие служебные функции по поиску в сети разделяемых ресурсов.
— Стек Novell изначально разрабатывался для небольших локальных сетей.
— Особенностью стека Novell является то, что основной прикладной протокол NCP не пользуется транспортным протоколом SPX, а обращается непосредственно к сетевому протоколу IPX. Это значительно ускоряет работу стека, но усложняет прикладной протокол NCP.
— Сетевой IPX-адрес состоит из номера сети, назначаемого администратором, и номера узла, который в локальных сетях совпадает с аппаратным адресом узла, то есть МАС-адресом. Использование аппаратных адресов узлов на сетевом уровне ускоряет работу протокола, так как при этом отпадает необходимость в | выполнении протокола типа ARP. Также упрощается конфигурирование компьютеров сети, так как они узнают свой номер сети от локального маршрутизатора, а номер узла извлекается из сетевого адаптера.
— Недостатком IPX-адресации является ограничение в 6 байт, накладываемое на адрес узла на сетевом уровне. Если какая-либо составная сеть использует аппаратные адреса большего размера (это может произойти, например, в сети Х.25), то протокол IPX не сможет доставить пакет конечному узлу такой сети.
— Номера сетей Novell не распределяются централизованно, а выдаются адмирнистратором.
— лиценцированное программное обеспечение, сдерживало широкое распространение.
— IPX-маршрутизаторы используют протоколы динамической маршрутизации RIP IPX, являющийся аналогом RIP IP, и NLSP, который во многом похож на протокол OSPF сетей TCP/IP.
— каждый маршрутизатор должен знать, как попасть во все остальные сегменты сети, что несмотря на разработку протокола NLSP слишком загружает трафик широковещательными сообщениями маршрутизаторов.
1. Понятие протокола;
2. Что такое стек протоколов?
3. Как протоколы располагаются в стеке?
4. Что такое дейтограмма и сеанс?
5. Что такое «маршрутизированный протокол»?
6. Какой компонент должен присутствовать в сетевом имени маршрутизированного протокола?
7. Стек NetBIOS/SMB маршрутизированный или нет?
8. Какой вид связи предоставляет стек NetBIOS/SMB: дейтограммный, сеансовый или по выбору?
9. Что из себя представляет имя NetBIOS?
10. Как устанавливается соответствие сетевого и аппаратного имен в стеке NetBIOS/SMB?
11. Стек IPX/ SPX маршрутизированный или нет?
12. Какой вид связи – дейтограммный или сеансовый или по выбору предоставляет стек IPX/SPX?
13. Назначение протокола SPX?
14. Структура имени IPX/SPX и его размерность?
15. Кто присваивает сетевые адреса IPX?
16. Что такое «сокет»?
17. Почему в стеке IPX/SPX в явном виде присутствует сокет?
18. Что такое «хоп» и «тик»?
19. Плюсы и минусы аппаратного представления адреса узла в стеке IPX/SPX?
20. Чем схема маршрутизации принятая в стеке IPX/SPX ограничивает масштаб сети?
21. Недостатки протокола RIP в стеке IPX/SPX.
22. Каким образом устранялись недостатки и ограничения по масштабу сети в сетях IPX/SPX?
23. Каким образом стек IPX/SPX стал маршрутизированным в глобальных сетях?
Sap протокол что это
The Session Announcement Protocol (SAP) must be one of the simplest protocols around. To announce a multicast session, the session creator merely multicasts packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place. People that wish to know which sessions are going to be active simply listen to the same well-known multicast group, and receive those announcement packets. Of course, the protocol gets a little more complex when we take security and caching into account, but basically that’s it.
The SAP packet format (for IPv4) is shown in figure 6.2. The Message Type (MT) field indicates whether this packet announces a session, or deletes an announcement. One bit (E) indicates whether or not the payload is encrypted and one bit (C) indicates whether or not the payload is compressed. The combination of message ID hash and original source is supposed to provide a unique announcement ID that can be used to identify this particular version of this particular session. This is useful for caching or for ignoring packets that we previously failed to decrypt, but as this announcement ID is not guaranteed to be unique, care must be taken to also check the packet length and periodically check the packet contents themselves.
SAP announcements can be authenticated by including a digital signature of the payload in the optional authentication header . Both PGP and PKCS#7 based digital signatures are currently supported in the SAP protocol, although currently not many announcements are authenticated. As multicast-based sessions become more popular and people attempt to subvert them, this will no-doubt change.
SAP announcements can also be encrypted. However, this does not mean that the standard way to have small private wide-area conferences will be to announce them with encrypted SAP — the Session Initiation Protocol is a more appropriate mechanism for such conferences. The main uses for encrypted SAP announcements would appear to be in intranet environments where the SAP announcement bother few additional people, or for very large sessions where members are charged to participate. In the latter case, it would probably be a good idea to provide an additional level of access control beyond SAP encryption because it is easy for one misbehaving participant to leak a SAP key to other potential participant unless the keys are embedded in hardware as they are with satellite television smart cards.
The announcement rate for SAP is quite low, with typically several minutes between repeated announcements of the same session. Thus a user starting a SAP receiver will have to wait for a few minutes before seeing all the sessions. This is normally solved by caching — either by running a SAP receiver in the background all the time to keep the cache up-to-date, or by going to a local SAP proxy on startup and requesting a cache download.
It should be clear that although SAP will scale to any number of receivers, it will not scale to huge numbers of sessions. It is currently an IETF Experimental Standard, which reflects this belief that we will eventually need to replace it with something different. In the meantime though, it is a great way to bootstrap the use of IP multicast, and with appropriate caching, SAP will be OK with up to a few thousand sessions advertised.
SAP should be used for sessions of some public interest where the participants are not known in advance. If you know who you want in your session, a better mechanism is to explicitly invite them using SIP.
SAP/SDP Listener
Over the last years the Internet has been experiencing an extraordinary development not only in what refers the number of users but also with the respect to the increasing diversity of services that started being deployed over this global network infrastructure. Multimedia multicast sessions, such as videoconferencing, are a perfect example of how Internet is currently used to support functionalities that go well beyond the single HTML page retrieval.
The proliferation of these multimedia sessions, which by definition involve more than one participant, revealed the need of specifying a standard mean to distribute session information to prospective participants. Session Announcement Protocol (SAP) and Session Description Protocol (SDP) are two complementary protocols that were designed for this purpose.
The project here described aimed to develop a software module capable of receiving session announcements, extracting the data contained in a session description and presenting this information in a understandable way to a end user. By making use of external applications to handle multimedia content this module also offers the possibility of joining to a particular announced session.
Introduction
The expansion of the Internet in geographical scope has been accompanied by a growth in the diversity and complexity of services supported over it. From a single text-based approach the users have been progressively using the Internet as a powerful infrastructure to exchange richer types of data. The generation of multimedia content in multiple formats and the need of distributing this information led to the creation of multicast multimedia sessions. In order to join and participate in multimedia sessions a potential participant needs in first place to discover what sessions are taking (or will take) place and after he needs to know the relevant details about a particular session. The project here described deals with two complementary protocols, Session Announcement Protocol [1] and Session Description Protocol [2] , that are used to distribute and convey the necessary information about multimedia sessions.
The project consisted of developing a software module capable of receiving session announcements, extracting the data contained in a session description and presenting this information in a understandable way to a end user. By making use of external applications to handle multimedia content this module also offers the possibility of joining to a particular announced session.
The remaining part of this document is organized as follows. First I provide some background on SAP and SDP protocols. The section on the program documentation provides a link to another page containing the details of the software usage and some information about the development process. The related work section highlights the difference between this project and other available solutions and the task list presents in a succinct way the several components of the work carried on.
SAP is a simple protocol designed to be used to distribute information about multimedia sessions. A session is advertised by means of a multicast packet sent to a well known address/port. SAP defines the format that these multicast packets must conform to in order to be identified as SAP announcements. Global session announcements should be sent to the multicast address 224.2.127.254 and to the port number 9875.
SAP imposes that each announcement must take place in a periodically fashion. It’s therefore responsibility of each announcer to send periodic repetitions of SAP announcements for session that is advertising. SAP defines a mechanism to convey a session description to potential participants but it does not define itself a format the descriptions should obey to. Therefore it is commonly used with SDP in order to provide the necessary details about the session. Each SAP packet contains a header and a single session description as payload. The format of a SAP packet is shown next:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | ||
| V=1 | A | R | T | E | C | Authentication length | Message ID Hash | ||||||||||||||||||||||||||
| Originating source (32 or 128 bits) | |||||||||||||||||||||||||||||||||
| Optional Authentication Data | |||||||||||||||||||||||||||||||||
| Optional Payload Type | 0 | Payload | |||||||||||||||||||||||||||||||
| Payload . | |||||||||||||||||||||||||||||||||
V= version; A=Address type; R=Reserved; T=Message type; E=Encryption bit; C=Compression bit
SDP defines a format intended to be used for describing multimedia sessions where session is defined in RFC 2327 as "a set of multimedia senders and receivers and the data streams flowing from senders to receivers". The information conveyed by each SDP description must be enough to enable joining and participating in the session. The descriptions are exclusively textual using UTF-8 encoding.
Each description may be divided into two main sections. The first of these sections provides session-level information including among other things the session name, the creator of the session and the time(s) the session is active. The second section consists of one or more media-level descriptions. Each media description applies only to a single media and provides details about the media type, the transport protocol used (RTP, UDP, . ) the port number and eventually the multicast address if not defined yet at the session level.
A SDP description is formed by a set of lines of text each of them of the form <type>=<value>, where type is always a single character and it serves to make a distinction between the different kinds of information contained in a description. Each session starts with a "v=" line and a "m=" line identifies the beginning of a media description. The general "template" as well as an example, both extracted from RFC 2327 document, of an SDP description are listed next:
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Program Documentation
The documentation for the software developed can be found here.
Related Work
There are several existent tools capable of receiving SAP announcements and presenting the session information through a user graphical interface. The most well-known of these available tools is sdr developed at University College of London (UCL).
In this project I have tried to design a simpler but more intuitive user interface than those that are typically seen in other available tools. Moreover, the this project was developed with the main intuit of being integrated in the existing sipc application.
SAP Protocol
The SAP Protocol is the protocol used by SAP programs that communicate using the NI interface. This is an enhanced version of the TCP/IP protocol, which has been extended by one field and some options for error information.
The initial letter S can be used in the route permission table to permit the SAP protocol only. The line is interpreted in the usual way, but only SAP programs (SAP GUI, SAP application server) are allowed to communicate with each other.
The NI network interface provides the SAP protocol as the default for communication, although it can also use the TCP/IP protocol with external programs (for example telnet oder lpd ) that do not «speak» SAP protocol.