2.3.8 Internetworking Over NBMA (ion)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98


Andy Malis <malis@ascend.com>
George Swallow <swallow@cisco.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

Mailing Lists:

General Discussion:ion@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: In Body: subscribe ion
Archive: http://netlab.ucs.indiana.edu/hypermail/ion

Description of Working Group:

Note: This Working Group is jointly chartered by the Routing Area. The Routing Area Director: Joel Halpern (jhalpern@newbridge.com)


The Internetworking Over NBMA Working Group was formed to combine the work of two previous working groups, IP Over ATM (ipatm) and Routing Over Large Clouds (rolc), because these two groups were often working very closely together on similar, if not identical, problems and solutions. The group will be evolutionary, not revolutionary; it will continue the work in the previous groups on the NBMA Next Hop Resolution Protocol (NHRP), IPv4 over ATM, and IPv6 over ATM.


This WG will focus on the issues involved in internetworking network layer protocols over NBMA (non-broadcast multiple access) subnetwork technologies, such as ATM, Frame Relay, SMDS, and X.25 private and public networks. The group will endeavor to make all its solutions applicable to the entire range of network layer protocols and NBMA subnetworks. We recognize, however, that there will be cases where specific optimizations to IPv4, IPv6, and particular subnetwork technologies will result in better service to the user.

The group will focus on protocols for encapsulation, multicasting, addressing, address resolution and neighbor discovery, interactions with and optimization of internetworking-layer routing protocols when run over NBMA subnetworks, and protocol-specific network management support, as appropriate. The working group will submit these protocols for standardization.

The working group may also produce experimental and informational documents, including "Best Current Practices" guidelines, as required.

For ATM, the WG will continue the ipatm WG's transition from the LIS model described in RFC 1577 to the generalized NHRP model developed by the rolc WG, including a transition plan for existing networks.

The working group will coordinate its activities with the following other working groups:

1) Integrated Services over Specific Lower Layers (issll), for coordinating Quality of Service (QoS) issues and the implementation of IP integrated services capabilities (RSVP, the service models, etc.) over NBMA networks.

2) IP Next Generation (ipng), for IPv6 over ATM coordination.

The working group will also coordinate its work with other relevant standards bodies (e.g., ATM Forum, Frame Relay Forum, ANSI T1S1, ITU-T) and make recommendations to these organizations regarding the requirements for IP internetworking where the current published subnetwork standards, practices, or functionality do not meet the needs of internetworking.

The working group will not develop subnetwork layer standards.

Goals and Milestones:



Begin work on internetworking over Frame Relay SVCs (RFC 1490 extension), using NHRP for address resolution.



Revise drafts on NHRP, 1577 revisions, server synchronization (applicable to both NHRP and ATMARP), multicast server and broadcast for ATM, IPv6 neighbor discovery, ATM UNI 4.0 signaling (RFC 1755 update), Classical IP and NHRP MIBs, NHRP applicability, ATMARP to NHRP transition plan, and router-router NHRP.



IAB and IESG review of WG Status, and plans. This meeting will be scheduled to occur during SIGCOMM '96.



