Обслуговуючий персонал тих років зіткнувся з проблемами постійного підключення та переміщення нових пристроїв, а також з необхідністю зміни конфігурації мережі для відповідності сучасним вимогам до мереж. Все це призвело до необхідності створення механізму для автоматиза-ції конфігурації мережевих вузлів, розподілених операційних систем і мережевого програмного забезпечення. Найбільш ефективним способом реалізації такого механізму може бути збереження конфігураційних параметрів і образів програмного забезпечення на одному або декількох серве-рах завантаження (boot server). Під час запуску система взаємодіє з таким сервером, отримує від нього початкові параметри конфігурації і при необхідності завантажує з нього потрібне програмне забезпечення.
BOOTP був введений в RFC 951 як заміна застарілого RARP. Спочатку ВООТР розроблявся для бездискових робочих станцій. Сучасні умови привели до необхідності автоматизації завантаження систем, що мають в ПЗУ тільки базові засоби для IP. UDP і TFTP. Вихідний сценарій завантаження виглядав наступним чином:
Формат повідомлення BOOTP
Для запиту та відповіді завантаження використовується однаковий формат повідомлення. У запиті деякі поля мають нульові значення.
Повідомлення BOOTP складається з:
Код операції (opcode) дорівнює 1 для запиту і 2 для відгуку.
ідентифікатор транзакції
Ідентифікатор транзакції (transaction ID) - 32-бітове ціле число, яке встановлюється клієнтом і повертається сервером. Воно дозволяє клієнту зіставити відгук із запитом. Клієнт встановлює в це поле випадкове число для кожного запиту.
Лічильник секунд
Коли клієнт відсилає перший запит на завантаження даних, поле лічильника секунд має нульове значення. Якщо на запит не спадає відповіді, по завершенні тайм-ауту клієнт знову відправляє запит, змінюючи значення в полі лічильника секунд. Для тайм-ауту клієнт використовує випадковий інтервал, що збільшується до значення 60 с.
Дане поле не має спеціального призначення. Його вміст може перевіряти сервер або мережевий монітор для визначення тривалості очікування клієнтом завантаження по мережі. Сервер може використовувати значення з поля лічильника секунд для ранжирування запитів по пріоритетам, проте в даний час в більшості реалізацій це поле ігнорується.
Ім'я хоста сервера
Ім'я хоста сервера (server hostname) це рядок, яка заповнюється сервером (не обов'язково).
Ім'я завантажувального файлу
Сервер також може заповнити поле імені завантажувального файлу (boot filename). У це поле заноситься повний шлях до файлу, який використовується при завантаженні.
Область для розробників
номери портів
Для BOOTP виділено два заздалегідь відомих порту: 67 для сервера і 68 для клієнта. Це означає, що клієнт не вибирає невикористаний динамічно призначається порт, а використовує порт номер 68. Причина, по якій були обрані два номери портів, замість того щоб використовувати тільки один для сервера, полягає в тому, що сервер може відправити відгук (хоча зазвичай він цього не робить) широкомовною чином.
Якщо відгук від сервера поширювався б широкомовною чином, і якщо клієнту було б необхідно вибрати динамічно призначається номер порту, ці широкомовні пакети також були б отримані іншими додатками на інших хостах, які використовують той же самий динамічно призначається номер порту. Таким чином, можна зробити висновок, що відправляти циркулярний запит на випадковий (динамічно призначається) номер порту не раціонально.
Якщо клієнт скористається заздалегідь відомим портом сервера (67), всі сервери в мережі будуть змушені переглядати кожен широкомовний відгук. (Якщо все сервера були "розбуджені", їм доведеться перевірити код операції, визначити, що це відгук, а не запит, і знову "заснути".) Тому вибір був зупинений на тому, як все зроблено зараз, тобто клієнт має свій власний єдиний заздалегідь відомий порт, який відрізняється від заздалегідь відомого порту сервера.