One document matched: draft-wu-pce-discovery-priority-allocation-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-pce-discovery-priority-allocation-00"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="OSPF for PCE priority">OSPF extension for priority
    allocation support in the PCE discovery</title>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>sunseawq@huawei.com</email>
      </address>
    </author>

    <date year="2013" />

    <area>Routing Area</area>

    <workgroup>PCE working group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Path Computation Element</keyword>

    <abstract>
      <t>Each network domain may contain multiple PCE servers. It provides
      redundancy to the PCCs in the event of a server failure. However load
      balance decision is made by PCC,it doesn’t enable real load balance
      across the PCE servers if PCC still tries PCE one by one and PCE doesn’t
      indicate the load status to the PCC. </t>

      <t>This document proposes new PCE discovery sub-TLV that can be
      announced as attribute in the OSPF advertisement (defined in [RFC5088 ])
      to distribute priority information. </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Usually a single PCE server sits per domain in the nework. The PCE
      server disseminates its address in the network using OSPF [RFC5088] or
      ISIS [RFC5089] and the PCCs connect to it automatically. However in some
      cases, each network domain may contain multiple PCE servers. It provides
      redundancy to the PCCs in the event of a server failure.</t>

      <t>However load balance decision is made by PCC,it doesn’t enable real
      load balance across the PCE servers if PCC still tries PCE one by one
      and PCE doesn’t indicate the load status to the PCC (e.g., the number of
      incoming requests that have already targeted to the PCE).</t>

      <t>This document proposes new PCE discovery TLV that can be announced as
      attribute in the OSPF advertisement (defined in [RFC5088 ]) to
      distribute priority information. </t>
    </section>

    <section title="Conventions used in this document">
      <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">RFC2119</xref>.</t>
    </section>

    <section title="PCE-ALLOCATION-PRIORITY Sub-TLV for PCE Load Balancing">
      <t>The PCE-Allocated-Priority sub-TLV is an optional sub-TLV used to
      indicate allocated priority of each PCE. The format of the sub-TLVs is
      identical to the TLV format used by the Traffic Engineering Extensions
      to OSPF [RFC3630]. It MAY be present within the PCED TLV. It MUST NOT be
      present more than once. If it appears more than once, only the first
      occurrence is processed and any others MUST be ignored. </t>

      <t>The value field of the PCE-ALLOCATED-PRIORITY sub-TLV is expressed as
      32-bit unsigned integer value..</t>

      <t>The format of the PCE-ALLOCATED-PRIORITY sub-TLV is as follows:</t>

      <figure>
        <artwork>     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type = TBD         |            Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Allocated Priority                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type:     TBD
      Length:   4 octets
      Value:    This contains allocated priority value for each PCE 
                server. The priority value can be allocated based 
                on PCE load or incoming request to the PCE server.
</artwork>
      </figure>

      <section title="Use of PCE-ALLOCATION-PRIORITY sub-TLV for PCE discovery">
        <t>Multiple servers can be present in a single network for redundancy
        in which case each PCE server is allocated with a priority value. The
        priority can be allocated based on PCE load (e.g., incoming request to
        the PCE server) announced as attribute in the OSPF advertisement. The
        PCC can be configured to use the highest priority PCE server that is
        available or specify the priority of a computation request when
        multiple PCEs has already been found using OSPF[RFC5088].</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>This document raises no new security issues beyond those described in
      [RFC5088].</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA maintains the registry for the TLVs. PCE-allocated-priority
      sub-TLV will require one new type code per sub-TLV defined in this
      document. </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC5088">
        <front>
          <title>OSPF Protocol Extensions for Path Computation Element (PCE)
          Discovery</title>

          <author fullname="JL. Le Roux" initials="JL." surname="Le Roux">
            <organization></organization>
          </author>

          <date month="January" year="2008" />
        </front>

        <seriesInfo name="RFC" value="5088" />

        <format target="http://www.rfc-editor.org/rfc/rfc5088.txt" type="TXT" />
      </reference>
    </references>
  </back>
</rfc>