ROLC Overview

["j.garrett" <[e-mail]>]

I think it may be useful to summarize the ROLC
problem and proposed solutions.

The ROLC Problem:  Multiple IP networks (or prefixes)
may be overlaid on the same Large Cloud (i.e., subnetwork,
such as ATM, SMDS, Frame Relay, X.25, others?).
In many cases current routing procedures will choose
multi-hop paths across the large cloud.  This may happen
for at least two reasons:

  1)  Current routing procedures are constrained by the
      scope of current address resolution procedures.
      The scope of current address resolution is an IP network,
      or LIS.  Routing procedures will not choose a next-hop
      unless address resolution procedures are available to
      determine the subnetwork address of the next-hop.
      Therefore, next-hops are on the same IP network/LIS
      as the host/router using the next-hop.  Therefore,
      paths across a Large Cloud with multiple IP networks/LISs
      are often multi-hop paths.

  2)  Some routing procedures may aggregate routes.  If a router
      aggregates multiple routes that do not all share the same
      next-hop, and if the next-hop for at least one of the
      aggregated routes is on the Large Cloud, such aggregation
      may lead to multi-hop paths across the Large Cloud, even if
      the address resolution constraint has been solved.

At least two routing protocols (BGP-4 and IDRP) perform route
aggregation today.  Both have a path attribute (AGGREGATOR) that
identifies a route as aggregated, and identify the IP address
of the router that did the aggregation.  An Internet-Draft
(draft-rekhter-idr-over-atm-00.txt) describes how a router
can solicit help from the AGGREGATOR to undo aggregation
of aggregated routes.  IMHO, this approach (i.e., undo aggregation
within the protocol that does the aggregation) is the proper
solution to item 2, above.

Item 1, above, has been discussed since the Spring of 1991, first
in the IPLPDN working group, and more recently in the ROLC group.
Two types of solution have been discussed.  One type of solution
is to overlay separate routing and address resolution procedures
on top of "base" routing and address resolution procedures.
One example of this approach is to send Redirects to routers.
Shortcut routing was another variation, and NHRP is the most
recent incarnation.  To date, every approach of this type has
been shown to create stable routing loops.

The second type of solution to item 1, above, is to enhance
address resolution, allowing "base" routing to use next-hops
that are not on the same IP network as the router/host using
the next-hop.  The enhancement is based on the observation that
the router ADVERTISING a next-hop must be able to resolve the
address of the next-hop.  Two approaches have been
suggested for the router advertising the next-hop to also
help resolve the IP address of the next-hop.  One approach
simply adds the subnetwork address of the next-hop to the
routing protocol.  Paul Francis suggested such an approach
for BGP in  "Border Gateway Protocol NEXT-HOP-SNPA Attribute"
(draft-ietf-bgp-nexthop-00.txt) dated April 15, 1991.
An alternate approach (query/response, with querys sent to
the source of the routing information) was suggested by
Garrett, Hagan, and Wong (Directed ARP, RFC 1433).  Embedding
the subnetwork address in the routing protocol resolves all
advertised next-hop routers.  However, this approach requires
addition to the syntax of every protocol that carries the
information.  The query/response approach resolves advertised
next-hop routers, and also resolves destinations (ie, hosts)
on the same subnetwork.  The query/response approach requires
implementation of the query/response protocol, and changes
to the procedures used by routing protocols (i.e., determination
of next-hops to advertise) but does not require changes to
the syntax of the routing protocol.

I hope this overview is true, complete, and fair.  If so,
perhaps it can help us focus.

John Garrett
AT&T Bell Labs
[e-mail]
908 580-4719