Submit NHRP, RFC 1577 revisions, and server synchronization to the IESG as a Proposed Standard, complete the ATMARP to NHRP transition plan and NHRP applicability statement, revise drafts on multicast server and broadcast for ATM, IPv6 neighbor discovery, classical IP and NHRP MIBs, router-router NHRP, ATM UNI 4.0 signaling (RFC 1755 upd



Submit IPv6 neighbor discovery, classical IP and NHRP MIBs, router-router NHRP, ATM UNI 4.0 signaling (RFC 1755 update), multicast server and broadcast for ATM, and NHRP for Frame Relay SVCs to the IESG.



Publish the IP over ATM Framework document (now RFC 1932), submit the MARS draft to IESG as a Proposed Standard.

Jan 98


Update for RFC1490 (to be submitted as Standard)

Jan 98


Update for RFC1293 (to be submitted as Draft Standard)

Feb 98


Submit IPv6 over NBMA, ATM, and FR drafts to IESG for consideration as a Proposed Standard.

Feb 98


Submit Distributed MARS Service Using SCSP to IESG for consideration as an Informational RFC.

Feb 98


Submit NHRP MIB to IESG for consideration as a Proposed Standard.

Mar 98


Submit ILMI-Based Server Discovery for ATMARP to IESG for consideration as a Proposed Standard.

Mar 98


Submit ILMI-Based Server Discovery for MARS to IESG for consideration as a Proposed Standard.

Mar 98


Submit Intra-area Unicast based upon OSPF ARA to IESG for consideration as a Proposed Standard.

Mar 98


Submit ILMI-Based Server Discovery for NHRP to IESG for consideration as a Proposed Standard.

Mar 98


Submit Ion Security I-D to IESG for consideration as a Proposed Standard.

Nov 98


NHRP client guidelines

Nov 98


Use of Proxy PAR

Nov 98


Router-Router NHRP

Dec 98




Request For Comments:







Issues affecting MARS Cluster Size



Multicast Server Architectures for MARS-based ATM multicasting.



Management Information Base for Frame Relay DTEs Using SMIv2



IP Broadcast over ATM Networks



Using the MARS model in non-ATM NBMA networks.



Classical IP and ARP over ATM



Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)



NHRP Protocol Applicability Statement



Server Cache Synchronization Protocol (SCSP)



A Distributed NHRP Service Using SCSP



ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update



NBMA Next Hop Resolution Protocol (NHRP)



Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM



Classical IP to NHRP Transition

Current Meeting Report

August 24, 1998 Chicago

ION met for a single session on Monday afternoon.

1. Workgroup Status

We opened with Andy Malis reporting on the current status of the working groups
documents. Since the previous meeting 10 new RFCs have been published, and a
number of others are in the final stages of

New RFCs

- RFC 2225, Classical IP and ARP over ATM, M. Laubach, J. Halpern, Proposed

- RFC 2320, Definitions of Managed Objects for Classical IP and ARP Over ATM
Using SMIv2 (IPOA-MIB), M. Greene, J. Luciani, K. White, T. Kuo, Proposed

- RFC 2331, ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update,
M. Maher, Proposed Standard

- RFC 2332, NBMA Next Hop Resolution Protocol (NHRP), J. Luciani, D. Katz,
D. Piscitello, B. Cole, N. Doraswamy, Proposed Standard

- RFC 2333, NHRP Protocol Applicability Statement, D. Cansever, Proposed Standard

- RFC 2334, Server Cache Synchronization Protocol (SCSP), J. Luciani,
G. Armitage, J. Halpern, N. Doraswamy, Proposed Standard (will be reissued)

- RFC 2335, A Distributed NHRP Service Using SCSP, J. Luciani, Proposed Standard

- RFC 2336, Classical IP to NHRP Transition, J. Luciani, Informational

- RFC 2337, Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM,
D. Farinacci, D. Meyer, Y. Rekhter, Experimental

- RFC 2366, Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based
ATM Networks, C. Chung, M. Greene, Proposed Standard

Awaiting RFC publication

- draft-ietf-ion-inarp-update-03.txt, Inverse Address Resolution Protocol, approved
by IESG 8/18/98 (Draft Standard)

Drafts in IESG Review

- draft-ietf-ion-scsp-mars-01.txt, A Distributed MARS Service Using SCSP, 3/25/98,
Proposed Standard

- draft-ietf-ion-nhrp-mobile-nhc-00.txt, NHRP with Mobile NHCs, 5/1/98,
Proposed Standard

- draft-ietf-ion-nhrp-mib-04.txt, Definitions of Managed Objects for the NBMA Next
Hop Resolution Protocol (NHRP), 5/22/98, Proposed Standard

- draft-ietf-ion-fr-update-05.txt, Multiprotocol Interconnect over Frame Relay,
6/27/98, Standard

- draft-ietf-ion-ipv6-01.txt, IPv6 over Non-Broadcast Multiple Access (NBMA)
networks, 8/11/98, Proposed Standard

- draft-ietf-ion-ipv6-atm-02.txt, IPv6 over ATM Networks, 8/11/98, Proposed

