CURRENT MEETING REPORT

Reported by Howard Berkowitz, PSC International, George Swallow, Cisco Systems, and Andrew Malis, Ascom Nexion, Inc.

Minutes of the Routing Over Large Clouds Working Group (rolc)

Agenda

FIRST SESSION

ATM Forum MPOA Report

George Swallow, the ATM Forum Multi-Protocol Over ATM (MPOA) Sub-Working Group Chair, reported that The Forum met twice since Dallas and has concentrated on integrating LAN Emulation (LANE) into the MPOA architecture. The IETF's liaison on server synchronization was well-received, and a liaison was sent back to the IETF.

LANE now supports multiple servers, and has a slightly different problem space than NHRP or ATMARP. MPOA also is building on NHRP and MARS.

NHRP 08beta Specification draft-ietf-rolc-nhrp-08-beta

Jim Luciani spoke on the NHRP specification. Version 08 beta collected several changes, but is not quite ready to be issued as an Internet-Draft. There are some open issues that Jim wanted to address. The major changes from version 07 were wording changes, a Don't Reply bit was added to the NHRP Purge Request, correcting the LAG discussion, a NAK code was added to the Resolution Reply, and two error codes were re-instituted.

Open issues & discussion:

Should there be an error indication when the hop count is exceeded? It was agreed that there should be, subject to usual constraints on not sending an error in response to an error message. It is reasonable to send back the error indication because a loop in the direction of the destination does not imply a loop exists back to the source.

Should NHRP registration replies be routed by NBMA or protocol address? In other words, in the case where a client is registering, but is not talking directly to the registration server, should a VC be opened from the server back to the requester? The working group agreed that yes, the response will go at the ATM layer to the NBMA address of the requester.

Should a router client be allowed to allowed to register an arbitrary station? The current specification implies a client can register itself or a subnet of which it is a member. The working group agreed that for a router to register a subnet behind it without it also having an address on that subnet, it must be an NHS and serve that subnet. The text needs to be clarified on this point.

The next step is to produce a real version 08 to become an Internet-Draft as soon as possible. Once there is a server synchronization draft to reference in the NHRP spec, it will be possible to have a working group last call in order to send the specification to the IESG. At this point, no other changes (other than bug fixes and clarifications) are expected in the draft.

Server Synchronization

Both the IPATM and ROLC working groups have been working on multiple server synchronization. Both working groups realize that if a technology requires a server, one server alone is not enough for robustness, load leveling, etc. ATMARP will eventually transition to NHRP, so the two groups are cooperating to ensure the same synchronization mechanism is used for NHRP, ATMARP, and MARS servers, and potentially other address resolution servers as well. The synchronization mechanism must not be specific to NHRP.

The Classic2 ipatm specification includes a service synchronization protocol, which is similar to SCSP but has different implementation characteristics. It has been agreed that the server synchronization part of Classic2 will become a separate document. This allows reference by ipatm and rolc as needed to the new mechanism. The SCSP and Classic2 authors are collaborating to produce a single specification.

Presentation on LANE Server Synchronization (Keith McCloghrie)

Keith McCloghrie presented this to inform the ROLC Working Group on LAN Emulation's server synchronization protocol.

LANE 1.0 specifies the LAN Emulation Client (LEC) to Server (LES) interface. LANE 2.0 involves server-to-server protocols as well.

Because of LAN Emulation's topology requirements -- full mesh is useful in small systems, but tree of point-to-point links scales better -- the LANE servers use a combination called a "peer-tree." In a peer tree, each node either is a complex node (of multiple LES) or is a single LES. A pure tree has no complex nodes and no redundant links; a pure mesh has a single complex node. Spanning tree is used to produce a loop-free tree. Each node in the tree has all information for itself and the nodes below it, therefore, the root and only the root has full information.

New registrations are sent toward the tree's root, with intermediate nodes rejecting if they find a conflict. Only the root responds with success. Tradeoffs are possible; an optimistic LES assumes registration will succeed, but will revoke registration of the LEC if an error is detected.

