home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-idr-bgp4-cap-neg-00.txt < prev    next >
Text File  |  1997-09-09  |  6KB  |  237 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                      Ravi Chandra
  6. Internet Draft                                            Cisco Systems
  7. Expiration Date: February 1998                          John G. Scudder
  8.                                         Internet Engineering Group, LLC
  9.  
  10.                   Capabilities Negotiation with BGP-4
  11.  
  12.                    draft-ietf-idr-bgp4-cap-neg-00.txt
  13.  
  14.  
  15. 1. Status of this Memo
  16.  
  17.    This document is an Internet-Draft.  Internet-Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time.  It is inappropriate to use Internet-Drafts as reference
  25.    material or to cite them other than as ``work in progress.''
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.  
  34. 2. Abstract
  35.  
  36.    Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
  37.    OPEN message with one or more unrecognized Optional Parameters, the
  38.    speaker must terminate BGP peering. This complicates introduction of
  39.    new capabilities in BGP.
  40.  
  41.    This document defines new Optional Parameter, called Capabilities,
  42.    that is expected to facilitate introduction of new capabilities in
  43.    BGP by providing graceful capability negotiation.
  44.  
  45.    The proposed parameter is backward compatible - a router that
  46.    supports the parameter can maintain BGP peering with a router that
  47.    doesn't support the parameter.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Chandra, Scudder                                                 [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.  
  62. Internet Draft     draft-ietf-idr-bgp4-cap-neg-00.txt        August 1997
  63.  
  64.  
  65. 3. Overview of Operations
  66.  
  67.    When a BGP speaker that supports capabilities negotiation sends an
  68.    OPEN message to its BGP peer, the message includes an Optional
  69.    Parameter, called Capabilities. The parameter lists the capabilities
  70.    supported by the speaker. The speaker can mark a listed capability as
  71.    "Required", which means that if the peer doesn't recognize/support
  72.    the capability, the BGP peering shall be terminated.
  73.  
  74.    When the peer receives the OPEN message, if the message contains the
  75.    Capabilities Optional Parameter, the peer checks whether it supports
  76.    all of the listed capabilities marked as R, and if not, sends a
  77.    NOTIFICATION message, and terminates peering. The Error Subcode in
  78.    the message is set to Unsupported Capability. The message should
  79.    contain all the capabilities marked as R that are not supported by
  80.    the peer.  If the peer doesn't support a capability that is not
  81.    marked as R, the peer should not use this as a reason to terminate
  82.    peering.
  83.  
  84.    A BGP speaker may use a particular capability when peering with
  85.    another speaker if both speakers support that capability.  A BGP
  86.    speaker determines the capabilities supported by its peer by
  87.    examining the list of capabilities present in the Capabilities
  88.    Optional Parameter carried by the OPEN message that the peer sends to
  89.    the speaker.
  90.  
  91.    A BGP speaker determines that its peer doesn't support capabilities
  92.    negotiation, if in response to an OPEN message that carries the
  93.    Capabilities Optional Parameter, the speaker receives a NOTIFICATION
  94.    message with the Error Subcode set to Unsupported Optional Parameter.
  95.  
  96.  
  97. 4. Capabilities Optional Parameter (Parameter Type 2):
  98.  
  99.    This is an Optional Parameter that is used by a BGP speaker to convey
  100.    to its BGP peer the list of capabilities supported by the speaker.
  101.  
  102.    The parameter contains one or more triples <Capability Code,
  103.    Capability Length, Capability Value>, where each triple is encoded as
  104.    shown below:
  105.  
  106.  
  107.       +------------------------------+
  108.       | Capability Code (1 octet)    |
  109.       +------------------------------+
  110.       | Capability Length (1 octet)  |
  111.       +------------------------------+
  112.       | Capability Value (variable)  |
  113.  
  114.  
  115.  
  116. Chandra, Scudder                                                 [Page 2]
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Internet Draft     draft-ietf-idr-bgp4-cap-neg-00.txt        August 1997
  123.  
  124.  
  125.       +------------------------------+
  126.  
  127.  
  128.  
  129.    The use and meaning of these fields are as follows:
  130.  
  131.       Capability Code:
  132.  
  133.          Capability Code is a one octet field that unambiguously
  134.          identifies individual capabilities.
  135.  
  136.          The high-order bit of this field is used to mark the capability
  137.          as "Required" (if the bit is set to 1).
  138.  
  139.       Capability Length:
  140.  
  141.          Capability Length is a one octet field that contains the length
  142.          of the Capability Value field in octets.
  143.  
  144.       Capability Value:
  145.  
  146.          Capability Value is a variable length field that is interpreted
  147.          according to the value of the Capability Code field.
  148.  
  149.  
  150.  
  151. 5. Extensions to Error Handling
  152.  
  153.    This document defines new Error Subcode - Unsupported Capability.
  154.    The value of this Subcode is 7. The Data field in the NOTIFICATION
  155.    message lists the set of capabilities that are marked as Required,
  156.    but are either unsupported or unrecognized by the BGP speaker that
  157.    sends the message. Each such capability is encoded the same way as it
  158.    was encoded in the received OPEN message.
  159.  
  160.  
  161. 6. Security Considerations
  162.  
  163.    Security issues are not discussed in this document.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. Chandra, Scudder                                                 [Page 3]
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Internet Draft     draft-ietf-idr-bgp4-cap-neg-00.txt        August 1997
  183.  
  184.  
  185. 7. Acknowledgements
  186.  
  187.    To be supplied.
  188.  
  189.  
  190. 8. References
  191.  
  192.  
  193.    [BGP-4]
  194.  
  195.  
  196.  
  197. 9. Author Information
  198.  
  199.  
  200.    Ravi Chandra
  201.    Cisco Systems, Inc.
  202.    170 West Tasman Drive
  203.    San Jose, CA 95134
  204.    e-mail: rchandra@cisco.com
  205.  
  206.    John G. Scudder
  207.    Internet Engineering Group, LLC
  208.    122 S. Main, Suite 280
  209.    Ann Arbor, MI 48104
  210.    e-mail: jgs@ieng.com
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236. Chandra, Scudder                                                 [Page 4]
  237.