Перевод RFC 2842

На главную

Network Working Group Request for Comments: 2842 Category: Standards Track

R. Chandra

Redback Networks Inc.

J. Scudder

cisco Systems

May 2000

Анонсирование возможностей в BGP-4

Capabilities Advertisement with BGP-4¹

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.

Авторские права

Тезисы

В настоящее время BGP-4 требует от узла BGP разрыва соединения с партнером при получении от того сообщения OPEN с одним или несколькими нераспознанными значениями дополнительных параметров. Это осложняет добавление новых возможностей в BGP.

В этом документе определяется новый дополнительный параметр Capabilities, который будет способствовать добавлению новых возможностей в протокол BGP путем анонсирования этих возможностей партнеру без разрыва соединения BGP.

1. Обзор

Когда узел BGP [BGP-4], поддерживающий анонсирование возможностей, передает своему партнеру сообщение OPEN, это сообщение может включать дополнительный параметр (Optional Parameter) Capabilities. Данный параметр включает список возможностей, поддерживаемых узлом.

Узел BGP определяет поддерживаемые партнером возможности, проверяя список возможностей, включенных в дополнительный параметр Capabilities сообщения OPEN, которое данный узел получил от своего партнера.

Узел BGP, поддерживающий ту или иную возможность, может использовать ее при работе со своим партнером после того, как определеит (как описано выше), что партнер также поддерживает эту возможность.

Узел BGP считает, что его партнер не поддерживает ту или иную возможность, если в ответ на сообщение OPEN с дополнительным параметром Capabilities приходит сообщение NOTIFICATION, содержащее Error Subcode = Unsupported Optional Parameter. В таких случаях узлу следует предпринять попытку заново организовать соединение BGP с этим партнером без использования дополнительного параметра Capabilities.

Если узел BGP, поддерживающий ту или иную возможность, определяет, что его партнер не поддерживает эту возможность, узел может передать партнеру сообщение NOTIFICATION и разорвать соединение с ним. В поле Error Subcode этого сообщения следует поместить значение Unsupported Capability. В сообщение следует включать возможность (возможности), которая заставила узел передать это сообщение. Решение о передаче сообщения и разрыве соединения с партнером узел принимает по своему усмотрению. При разрыве соединения не следует предпринимать попытки его автоматического восстановления.

2. Дополнительный параметр Capabilities (тип 2)

Этот дополнительный параметр (Optional Parameter) используется узлом BGP для передачи своему BGP-партнеру списка поддерживаемых данным узлом возможностей.

Параметры включаются в форме одного или нескольких триплетов <Capability + ------------------------------ +

Code, Capability Length, Capability Value>, каждый из которых представляется в | Capability Code (1 октет) | формате: + ------------------------------ +

Краткое описание поле приведено ниже. | Capability Length (1 октет) |

+ ------------------------------ +

Capability Code (код возможности) | Capability Value (перемен.) |

+ ------------------------------ +

Capability Code представляет собой 1-октетное поле, однозначно

идентифицирующее данную возможность.

Capability Length (размер)

Capability Length представляет собой 1-октетное поле, указывающее размер поля Capability Value в октетах.

Capability Value (значение)

Поле Capability Value имеет переменный размер и интерпретируется в зависимости от кода возможности (Capability Code).

¹Данный документ утратил силу и заменен RFC 3392, перевод которого имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru rfc.com.ru

Перевод RFC 2842

Та или иная возможность, указанная полем Capability Code, может включаться в Optional Parameter в нескольких экземплярах.

3. Расширение для обработки ошибок

В этом документе определено новый субкод ошибки (Error Subcode) – Unsupported Capability (неподдерживаемая возможность) со значением 7. В поле данных (Data) сообщения NOTIFICATION следует включать список возможностей, которые вызвали генерацию этого сообщения. В этом случае каждая из включаемых в список возможностей кодируется так же, как в сообщениях OPEN.

4. Согласование с IANA

Параграф 2² определяет новый дополнительный параметр Capability с полем Capability Code. IANA поддерживает реестр значений Capability Code. Нулевое (0) значение Capability Code является резервным. Коды возможностей в диапазоне от 1 до 63 выделяются IANA путем согласования с IETF ("IETF Consensus"), как описано в документе RFC 2434. Коды из диапазона 64 - 127 распределяются IANA в порядке поступления запросов (процедура "First Come First Served"), описанном в документе RFC 2434. Коды от 128 до 255 предназначены для приватного использования ("Private Use"), как определено в RFC 2434.

5. Вопросы безопасности

Данное расширение не оказывает влияния на проблемы безопасности, связанные с протоколом BGP [Heffernan].

6. Благодарности

Авторы выражают свою признательность членам рабочей группы IDR за просмотр документа и комментарии.

7. Литература

