Trade-offs and open issues with path discovery and transport or not all requirements are orthogonal… Henning Schulzrinne Columbia University NSIS working group IETF 55 (November 2002, Atlanta)

Overview Need to identify requirements and design goals that are orthogonal and others that may not be –solution space isn’t infinite, so instructive to look at building blocks and their properties two fundamental issues in signaling: –next-node discovery –message transport will try to explore design space, not one solution

Next-node discovery Basic function, regardless of *-orientation generally, NI needs to establish state so that messages can flow in both directions –implicit assumption, could have unidirectional NI NE NR NI NE NR

Next-node discovery Next-node discovery is probably fundamental distinction between path-coupled and path- decoupled Need to understand complexity before ruling out options path-coupled: –one of the routers downstream –unless every data packet is a signaling packet, always only guess at coupling! path-decoupled: –some server in next AS –anything else make (interdomain) sense?

Next-node discovery: path-coupled All discovery is approximate –some node could use any feature of the discovery packet to route it differently discovery = datadivergence causes constraints destination address load balancing source & destination address L4 load balancing? no signaling proxies (ICMP errors misdirected to data source) full 5-tuplepresence of router alert options? no signaling proxies how to disentangle at end system?

Next-node discovery: path-coupled Discovery behavior options: –straight-through –hop-by-hop NI NE NR non NE

Next-node discovery: path-coupled NINE NR non NE hop-by-hop discovery (“incremental”)

Next-node discovery: incremental Probably needed for use with existing transport protocols –need known end point address discovery not needed if next node = next (IP) hop may be able to use OSPF/IGRP/IS-IS information to look further ahead – dangerous? How many different next nodes are likely? –next network boundary? –only at edges  equal to number of sessions

Combining flow-through and transport sessions NINRNE non NE use existing transport connection if available

Next-node discovery: path- decoupled Not well defined if several in one AS basically, an inter-domain service location problem IETF tool kit for distributed solutions: –SLP (with extension in progress) –DNS SRV/NAPTR (see SIP) Probably not: –multicast or anycast –LDAP

Transport Two fundamental options: –“flow-through” –NE-NE transport associations Which transport services do we need? –reliable –flow controlled –congestion controlled –sequenced Not necessarily all of these all the time, but transport choice may limit applicability Some can be done at NSLP –e.g., sequencing

Extreme Transport Signaling transport users may require large data volumes: –active network code –signed objects (easily several kB long if self- contained; standard cert is ~5 kB) –objects with authentication tokens (OSP, …) –diagnostics accumulating data Signaling applications may have high rates: –DOS attacks –automated retry after reservation failure (“redial”) –odd routing (load balancing over backup link)

Signaling Transport Connection reuse for multiple signaling associations  –better RTT and congestion window estimation  faster loss recovery –amortize connection setup overhead –amortize setup costs for L3/4 security associations –congestion management

Lower and upper layers Do all nodes process all NSIS messages? “omnivorous”: –all messages, even unknown signaling protocols –e.g., firewalls –depends on what information is common common flow identification? “vegetarians”: –only things they know and can understand