2.3.8 Internetworking Over NBMA (ion)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

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)

Motivation

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.

Description

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:

Done

  

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

Done

  

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.

Done

  

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

Done

  

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

Done

  

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.

Done

  

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

  

CLOSE DOWN WORKING GROUP

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2121

 

Issues affecting MARS Cluster Size

RFC2149

 

Multicast Server Architectures for MARS-based ATM multicasting.

RFC2115

DS

Management Information Base for Frame Relay DTEs Using SMIv2

RFC2226

PS

IP Broadcast over ATM Networks

RFC2269

 

Using the MARS model in non-ATM NBMA networks.

RFC2225

PS

Classical IP and ARP over ATM

RFC2320

PS

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

RFC2333

PS

NHRP Protocol Applicability Statement

RFC2334

PS

Server Cache Synchronization Protocol (SCSP)

RFC2335

PS

A Distributed NHRP Service Using SCSP

RFC2331

PS

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

RFC2332

PS

NBMA Next Hop Resolution Protocol (NHRP)

RFC2337

E

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

RFC2336

 

Classical IP to NHRP Transition

RFC2390

DS

Inverse Address Resolution Protocol

RFC2417

PS

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

RFC2427

S

Multiprotocol Interconnect over Frame Relay

RFC2443

E

A Distributed MARS Service Using SCSP

Current Meeting Report

Internetworking Over NBMA WG (ion) Working Group Minutes
Thursday, December 10, 0900-1130
Chairs: Andrew Malis, Ascend Communications <malis@ascend.com>

Minutes recorded by Ken Rehbehn <krehbehn@visualnetworks.com>

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

Administrivia

Andy announced that George Swallow was unable to attend today's meeting due to a family emergency. In addition, George will be leaving as co-chair of the ION group following this meeting to concentrate on his MPLS duties.

Andy will take over all the duties of the Chair. Andy observed that the work of the group has been slowing down, and the agenda reflects this reduction in work items.

Current Documents Status

The group has produced 18 RFCs. No drafts are currently in Working Group Last Call. Andy presented a review of the document status.

Four documents recently published as RFCs

RFC 2390, Inverse Address Resolution Protocol, T. Bradley, C. Brown, A.Malis (Draft Standard)

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

RFC 2427, Multiprotocol Interconnect over Frame Relay, C. Brown, A. Malis (STD 55)

RFC 2443, A Distributed MARS Service Using SCSP, J. Luciani, A. Gallo (Proposed Standard)

Awaiting RFC Publication

Two internet drafts were approved as proposed standards by the IESG on November 25, 1998:

In IESG Review

A set of drafts are currently in review by the IESG following the working group last call:

Other Drafts In Progress

=> Joel presented this at the last meeting and asked for comments. Very little feedback has been received. Andy urges the working members to send comments to Joel.

=> Discussed during the working group meeting. See below.

=> The working group is waiting for additional comments on this draft before a decision is made on the draft's status. Working group members with interest in this area were asked to make comments on the mail list.

=> This draft re-publishes the ATM Forum's Proxy PNNI-Augmented Routing (PAR) specification. The current forum document is in a ballot stage with approval expected soon. The authors are waiting for this process to complete before sending out the updated internet draft. The authors have already incorporated the changes and expect to publish very soon after ATM Forum approval. When published, the draft will be placed in working group last call as an informational RFC.

=> This draft was updated 3 weeks ago. The authors request comments from the working group.

=> The authors request comments from the working group.

=> This draft requires additional analysis. Working group members are asked to look at the draft and provide comments to the mail list.

RFC 1356 Update

RFC 1356, the IP over X.25 specification, is currently a draft standard and is overdue to be advanced to full standard. To meet a key requirement for promotion, he requests implementation reports be posted on the mail list. An implementation report should include:

1) A statement that RFC 1356 was implemented,

2) Identities of the other implementations for which interoperability has been demonstrated, and

3) What portions of the RFC were not implemented.

SCSP MIB (draft-ietf-ion-scsp-mib-00.txt)

Cliff Wang presented the Server Cache Synchronization Protocol (SCSP) MIB. He invited comments from the working group members. This document defines the SCSP protocol independent MIB definition, which contains three tables: scspServerGroupTable, scspLSTable, and scspDCSTable.

The first protocol dependent MIB is the SCSP ATMARP dependent MIB. Comments from the mail list resulted in the Hello FSM being moved from the SCSP protocol independent MIB to the ATMARP dependent MIB.

Two additional protocol dependent MIBs are required, MARS and NHRP. Cliff is not able to participate in this work and asks for volunteers to take over.