- draft-ietf-ion-ipv6-fr-00.txt, Transmission of IPv6 Packets over Frame Relay
Networks, 8/11/98, Proposed Standard

- draft-ietf-ion-ipv6-ind-00.txt, Extensions to IPv6 Neighbor Discovery for Inverse
Discovery, 8/11/98, Proposed Standard

Other Drafts in Progress

- draft-armitage-ion-mars-scsp-03.txt, Redundant MARS architectures and SCSP,
7/7/97, G. Armitage

- draft-armitage-ion-sec-arp-00.txt, Security Issues for the ATMARP Protocol,
10/13/97 , G. Armitage

- draft-armitage-ion-security-01.txt, Security Issues for ION Protocols, 10/13/97,
G. Armitage

- draft-carlson-nhrp-01.txt, Guidelines for Next Hop Client (NHC) Developers,
3/19/98, R. Carlson, L. Winkler

- draft-ietf-ion-discov-atmarp-01.txt, ILMI-Based Server Discovery for ATMARP,
5/11/98, M. Davison

- draft-ietf-ion-discov-mars-01.txt, ILMI-Based Server Discovery for MARS,
5/11/98, M. Davison

- draft-ietf-ion-discov-nhrp-01.txt, ILMI-Based Server Discovery for NHRP,
5/11/98, M. Davison

- draft-ietf-ion-intra-area-unicast-01.txt, Intra-area IP unicast among routers over
legacy ATM, 11/21/97, J. Heinanen

- draft-ietf-ion-proxypar-arch-00.txt, Proxy PAR, 3/13/98, P. Droz, T. Przygienda

- draft-ietf-ion-scsp-atmarp-00.txt, A Distributed ATMARP Service Using SCSP,
4/16/97, B. Fox, J. Luciani

- draft-wang-ion-scsp-mib-00.txt, Definitions of Managed Objects for SCSP Using
SMIv2, 11/24/97, J. Luciani, C. Verrilli, C. Wang

- draft-wang-ion-sec-scsp-00.txt, Security Analysis to Server Cache Synchronization
Protocol, 3/9/98, C. Wang, S. Wu

Grenville Armitage reports that he is no longer in a position to progress the drafts which
he has authored. The wg is soliciting someone to take on this effort.

2. Router to Router NHRP - Joel Halpern


As defined, at least one end of a NHRP query must be stable. That is, the binding
between either the source IP and NBMA addresses or the binding between the
destination IP and NBMA addresses must be stable. However, NHRP is being used
between router. This is subject to loops. The purpose of this draft is to define how to
use NHRP safely/correctly between routers. It is based on work done by Yakov Rekhter

Two general issues are addressed: prefix handling and routing protocol boundaries.

The approach to prefix handling is to send the complete destination IP address and to
set the prefix lenght to one. (Optimally this should be zero, however the current coding
does not allow one to express zero. This deficiency is so minor as to not be considered
worth fixing.)

Each router which processes the query must increase the length to the lenght of the
prefix it uses to this destination. If however, there are prefixes contained within the
range of that prefix, then the lenght must be increase to the longest of these prefixes.
In no case does a router shorted the prefix length.

To avoid loops, and avoid excessive maintenance it is necessary to keep state.
Specifically, keep state at each routing protocol border. Due to the possibility of
running multiple IGPs, it may not be possible to implicitly determine the IGP/IGP
border. Thus a mechanism is added to note the IGP from which this query was routed
at the previous hop.

Routing Stability

Routing sometimes changes. Shortcuts based on transitory state are a waste of effort,
or worse So, we should avoid this. Should we avoid using routing entries in holddown?
Any other ways to tell when things are stable?


Mostly, we just need to know when we enter BGP. However, we can not exit the
NBMA inside an AS. The exit device will not be in a position to monitor topology.
How do we detect this case? Can we just have the BGP Border do monitoring rather
than termination?

Additional Issues

What happens if a "state maintaining router" other than the NBMA ingress or egress
loses its state? Can we detect this? Can we recover?

Are there scaling implications which limit the applicability and need to be spelled out?

