draft-estrin-unified-routing

Last Version:	draft-estrin-unified-routing-00.txt		Tracker Entry
Date:	25-Jun-2002
Disposition:	expired

Network Working Group                                     Deborah Estrin
INTERNET_DRAFT							     USC
                                                                 Tony Li
							   Cisco Systems
							   Yakov Rekhter
				   T.J. Watson Research Center, IBM Corp.

                                                                May 1994

              Unified Routing Requirements for IPng
		<draft-estrin-ipng-unified-routing-00.txt>


Status of this Memo

   This document was submitted to the IETF IPng area in response to
   RFC 1550  Publication of this document does not imply acceptance 
   by the IPng area of any ideas expressed within.  Comments should
   be submitted to the big-internet@munnari.oz.au mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

1.0 IPng Requirements
  The following list provides requirements on the IPng from the perspective
  of the Unified Routing Architecture, as describe in RFC1322.

  . To provide scalable routing, IPng addressing must provide support
  for topologically significant address assignment.

  . Since it is hard to predict how routing information will be
  aggregated, the IPng addressing structure should impose as few
  preconditions as possible on the number of levels in the hierarchy.
  Specifically, the number of levels must be allowed to be different
  at different parts in the hierarchy. Further, the levels must not
  be statically tied to particular parts (fields) in the addressing
  information.

  . Hop-by-hop forwarding algorithm requires IPng to carry enough
  information in the Network Layer header to unambiguously determine a
  particular next hop. Unless mechanisms to compute context-sensitive
  forwarding tables and provide consistent forwarding are defined,
  the requirement assumes the presence of full hierarchical addresses.
  Therefore, IPng packet format must provide efficient determination of
  the full hierarchical destination address.

  . Hierarchical address assignment should not imply strictly
  hierarchical routing. Therefore, IPng should carry enough information
  to provide forwarding along both hierarchical and non-hierarchical
  routes.

  . The IPng packet header should accommodate a "routing label" or
  "route ID". This label will be used to identify a particular FIB to be
  used for packet forwarding by each router.

  Two types of routing labels should be supported: "strong" and "weak".

  When a packet carries a "strong" routing label and a router does not
  have a FIB with this label, the packet is discarded (and an error
  message is sent back to the source).

  When a packet carries a "weak" routing label and a router does not
  have a FIB with this label, the packet should be forwarded via a
  "default" FIB, i.e., according to the destination address. In
  addition, the packet should carry an indication that somewhere along
  the path the desired routing label was unavailable.

  . IPng should provide a source routing mechanism with the following
  capabilities (i.e. flexibility):

    - Specification of either individual routers or collections of routers
      as the entities in the source route.

    - The option to indicate that two consecutive entities in a source route
      must share a common subnet in order for the source route to be valid.

    - Specification of the default behavior when the route to the next entry
      in the source route is unavailable:

    - The packet is discarded, or

    - The source route is ignored and the packet is forwarded based only on
      the destination address (and the packet header will indicate this
      action).

    - A mechanism to verify the feasibility of a source route.