[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771³, March 1995.

[Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385⁴, August 1998.

8. Адреса авторов

Ravi Chandra

Redback Networks Inc. 350, Holger Way San Jose, CA 95134 EMail: rchandra@redback.com

John G. Scudder

Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: jgs@cisco.com

Перевод на русский язык Николай Малых

nmalykh@bilim.com

9. Полное заявление авторских прав

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

²В оригинале ошибочно указан параграф 4 (Section 4). Прим. перев.

³Этот документ заменен RFC 4271. Перевод имеется на сайте http://rfc.com.ru. Прим. перев.

⁴Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 2 rfc.com.ru


	На главную




	Network Working Group Request for Comments: 2842 Category: Standards Track			R. Chandra Redback Networks Inc. J. Scudder cisco Systems May 2000

	Анонсирование возможностей в BGP-4 Capabilities Advertisement with BGP-4¹ Статус документа В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений. Авторские права Copyright (C) The Internet Society (2000). All Rights Reserved. Тезисы В настоящее время BGP-4 требует от узла BGP разрыва соединения с партнером при получении от того сообщения OPEN с одним или несколькими нераспознанными значениями дополнительных параметров. Это осложняет добавление новых возможностей в BGP. В этом документе определяется новый дополнительный параметр Capabilities, который будет способствовать добавлению новых возможностей в протокол BGP путем анонсирования этих возможностей партнеру без разрыва соединения BGP. *1. Обзор* Когда узел BGP [BGP-4], поддерживающий анонсирование возможностей, передает своему партнеру сообщение OPEN, это сообщение может включать дополнительный параметр (Optional Parameter) Capabilities. Данный параметр включает список возможностей, поддерживаемых узлом. Узел BGP определяет поддерживаемые партнером возможности, проверяя список возможностей, включенных в дополнительный параметр Capabilities сообщения OPEN, которое данный узел получил от своего партнера. Узел BGP, поддерживающий ту или иную возможность, может использовать ее при работе со своим партнером после того, как определеит (как описано выше), что партнер также поддерживает эту возможность. Узел BGP считает, что его партнер не поддерживает ту или иную возможность, если в ответ на сообщение OPEN с дополнительным параметром Capabilities приходит сообщение NOTIFICATION, содержащее Error Subcode = Unsupported Optional Parameter. В таких случаях узлу следует предпринять попытку заново организовать соединение BGP с этим партнером без использования дополнительного параметра Capabilities. Если узел BGP, поддерживающий ту или иную возможность, определяет, что его партнер не поддерживает эту возможность, узел может передать партнеру сообщение NOTIFICATION и разорвать соединение с ним. В поле Error Subcode этого сообщения следует поместить значение Unsupported Capability. В сообщение следует включать возможность (возможности), которая заставила узел передать это сообщение. Решение о передаче сообщения и разрыве соединения с партнером узел принимает по своему усмотрению. При разрыве соединения не следует предпринимать попытки его автоматического восстановления. *2. Дополнительный параметр Capabilities (тип 2)* Этот дополнительный параметр (Optional Parameter) используется узлом BGP для передачи своему BGP-партнеру списка поддерживаемых данным узлом возможностей. Параметры включаются в форме одного или нескольких триплетов <Capability + ------------------------------ + Code, Capability Length, Capability Value>, каждый из которых представляется в \| Capability Code (1 октет) \| формате: + ------------------------------ + Краткое описание поле приведено ниже. \| Capability Length (1 октет) \| + ------------------------------ + Capability Code (код возможности) \| Capability Value (перемен.) \| + ------------------------------ + Capability Code представляет собой 1-октетное поле, однозначно идентифицирующее данную возможность. Capability Length (размер) Capability Length представляет собой 1-октетное поле, указывающее размер поля Capability Value в октетах. Capability Value (значение) Поле Capability Value имеет переменный размер и интерпретируется в зависимости от кода возможности (Capability Code). ¹Данный документ утратил силу и заменен RFC 3392, перевод которого имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru rfc.com.ru



	Перевод RFC 2842 Та или иная возможность, указанная полем Capability Code, может включаться в Optional Parameter в нескольких экземплярах. *3. Расширение для обработки ошибок* В этом документе определено новый субкод ошибки (Error Subcode) – Unsupported Capability (неподдерживаемая возможность) со значением 7. В поле данных (Data) сообщения NOTIFICATION следует включать список возможностей, которые вызвали генерацию этого сообщения. В этом случае каждая из включаемых в список возможностей кодируется так же, как в сообщениях OPEN.

	*4. Согласование с IANA* Параграф 2² определяет новый дополнительный параметр Capability с полем Capability Code. IANA поддерживает реестр значений Capability Code. Нулевое (0) значение Capability Code является резервным. Коды возможностей в диапазоне от 1 до 63 выделяются IANA путем согласования с IETF ("IETF Consensus"), как описано в документе RFC 2434. Коды из диапазона 64 - 127 распределяются IANA в порядке поступления запросов (процедура "First Come First Served"), описанном в документе RFC 2434. Коды от 128 до 255 предназначены для приватного использования ("Private Use"), как определено в RFC 2434. *5. Вопросы безопасности* Данное расширение не оказывает влияния на проблемы безопасности, связанные с протоколом BGP [Heffernan]. *6. Благодарности* Авторы выражают свою признательность членам рабочей группы IDR за просмотр документа и комментарии. *7. Литература* [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771³, March 1995. [Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385⁴, August 1998. *8. Адреса авторов* Ravi Chandra Redback Networks Inc. 350, Holger Way San Jose, CA 95134 EMail: rchandra@redback.com

	John G. Scudder Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: jgs@cisco.com

	Перевод на русский язык Николай Малых nmalykh@bilim.com *9. Полное заявление авторских прав* Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Подтверждение Финансирование функций RFC Editor обеспечено Internet Society.

	²В оригинале ошибочно указан параграф 4 (Section 4). Прим. перев. ³Этот документ заменен RFC 4271. Перевод имеется на сайте http://rfc.com.ru. Прим. перев. ⁴Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 2 rfc.com.ru