Do we need a formal proof of correctness? This latter issue was discussed. It was
decided that good engineering and field experience would suffice.

Joel requested the help of the working group on the open issues. The draft moved
to a wg draft.

3. Setting up shortcuts without NHRP, K. K. Ramakrishnan, Tony Lauck

Tony Lauck presented a scheme for setting up ATM shortcuts using information carried
in OSPF. This scheme as Rob Coltun pointed out is very similar to the ARA proposal.

Jim Luciani questioned the actual latency reduction. This lead the authors to note
another item that they are working on is a fast ATM call setup. Jim also pointed out
that this scheme bypasses some of the policy and security mechanisms which exist
in NHRP.

The presentation was informational; the work group was not asked to take any action.
K.K. plans to work with Rob and Juha to incorporate his ideas into the ARA proposal.

4. Lou Berger NHRP Flow Extension


This draft provides a finer granularity NHRP resolution. Resolution based on
destination addresses may not be adequate for all cases. The case addressed by this
document is when the NBMA next hop is dependent on the contents of a data packet,
i.e. its type of traffic. The extension presented in this document provides the ability to
resolve NBMA next hops based on destination and additional data packet information.

Possible uses of this extention are selecting among multiple parallel links, filtering,
and use with other extensions, i.e. the in progress CoS/QoS Extension. Although the
current draft concerns itself largely with policy, the real objective is CoS/QoS although
that section is weak due to time constraints.

Basic Operation

Requesting NHC includes Flow Extension in NHRP request message The extention
describes the flow and initializes the Policy Area. Intermediate and serving NHSs
update the extention based on local policy they are only allowed to describe in MORE
restrictive fashion.

The serving NHS includes extension in corresponding Resolution Reply message.
The are no changes to transit NHS processing.

The source NHC acts based on information in reply. The source NHC may:

1. Use the indicated next hop(s) following information in Reply (normal case),
forwarding matching data traffic and NOT forwarding non matching traffic.

2. Use the Routed path (in the case where the shortcut resources are unavailable or
other error

3. Drop matching traffic when indicated by extension.

The source NHC MUST NOT forward non-matching data traffic based on reply

Lou would like feedback from working group. He will be issuing an updated draft
prior to Orlando.

Related to this draft is a CoS/QoS Extension. This is in progress - and a draft will
be issued soon. NHRP Requests will include capabilities. Replies will provide the
desired CoS/QoS. Support for multiple semantics is planned including IntServ, ATM,
and rewriting the ToS field in support of DifServ.

4. IPv6 over NBMA networks - Markus Jork

Markus reported that ION WG last call had ended for


Issues around IPv6 over ATM in PVC mode raised by the WIDE project have been
resolved one week after the last IETF. New ND option number in draft-ietf-ion-ipv6
needs to be registered with the IANA.

5. RFC 1483 update - Dan Grossman

RFC 1483 has been a proposed standard since July 1993.

Since then there has been much progress, implementation experience since then. The
current effort is to update the document and to advance it to a Draft Standard.

In that vein, Dan has endeavored to lean up anachronism and improve English. The
references have been updated. AAL5 options which did not exist at the time of the
original draft have been addressed.

Some notes on how things were expected to evolve were dropped. Dan added a lot of
Must & Must nots and requested that wg participants please check.

The section on LLC vs VC mux selection was removed as this is mostly historical.

Clarified applicability of the NLPID encapsulation - this is now required for certain
Frame Relay interworking scenarios. A reference to RFC 2364 was added for the
PPP case.

AAL5 reference was updated to point to Recommendation I.363.5. The text on AAL5
now specifically excludes assured mode, streaming mode, and the corrupted delivery
option. The reassembly timer option is specifically allowed.

A reference to CCITT work-in-progress was replace by a reference to RFC 1755.

The draft will be updated and re-issued as a workgroup draft. Juha Heinanen will be
added as an author, as this remains largely his original work.


Introduction and Agenda
Agenda Update
NHRP Flow Extension
Router to Router NHRP
Multiprotocol Over ATM Update

Attendees List

go to list