As per Relevance of the word capabilities, we have this rfc below:
Network Working Group R.
Request for Comments: 2842 Redback Networks Inc
Category: Standards Track J.
cisco
May 2000
Capabilities Advertisement with BGP-4
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives
OPEN message with one or more unrecognized Optional Parameters,
speaker must terminate BGP peering. This complicates introduction
new capabilities in BGP
This document defines new Optional Parameter, called Capabilities
that is expected to facilitate introduction of new capabilities
BGP by providing graceful capability advertisement without
that BGP peering be terminated
1. Overview of
When a BGP speaker that supports capabilities advertisement sends
OPEN message to its BGP peer, the message may include an
Parameter, called Capabilities. The parameter lists the
supported by the speaker
A BGP speaker determines the capabilities supported by its peer
examining the list of capabilities present in the
Optional Parameter carried by the OPEN message that the
receives from the peer
A BGP speaker that supports a particular capability may use
capability with its peer after the speaker determines (as
above) that the peer supports this capability
Chandra & Scudder Standards Track [Page 1]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000
A BGP speaker determines that its peer doesn't support
advertisement, if in response to an OPEN message that carries
Capabilities Optional Parameter, the speaker receives a
message with the Error Subcode set to Unsupported Optional Parameter
In this case the speaker should attempt to re-establish a
connection with the peer without sending to the peer the
Optional Parameter
If a BGP speaker that supports a certain capability determines
its peer doesn't support this capability, the speaker may send
NOTIFICATION message to the peer, and terminate peering. The
Subcode in the message is set to Unsupported Capability. The
should contain the capability (capabilities) that causes the
to send the message. The decision to send the message and
peering is local to the speaker. Such peering should not be re
established automatically
2. Capabilities Optional Parameter (Parameter Type 2):
This is an Optional Parameter that is used by a BGP speaker to
to its BGP peer the list of capabilities supported by the speaker
The parameter contains one or more triples <Capability Code
Capability Length, Capability Value>, where each triple is encoded
shown below
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
The use and meaning of these fields are as follows
Capability Code
Capability Code is a one octet field that
identifies individual capabilities
Capability Length
Capability Length is a one octet field that contains the
of the Capability Value field in octets
Chandra & Scudder Standards Track [Page 2]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000
Capability Value
Capability Value is a variable length field that is
according to the value of the Capability Code field
A particular capability, as identified by its Capability Code,
occur more than once within the Optional Parameter
3. Extensions to Error
This document defines new Error Subcode - Unsupported Capability
The value of this Subcode is 7. The Data field in the
message lists the set of capabilities that cause the speaker to
the message. Each such capability is encoded the same way as it
encoded in the received OPEN message
4. IANA
Section 4 defines a Capability Optional Parameter along with
Capability Code field. IANA is expected to create and maintain
registry for Capability Code values. Capability Code value 0
reserved. Capability Code values 1 through 63 are to be assigned
IANA using the "IETF Consensus" policy defined in RFC2434.
Code values 64 through 127 are to be assigned by IANA, using
"First Come First Served" policy defined in RFC2434. Capability
values 128 through 255 are for "Private Use" as defined in RFC2434.
5. Security
This extension to BGP does not change the underlying security
inherent in the existing BGP [Heffernan].
6.
The authors would like to thank members of the IDR Working Group
their review and comments
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
MD5 Signature Option", RFC 2385, August 1998.
Chandra & Scudder Standards Track [Page 3]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000
8. Authors'
Ravi
Redback Networks Inc
350, Holger
San Jose, CA 95134
EMail: rchandra@redback.
John G.
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134
EMail: jgs@cisco.
Chandra & Scudder Standards Track [Page 4]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000
9. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Chandra & Scudder Standards Track [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
