Transcript NSIS - Columbia University

Trade-offs and open issues with
path discovery and transport or
not all requirements are
orthogonal…
Henning Schulzrinne
Columbia University
[email protected]
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
NE
NE
NR
NI
NE
NE
NE
NR
Next-node discovery
• Next-node discovery is probably fundamental
distinction between path-coupled and pathdecoupled
• 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 = data
divergence
causes
constraints
destination
address
load balancing
source &
destination
address
L4 load
balancing?
full 5-tuple
presence of router no signaling proxies
alert options?
how to disentangle at end
system?
no signaling proxies (ICMP errors
misdirected to data source)
Next-node discovery: path-coupled
• Discovery behavior options:
– straight-through
– hop-by-hop
NI
NE
non
NE
NE
NR
Next-node discovery: path-coupled
hop-by-hop discovery (“incremental”)
NI
NE
non
NE
NE
NR
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
NI
NE
use existing transport
connection if available
non
NE
NE
NR
Next-node discovery: pathdecoupled
• 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 selfcontained; 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