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-multiprotocol-01.txt < prev    next >
Text File  |  1997-09-26  |  17KB  |  536 lines
  1.  
  2. Network Working Group                                   Tony Bates
  3. Internet Draft                                       Cisco Systems
  4. Expiration Date: March 1998                           Ravi Chandra
  5.                                                      Cisco Systems
  6.                                                          Dave Katz
  7.                                                   Juniper Networks
  8.                                                      Yakov Rekhter
  9.                                                      Cisco Systems
  10.  
  11.  
  12.                    Multiprotocol Extensions for BGP-4
  13.  
  14.                 draft-ietf-idr-bgp4-multiprotocol-01.txt
  15.  
  16.  
  17. 1. Status of this Memo
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups.  Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time.  It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as ``work in progress.''
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  31.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.    ftp.isi.edu (US West Coast).
  34.  
  35.  
  36. 2. Abstract
  37.  
  38.    Currently BGP-4 [BGP-4] is capable of carrying routing information
  39.    only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
  40.    enable it to carry routing information for multiple Network Layer
  41.    protocols (e.g., IPv6, IPX, etc...). The extensions are backward
  42.    compatible - a router that supports the extensions can interoperate
  43.    with a router that doesn't support the extensions.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Bates, Chandra, Katz, Rekhter                                    [Page 1]
  54.  
  55.  
  56.  
  57.  
  58.  
  59. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  60.  
  61.  
  62. 3. Overview
  63.  
  64.    The only three pieces of information carried by BGP-4 that are IPv4
  65.    specific are (a) the NEXT_HOP attribute (expressed as an IPv4
  66.    address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI
  67.    (expressed as IPv4 address prefixes). This document assumes that any
  68.    BGP speaker (including the one that supports multiprotocol
  69.    capabilities defined in this document) has to have an IPv4 address
  70.    (which will be used, among other things, in the AGGREGATOR
  71.    attribute). Therefore, to enable BGP-4 to support routing for
  72.    multiple Network Layer protocols the only two things that have to be
  73.    added to BGP-4 are (a) the ability to associate a particular Network
  74.    Layer protocol with the next hop information, and (b) the ability to
  75.    associated a particular Network Layer protocol with NLRI. To identify
  76.    individual Network Layer protocols this document uses Address Family,
  77.    as defined in [RFC1700].
  78.  
  79.    One could further observe that the next hop information (the
  80.    information provided by the NEXT_HOP attribute) is meaningful (and
  81.    necessary) only in conjunction with the advertisements of reachable
  82.    destinations - in conjunction with the advertisements of unreachable
  83.    destinations (withdrawing routes from service) the next hop
  84.    information is meaningless. This suggests that the advertisement of
  85.    reachable destinations should be grouped with the advertisement of
  86.    the next hop to be used for these destinations, and that the
  87.    advertisement of reachable destinations should be segregated from the
  88.    advertisement of unreachable destinations.
  89.  
  90.    To provide backward compatibility, as well as to simplify
  91.    introduction of the multiprotocol capabilities into BGP-4 this
  92.    document uses two new attributes, Multiprotocol Reachable NLRI
  93.    (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI
  94.    (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the
  95.    set of reachable destinations together with the next hop information
  96.    to be used for forwarding to these destinations. The second one
  97.    (MP_UNREACH_NLRI) is used to carry the set of unreachable
  98.    destinations.  Both of these attributes are optional and non-
  99.    transitive.  This way a BGP speaker that doesn't support the
  100.    multiprotocol capabilities will just ignore the information carried
  101.    in these attributes, and will not pass it to other BGP speakers.
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Bates, Chandra, Katz, Rekhter                                    [Page 2]
  114.  
  115.  
  116.  
  117.  
  118.  
  119. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  120.  
  121.  
  122. 4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
  123.  
  124.    This is an optional non-transitive attribute that can be used for the
  125.    following purposes:
  126.  
  127.       (a) to advertise a feasible route to a peer
  128.  
  129.       (b) to permit a router to advertise the Network Layer address of
  130.       the router that should be used as the next hop to the destinations
  131.       listed in the Network Layer Reachability Information field of the
  132.       MP_NLRI attribute.
  133.  
  134.       (c) to allow a given router to report some or all of the
  135.       Subnetwork Points of Attachment (SNPAs) that exist within the
  136.       local system
  137.  
  138.    The attribute contains one or more triples <Address Family
  139.    Information, Next Hop Information, Network Layer Reachability
  140.    Information>, where each triple is encoded as shown below:
  141.  
  142.  
  143.       +---------------------------------------------------------+
  144.       | Address Family Identifier (2 octets)                    |
  145.       +---------------------------------------------------------+
  146.       | Subsequent Address Family Identifier (1 octet)          |
  147.       +---------------------------------------------------------+
  148.       | Length of Next Hop Network Address (1 octet)            |
  149.       +---------------------------------------------------------+
  150.       | Network Address of Next Hop (variable)                  |
  151.       +---------------------------------------------------------+
  152.       | Number of SNPAs (1 octet)                               |
  153.       +---------------------------------------------------------+
  154.       | Length of first SNPA(1 octet)                           |
  155.       +---------------------------------------------------------+
  156.       | First SNPA (variable)                                   |
  157.       +---------------------------------------------------------+
  158.       | Length of second SNPA (1 octet)                         |
  159.       +---------------------------------------------------------+
  160.       | Second SNPA (variable)                                  |
  161.       +---------------------------------------------------------+
  162.       | ...                                                     |
  163.       +---------------------------------------------------------+
  164.       | Length of Last SNPA (1 octet)                           |
  165.       +---------------------------------------------------------+
  166.       | Last SNPA (variable)                                    |
  167.       +---------------------------------------------------------+
  168.       | Network Layer Reachability Information (variable)       |
  169.       +---------------------------------------------------------+
  170.  
  171.  
  172.  
  173. Bates, Chandra, Katz, Rekhter                                    [Page 3]
  174.  
  175.  
  176.  
  177.  
  178.  
  179. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  180.  
  181.  
  182.    The use and meaning of these fields are as follows:
  183.  
  184.       Address Family Identifier:
  185.  
  186.          This field carries the identity of the Network Layer protocol
  187.          associated with the Network Address that follows. Presently
  188.          defined values for this field are specified in RFC1700 (see the
  189.          Address Family Numbers section).
  190.  
  191.       Subsequent Address Family Identifier:
  192.  
  193.          This field provides additional information about the type of
  194.          the Network Layer Reachability Information carried in the
  195.          attribute.
  196.  
  197.       Length of Next Hop Network Address:
  198.  
  199.          A 1 octet field whose value expresses the length of the
  200.          "Network Address of Next Hop" field as measured in octets
  201.  
  202.       Network Address of Next Hop:
  203.  
  204.          A variable length field that contains the Network Address of
  205.          the next router on the path to the destination system
  206.  
  207.       Number of SNPAs:
  208.  
  209.          A 1 octet field which contains the number of distinct SNPAs to
  210.          be listed in the following fields.  The value 0 may be used to
  211.          indicate that no SNPAs are listed in this attribute.
  212.  
  213.       Length of Nth SNPA:
  214.  
  215.          A 1 octet field whose value expresses the length of the "Nth
  216.          SNPA of Next Hop" field as measured in semi-octets
  217.  
  218.       Nth SNPA of Next Hop:
  219.  
  220.          A variable length field that contains an SNPA of the router
  221.          whose Network Address is contained in the "Network Address of
  222.          Next Hop" field.  The field length is an integral number of
  223.          octets in length, namely the rounded-up integer value of one
  224.          half the SNPA length expressed in semi-octets; if the SNPA
  225.          contains an odd number of semi-octets, a value in this field
  226.          will be padded with a trailing all-zero semi-octet.
  227.  
  228.       Network Layer Reachability Information:
  229.  
  230.  
  231.  
  232.  
  233. Bates, Chandra, Katz, Rekhter                                    [Page 4]
  234.  
  235.  
  236.  
  237.  
  238.  
  239. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  240.  
  241.  
  242.          A variable length field that lists NLRI for the feasible routes
  243.          that are being advertised in this attribute. When the
  244.          Subsequent Address Family Identifier field is set to one of the
  245.          values defined in this document, each NLRI is encoded as
  246.          specified in the "NLRI encoding" section of this document.
  247.  
  248.    The next hop information carried in the MP_REACH_NLRI path attribute
  249.    defines the Network Layer address of the border router that should be
  250.    used as the next hop to the destinations listed in the MP_NLRI
  251.    attribute in the UPDATE message.  When advertising a MP_REACH_NLRI
  252.    attribute to an external peer, a router may use one of its own
  253.    interface addresses in the next hop component of the attribute,
  254.    provided the external peer to which the route is being advertised
  255.    shares a common subnet with the next hop address.  This is known as a
  256.    "first party" next hop.  A BGP speaker can advertise to an external
  257.    peer an interface of any internal peer router in the next hop
  258.    component, provided the external peer to which the route is being
  259.    advertised shares a common subnet with the next hop address.  This is
  260.    known as a "third party" next hop information.  A BGP speaker can
  261.    advertise any external peer router in the next hop component,
  262.    provided that the Network Layer address of this border router was
  263.    learned from an external peer, and the external peer to which the
  264.    route is being advertised shares a common subnet with the next hop
  265.    address.  This is a second form of "third party" next hop
  266.    information.
  267.  
  268.    Normally the next hop information is chosen such that the shortest
  269.    available path will be taken.  A BGP speaker must be able to support
  270.    disabling advertisement of third party next hop information to handle
  271.    imperfectly bridged media or for reasons of policy.
  272.  
  273.    A BGP speaker must never advertise an address of a peer to that peer
  274.    as a next hop, for a route that the speaker is originating.  A BGP
  275.    speaker must never install a route with itself as the next hop.
  276.  
  277.    When a BGP speaker advertises the route to an internal peer, the
  278.    advertising speaker should not modify the next hop information
  279.    associated with the route.  When a BGP speaker receives the route via
  280.    an internal link, it may forward packets to the next hop address if
  281.    the address contained in the attribute is on a common subnet with the
  282.    local and remote BGP speakers.
  283.  
  284.    An UPDATE message that carries the MP_REACH_NLRI must also carry the
  285.    ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP
  286.    exchanges).  Moreover, in IBGP exchanges such a message must also
  287.    carry the LOCAL_PREF attribute. If such a message is received from an
  288.    external peer, the local system shall check whether the leftmost AS
  289.    in the AS_PATH attribute is equal to the autonomous system number of
  290.  
  291.  
  292.  
  293. Bates, Chandra, Katz, Rekhter                                    [Page 5]
  294.  
  295.  
  296.  
  297.  
  298.  
  299. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  300.  
  301.  
  302.    the peer than sent the message. If that is not the case, the local
  303.    system shall send the NOTIFICATION message with Error Code UPDATE
  304.    Message Error, and the Error Subcode set to Malformed AS_PATH.
  305.  
  306.  
  307.  
  308. 5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
  309.  
  310.    This is an optional non-transitive attribute that can be used for the
  311.    purpose of withdrawing multiple unfeasible routes from service.
  312.  
  313.    The attribute contains one or more triples <Address Family
  314.    Information, Unfeasible Routes Length, Withdrawn Routes>, where each
  315.    triple is encoded as shown below:
  316.  
  317.       +---------------------------------------------------------+
  318.       | Address Family Identifier (2 octets)                    |
  319.       +---------------------------------------------------------+
  320.       | Subsequent Address Family Identifier (1 octet)          |
  321.       +---------------------------------------------------------+
  322.       | Withdrawn Routes (variable)                             |
  323.       +---------------------------------------------------------+
  324.  
  325.  
  326.  
  327.    The use and the meaning of these fields are as follows:
  328.  
  329.       Address Family Identifier:
  330.  
  331.          This field carries the identity of the Network Layer protocol
  332.          associated with the NLRI that follows. Presently defined values
  333.          for this field are specified in RFC1700 (see the Address Family
  334.          Numbers section).
  335.  
  336.       Subsequent Address Family Identifier:
  337.  
  338.          This field provides additional information about the type of
  339.          the Network Layer Reachability Information carried in the
  340.          attribute.
  341.  
  342.       Withdrawn Routes:
  343.  
  344.          A variable length field that lists NLRI for the routes that are
  345.          being withdrawn from service. When the Subsequent Address
  346.          Family Identifier field is set to one of the values defined in
  347.          this document, each NLRI is encoded as specified in the "NLRI
  348.          encoding" section of this document.
  349.  
  350.  
  351.  
  352.  
  353. Bates, Chandra, Katz, Rekhter                                    [Page 6]
  354.  
  355.  
  356.  
  357.  
  358.  
  359. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  360.  
  361.  
  362.    An UPDATE message that contains the MP_UNREACH_NLRI is not required
  363.    to carry any other path attributes.
  364.  
  365.  
  366. 6. NLRI encoding
  367.  
  368.    The Network Layer Reachability information is encoded as one or more
  369.    2-tuples of the form <length, prefix>, whose fields are described
  370.    below:
  371.  
  372.  
  373.       +---------------------------+
  374.       |   Length (1 octet)        |
  375.       +---------------------------+
  376.       |   Prefix (variable)       |
  377.       +---------------------------+
  378.  
  379.  
  380.  
  381.    The use and the meaning of these fields are as follows:
  382.  
  383.       a) Length:
  384.  
  385.          The Length field indicates the length in bits of the address
  386.          prefix. A length of zero indicates a prefix that matches all
  387.          (as specified by the address family) addresses (with prefix,
  388.          itself, of zero octets).
  389.  
  390.       b) Prefix:
  391.  
  392.          The Prefix field contains address prefixes followed by enough
  393.          trailing bits to make the end of the field fall on an octet
  394.          boundary.  Note that the value of trailing bits is irrelevant.
  395.  
  396.  
  397.  
  398. 7. Subsequent Address Family Identifier
  399.  
  400.    This document defines the following values for the Subsequent Address
  401.    Family Identifier field carried in the MP_REACH_NLRI and
  402.    MP_UNREACH_NLRI attributes:
  403.  
  404.       1 - Network Layer Reachability Information used for unicast
  405.       forwarding
  406.  
  407.       2 - Network Layer Reachability Information used for multicast
  408.       forwarding
  409.  
  410.  
  411.  
  412.  
  413. Bates, Chandra, Katz, Rekhter                                    [Page 7]
  414.  
  415.  
  416.  
  417.  
  418.  
  419. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  420.  
  421.  
  422.       3 - Network Layer Reachability Information used for both unicast
  423.       and multicast forwarding
  424.  
  425.  
  426.    This document reserves values 128-255 for vendor-specific
  427.    applications.
  428.  
  429.    This document reserves value 0.
  430.  
  431.  
  432. 8. Security Considerations
  433.  
  434.    Security issues are not discussed in this document.
  435.  
  436.  
  437. 9. Acknowledgements
  438.  
  439.    To be supplied.
  440.  
  441.  
  442. 10. References
  443.  
  444.  
  445.    [BGP-4]
  446.  
  447.    [IPv4]
  448.  
  449.    [IPv6]
  450.  
  451.    [RFC1700]
  452.  
  453.  
  454. 11. Author Information
  455.  
  456.    Tony Bates
  457.    Cisco Systems, Inc.
  458.    170 West Tasman Drive
  459.    San Jose, CA 95134
  460.    email: tbates@cisco.com
  461.  
  462.    Ravi Chandra
  463.    Cisco Systems, Inc.
  464.    170 West Tasman Drive
  465.    San Jose, CA 95134
  466.    email: rchandra@cisco.com
  467.  
  468.    Dave Katz
  469.    Juniper Networks, Inc.
  470.  
  471.  
  472.  
  473. Bates, Chandra, Katz, Rekhter                                    [Page 8]
  474.  
  475.  
  476.  
  477.  
  478.  
  479. Internet Draft  draft-ietf-idr-bgp4-multiprotocol-01.txt  September 1997
  480.  
  481.  
  482.    3260 Jay St.
  483.    Santa Clara, CA 95054
  484.    email: dkatz@jnx.com
  485.  
  486.    Yakov Rekhter
  487.    Cisco Systems, Inc.
  488.    170 West Tasman Drive
  489.    San Jose, CA 95134
  490.    email: yakov@cisco.com
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533. Bates, Chandra, Katz, Rekhter                                    [Page 9]
  534.  
  535.  
  536.