Network Working Group E. Chen
Request for Comments: 4486 Cisco Systems
Category: Standards Track V. Gillet
France Telecom
April 2006
Subcodes for BGP Cease Notification Message
Субкоды для сообщений BGP Cease Notification
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2006).
Аннотация
Этот документ определяет несколько субкодов для сообщений BGP Cease NOTIFICATION, которые будут предоставлять дополнительные сведения, помогающие операторам сетей сопоставлять события в сети и диагностировать проблемы партнёрства BGP.
1. Введение
Этот документ определяет несколько субкодов для сообщений BGP Cease NOTIFICATION, которые будут предоставлять дополнительные сведения, помогающие операторам сетей сопоставлять события в сети и диагностировать проблемы партнёрства BGP. Документ также рекомендует узлам BGP реализовать механизм отката (backoff) при попытках восстановить соединение BGP после получения узлом сообщения NOTIFICATION с субкодом CEASE.
2. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC-2119].
3. Определение субкодов
В таблице приведены субкоды, определённые для сообщений Cease NOTIFICATION.
|
Субкод |
Символьное имя |
Причина |
|---|---|---|
|
1 |
Maximum Number of Prefixes Reached |
Достигнуто максимальное число префиксов |
|
2 |
Administrative Shutdown |
Административное отключение |
|
3 |
Peer De-configured |
Отмена настройки партнёра |
|
4 |
Administrative Reset |
Административный сброс |
|
5 |
Connection Rejected |
Соединение отвергнуто |
|
6 |
Other Configuration Change |
Другие изменения конфигурации |
|
7 |
Connection Collision Resolution |
Разрешение конфликта соединений |
|
8 |
Out of Resources |
Нехватка ресурсов |
4. Использование субкодов
Если узел BGP решает разорвать партнёрство с соседом по причине превышения числом полученных от него префиксов локально настроенного верхнего предела (как указано в [BGP-4]), он должен передать соседу сообщение NOTIFICATION с кодом ошибки Cease и субкодом Maximum Number of Prefixes Reached. Сообщение может включать сведения о семействе адресов (Address Family) [BGP-MP] и верхней границе с поле Data, показанном на рисунке 1, где смысл и использование пары <AFI, SAFI> соответствуют заданному в разделе 7 [BGP-MP].
+-------------------------------+ | AFI (2 октета) | +-------------------------------+ | SAFI (1 октет) | +-------------------------------+ |Предел числа префиксов (4 окт.)| +-------------------------------+
Рисунок 1. Необязательное поле данных.
Если узел BGP решает административно разорвать партнёрство с соседом, ему следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом Administrative Shutdown.
Если узел BGP решает отменить настройку (de-configure) партнёра, ему следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом Peer De-configured.
Если узел BGP решает административно сбросить (reset) партнёрство с соседом, ему следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом Administrative Reset».
Если узел BGP решает запретить соединение BGP (например, партнёр не настроен локально) после восприятия транспортного соединения, ему следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом Connection Rejected.
Если узел BGP решает административно сбросить (reset) партнёрство с соседом по причинам, отличным от указанных выше, ему следует передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом Other Configuration Change.
Если узел BGP решает передать сообщение NOTIFICATION с кодом ошибки Cease в результате процедуры разрешения конфликта (как описано в [BGP-4]), ему следует указать субкод Connection Collision Resolution.
Если у узла BGP недостаточно ресурсов (например, памяти) и он решает сбросить сессию, он может передать сообщение NOTIFICATION с кодом ошибки Cease и субкодом Out of Resources.
Узлу BGP рекомендуется вести себя, как будто атрибут DampPeerOscillations [BGP-4] имеет значение TRUE для этого партнёра при повторе попытки соединения BGP после приёма сообщения Cease NOTIFICATION с субкодом Administrative Shutdown, Peer De-configured, Connection Rejected или Out of Resources. Реализации следует задавать верхнюю границу числа автоматических повторов попыток. По достижении этого предела реализация будет прекращать попытки соединения BGP до административного вмешательства, т. е. установит для атрибута AllowAutomaticStart [BGP-4] значение FALSE.
5. Взаимодействие с IANA
Этот документ задаёт субкоды 1 — 8 для сообщений BGP Cease NOTIFICATION. Расширение этого списка возможно по процедуре Standards Action, заданной в [RFC-2434], или процедуре Early IANA Allocation из [RFC-4020]. Назначение включает номер и имя субкода.
6. Вопросы безопасности
Это расширение не влияет на базовые вопросы безопасности, связанные с имеющимся протоколом BGP.
7. Благодарности
Авторы благодарны Yakov Rekhter, Pedro Marques, Andrew Lange, Don Goodspeed за их рецензии и комментарии.
8. Литература
8.1. Нормативные документы
[BGP-4] Rekhter, Y., Li, T., and S. Hares, «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, «Multiprotocol Extensions for BGP-4», RFC 2858, June 2000.
[RFC-2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.
[RFC-2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
8.2. Дополнительная литература
[RFC-4020] Kompella, K. and A. Zinin, «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 4020, February 2005.
Адреса авторов
Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA EMail: enkechen@cisco.com Vincent Gillet France Telecom Longues Distances 61, rue des Archives 75003 Paris FRANCE EMail: vgi@opentransit.netПеревод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).