Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Тезисы
В этом документе определяется новый дополнительный параметр Capabilities, который предположительно, будет упрощать добавление новых возможностей в протокол BGP (Border Gateway Protocol) путем анонсирования этих возможностей партнеру без разрыва соединения BGP.
Этот документ заменяет собой RFC 3392.
1. Введение
Базовая спецификация BGP-4 [RFC4271] требует от узла BGP разрыва соединения с партнером при получении от того сообщения OPEN с одним или несколькими нераспознанными значениями дополнительных параметров. Это осложняет добавление новых возможностей в BGP.
Данная спецификация определяет Optional Parameter и правила обработки, позволяющие узлам BGP согласовывать возможности в сообщениях OPEN. Пара узлов BGP, поддерживающих данную спецификацию, может организовать партнерские отношения даже при представлении неподдерживаемых возможностей, если поддерживаются все возможности, требуемые для организации партнерства.
2. Описание требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].
3. Обзор
Когда узел BGP [RFC4271], поддерживающий анонсирование возможностей, передает своему партнеру сообщение OPEN, это сообщение может включать дополнительный параметр Capabilities. Данный параметр содержит список возможностей, поддерживаемых узлом.
Узел BGP определяет поддерживаемые партнером возможности, проверяя список возможностей, включенных в дополнительный параметр Capabilities сообщения OPEN, которое данный узел получил от своего партнера.
Узел BGP, поддерживающий ту или иную возможность, может использовать ее при работе со своим партнером после того, как определит (как описано выше), что партнер также поддерживает эту возможность. Проще говоря, та или иная возможность может поддерживаться для соединения, если ее анонсируют оба партнера. Если любой из партнеров не анонсирует ту или иную возможность, последняя не может использоваться.
Узел BGP считает, что его партнер не поддерживает ту или иную возможность, если в ответ на сообщение OPEN с дополнительным параметром Capabilities приходит сообщение NOTIFICATION, содержащее Error Subcode = Unsupported Optional Parameter (это следствие базовой спецификации BGP-4 [RFC4271], а не новое требование). В таких случаях узлу следует предпринять попытку заново организовать соединение BGP с этим партнером без использования дополнительного параметра Capabilities.
Если узел BGP, поддерживающий ту или иную возможность, определяет, что его партнер не поддерживает эту возможность, узел может передать партнеру сообщение NOTIFICATION и разорвать соединение с ним (см. параграф 5. Расширение для обработки ошибок). Например, узлу BGP может потребоваться разрыв соединения, если он организовал это соединение для обмена маршрутами IPv6 и узнал, что партнер не поддерживает многопротокольные расширения для BGP-4 [RFC4760]. В таких случаях в поле Error Subcode этого сообщения следует поместить значение Unsupported Capability. Сообщение должно включать возможность (возможности), которая заставила узел передать это сообщение. Решение о передаче сообщения и разрыве соединения с партнером узел принимает по своему усмотрению. При разрыве соединения не следует предпринимать попытки его автоматического восстановления.
Если узел BGP получает от своего партнера анонс возможности, которую он не поддерживает или не может распознать, данный узел должен игнорировать эту возможность. В частности, недопустимо передавать сообщение Unsupported Capability NOTIFICATION и разрывать сессию BGP в ответ на получение анонса возможности, не поддерживаемой локальным узлом.
4. Дополнительный параметр Capabilities (тип 2)
Этот дополнительный параметр (Optional Parameter) используется узлом BGP для передачи своему BGP-партнеру списка поддерживаемых данным узлом возможностей. Представление значений BGP Optional Parameter описано в параграфе 4.2 [RFC4271]. Дополнительный параметр Capabilities относится к типу 2.
Параметр включает один или множество триплетов <Capability Code, Capability Length, Capability Value>, каждый из которых представляется в формате:
+------------------------------+ | Capability Code (1 octet) | +------------------------------+ | Capability Length (1 octet) | +------------------------------+ | Capability Value (variable) | ~ ~ +------------------------------+
Использование и значение полей описано ниже.
- Capability Code (код возможности)
- Capability Code представляет собой 1-октетное поле, однозначно идентифицирующее данную возможность.
- Capability Length (размер)
- Capability Length представляет собой 1-октетное поле, указывающее размер поля Capability Value в октетах.
- Capability Value (значение)
- Поле Capability Value имеет переменный размер и интерпретируется в зависимости от кода возможности (Capability Code).
Узлу BGP не следует включать в сообщения дубликаты возможностей с совпадающими значениями полей Capability Code, Capability Length, Capability Value. Отметим однако, что обработка дубликатов не требует специальных действий, поскольку дополнительный экземпляр возможности ничего не изменяет в списке анонсируемых возможностей; поэтому узел BGP BGP BGP BGP должен быть готов к восприятию сообщений со множеством экземпляров одной возможности.
Узлы BGP могут включать более одного экземпляра возможности (заданной значением Capability Code) с отличным от нуля значением поля Capability Length, но с разными значениями Capability Value (значения поля Capability Length могут совпадать или различаться). Обработка таких экземпляров определяется значением поля Capability Code и должна быть описана в документе, содержащем спецификации новой возможности.
Дополнительный параметр Capabilities (OPEN Optional Parameter Type 2) следует включать в сообщение OPEN только один раз. Если узел BGP хочет включть в сообщение OPEN множество возможностей, ему следует делать это, как описано выше, перечисляя все возможноссти с использованием формата TLV в одном параметре Capabilities. Однако для совместимости с более ранними версиями узел BGP должен быть готов к получению сообщений OPEN содержащих множество параметров Capabilities, каждый из которых содежит TLV для одной или множества возможностей. Набор возможностей следует обрабатывать одинаково во всех случаях независимо от того, получен этот набор в одном параметре Capabilities сообщения OPEN или распределен по множеству параметров Capabilities.
5. Расширение для обработки ошибок
В этом документе определено новый субкод ошибки (Error Subcode) — Unsupported Capability (неподдерживаемая возможность) со значением 7. В поле данных (Data) сообщения NOTIFICATION должен включаться список возможностей, которые вызвали генерацию этого сообщения. В этом случае каждая из включаемых в список возможностей кодируется так же, как в сообщении OPEN.
Как указано в параграфе 3. Обзор, сообщение Unsupported Capability NOTIFICATION обеспечивает для узла BGP способ уведомления о том, что его партнер не поддерживает возможность, без которой партнеры не смогут работать. Недопустимо использовать такие уведомления в случаях, когда узел BGP получает анонс возможности, который он не способен понять; такие анонсы должны игнорироваться.
6. Согласование с IANA
В этом документе определен новый дополнительный параметр Capability с полем Capability Code. IANA поддерживает реестр значений Capability Code. Нулевое (0) значение Capability Code является резервным. Коды возможностей в диапазоне от 1 до 63 выделяются IANA после обзора IETF («IETF Review»), как описано в документе [RFC5226]. Коды из диапазона 64 — 127 распределяются IANA в порядке поступления запросов (процедура «First Come First Served»), описанном в документе [RFC5226]. Коды от 128 до 255 предназначены для приватного использования («Private Use»), как определено в [RFC5226].
IANA поддерживает реестр дополнительных параметров сообщений OPEN, называемый «BGP OPEN Optional Parameter Types». Дополнительные параметры идентифицируются однооктетными целыми числами без знака Parameter Type. Значения типов (0 — резерв) распределяются в соответствии с процедурой «IETF Review», определенной в [RFC5226].
В настоящее время реестр ыключает два значения Parameter Type:
- Parameter Type 1: Authentication свидетельство подлинности (не рекомендуется использовать) [RFC4271] [RFC5492]
- Parameter Type 2: Capabilities — возможности [RFC5492]
7. Вопросы безопасности
Данное расширение не оказывает влияния на проблемы безопасности, связанные с протоколом BGP [RFC4272].
8. Благодарности
Авторы выражают свою признательность членам рабочей группы IDR, а также IESG и его управлениям за просмотр документа и комментарии.
9. Литература
9.1. Нормативные документы
| [RFC2119] | Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, Март 1997. |
| [RFC4271] | Rekhter, Y., Li, T., and S. Hares, «Протокол BGP-4», RFC 4271, Январь 2006 |
| [RFC5226] | Narten, T. и H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, Май 2008. |
9.2. Дополнительная литература
| [RFC4272] | Murphy, S., «Анонсирование возможностей в BGP-4», RFC 4272, Январь 2006. |
| [RFC4760] | Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Многопротокольные расширения для BGP-4», RFC 4760, Январь 2007. |
Приложение A. Сравнение RFC 2842 и RFC 3392
В дополнение к незначительным редакторским правкам в RFC 3392 разъяснен вопрос обработки множества экземпляров анонса одной возможности.
Приложение B. Сравнение RFC 3392 с данным документом
В этом документе внесены незначительные редакторские правки, обновлены ссылки, разъяснено использование сообщений Unsupported Optional Parameter NOTIFICATION и обработка множества параметров Capabilities в сообщении OPEN, а также изменен уровней требований в ряде случаев со следует на должно (MUST взамен SHOULD).
Адреса авторов
John G. Scudder
Juniper Networks
EMail: ten.repinuj@sgj
Ravi Chandra
Sonoa Systems
EMail: moc.smetsysaonos@ardnahcr