RFC 1483 Update (draft-ietf-ion-multiprotocol-atm-00.txt)

Dan Grossman presented the proposed update to RFC1483. Currently, RFC1483 is at proposed draft status. Dan produced the first draft to update the RFC before the last meeting. Comments have been received on the mail list.

The goal is to proceed to working group last call shortly after this meeting.

Dan described the initial objectives for the RFC update:

Since August, work has been done to clean up authorship and acknowledgement text. Dan has added RFC 2119 language to clearly indicate conformance requirements. In addition, the AAL5 streaming mode is no longer excluded.

Finally, Dan has improved the Security Considerations section of the document. Text has been added to state that encapsulation does not effect security as much as protocols at the higher layers. A reference was added for the ATM Forum's security work. Andy suggested that Dan look at RFC2427 (Multiprotocol over Frame Relay) for another example of an encapsulation-related Security Considerations section.

Dan reported that after the draft was initially published, Juha Heinänen, the RFC 1483 editor, asked for clarification of padding for bridged PDUs. These did not make it into the current draft but will be added in the next version. Another comment received from a member of the working group reported misstatements about the use of RFC1483 by ATM Forum LAN Emulation (LANE). Dan has corrected the text for the next version.

At Jim Luciani's request (see the VPN ID discussion below), the WG will wait until February before issuing last call so that late-breaking results from the February ATM Forum meeting can be included.

Dan plans to issue a revised draft around the first of the year, and it will be updated one additional time in February to incorporate the ATM Forum work and comments from the January version. It will be sent out for working group last call at that time. The working group agreed.

SCSP for ATMARP (draft-ietf-ion-scsp-atmarp-01.txt)

Joel Halpern presented the status of the draft. The only reason the draft is not done is because there was a question about what to do with conflicting information at multiple servers. A solution was prepared and documented in the latest draft. The solution provides for both servers to clear information for the clients and send a management trap.

Joel plans to get this done and out.

VPN IDs for NHRP (draft-fox-vpn-id-00.txt)

Bernhard Petri presented the Virtual Private Network (VPN) identifier draft. The draft was targeted to the VPN BOF earlier this week as well as ION. Many potential VPN mechanisms exist. The draft states a requirement for a globally unique VPN identifier. The identifier would be independent of the specific technical solution for VPN and would be used to solve problems in VPN address scope, configuration, performance monitoring, and fault management.

A number of possible identifier formats are presented in the draft. The proposed format consists of a 3-octet OUI followed by a 4-octet VPN index.

A NHRP VPN internet draft is planned for the next IETF meeting. The draft will use the proposed VPN ID. One potential use is to encode the VPN ID in NHRP messages. A second application is the server-server solution for MPOA VPNs.

Bernhard requested comments from the working group members.

Dan Grossman asked if this encapsulation impact of this work should be described in the RFC 1483 update. Jim Luciani advised that while the NHRP VPN draft will use a TLV to encode the VPN ID, the ATM Forum MPOA group wants to also investigate an LLC/SNAP (0x00-A0-3E + PID + VPN-ID) encoding. This will impact the RFC 1483 update. Work is being brought into the February ATM Forum meeting, and the results will then be sent to Dan for inclusion in the RFC 1483 update.

Andy asked Bernhard if he had any objections to this becoming an ION working group document. There was no objection and the draft will be re-published as a working group document.

Implementation report, Mikhail Smirnov

Mikhail presented the results of an ATM multicast implementation that uses a layer 2 protocol similar to MARs. He described the work as a lightweight implementation of MARs that included two extra features: shortcuts and Quality of Service. The protocol is described in draft-smirnov-ion-earth-02.txt. RSVP was used to obtain the quality of service indications, but any other QoS signaling protocol can also be made to work.

In the future, they would like to add AAA capabilities to their Multicast Integration Server.

The purpose of the presentation was to make the community aware of the work and experience. An experimental RFC may result.

Open discussion

Andy reminded the group that the ATM Forum is a major customer for the work performed here.

Andy reviewed the plans for the working group. He advised that the current plan had been to complete all current work at this meeting. The group would then transition to a quiescent state to allow development of implementations. The Area Directors and the working group chairs feel that this period is required to get real experience with the protocols developed up to this time.

At least one additional meeting is required to complete the on-going internet drafts. The current plan is to meet in March, which will be the last formal meeting of the working group for a while.

There being no further discussion, the meeting was adjourned.

Slides

Agenda
SCSP Protocol Independent MIB
Multiprotocol Over ATM Update
Virtual Private Network
Supporting IP Multicast with QoS in ATM Networks