Resolution requests are sent toward the root. If the answer is "not registered", then the root floods. Pessimistic LES enhancement assumes failure and floods at each node.

Issues remain -- a caching mechanism is needed, with appropriate purging mechanisms that do not cause momentary losses of connectivity. Another issue involves healing after partition repair. Conflicts then need to be resolved.

The LANE scaling goal is 20+ servers, 2000+ clients. The LANE group thinks it can scale beyond that.

Server Cache Synchronization Protocol (SCSP) draft-ietf-rolc-sscp-01

Jim Luciani presented his Server Cache Synchronization Protocol (SCSP) draft. It is largely based on OSPF, principally to avoid reinventing the wheel and use well-known reasonable-overhead mechanisms.

A Server Group (SG) is a set of synchronized servers bound to a SG through some commonality (e.g., membership in a LIS or LAG).

All statements about SCSP are made from the perspective of the protocol stack in the Local Server (LS). Directly Connected Servers (DCSs) are one hop away (e.g., through a VC). A Remote Server (RS) is neither a LS or DCS but is still part of the SG.

Three basic messages are defined, a Hello, a Client State Update and a Cache Alignment.

Each server has separate state machines for Hello and Cache Alignment. The exact mechanism for the necessary preconfiguration of the LS (i.e., who are the DCSs) is implementation specific.

All servers within SG need to be synchronized, but these servers emphatically do not keep synchronized with other SGs. Registration within a SG is replicated to all other servers in the SG. Early simulation results suggests performance requirement is modest, considering there is no need for such resource intensive things as a Dijkstra calculation.

Open Issues:

SECOND SESSION

NHRP MIB

Maria Greene and Jim Luciani received from the MIB from Avri Doria, the previous editor. It is based in part on the Classical IP MIB, which will aid the modeling of co-resident ATMARP and NHRP environments. Input is welcome. The current plan is to submit it to next IETF meeting in June.

NHRP Protocol Applicability Statement

Derya Cansever submitted the current draft several weeks ago and received some comments. It will be updated as appropriate. He asked for additional questions or comments - there were none.

NHRP for Destinations off the NBMA Network

Yakov Rekhter issued a new draft with some text to deal with not replying when routing is in a transient state.

Support for Sparse Mode PIM over ATM

Yakov presented a mechanism to eliminate extra layer three hops across an ATM network for multicast traffic. This technique is applicable to both Sparse Mode Protocol Independent Multicasting (PIM) and Core Based Trees (CBT).

The primary focus is on supporting sparsely populated multicast groups, especially for flows that have sufficiently high volume or QoS requirements.

Yakov also discussed the relationship between multicast shortcuts and RSVP, and concluded that they are orthogonal issues, and a shortcut mechanism should not be a part of RSVP.

Multicast Inscalability over Large Clouds

Masataka Ohta discussed the inscalability of multicast over large clouds.

His assumption is that a "large cloud" is too large for centralized servers to handle all hosts. He discussed how message rates and number of peer relationships are both issues.

His proposal is to make the link layer entities able to recognize IP protocols, so that servers are not necessary.

OSPF Cut-Through

Rob Coltun presented work in progress, with an Internet-Draft forthcoming.

He discussed a mechanism for using information in OSPF to eliminate some hops for NHRP requests. It is not intended to replace NHRP, but is rather an optimization.

His goals are to decrease set-up (address resolution) time, facilitate router-to-router NHRP, and increase IP routing's visibility of the NBMA overlay

Rob's proposal is to add the ability for routers (Next Hop Servers) to advertise, in OSPF, their NBMA subnet layer address. This advertisement associates, with the NBMA address, the LIS, the area border, and the AS boundary router. This information is used to establish direct VCs to NHSes to short cut the NHRP query, rather than requiring the query to follow the routed path.

Following Rob's talk, the meeting adjourned.