Internetworking over NBMA (ion) minutes Monday, 8/12/97, 1300-1500 and 1530-1730. Chaired by Andrew Malis and George Swallow. Minutes recorded by Andrew Malis. Agenda - First Session 1. Introduction and administrivia 2. Jim Luciani, SCSP for MARS draft-ietf-ion-scsp-mars-00.txt 3. Grenville Armitage, IPv6 over ATM update draft-ietf-ion-tn-01.txt 4. Juha Heinanen, Intra-area IP unicast among routers over legacy ATM draft-ietf-ion-intra-area-unicast-00.txt 5. Rob Coltun and Juha Heinanen, OSPF Address Resolution Advertisements draft-ietf-ospf-ara-00.txt 6. Nanying Yin and Shantigram Jagannath, End-to-End Traffic Management issues in IP/ATM Internetworks draft-jagan-e2e-traf-mgmt-00.txt Agenda - Second Session 1. Mike Davison, Simple ILMI -Based Server Discovery draft-davison-ilmi-discov-atmarp-00.txt draft-davison-ilmi-discov-mars-00.txt 2. David Breitgand et al, IMSS: IP Multicast Shortcut Service draft-anker-congress-00.txt 3. Norihiro Ishikawa, IP Multicast Routing over ATM draft-ishikawa-ion-mcatm-routing-00.txt draft-ishikawa-ion-mcatm-mlis-00.txt 4. Yao-Min Chen and Jun Ogawa, RISP, two drafts in progress There were 195 attendees. First session: Andy Malis began the meeting by presenting the current list of documents before the working group. Jeff Burgan, the group's Internet Area Director, added a few comments with regards to documents that are on his queue to review. The security sections are mostly complete for NHRP and SCSP, and NHRP and SCSP (and their associated drafts) will be advanced together. The Classic2 and broadcast drafts will be advanced shortly. The IESG still needs to review the UNI 4.0 signaling and Classical IP MIB documents. The RFC 1490 and 1293 updates are also waiting for new security text, and the 1293 update needs to collect implementation experience. Jim Luciani spoke on SCSP for MARS. The MCS client registers with a single server - any server in the server group may be used. The servers in the server group use SCSP to synchronize their databases. If their server fails, then the clients registered with a particular server must re-register with another server, and SCSP will purge their prior registration. Jim's presentation was accepted by the group, and work on the document will continue. Grenville Armitage spoke on three topics, IPv6 over NBMA, the status of some of his other documents, and his new ion security draft. For IPv6 over NBMA, the interface token is now based on 8-octet EUI-64, he cleaned up some vague text, specified host triggered transient neighbor discovery, and folded in some text from a previous expired draft that had gotten lost along the way. Still to do is the syntax mapping between ND and NHRP at routers, and clean up the misleading "ATM dependency" implied by current text. The text really shouldn't be dependent on ATM, but should work for any NBMA network. Document update: draft-armitage-ion-distmars-spec-00.txt is being dropped. draft-armitage-ion-mars-nbma-02.txt is complete and Grenville has asked for a WG last call for Informational. This will happen shortly. Grenville then presented his new ion protocol security draft. The reasons for the draft are that the IESG is more security focused and it is needed for long-term credibility of IP/ATM installations. Version 00 is a summary of some security issues with RFC 1577, RFC 2022, and NHRP. There are no solutions yet - Grenville will focus on the NHRP/MARS authentication TLV and key management issues (the TLV definition is in the NHRP and SCSP documents). His plans are to spin off RFC 1755 stuff, add SCSP vulnerabilities and the use of TLV, add intra-cluster/LAG/SG key management, and iterate with WG input on mailing list. Juha Heinanen spoke on intra-area IP unicast among routers over legacy ATM. The problem being solved is how to efficiently and dynamically implement IP unicast among routers that are in the same area of a link state routing domain and are connected to the same ATM network (for example, an ISP's routers). There are two modes of operation: optimize connectivity between a large number of routers (non-full-mesh), or automate the setup of a full mesh if the number of routers is small enough. Each router must belong to the same area to learn about each other, and the best egress to each destination. However, not all the routers in the area need to be ATM-attached. The initial configuration is a non-full mesh default connectivity between the routers, perhaps one path between each pair of "adjacent" routers. Each router then measures the amount to traffic to each destination router. If there is enough traffic, it opens a VC to allow a direct path for that traffic. The VC is treated as being unidirectional, and is not added to the routing tables. It is strictly local to the sending router. The ATM VC properties are decided locally. The IP packets use VC multiplexing for efficiency, since only IP is used on the VC. Joel Halpern noted that it's pretty silly to assume that this will be IP only, since the same mechanism can be used for other protocols, and the same VCs can then be shared. He's been burned many times by not having multiplexing headers on frames. Juha said that it isn't a big issue to him, and he would agree to LLC/SNAP as the default and VC-multiplexed as an option. George Swallow made the point that this can be signaled. Juha agreed with Joel that LLC/SNAP be the recommended default. The threshold constants to trigger opening VCs are configurable. There are ways to configure the constants to create a full mesh of VCs. Routers learn each others' router IDs and reachability via the routing algorithm. For OSPF, the address resolution information is included in a new option, the address resolution advertisement (ARA). The flooding scope of the ARA is area-local. The service type of the ARA identifies the use of the ATM address for this particular purpose. Possible enhancements are the use of multipoint-to-point VCs and dynamic renegotiation of the traffic parameters. There are security considerations. The dynamic VCs bypass the normal hop-by-hop control path, so location of any access filters should therefore be designed carefully. George noted that this is worse than NHRP, because you can filter on NHRP requests and terminate the query along the path if necessary. Juha's scheme allows you to tunnel past filters if you aren't careful. George also noted that operationally, most filtering is done around the edges which tends to minimize this issue. There was a question regarding whether Juha would be able to provide guidelines for configuring this to work well to establish the shortcuts at the appropriate time, without creating too many VCs, and guidelines for the VC's QoS parameters. George noted that these kinds of concerns cross many protocols, including MPOA, LANE, NHRP, and anything else that is setting up dynamic VCs, and so probably aren't appropriate to be included just in Juha's draft. There was a question if the asymmetric traffic paths caused by unidirectional VCs would be a problem for applications. George noted that asymmetric routing is now quite common in the Internet, and the applications and routing adapt just fine. The chairs will discuss with the area directors whether this should be submitted as an informational or proposed standard RFC. Rob Coltun spoke on the OSPF ARA option. The general idea is that routers advertise link-layer associations using link-layer attachments for directly connected networks and hosts. The ARA advertises a single vertex and a list of vertex associations. There may be multiple ARAs for the same vertex. The vertex may be a router or a network. The advertisements are scoped. They are distributed in an opaque link state advertisement. Opaque LSAs have gone through last call in the OSPF working group. BGP is going in a very similar direction, where the next hop information can include an ATM address. The vertex association in the advertisement includes the service type (ATM pt-pt, pt-mpt, mpt-pt, Ethernet), the IS service type, the administrative weight, the logical network ID, and resolution information. The ARAs are referenced by the routing information base after the SPF calculation. Juha's draft is an example of a user of this information in the routing information base. It does not actually go into the forwarding table. Possible uses are virtual routers (an Ethernet switch with router controller - however, it doesn't work well with VLANs), multicast shortcuts (works well with MOSPF), router-to-router shortcuts (ATM and Ethernet), and ISPs (with BGP). Rob presented an example of an SPF calculation with the additional vertex information. Andre Fredette had a suggestion to improve its performance with VLANs, MPOA, and NHRP in general, by adding an option to tell the sending host to query for the ATM address. The NHRP server can then return the proper ATM-layer address. A question was asked about when this is superior to NHRP. Rob said that the router-to-router case works better than with NHRP. He said that NHRP works great with hosts, but when in a router-only environment, this has a number of advantages, including being able to do address resolutions without requests. The questioner asked about the overhead of adding this information to the LSAs, and Rob replied that as long as you're under 200 or so routers, it shouldn't be a problem. Rob and Ross Callon discussed the possibility of this mechanism's usefulness for MPLS. Rob noted that the encapsulation type might be added to the advertisements so that the receiver can choose which it wants. Ross suggested that the receivers be able to receive both, and the sender can then chose which to use as a local decision. No encapsulation type assumes that LLC/SNAP will be used. Andre noted that this was discussed in the MPOA group, and it uncovered a rat's nest of issues. This will be further discussed on the list. Shantigram Jagannath discussed end-to-end traffic management issues in IP/ATM internetworks. This is being provided for the working group's general information. IP over ATM is typically used to interconnect legacy networks. There is very little end-to-end ATM. Support of end-to-end QoS and traffic management become important issues. We must consider strategies for improving end-user throughput and delay. A typical example for IP over ATM has users on LANs interconnected via an ATM network and ATM edge devices. The users are using end-to-end TCP flow control at the TCP layer. ATM flow control, if used, is limited to the ATM subnetwork. The end-to-end performance may not be better even if the ATM network is kept congestion-free by using ATM-layer mechanisms. When ATM-layer congestion occurs, cells are dropped, perhaps by Early Packet Discard. Loss of packets reduces the TCP window. With ABR, there are two flow control loops - one at the ATM layer and one at the TCP layer. Congestion at the ATM layer causes queues to increase in the edge device, finally causing overflow and TCP window reduction. Is there a method to achieve good end-to-end performance with limited edge buffers and limited buffers inside ATM? They ran a simulation of TCP over ABR. The TCP was RFCs 793 and 1122 with fast retransmission and recovery. They simulated ten TCP sources going though the ATM network. Their metrics were effective throughput and file transfer delay. Their results were that ABR needs large buffers in the edge device and UBR needs large buffers in the ATM switch. Larger edge buffers can improve ABR throughput, but also increases delay. Smaller buffers can lead to more TCP window dynamic, which reduces throughput and adds delay due to packet loss. In limited buffer situations, UBR with Early Packet Discard performs comparably to ABR, if not better. An observation was that ABR keeps the ATM network clean of congestion, but it may not result in better end-user performance. They proposed the use of feedback information from the network and monitored TCP window state though edge device queue depth, early detection and packet discard, and discard only when necessary. The objective is better throughput and delay with limited buffers in edge devices and inside ATM switches. He presented their adaptive discard algorithm, which drops from the front of the queue to reduce TCP feedback delay and make sure that there are packets to generate duplicate ACKs. The adaptive discard based on rate feedback and current queue length. They plan future work to extend the algorithm for UBR. Raj Nair noted that there are specific issues for short-lived flows that have to be specially handled. This will be further investigated. He were asked if you have to use non-linear solutions because there are nested feedback loops? The answer was that no, that is not required to be able to model this behavior. They will revise their draft based upon comments and future work, and the working group chairs will discuss with the area directors whether this fits within the working group charter as a working group document. Second session: Mike Davison presented ILMI-based server discovery. This is a simple mechanism used to locate servers for protocols such as ATMARP and MARS. It is based on the ATM Forum's Service Registry MIB. Mike presented the client behavior used to obtain the server information from the table. These drafts have been adopted by the WG as a work item. David Breitgand presented IMSS, IP multicast shortcuts. The basic proposal is best effort service and shortcuts only among routers, complementing MARS, coexisting with IDR protocols, membership management using CONGRESS, and shortcut connections management using IP-SENATE. This is an extension of MARS for inter-LIS communications. Joel Halpern noted that many efforts along these lines have had problems with the fact that different source addresses because of source-specific multicast addressing (PIM, OSPF, etc.). This seems to have the same problem as the other efforts. They use multicast servers rather than a full mesh of pt-mpt connections. They specify the use of pt-pt connections between the servers and their clients, but in response to a question, agreed that pt-mpt could be used from the servers to the clients. Joel noted that this paper does not properly note that the behavior is source-specific, and the source may not be ATM-attached. This paper used the concept of "D group", which is not properly defined because it assumes the same multicast tree from all sources. David agreed as a result of this discussion that his proposal had some major flaws that he needs to address in a revised version of his draft. The talk was terminated while they discussed these issues offline. Following the offline discussion discussion, they returned and continued their presentation following the next two presentations. He explained how he resolved the issue that Joel pointed out with respect to determining which routers are part of the same D group. George Swallow announced following the end of this talk that the chairs and the area directors will be updating the working group's charter to update the goals and milestones, and to determine the scope of future work, especially with regards to multicasting and shortcuts. No further action will be taken on this or other multicast shortcut proposals by the working group until the charter revision has completed. Norihiro Ishikawa presented IP Multicast Routing over ATM. The requirements for IP multicasting over ATM are scalability, efficient use of ATM, robustness, interworking, and support for applications. He wishes to extend the current architecture for IP multicasting over an ATM MLIS, using a shared-tree architecture. Multicast shortcuts are efficiently supported. He proposed a new set of IGMP messages that are optimized for operation over ATM, and the ability to produce shortcuts. He has implemented sender, receiver, and multicast router functions, by extending the OS kernel (SunOS 4.1.4). He obtained performance results of approximately 90% of unicast traffic for multicast UDP/IP traffic. There are two drafts: the first provides the functionality of IGMP over ATM, and the second provides the multicast shortcuts over ATM in an efficient and scalable manner. His conclusion is that IP multicast over ATM is as easy as IP multicast over shared media LANs such as Ethernet if a simple approach is taken such as a simplified MARS approach or an IGMP based approach (his proposal). Such a mechanism is required for thin clients (STB, NC, InternetTV). Masataka Ohta commented on the scalability of shortcuts in general. There was agreement that multicast shortcuts do not scale in all cases. Mikhail Smirnov suggested an improvement to the proposed algorithm for adding shortcuts to the multicast tree. The chairs noted that independently extending IGMP for ATM MLISes, rather than using MARS, didn't conform to previous working group documents. No further action will be taken on these drafts until the charter revision has been completed. Jun Ogawa and Yao-Min Chen presented Responder Initiated Shortcut Path (RISP). This is a follow-on to work to a presentation that was made in the Memphis meeting. They have updated their protocol based upon the comments received there, and would like to publish it as an informational RFC. The current status of the work is that it has been split along two directions: a stand-alone protocol and a callback option for NHRP. The former operates on NBMA networks that do not have any address resolution facilities, and this is where they have been concentrating their effort. They described how the stand-alone protocol works. It configures VCs as point-to-point interfaces, which are registered as host route entries in the routing information base. Given that it works without any address resolution, they felt that its use as an NHRP callback option should be reexamined. They proposed their callback protocol header use the NRHP LLC/SNAP ID, and have a version/protocol number to be assigned from the NHRP/MARS space. In their discussion of a callback option for NHRP, they noted that NHRP is a client-server protocol, while RISP is a potentially serverless peer-to-peer protocol. The NHRP callback option is meaningful for NHRP if per-flow shortcuts are considered a suitable target by the WG, but they have not done any work on it at this time. Jim Luciani pointed out that this is a brand new protocol. He also noted that you double the overhead of NHRP queries, and you circumvent the security on the reverse path if you have bi-directional VCs. He pointed out some other problems that had previously been discussed regarding this and similar schemes both in the IETF and the ATM Forum. He mentioned that you're effectively building a Next-Hop Server in the routers. He also wanted to understand their motivation in not using an existing protocol. George Swallow noted that the group is trying to produce interoperable solutions, and this working group should not be producing two different protocols to produce the same, or similar, functionality. There was general agreement from the group, and no further action will be taken on the draft. Following the remainder of David Breitgand's talk, the working group adjourned. ________________________________________________________________________ Andrew G. Malis malis@casc.com phone:508 952-7414 fax:508 392-1484 Ascend Communications, Inc. 5 Carlisle Road Westford, MA 01886 From - Wed Sep 10 16:06:32 1997 Received: from webserver.casc.com by ietf.org id aa08608; 6 Sep 97 13:19 EDT Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id NAA00158 for <dwalker@ietf.org>; Sat, 6 Sep 1997 13:17:08 -0400 Received: from amalis.casc.com by casc.com (SMI-8.6/SMI-SVR4-bob.2) id NAA17394; Sat, 6 Sep 1997 13:19:10 -0400 Message-Id: <3.0.2.32.19970906130611.00759f68@152.148.10.6> X-Sender: amalis@152.148.10.6 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sat, 06 Sep 1997 13:06:11 -0400 To: Dixie Walker <dwalker@ietf.org> From: "Andrew G. Malis" <malis@alpo.casc.com> Subject: ION Munich minutes (resend) Cc: "Andrew G. Malis" <malis@alpo.casc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: X-Mozilla-Status: 8001 Internetworking over NBMA (ion) minutes Monday, 8/12/97, 1300-1500 and 1530-1730. Chaired by Andrew Malis and George Swallow. Minutes recorded by Andrew Malis. Agenda - First Session 1. Introduction and administrivia 2. Jim Luciani, SCSP for MARS draft-ietf-ion-scsp-mars-00.txt 3. Grenville Armitage, IPv6 over ATM update draft-ietf-ion-tn-01.txt 4. Juha Heinanen, Intra-area IP unicast among routers over legacy ATM draft-ietf-ion-intra-area-unicast-00.txt 5. Rob Coltun and Juha Heinanen, OSPF Address Resolution Advertisements draft-ietf-ospf-ara-00.txt 6. Nanying Yin and Shantigram Jagannath, End-to-End Traffic Management issues in IP/ATM Internetworks draft-jagan-e2e-traf-mgmt-00.txt Agenda - Second Session 1. Mike Davison, Simple ILMI -Based Server Discovery draft-davison-ilmi-discov-atmarp-00.txt draft-davison-ilmi-discov-mars-00.txt 2. David Breitgand et al, IMSS: IP Multicast Shortcut Service draft-anker-congress-00.txt 3. Norihiro Ishikawa, IP Multicast Routing over ATM draft-ishikawa-ion-mcatm-routing-00.txt draft-ishikawa-ion-mcatm-mlis-00.txt 4. Yao-Min Chen and Jun Ogawa, RISP, two drafts in progress There were 195 attendees. First session: Andy Malis began the meeting by presenting the current list of documents before the working group. Jeff Burgan, the group's Internet Area Director, added a few comments with regards to documents that are on his queue to review. The security sections are mostly complete for NHRP and SCSP, and NHRP and SCSP (and their associated drafts) will be advanced together. The Classic2 and broadcast drafts will be advanced shortly. The IESG still needs to review the UNI 4.0 signaling and Classical IP MIB documents. The RFC 1490 and 1293 updates are also waiting for new security text, and the 1293 update needs to collect implementation experience. Jim Luciani spoke on SCSP for MARS. The MCS client registers with a single server - any server in the server group may be used. The servers in the server group use SCSP to synchronize their databases. If their server fails, then the clients registered with a particular server must re-register with another server, and SCSP will purge their prior registration. Jim's presentation was accepted by the group, and work on the document will continue. Grenville Armitage spoke on three topics, IPv6 over NBMA, the status of some of his other documents, and his new ion security draft. For IPv6 over NBMA, the interface token is now based on 8-octet EUI-64, he cleaned up some vague text, specified host triggered transient neighbor discovery, and folded in some text from a previous expired draft that had gotten lost along the way. Still to do is the syntax mapping between ND and NHRP at routers, and clean up the misleading "ATM dependency" implied by current text. The text really shouldn't be dependent on ATM, but should work for any NBMA network. Document update: draft-armitage-ion-distmars-spec-00.txt is being dropped. draft-armitage-ion-mars-nbma-02.txt is complete and Grenville has asked for a WG last call for Informational. This will happen shortly. Grenville then presented his new ion protocol security draft. The reasons for the draft are that the IESG is more security focused and it is needed for long-term credibility of IP/ATM installations. Version 00 is a summary of some security issues with RFC 1577, RFC 2022, and NHRP. There are no solutions yet - Grenville will focus on the NHRP/MARS authentication TLV and key management issues (the TLV definition is in the NHRP and SCSP documents). His plans are to spin off RFC 1755 stuff, add SCSP vulnerabilities and the use of TLV, add intra-cluster/LAG/SG key management, and iterate with WG input on mailing list. Juha Heinanen spoke on intra-area IP unicast among routers over legacy ATM. The problem being solved is how to efficiently and dynamically implement IP unicast among routers that are in the same area of a link state routing domain and are connected to the same ATM network (for example, an ISP's routers). There are two modes of operation: optimize connectivity between a large number of routers (non-full-mesh), or automate the setup of a full mesh if the number of routers is small enough. Each router must belong to the same area to learn about each other, and the best egress to each destination. However, not all the routers in the area need to be ATM-attached. The initial configuration is a non-full mesh default connectivity between the routers, perhaps one path between each pair of "adjacent" routers. Each router then measures the amount to traffic to each destination router. If there is enough traffic, it opens a VC to allow a direct path for that traffic. The VC is treated as being unidirectional, and is not added to the routing tables. It is strictly local to the sending router. The ATM VC properties are decided locally. The IP packets use VC multiplexing for efficiency, since only IP is used on the VC. Joel Halpern noted that it's pretty silly to assume that this will be IP only, since the same mechanism can be used for other protocols, and the same VCs can then be shared. He's been burned many times by not having multiplexing headers on frames. Juha said that it isn't a big issue to him, and he would agree to LLC/SNAP as the default and VC-multiplexed as an option. George Swallow made the point that this can be signaled. Juha agreed with Joel that LLC/SNAP be the recommended default. The threshold constants to trigger opening VCs are configurable. There are ways to configure the constants to create a full mesh of VCs. Routers learn each others' router IDs and reachability via the routing algorithm. For OSPF, the address resolution information is included in a new option, the address resolution advertisement (ARA). The flooding scope of the ARA is area-local. The service type of the ARA identifies the use of the ATM address for this particular purpose. Possible enhancements are the use of multipoint-to-point VCs and dynamic renegotiation of the traffic parameters. There are security considerations. The dynamic VCs bypass the normal hop-by-hop control path, so location of any access filters should therefore be designed carefully. George noted that this is worse than NHRP, because you can filter on NHRP requests and terminate the query along the path if necessary. Juha's scheme allows you to tunnel past filters if you aren't careful. George also noted that operationally, most filtering is done around the edges which tends to minimize this issue. There was a question regarding whether Juha would be able to provide guidelines for configuring this to work well to establish the shortcuts at the appropriate time, without creating too many VCs, and guidelines for the VC's QoS parameters. George noted that these kinds of concerns cross many protocols, including MPOA, LANE, NHRP, and anything else that is setting up dynamic VCs, and so probably aren't appropriate to be included just in Juha's draft. There was a question if the asymmetric traffic paths caused by unidirectional VCs would be a problem for applications. George noted that asymmetric routing is now quite common in the Internet, and the applications and routing adapt just fine. The chairs will discuss with the area directors whether this should be submitted as an informational or proposed standard RFC. Rob Coltun spoke on the OSPF ARA option. The general idea is that routers advertise link-layer associations using link-layer attachments for directly connected networks and hosts. The ARA advertises a single vertex and a list of vertex associations. There may be multiple ARAs for the same vertex. The vertex may be a router or a network. The advertisements are scoped. They are distributed in an opaque link state advertisement. Opaque LSAs have gone through last call in the OSPF working group. BGP is going in a very similar direction, where the next hop information can include an ATM address. The vertex association in the advertisement includes the service type (ATM pt-pt, pt-mpt, mpt-pt, Ethernet), the IS service type, the administrative weight, the logical network ID, and resolution information. The ARAs are referenced by the routing information base after the SPF calculation. Juha's draft is an example of a user of this information in the routing information base. It does not actually go into the forwarding table. Possible uses are virtual routers (an Ethernet switch with router controller - however, it doesn't work well with VLANs), multicast shortcuts (works well with MOSPF), router-to-router shortcuts (ATM and Ethernet), and ISPs (with BGP). Rob presented an example of an SPF calculation with the additional vertex information. Andre Fredette had a suggestion to improve its performance with VLANs, MPOA, and NHRP in general, by adding an option to tell the sending host to query for the ATM address. The NHRP server can then return the proper ATM-layer address. A question was asked about when this is superior to NHRP. Rob said that the router-to-router case works better than with NHRP. He said that NHRP works great with hosts, but when in a router-only environment, this has a number of advantages, including being able to do address resolutions without requests. The questioner asked about the overhead of adding this information to the LSAs, and Rob replied that as long as you're under 200 or so routers, it shouldn't be a problem. Rob and Ross Callon discussed the possibility of this mechanism's usefulness for MPLS. Rob noted that the encapsulation type might be added to the advertisements so that the receiver can choose which it wants. Ross suggested that the receivers be able to receive both, and the sender can then chose which to use as a local decision. No encapsulation type assumes that LLC/SNAP will be used. Andre noted that this was discussed in the MPOA group, and it uncovered a rat's nest of issues. This will be further discussed on the list. Shantigram Jagannath discussed end-to-end traffic management issues in IP/ATM internetworks. This is being provided for the working group's general information. IP over ATM is typically used to interconnect legacy networks. There is very little end-to-end ATM. Support of end-to-end QoS and traffic management become important issues. We must consider strategies for improving end-user throughput and delay. A typical example for IP over ATM has users on LANs interconnected via an ATM network and ATM edge devices. The users are using end-to-end TCP flow control at the TCP layer. ATM flow control, if used, is limited to the ATM subnetwork. The end-to-end performance may not be better even if the ATM network is kept congestion-free by using ATM-layer mechanisms. When ATM-layer congestion occurs, cells are dropped, perhaps by Early Packet Discard. Loss of packets reduces the TCP window. With ABR, there are two flow control loops - one at the ATM layer and one at the TCP layer. Congestion at the ATM layer causes queues to increase in the edge device, finally causing overflow and TCP window reduction. Is there a method to achieve good end-to-end performance with limited edge buffers and limited buffers inside ATM? They ran a simulation of TCP over ABR. The TCP was RFCs 793 and 1122 with fast retransmission and recovery. They simulated ten TCP sources going though the ATM network. Their metrics were effective throughput and file transfer delay. Their results were that ABR needs large buffers in the edge device and UBR needs large buffers in the ATM switch. Larger edge buffers can improve ABR throughput, but also increases delay. Smaller buffers can lead to more TCP window dynamic, which reduces throughput and adds delay due to packet loss. In limited buffer situations, UBR with Early Packet Discard performs comparably to ABR, if not better. An observation was that ABR keeps the ATM network clean of congestion, but it may not result in better end-user performance. They proposed the use of feedback information from the network and monitored TCP window state though edge device queue depth, early detection and packet discard, and discard only when necessary. The objective is better throughput and delay with limited buffers in edge devices and inside ATM switches. He presented their adaptive discard algorithm, which drops from the front of the queue to reduce TCP feedback delay and make sure that there are packets to generate duplicate ACKs. The adaptive discard based on rate feedback and current queue length. They plan future work to extend the algorithm for UBR. Raj Nair noted that there are specific issues for short-lived flows that have to be specially handled. This will be further investigated. He were asked if you have to use non-linear solutions because there are nested feedback loops? The answer was that no, that is not required to be able to model this behavior. They will revise their draft based upon comments and future work, and the working group chairs will discuss with the area directors whether this fits within the working group charter as a working group document. Second session: Mike Davison presented ILMI-based server discovery. This is a simple mechanism used to locate servers for protocols such as ATMARP and MARS. It is based on the ATM Forum's Service Registry MIB. Mike presented the client behavior used to obtain the server information from the table. These drafts have been adopted by the WG as a work item. David Breitgand presented IMSS, IP multicast shortcuts. The basic proposal is best effort service and shortcuts only among routers, complementing MARS, coexisting with IDR protocols, membership management using CONGRESS, and shortcut connections management using IP-SENATE. This is an extension of MARS for inter-LIS communications. Joel Halpern noted that many efforts along these lines have had problems with the fact that different source addresses because of source-specific multicast addressing (PIM, OSPF, etc.). This seems to have the same problem as the other efforts. They use multicast servers rather than a full mesh of pt-mpt connections. They specify the use of pt-pt connections between the servers and their clients, but in response to a question, agreed that pt-mpt could be used from the servers to the clients. Joel noted that this paper does not properly note that the behavior is source-specific, and the source may not be ATM-attached. This paper used the concept of "D group", which is not properly defined because it assumes the same multicast tree from all sources. David agreed as a result of this discussion that his proposal had some major flaws that he needs to address in a revised version of his draft. The talk was terminated while they discussed these issues offline. Following the offline discussion discussion, they returned and continued their presentation following the next two presentations. He explained how he resolved the issue that Joel pointed out with respect to determining which routers are part of the same D group. George Swallow announced following the end of this talk that the chairs and the area directors will be updating the working group's charter to update the goals and milestones, and to determine the scope of future work, especially with regards to multicasting and shortcuts. No further action will be taken on this or other multicast shortcut proposals by the working group until the charter revision has completed. Norihiro Ishikawa presented IP Multicast Routing over ATM. The requirements for IP multicasting over ATM are scalability, efficient use of ATM, robustness, interworking, and support for applications. He wishes to extend the current architecture for IP multicasting over an ATM MLIS, using a shared-tree architecture. Multicast shortcuts are efficiently supported. He proposed a new set of IGMP messages that are optimized for operation over ATM, and the ability to produce shortcuts. He has implemented sender, receiver, and multicast router functions, by extending the OS kernel (SunOS 4.1.4). He obtained performance results of approximately 90% of unicast traffic for multicast UDP/IP traffic. There are two drafts: the first provides the functionality of IGMP over ATM, and the second provides the multicast shortcuts over ATM in an efficient and scalable manner. His conclusion is that IP multicast over ATM is as easy as IP multicast over shared media LANs such as Ethernet if a simple approach is taken such as a simplified MARS approach or an IGMP based approach (his proposal). Such a mechanism is required for thin clients (STB, NC, InternetTV). Masataka Ohta commented on the scalability of shortcuts in general. There was agreement that multicast shortcuts do not scale in all cases. Mikhail Smirnov suggested an improvement to the proposed algorithm for adding shortcuts to the multicast tree. The chairs noted that independently extending IGMP for ATM MLISes, rather than using MARS, didn't conform to previous working group documents. No further action will be taken on these drafts until the charter revision has been completed. Jun Ogawa and Yao-Min Chen presented Responder Initiated Shortcut Path (RISP). This is a follow-on to work to a presentation that was made in the Memphis meeting. They have updated their protocol based upon the comments received there, and would like to publish it as an informational RFC. The current status of the work is that it has been split along two directions: a stand-alone protocol and a callback option for NHRP. The former operates on NBMA networks that do not have any address resolution facilities, and this is where they have been concentrating their effort. They described how the stand-alone protocol works. It configures VCs as point-to-point interfaces, which are registered as host route entries in the routing information base. Given that it works without any address resolution, they felt that its use as an NHRP callback option should be reexamined. They proposed their callback protocol header use the NRHP LLC/SNAP ID, and have a version/protocol number to be assigned from the NHRP/MARS space. In their discussion of a callback option for NHRP, they noted that NHRP is a client-server protocol, while RISP is a potentially serverless peer-to-peer protocol. The NHRP callback option is meaningful for NHRP if per-flow shortcuts are considered a suitable target by the WG, but they have not done any work on it at this time. Jim Luciani pointed out that this is a brand new protocol. He also noted that you double the overhead of NHRP queries, and you circumvent the security on the reverse path if you have bi-directional VCs. He pointed out some other problems that had previously been discussed regarding this and similar schemes both in the IETF and the ATM Forum. He mentioned that you're effectively building a Next-Hop Server in the routers. He also wanted to understand their motivation in not using an existing protocol. George Swallow noted that the group is trying to produce interoperable solutions, and this working group should not be producing two different protocols to produce the same, or similar, functionality. There was general agreement from the group, and no further action will be taken on the draft. Following the remainder of David Breitgand's talk, the working group adjourned. ________________________________________________________________________ Andrew G. Malis malis@casc.com phone:508 952-7414 fax:508 392-1484 Ascend Communications, Inc. 5 Carlisle Road Westford, MA 01886