2.3.7 Internetworking Over NBMA (ion)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 06-Jan-99


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

Internet Area Director(s):

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

Internet Area Advisor:

Jeffrey Burgan <burgan@corp.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



Inverse Address Resolution Protocol



Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks



Multiprotocol Interconnect over Frame Relay



A Distributed MARS Service Using SCSP



IPv6 over Non-Broadcast Multiple Access (NBMA) networks



IPv6 over ATM Networks



NHRP with Mobile NHCs

Current Meeting Report

Internetworking Over NBMA (ION) Working Group Minutes
IETF-44, Minneapolis (March 15-19, 1999)

Date: Monday, March 15, 1300-1500

Chair: Andrew Malis, Ascend Communications, malis@ascend.com

Minutes recorded by Bernhard Petri, Siemens, bernhard.petri@icn.siemens.de

Mailing List Information:
Discussion: ion@sunroof.eng.sun.com
E-Mail-Archive: http://netlab.ucs.indiana.edu/hypermail/ion
(un)subscribe requests to: majordomo@sunroof.eng.sun.com


1. Administrivia, current documents status

2. Router-to-router NHRP update, Joel Halpern
- draft-ietf-ion-r2r-nhrp-01.txt

3. RFC 1483 update, Dan Grossman
- draft-ietf-ion-multiprotocol-atm-02.txt

4. Open discussion

Agenda Item 1: Administrivia, current document status

Andy Malis welcomed the participants. He indicated that this meeting will be the last face-to-face meeting of the ION working group for several IETFs. The IESG has requested the ION group to take a breather, and focus on getting more implementation experience on the completed work.

This does not mean that the ION working group will be dissolved. The work will be continued to complete the outstanding documents and share implementation experience, and the mailing list will stay active.

Andy presented the agenda. There were no request for changes or additional agenda items.

Following the review of the agenda, Andy presented on overview of the status of work in the ION group:

Since the last meeting in Orlando, 3 new RFCs have been published:
- RFC 2491 - IPv6 over Non-Broadcast Multiple Access (NBMA) networks, G. Armitage, P. Schulter, M. Jork, G. Harter, Proposed Standard
- RFC 2492 - IPv6 over ATM Networks, G. Armitage, P. Schulter, M. Jork, Proposed Standard
- RFC 2520 - NHRP with Mobile NHCs, J. Luciani, H. Suzuki, N. Doraswamy, D. Horton, 2/99, Experimental

The ION group has published 23 RFCs to date.

The following document is awaiting RFC publication:
- draft-carlson-nhrp-03.txt Guidelines for Next Hop Client (NHC) developers

The following drafts currently are in IESG Review:
- draft-ietf-ion-ipv6-fr-02.txt
- draft-ietf-ion-ipv6-ind-00.txt
- draft-ietf-ion-discov-atmarp-05.txt
- draft-ietf-ion-discov-mars-05.txt
- draft-ietf-ion-discov-nhrp-05.txt
- draft-ietf-ion-nhrp-mib-05.txt
- draft-ietf-ion-scsp-mib-00.txt
- draft-ietf-ion-proxypar-arch-01.txt

Currently, there are no drafts are in WG Last Call.

The following drafts are in progress
- This was further discussed later in the meeting.
- The status of this draft was briefly discussed. The author, Lou Berger, indicated that there seems to be not much further interest in the draft, and suggested to stop work, pending objection from the list.
- This is under active development.
- This was further discussed later in the meeting.
- The status of this draft was briefly discussed. The authors plan to provide an update.
- Jim Luciani volunteered to contact the authors of this draft to see which further updates are planned.
- This is under active development.

RFC 1356 update (Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode)

RFC 1356 is currently at the draft standard level, and is due to be progressed to full standard. Andy repeated his request for reports on implementations and interoperability. Information should be sent to malis@ascend.com indicating that you have an implementation, as well as other implementations with which it is known to interoperate.

Agenda Item 2: Router-to-router NHRP update, draft-ietf-ion-r2r-nhrp-01.txt

Draft-ietf-ion-r2r-nhrp-01.txt was recently updated. Joel Halpern reported about this update of the router to-router NHRP draft.

Two rules how targets relate to routing table entries are applied in the draft. Basically, the target must fall within a single forwarding entry.

The editor's notes of the previous draft have been resolved:
- Stability is inferred from routing
- It is up to the BGP router to know whether it is exiting NBMA; a hint is given to implementors to be careful in this.

A list of open issues at the end of the document was kept for information. It is expected that implementation experience will provide more information about those.

Joel will ask Andy to issue the last call on this document next week.

There were no questions on the draft.

Agenda Item 3: RFC 1483 update, draft-ietf-ion-multiprotocol-atm-02.txt

Dan Grossman reported about the status of the RFC 1483 update - draft-ietf-ion-multiprotocol-atm-02.txt.

He reported that no comments have been made onto the draft on the mailing list, so it is planned to go for WG last call after this meeting.

Dan also summarized the basic objectives of the updating activity for RFC 1483:
- clean out anachronisms in the draft
- reference subsequent work
- editorial changes for clarity and style
- address (exclude/include/allow) AAL5 options added since RFC 1483
- minor technical clarifications
- add VPN identification (decision at last Orlando meeting)

Major changes to the draft that have been made since the Orlando meeting were the modification of the security considerations to reflect RFC 2427, and the addition of the material on VPN identification.

Bernhard Petri reported in more detail about the new section 8 of the draft which is related to VPN identification. This section is based on the concept outlined in draft-ietf-ion-vpn-id-00.txt, which had been presented at the Orlando meeting. Following the agreement at the Orlando meeting to specify LLC/SNAP-based VPN identification within the update of RFC 1483, the new section 8 had been drafted correspondingly.

Section 8.1 specifies the format of the LLC/SNAP based VPN encapsulation header (0x00-A0-3E + PID + VPN-ID encoding) where the SNAP protocol ID (PID) will be allocated by IANA. Section 8.3 shows the various alternatives for identification of the VPN in case of VC muxing (administrative assignment per ATM connection, ATM control signalling, or LLC/SNAP VPN encapsulation header, as specified in section 8.1).

The mechanism outlined in section 8 of the RFC 1483 update may be used by the "applications" of RFC 1483 (see Appendix D). Draft-ietf-ion-nhrp-vpn-00.txt shows how section 8 of RFC 1483 may be used by NHRP for the support of VPNs.

Andy Malis volunteered to care for the allocation of the required SNAP protocol ID from IANA.

Agenda Item 4: Open Discussion

No additional items were brought up. Andy again highlighted that the ION discussions will continue on the mailing list.


Multiprotocol over ATM Update
VPN Identification in Multiprotocol over AAL5