One document matched: draft-ietf-idr-link-bandwidth-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4360 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4893 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4893.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->

<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-idr-link-bandwidth-00.txt"
 ipr="pre5378Trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="Link Bandwidth">
    BGP Link Bandwidth Extended Community </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Pradosh Mohapatra" initials="P.M."
            surname="Mohapatra">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

          <!-- Reorder these if your country does things differently -->

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>pmohapat@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Rex Fernando" initials="R.F."
            surname="Fernando">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Ave</street>

          <!-- Reorder these if your country does things differently -->

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>rex@juniper.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="April" year="2009" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
<t>
   This document describes an application of BGP extended communities
   that allows a router to perform unequal cost load balancing.
</t>
    </abstract>

  </front>

  <middle>

    <section title="Introduction">

<t>
   When a BGP speaker receives multiple paths from its internal peers,
   it could select more than one path to send traffic to. In doing so,
   it might be useful to provide the speaker with information that
   would help it distribute the traffic unequally based on the cost of
   the external (DMZ) link. This document suggests that the external
   link bandwidth be carried in the network using a new extended
   community <xref target="RFC4360"></xref> - the link bandwidth 
   extended community.
</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
        and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>

</section> <!-- Introduction -->

<section anchor="link_bandwidth"
     title="Link Bandwidth Extended Community">
<t>
   When a BGP speaker receives a route from a directly connected
   external neighbor (the external neighbor that is one IP hop away)
   and advertises this route (via IBGP) to internal neighbors, as part
   of this advertisement the router may carry the bandwidth of the
   link that connects the router with the external neighbor. The
   bandwidth of such a link is carried in the Link Bandwidth
   Community. The community is optional non-transitive. A border
   router MUST strip the link bandwidth community from a route when it
   advertises the route to an external neighbor.
</t>
<t>
   It is noteworthy that the bandwidth carried in the Link Bandwidth
   extended community is the configured bandwidth of the EBGP link.
   It does not depend on the amount of traffic transiting that link.
</t>
<t>
   The value of the high-order octet of the extended Type Field is 0x40.
   The value of the low-order octet of the extended type field for this
   community is 0x04.
</t>
<t>
   The value of the Global Administrator subfield in the Value Field
   SHOULD represent the Autonomous System of the router that attaches
   the Link Bandwidth Community. If four octet AS numbering scheme is
   used <xref target="RFC4893"></xref>, AS_TRANS should be used in the 
   Global Administrator subfield.
</t>
<t>
   The bandwidth of the link is expressed as 4 octets in IEEE floating
   point format, units being bytes per second. It is carried in the
   Local Administrator subfield of the Value Field.
</t>
</section> <!-- Link Bandwidth Extended Community -->

<section title="Deployment Considerations">
<t>
   This document proposes to use the Link Bandwidth extended
   community for the purpose of load balancing in the following two
   scenarios. The first scenario is when the candidate paths are
   identical until and including the IGP distance step in the BGP
   decision process.  The second scenario is when the traffic goes
   via a tunneled network, in which case the candidate paths are
   identical for all steps before the IGP distance step in the BGP
   decision process.  Use of this community for other scenarios is
   outside the scope of this document.
</t>
<t>
   If there are multiple paths to reach a destination and if only some
   of them have link bandwidth community, the receiver should not
   perform unequal cost load balancing based on link bandwidths.
</t>
</section>

<section title="Acknowledgments">
<t>
   The authors would like to thank Yakov Rekhter, Srihari Sangli and
   Dan Tappan for proposing unequal cost load balancing as one
   possible application of the extended community attribute.
</t>
</section>

    <section anchor="IANA" title="IANA Considerations">
<t>
   This document defines a specific application of the two-octet AS
   specific extended community. IANA is requested to assign a sub-
   type value of 0x04 for the link bandwidth extended
   community.

      <figure align="center">
        <artwork align="left"><![CDATA[

   Name                                           Value
   ----                                           -----
   non-transitive Link Bandwidth Ext. Community  0x4004

            ]]></artwork>
      </figure>

</t>
    </section>

    <section anchor="Security" title="Security Considerations">
<t> 
There are no additional security risks introduced by this design.
</t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; 
        here (as shown)
     2. simply use a PI 
        "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: 
          include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included 
     files in the same directory as the including file. You can also define 
     the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be 
     either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include=
       "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      &RFC4360;

      &RFC4893;

    </references>
  </back>
</rfc>