Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ion/ion-minutes-97aug.txt

Text File | 1997-10-10 | 40KB | 813 lines

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   [e-mail]   phone:[phone]   fax:[phone]
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 <[e-mail]>; 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 <[e-mail]>
From: "Andrew G. Malis" <[e-mail]>
Subject: ION Munich minutes (resend)
Cc: "Andrew G. Malis" <[e-mail]>
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   [e-mail]   phone:[phone]   fax:[phone]
Ascend Communications, Inc.        5 Carlisle Road    Westford, MA 01886