NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Andy Malis <malis@casc.com>
George Swallow <swallow@cisco.com>
Frank Kastenholz <kasten@ftp.com>
Jeffrey Burgan <jburgan@baynetworks.com>
Jeff Burgan <jburgan@baynetworks.com>
General Discussion:ion@nexen.com
To Subscribe: ion-request@nexen.com
In Body: In Body: subscribe
Archive: ftp://ftp.nexen.com/pub/ion
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:
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. 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:
· Management Information Base for Frame Relay DTEs
· NBMA Next Hop Resolution Protocol (NHRP)
· NHRP Protocol Applicability Statement
· IP Broadcast over ATM Networks
· Classical IP and ARP over ATM
· Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2
· Multicast Server Architectures for MARS-based ATM multicasting.
· Server Cache Synchronization Protocol (SCSP)
· ATM Signaling Support for IP over ATM - UNI 4.0 Update
· Transient Neighbors for IPv6 over ATM
· Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
· Multiprotocol Interconnect over Frame Relay
· Classical IP to NHRP Transition
· Inverse Address Resolution Protocol
· Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
· NHRP for Destinations off the NBMA Subnetwork
· A Distributed ATMARP Service Using SCSP
· A Distributed NHRP Service Using SCSP
Request For Comments:
|
RFC |
Status |
Title |
|
RFC2121 |
I |
Issues affecting MARS Cluster Size |
Minutes of the Internetworking Over NBMA (ION) Working Group
Reported by: Karen O'Donoghue and edited by George Swallow
Andy Malis and George Swallow chaired the ION Working Group meeting, which met during two sessions on Tuesday April 8, at 0900-1130 and 1300-1500.
Andy presented the agenda and the current status of Working Group documents not being presented during the working group session.
The following document is awaiting RFC publication:
draft-armitage-ion-cluster-size (rumored to be RFC 2121)
The following drafts are in various stages of IESG review:
draft-ietf-iplpdn-frmib-dte (at the RFC editor)
draft-ietf-ion-bcast (completed IESG last call)
draft-ietf-ion-fr-update (completed IESG last call)
draft-ietf-rolc-nhrp (on hold by IESG awaiting SCSP)
draft-ietf-ion-marsmcs (Forwarded to IESG on 3/28/97)
Additional documents in progress:
draft-ietf-ion-mib (in progress)
draft-ietf-nhrp-mib (in progress)
draft-ietf-ion-mars-mib (in progress)
draft-ietf-ion-sig-uni4.0 (next revision, 03, will be released after Memphis)
draft-ietf-ion-inarp-update (will start WG last call after Memphis)
draft-ietf-r2r-nhrp (work should continue in earnest after Memphis meeting)
draft-carlson-nhrp-client (in progress)
The following internet drafts were presented and discussed:
1. RFC 1577 Update, Mark Laubach and Joel Halpern, draft-ietf-ion-classic2
Joel Halpern presented the current status of the draft. The latest revision will be published shortly after the Memphis meeting. All comments raised on the mailing list were incorporated with the exception of the comment regarding E.164 NSAP addresses. It was not clear how to satisfy the comment within the scope of the current effort. It was reiterated that the intention of this document is to begin the transition to NHRP. A Working Group last call will be issued once the draft appears.
2. Next Hop Resolution Protocol (NHRP), Jim Luciani, draft-ietf-rolc-nhrp
Jim Luciani made an informative presentation on NHRP, draft-ietf-rolc-nhrp-11, which has already gone through Working Group last call and has been forwarded to the IESG. The substantial changes to NHRP in revision 11 include the following:
· Addition of an NHRP Resolution Reply NAK
· Renaming of the B bit to the D bit.
The document is very stable at this point, but is being held up awaiting the completion of SCSP.
3. Server Cache Synchronization Protocol (SCSP), Jim Luciani, draft-ietf-ion-scsp
The document has been divided as decided at the last meeting in San Jose. The essential mechanisms have been pulled into a protocol independent draft, "draft-ietf-ion-scsp". The NHRP and ATMARP protocol specific portions have been moved to their own respective documents. The protocol independent piece will be going to Working Group last call. Another draft will be produced for each of the others.
The significant changes to draft-ietf-ion-scsp include:
· Removal of NHRP and ATMARP protocol specific portions to respective documents
· Hello, cache alignment, and cache state update on a per SG basis only
· Clearer demarcation between protocol dependent and protocol independent portions
· Use of a cache key to identify an atomic element of synchronization
· CSAS record to encapsulate all information necessary to identify the newness of an advertisement
· CSA record reformatted to include two pieces (newness information and protocol specific portions)
· Generic fragmentation engine removed
· Additional information on SCSP point-to-multipoint and broadcast mediums
· Protocol ID (PID) field reintroduced
· Family ID mechanism introduced (allowing for grouping of hello protocol instances)
· CSU replies now contain only CSAS records removed P bit from CSA record
· Reworded cache alignment text
SCSP-NHRP (draft-ietf-ion-scsp-nhrp): Significant aspects of this document include:
· Procedures for when an NHC wishes to leave a SG
· Values for SCSP mandatory common part
· Values for SCSP CSAS records
It was clarified that the ID assumes IPv4 addresses. The question about applicability to IPv6 was raised. It was pointed out that IPv6 would not be using NHRP to move registration information.
SCSP-ATMARP (draft-ietf-ion-scsp-atmarp): Jim presented the first cut at this document. A key issue is what to do when an ATMARP client wishes to rejoin a SG. ATMARP doesn't have a requestID or a purge, therefore you have to wait. The current text tells the client what to do. The document needs to tell the server what to do in order that the client will not be able to crash the server. Joel Halpern presented some of the alternatives that could be used to address this problem.
To summarize the status of the SCSP Documents, the NHRP Draft is being held by the IESG pending completion of the SCSP work. The SCSP protocol independent document is ready for working group last call. The SCSP-NHRP document is close to being ready. It was decided to continue discussion for one month on the mailing list and then issue the Working Group last call. The SCSP-ATMARP document needs additional work. Joel Halpern agreed to help on this particular document.
NHRP Protocol Applicability Statement, Derya Canserver, draft-ietf-ion-nhrp-appl
Derya Canserver presented the latest revision of the NHRP Applicability Document. M. Ohta voiced some concern that scalability issues raised on the mailing list were missing from the document. Group consensus appeared to be that the scalability issue is a concern, and that it is adequately discussed in the document. George Swallow voiced some concern about the statement that the r2r case is not addressed. Analysis has shown that the r2r case works fine if one is not crossing metric boundaries. George agreed to provide text to clarify this in the document. The intention of the Working Group is to turn this document around quickly and get it out for a last call.
5. Transient Neighbors for IPv6 over ATM, Grenville Armitage, draft-ietf-ion-tn
Grenville Armitage presented the document as released in March 1997. Major changes to the document include:
· Input from the San Jose meeting
· Augmented MARS now mandatory
· Rules for host side packet forwarding clarified
No issues were raised, and it is expected to go to Working Group last call soon.
6. MARS and SCSP, Grenville Armitage
The document draft-armitage-ion-mars-scsp has not been revised since November 1996. It provides a general overview. A new document, draft-armitage-ion-distmars-spec, is a first cut at specific details of MARS using SCSP. Grenville realizes this document is incomplete. He asked for volunteers to assist in the development of the specification.
7. VENUS, Grenville Armitage, draft-armitage-ion-venus
The Working Group last call on this document has now closed. There were some changes to the abstract suggested on the mailing list to clarify the intentions of the document. These changes are going to be made, and the document will be forwarded to the IESG as soon as possible for publication as an Informational RFC.
8. EARTH, Michael Smirnow, draft-smirnow-ion-earth
This work incorporates two major concepts: Multicast Logical IP Subnets (MLIS) and Multiprotocol over MLIS (MOM). There were a number of concerns raised during discussion of the document. The limitation of MARS to a single LIS was made to avoid some of the issues being raised with this document. The existing routing protocols will not work with this document. If the routing protocols are fixed and the MARS limitation is removed, it is unclear what the difference between this approach and MARS would be. While the working group appreciated his efforts, there was no consensus to accept this as a work item. It was decided to continue discussion on the mailing list. It may lead to an Experimental RFC.
9. Intra LIS Multicast Routers over ATM, David Meyer, draft-farinacci-intralis-multicast
This draft offers a simple means of multicast support for a LIS that contains no host. This document is based on the assumption that every router in a LIS knows (can obtain extra to this protocol) the IP and ATM addresses of all the other routers in the LIS. Each router maintains at least one point-to-multipoint VC that includes all the other routers in the LIS. It currently addresses PIM sparse-mode only, but the authors claim that the technique is extensible to other multicast protocols. There was consensus in the Working Group to address the topic. The solution may require optimizations to specific multicast routing protocols. Issues that need to be addressed include applicability, encapsulation, complexity, and interoperability. The authors agreed to carry the work forward to the mailing list.
10. Receiver Initiated Shortcut Path (RISP), Yao-Min Chin, draft-ogawa-receiver-shortcut-path
Yao-Min Chen presented RISP, draft-ogawa-receiver-shortcut-path.00. The discussion showed that this largely covered idea, which the Working Group had considered in developing NHRP, but did not incorporate. Since the functionality is close to NHRP, the draft was not accepted. The authors were encouraged to bring forward a draft for a receiver-initiated call as an option to NHRP.
11. Intra-area IP unicast among routers over legacy ATM, Juha Heinanen
Juha Heinanen made a presentation on using ATM addresses carried in opaque LSA in OSPF as a means for accomplishing IP unicast among routers within an OSPF area. It was noted that similar mechanisms could be incorporated into IS-IS and BGP.
The primary motivation is to provide a simple solution in the near term. Juha felt that label switching would not address the problem because it would take too long to develop; upgrading ATM networks is not easy or cheap; and we need a solution supported by the public ATM network.
Some key assumptions of this proposal include: the set of routers is small enough to form a single area for the link state routing protocol; and the maximum number of routers is less than 100.
The majority of the technical work is currently going on in the OSPF working group. Rob Coulton briefly discussed the technical work being pursued in OSPF. This WG will most likely result in an Informational RFC to document how to take advantage of the OSPF work.
1. Intra-area IP Unicast Among Routers over Legacy ATM
2. Address Resolution Advertisements
3. A Distributed ATMARP Service Using SCSP
4. Internetworking Over NBMA Working Group – Agenda
5. Next Hop Resolution Protocol Rev11
6. A Distributed NHRP Service Using SCSP
7. Receiver Initiated Shortcut Path – RISP
8. Easy IP Multicast Routing Through ATMs Clouds (EARTH)
9. Server Cache Synchronization Protocol