Minutes of the Routing Over Large Clouds Working Group (ROLC)
Working Group Goals and Technical Problem Statement
Analyze and propose enhancements to IP [and IPng] routing over large
``shared media'' link layer (with respect to IP) networks (ATM, Frame
Relay, X.25, SMDS, etc.).
Avoid ``extra hops'' when routing IP. Extra hops are defined as points
where an IP datagram leaves and re-enters the same link-layer-cloud as a
result of an IP routing decision, such as when routing between different
IP subnets overlaid on the same cloud.
Configurations to be considered include (see the illustrations in the
overheads following the minutes):
o Hops through a router from a terminal (synonymous with end-station
or host) in one LIS (IP subnet) to another terminal in a different
LIS, where all three are connected to the cloud, and the router is
a member of both subnets.
o Hops from a terminal on the cloud to the ``optimal'' next hop, for
off-network destinations. The example used was a
terminal-router-router-Ethernet path, where the first router joins
two LISs, and the second router connects the second LIS to an
external Ethernet. We would like to eliminate the hop through the
first router and go directly to the optimal exit router from the
cloud.
o Transit traffic through the cloud between routers on the cloud
``edge.''
The work is being done under the assumption that IP routing is not
meshed with the cloud routing. This means that IP is layered above the
link layer routing to keep as much of the IP layer assumptions as
possible.
One would like to make as few hops in and out of the cloud as possible
for a number of reasons, such as if the link-layer service is metered,
or to conserve link-layer resources.
At this point the discussion turned to the idea of merging the IP
routing and the link layer routing. Because this is considered an
explicit non-goal (in Seattle and before), the chair suggested that
perhaps this discussion would best be moved to a BOF at the next IETF
meeting.
There were also several questions about whether we would entertain
different solutions for connection-less and connection-oriented link
layers. Because we have a specific charter goal to be independent of
the link layer, the group should attempt to find a single solution.
Review of Requirements and Goals
Lists of the requirements and goals, compiled at the last meeting in
Seattle, are included in the overheads following the minutes. These are
the criteria against which proposed solutions will be compared.
One new goal was added in this meeting:
o As much auto-configuration as possible.
In order for us to be successful in this work, the rule that IP must use
a router to send datagrams to subnets other than the one to which it is
attached must be relaxed. Joel Halpern agrees that this ``rule'' must
be modified and feels that he is in a position to help move this along
(given a sufficiently strong technical proposal to back it up).
Also implicit in this work is the assumption that link layer processing
will either keep the connection up or kill the connection entirely. We
will not have to worry about a connection that is only partially
complete.
Caution must be taken to ensure that if there is a firewall router in
the long (extra hop) path, the final path must traverse this router so
as not to avert the filtering. It is the firewall router's job to
assure that it is traversed.
Review of NBMA Next Hop Resolution Protocol (NHRP)
The review of the NHRP specification, ``NBMA Next Hop Resolution
Protocol (NHRP)'' (draft-ietf-rolc-nhrp-01.txt), was led by Dave Katz,
the editor (and current primary author) of the document.
This work is the follow-on to the NARP document, ``NBMA Address
Resolution Protocol (NARP)'' (draft-ietf-rolc-nbma-arp-00.txt). Work on
NARP continues to progress in order to get at least a partial ROLC
solution out now.
Both NARP and NHRP use a server that provides the best possible
link-layer address to use to reach a particular IP terminal address.
NARP only covers the case when both terminals are connected to the same
link-layer cloud, while NHRP is designed to be the more general
solution.
While the documents do not require it, NARP and NHRP servers are
expected to be implemented in routers. Only some routers in a cloud are
required to be servers, and, in the case of NHRP, not all of the routers
in the cloud require NHRP to be implemented.
When two terminals, X and Y, learn of each other through messages passed
from their NHRP servers, the finished path is not advertised to others
so that others do not just use this path blindly. Each terminal must
find its own way through the cloud. The document does not point this
out specifically, but it will in the next revision.
Two basic assumptions prevail at this point:
1. If a terminal answers, it is assumed to be available to make a
connection.
2. All information about destinations have associated timers.
If two terminals that are trying to communicate are directly connected
to the network, should the request go all the way to the terminal? No.
The serving routers will already know about terminals because of prior
registration or configuration and there is no need to pass the request
further than the serving router.
Presently there is no language in the document talking about
authentication. This will be added in subsequent drafts.
NHRP is not intended to build on top of classical ARP described in
RFC 1577. It is a separate document.
Terminals not on the cloud do not have to register with a server, since
the router/server on the edge implicitly serves all on the subnets
behind it.
The network ID option is to detect if you are going from one cloud to
another.
The route record option addresses diagnosability. It helps keep track
of how things were propagated. In the case of link layer filtering,
NHRP sends the request to the end, and then may not be able to complete
the call. Adding an identity to the record list indicates that the
adding entity will ``sink'' the call. This provides the ability to
short-cut part of the way.
Multipath problems: If a duplicate packet is sent in different
directions to establish different paths to the same end, there may be
problems with explosion of data in replication and looping. Turning on
the report path option may help avoid this situation.
There was a request for the addition of a request identifier to avoid
the problem of opening simplex connections.
The draft specifies a protocol identifier for IP as CC. There are those
that wonder if this should be an ethertype value instead (0x0800). Dave
believes that getting NLPIDs for IPX, etc. is not that difficult and so
prefers this method.
How do you describe the various link layer addresses? This is a current
hole that must be filled. We could use the types defined in the ARP
fields now. Assume that we should use address families, not media
types.
If, when forming an NHRP reply, there are multiple valid answers, there
is no way to indicate the relative value of the various answers. There
should be a very specific way to indicate relative precedence rather
than relying on the order in which the answers are included in the
response packet.
If there is an NHRP register, then there should probably be an
unregister, but then this might add some authentication problems.
The question arose that there might be a need for a source route option.
Dave wishes to delay the addition of a source route option until is is
demonstrated that this option is truly useful.
Future Direction and Work Items
o NARP:
There are currently two NARP implementations in progress, by
Telecom Finland and NRL. The working group agreed that the NARP
specification should be published as an Experimental RFC while work
continues on NHRP.
o NHRP:
The group is encouraged to provide additional comments and send
them to the authors and/or the working group. Another draft will
be posted which will include some of the items discussed above, and
hopefully some additional authentication text. The next draft is
expected to be posted well before the meeting, so that it can be
discussed over the net. The working group's goal is to complete
work on the draft at the San Jose meeting.
Volunteers are solicited to help work on the open issues, especially
authentication.
