One document matched: draft-irtf-rrg-design-goals-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	  <!ENTITY RFC1958 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1958.xml">
	  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	  <!ENTITY RFC4192 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4192.xml">
	  ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-irtf-rrg-design-goals-03"
     ipr="trust200902"> 

  <front>
    <title abbrev="Design Goals">Design Goals for Scalable Internet Routing
    </title>

    <author fullname="Tony Li" initials="T." role="editor"
            surname="Li">
      <organization>Cisco Systems, Inc.</organization>

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

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

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

        <phone>+1 408 853 9317</phone>

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

      </address>
    </author>

    <date month="October" day="21" year="2010" />

    <area></area>

    <workgroup>Internet Research Task Force</workgroup>

    <keyword>routing</keyword>

    <abstract>
      <t>
	It is commonly recognized that the Internet
	routing and addressing architecture is facing challenges in
	scalability, mobility, multi-homing, and inter-domain traffic
	engineering.  The RRG is designing an alternate architecture to meet
	these challenges.  This document consists of a prioritized list of
	design goals for the architecture.
      </t>
    </abstract>
  </front>

  <middle>
    <!-- Section 1 -->
    <section title="Introduction">
      <t>It is commonly recognized that the Internet
	routing and addressing architecture is facing challenges in
	scalability, mobility, multi-homing, and inter-domain traffic
	engineering.  The Routing Research Group aims to design
	an alternate architecture to meet these challenges. 
	This document presents a prioritized list of
	design goals for the architecture.</t>

	<t>These goals should be taken as guidelines for evaluating possible
	architectural solutions.  The expectation is that these goals will
	be applied with good judgment.
      </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> <!-- end of 1.1 -->

      <section title="Priorities">
	<t>Each design goal in this document has been assigned a priority,
	  which is one of 'required', 'strongly desired', 'desired', and
	  'optional'. 
	  <list hangIndent="8" style="hanging">
            <t hangText="Required:">The solution is REQUIRED to support this
              goal.</t> 

            <t hangText="Strongly desired:">The solution SHOULD support this
              goal unless there exist compelling reasons showing it is
              unachievable, extremely inefficient, or impractical.</t>

	    <t hangText="Desired:">The solution SHOULD support this goal.</t>
	    
	    <t hangText="Optional:">The solution MAY support this goal.</t>
          </list>
	</t>

	<t>It is possible that two design goals at the same priority level may
	be found to be in conflict with one another.  If and when this happens,
	one of them may be subsequently re-prioritized to have the two in
	different priority levels.</t>
      </section>  <!-- end of 1.2 -->
    </section>

    <section title="General Design Goals Collected from Past">
      <t>
	<xref target="RFC1958">RFC 1958</xref> provides an excellent list of
	the original architectural principles of the Internet.  We
	incorporate them here by reference, as part of our desired design goals.
      </t>
    </section> <!-- end of Section 2 -->

    <section title="Design Goals for A New Routing Architecture">

      <section title="Improved routing scalability">
	<t>
	  Long experience with inter-domain routing has shown us that the
	  global BGP routing table is continuing to grow rapidly
	  <xref target="BGPGrowth"/>.  Carrying this large amount of state
	  in the control plane is expensive and places undue cost burdens
	  on network participants that do not necessarily get value from
	  the increases in the routing table size.  Thus, the first
	  required goal is to provide significant improvement to the
	  scalability of the control plane.  It is strongly desired to make
	  the control plane scale independently from the growth of the
	  Internet user population.  If a solution includes support for
	  alternative routes to support faster convergence, the alternative
	  routes should also factor into control plane scalability.
	</t>
      </section>

      <section title="Scalable support for traffic engineering">
	<t>
	Traffic engineering is the capability of directing traffic along
	paths other than those that would be computed by normal IGP/EGP
	routing.  Inter-domain traffic engineering today is frequently
	accomplished by injecting more-specific prefixes into the global
	routing table, which results in a negative impact on routing
	scalability.  A scalable solution for inter-domain traffic engineering
	is strongly desired.
	</t>
      </section>

      <section title="Scalable support for multi-homing">
	<t>
	 Multi-homing is the capability of an organization to be connected
	 to the Internet via more than one other organization.  The
	 current mechanism for supporting multi-homing is to let the
	 organization advertise one or multiple prefixes into the global
	 routing system, again resulting in a negative impact on routing
	 scalability. More scalable solutions for multi-homing are
	 strongly desired.
	</t>
      </section>

      <section title="Scalable support for mobility">
	<t>
	  Mobility is the capability of a host, network, or organization to
	  change its topological connectivity with respect to the remainder
	  of the Internet, while continuing to receive packets from the
	  Internet.  Existing mechanisms to provide mobility support
	  include (1) renumbering the mobile entity as it changes its
	  topological attachment point(s) to the Internet; (2) renumbering
	  and creating a tunnel from the entity's new topological location
	  back to its original location; and (3) letting the mobile entity
	  announce its prefixes from its new attachment point(s).  The
	  first approach alone is considered unsatisfactory as the change
	  of IP address may break existing transport or higher level
	  connections for those protocols using IP addresses as
	  identifiers.  The second requires the deployment of a 'home
	  agent' to keep track of the mobile entity's current location and
	  adds overhead to the routers involved, as well as adding stretch
	  to the path of inbound packet.  Neither of the first two
	  approaches impacts the routing scalability.  The third approach,
	  however, injects dynamic updates into the global routing system
	  as the mobile entity moves.  Mechanisms that help to provide more
	  efficient and scalable mobility support are desired, especially
	  when they can be coupled with security, especially privacy, and
	  support topological changes at a high-rate.
	</t>
      </section>

      <section title="Simplified renumbering">
	<t>
	  Today many of the end-sites receive their IP address assignments
	  from their Internet Service Providers (ISP).  When such a site
	  changes providers, for routing to scale, the site must renumber
	  into a new address block assigned by its new ISP.  This can be
	  costly, error-prone and painful.  Automated tools, once developed,
	  are expected to provide significant help in reducing the
	  renumbering pain.  It is not expected that renumbering will be
	  wholly automated, as some manual reconfiguration is likely to be
	  necessary for changing the last-mile link.  However, the overall
	  cost of this transition should be drastically lowered.
	</t>
	
	<t>
	  In addition to being configured into hosts and routers, where
	  automated renumbering tools can help, IP addresses are also often
	  used for other purposes such as access control lists. They are
	  also sometimes hard-coded into applications used in environments
	  where failure of the DNS could be catastrophic (e.g. certain
	  remote monitoring applications).  Although renumbering may be
	  considered a mild inconvenience for some sites, and guidelines
	  have been developed for renumbering a network without a flag day
	  <xref target="RFC4192"/>, for others, the necessary changes are
	  sufficiently difficult so as to make renumbering effectively
	  impossible.  It is strongly desired that a new architecture allow
	  end-sites to renumber their network with significantly less
	  disruption, or, if renumbering can be eliminated, the new
	  architecture must demonstrate how the topology can be
	  economically morphed to fit the addressing.
	</t>
      </section>

      <section title="Decoupling location and identification">
	<t>
	  Numerous sources have noted that an IPv4 address embodies both
	  host attachment point information and identification information.
	  This overloading has caused numerous semantic
	  collisions that have limited the flexibility of the Internet
	  architecture.  Therefore, it is desired that a solution separate
	  the host location information namespace from the identification
	  namespace. 
	</t>

	<t>
	  Caution must be taken here to clearly distinguish the decoupling of
	  host location and identification information, and the decoupling of
	  end-site addresses from globally routable prefixes; the latter has
	  been proposed as one of the approaches to a scalable routing
	  architecture.  Solutions to both problems, i.e. (1) the decoupling
	  of host location and identification information and (2) a scalable
	  global routing system (whose solution may, or may not, depend on
	  the second decoupling) are required and it is required that their
	  solutions are compatible with each other.
	</t>
      </section>

      <section title="First-class elements">
	<t>
	  In the branch of computer science that is devoted to programming
	  language design, there is an explicit notion of a "first-class
	  element" in the design.  These are language elements that are
	  fully integrated into the language, with clear, consistent,
	  logical and natural semantics and obvious interactions with all
	  of the other elements in the language <xref target="FirstClass"/>.
	</t>
	<t>
	  For our architectural purposes, it is strongly desired that the
	  primary mechanisms in an architecture all be first-class
	  elements.  More specifically, if a tunneling mechanism is used to
	  provide network layering, connectivity virtualization, or a
	  connection-oriented mode, then it is strongly desired that the
	  tunneling mechanism be a first-class element in the architecture.
	  This requires that the issues of path MTU, reachability, and
	  recursion be addressed.
	</t> 
      </section>

      <section title="Routing quality">
	<t>
	  The routing subsystem is responsible for computing a path from
	  any point on the Internet to any other point in the Internet.
	  The quality of the routes that are computed can be measured by a
	  number of metrics, such as convergence, stability, and stretch.  

	  <list><t>
	      The stretch factor is the maximum ratio between the length of a
	      route computed by the scheme and that of a shortest path
	      connecting the same pair of nodes. <xref target="JACM89"/>
	  </t>
	  </list>

	  A solution is strongly desired to provide routing quality
	  equivalent to what is available today or better.

	</t>
      </section>

      <section title="Routing security">
	<t>
	  Currently, the routing subsystem is secured through a number of
	  protocol specific mechanisms of varying strength and
	  applicability.  Any new architecture is required to provide at
	  least the same level of security as is deployed as of when the
	  new architecture is deployed.
	</t>
      </section>

      <section title="Deployability">
	<t>
	Since solutions that are not deployable are simply academic
	exercises, solutions are required to be deployable from a technical
	perspective. Furthermore, given the extensive deployed base of
	today's Internet, a solution is required to be incrementally
	deployable.
	</t>
      </section>

    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no requests to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>All solutions are required to provide security that is at least as
      strong as the existing Internet routing and addressing architecture.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">

      &RFC1958;
      &RFC2119;
      &RFC4192;
    </references>

    <references title="Informative References">
      <reference anchor="BGPGrowth" target="http://bgp.potaroo.net/">
	<front>
	  <title>BGP Routing Table Analysis Reports</title>
	  <author initials="G." surname="Huston">
	    <organization></organization>
	  </author>
	</front>
      </reference>

      <reference anchor="JACM89"
		 target="http://portal.acm.org/citation.cfm?id=65953"> 
	<front>
	  <title>A trade-off between space and efficiency for routing
	    tables</title>

	  <author initials="D." surname="Peleg" fullname="David Peleg">
	    <organization>Weizmann Institute, Rehovot, Israel</organization> 
	  </author>

	  <author initials="E." surname="Upfal" fullname="Eli Upfal">
	    <organization>Weizmann Institute, Rehovot, Israel</organization> 
	  </author>

	  <date month="July" year="1989"/>
	</front>
	<seriesInfo name='Journal of the ACM' value='Volume 36, Issue 3'/>
      </reference>

      <reference anchor="FirstClass"
		 target="http://en.wikipedia.org/wiki/First-class_object">
	<front>
	  <title>First-class object</title>
	  <author>
	    <organization>
	    </organization>
	  </author>
	</front>
      </reference>

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