One document matched: draft-irtf-rrg-design-goals-06.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">
	  <!ENTITY RFC4984 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4984.xml">
	  <!ENTITY RFC5887 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5887.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-06"
     ipr="trust200902"> 

  <front>
    <title abbrev="Scalable Routing 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="January" day="3" year="2011" />

    <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 Routing
	Research Group is investigating an alternate architecture to meet
	these challenges.  This document consists of a prioritized list of
	design goals for the target 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 inter-domain scalability,
	mobility, multi-homing, and inter-domain traffic engineering.
	<xref target='RFC4984'/> The Routing Research Group (RRG) aims to
	design an alternate architecture to meet these challenges.  This
	document presents a prioritized list of design goals for the target
	architecture.
      </t>

      <t>
	These goals should be taken as guidelines for the design and
	evaluation of possible architectural solutions.  The expectation is
	that these goals will be applied with good judgment.
      </t>
      <t>
	The goals presented here were initially presented and discussed at
	the start of the RRG work on a revised routing architecture, and
	were revisited and finalized after the work on that architecture
	was complete.  As such, this represents both the goals that the RG
	started with, plus revisions to those goals based on our increased
	understanding of the space.
      </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', and 'desired'.
	  <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>
          </list>
	</t>

      </section>  <!-- end of 1.2 -->
    </section>

    <section title="General Design Goals Collected from Past">
      <t>
	<xref target="RFC1958"/> provides a 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 that the
	  global BGP routing table is continuing to grow rapidly
	  <xref target="BGPGrowth"/>.  Carrying this large amount of state
	  in the inter-domain routing protocols 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 inter-domain routing
	  subsystem.  It is strongly desired to make the routing subsystem
	  scale independently from the growth of the Internet user
	  population.  If there is a coupling between the size of the user
	  base and the scale of the routing subsystem, then it will be very
	  difficult to retain any semblance of scalability.  If a solution
	  includes support for alternative routes to support faster
	  convergence, the alternative routes should also factor into
	  routing subsystem 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.  The additional prefixes injected to enable traffic
	  engineering place added burden on the scalability of the routing
	  architecture.  At the same time, the need for traffic engineering
	  capabilities is essential to network operations.  Thus, 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="Decoupling location and identification">
	<t>
	  Numerous sources have noted that an IP address embodies both
	  host attachment point information and identification information.
	  <xref target='IEN1'/> 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="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 
	  <list style='numbers'>
	    <t>
	      renumbering the mobile entity as it changes its topological
	      attachment point(s) to the Internet;
	    </t>
	    <t>
	      renumbering and creating a tunnel from the entity's new
	      topological location back to its original location; and
	    </t>
	    <t>
	      letting the mobile entity announce its prefixes from its new
	      attachment point(s).
	    </t>
	    </list>
	  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.  Ideally, such
	  mechanisms should completely decouple mobility from routing.
	</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 <xref target='RFC5887'/>.
	  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 renumbering
	  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="Modularity, composability, and seamlessness">
	<t>
	  A new routing architecture should be modular: it should subdivide
	  into multiple composable, extensible, and orthogonal subsystems.
	  The interfaces between modules should be natural and seamless,
	  without special cases or restrictions.  Similarly, the primitives
	  and abstractions in the architecture should be suitably general,
	  with operations equally applicable to abstractions and concrete
	  entities, and without deleterious side-effects that might hinder
	  communication between endpoints in the Internet.  These
	  properties are strongly desired in a solution.
	</t>
	<t>
	  As an example, if tunneling were used as a part of a solution,
	  tunneling should be completely transparent to both of the
	  endpoints, without requiring new mechanisms for determining the
	  correct maximum datagram size.
	</t>
	<t>
	  The resulting network should always fully approximate the current
	  best-effort Internet connectivity model, and it should also
	  anticipate changes to that model e.g. for multiple differentiated
	  and/or guaranteed upon levels of service in the future.
	</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>
	  A viable solution is 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.  This implies that a solution must continue to
	  support the functions in today's routing subsystem that are
	  actually used.  This includes but is not limited to the ability
	  to control routing based on policy.
	</t>
      </section>

      <section title='Summary of priorities'>
	<t>
	  The following table summarizes the priorities of the design goals
	  discussed above.
	</t>
	<texttable>
	  <ttcol>Design goal</ttcol>	<ttcol>Priority</ttcol>
	  <c>Scalability</c>		<c>Strongly desired</c>
	  <c>Traffic engineering</c>	<c>Strongly desired</c>
	  <c>Multi-homing</c>		<c>Strongly desired</c>
	  <c>Loc/id separation</c>	<c>Desired</c>
	  <c>Mobility</c>		<c>Desired</c>
	  <c>Simplified renumbering</c>	<c>Strongly desired</c>
	  <c>Modularity</c>		<c>Strongly desired</c>
	  <c>Routing quality</c>	<c>Strongly desired</c>
	  <c>Routing security</c>	<c>Required</c>
	  <c>Deployability</c>		<c>Required</c>
	</texttable>
      </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.  This document does not default any architecture or
	any protocol, and thus this document introduces no new security
	issues.
      </t> 
    </section>
  </middle>

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

      &RFC1958;
      &RFC2119;
      &RFC4192;
      &RFC4984;
      &RFC5887;
    </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="IEN1"
		 target="http://www.postel.org/ien/pdf/ien001.pdf">
	<front>
	  <title>Issues in the Interconnection of Datagram Networks</title>
	  
	  <author initials="C.J." surname="Bennett"
		  fullname="C.J. Bennett">
	    <organization>University College London</organization>
	  </author>

	  <author initials="S.W." surname="Edge" fullname="S.W. Edge">
	    <organization>University College London</organization>
	  </author>

	  <author initials="A.J." surname="Hinchley"
		  fullname="A.J. Hinchley"> 
	    <organization>University College London</organization>
	  </author>
	  
	  <date month="July" day="29" year="1977"/>

	</front>
	<seriesInfo name="Internet Experiment Note (IEN)" value="1"/>
	<seriesInfo name="INDRA Note" value="637"/>
        <seriesInfo name="PSPWN" value="76"/>
      </reference>

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