1992: "Internet/ATM: Signalling Requirements"

Presentation made at IETF 25 (Wash., DC) to the IP over ATM working group.

Transcript

1. Internet/ATM: Signalling Requirements Tom Lyon Sun Microsystems Computer Corporation pugs@eng.sun.com Goals forATM End-to-end ATM usage is desirable, across wide geographies and administrative domains Non end-to-end ATM is a fact of life forever - support it well Applications, end systems, people don’t want to know Except they want more performance in the end-to- end case Addressing ¯ Addressing and administration are all mixed up ¯ "Fixing" IP is an orthogonal problem ¯ Routers do a lot more than route - security, accounting, storm control, etc. ¯ MAC-level addressing model for ATM means separate routers are still needed ¯ Integrating ATM with multi-protocol addressing gets end-end performance with good control Header Avoidance ¯ For end-end ATM case, large parts of IP and TCP are redundant ¯ Avoid protocol/header overhead by terminating ATM connections at higher levels of protocol stacks ¯ Important to keep look, smell, and feel of TCP, but new protocol(s) required ¯ View connection as a cache of route/protocol decisions Addressing Requirements ¯ Type field in every address for multi-protocol addressing (OSI NSAP?) ¯ Sub-address hack for transiting E.164-only nets ¯ SAP/port addressing for identifying higher levels in protocol stack ¯ Address discovery- DHCP? ¯ Determination of end-to-end-ness Connectionless Connectionless semantics are important, performance needs work Certain things will always be better connectionless (service discovery, keep-alives) If switch understands network addressing, connectionless forwarding is small extra step Need signalling to discover and connect to connectionless service (router) 153
2. Multicast ¯ LAN/IP model is many-to-many; ATM model is 1-to-many ¯ Multicast server(s) provide chokepoint for IP over ATM Servedservice location & server-to-server issues: dynamic routing/recovery Many-to-many works better in connectionless world Routing Dynamic routing is a bigger issue for private networks than for public networks Customers unwilling to pay for same level of redundancy; but still want high availability Routing, addressing, policy, accounting all mixed up Can’t "fix it" in ATM - its a higher level problem Use existing work for ATM; don’t invent a new universe Other Per connection MTU discovery Lightweight connections for best-effort QOS 154