Transcript PPT Version

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 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!
• things may change in between next-node discovery (that aren't
visible to the previous node)
• 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
similarity between
discovery = data
divergence
causes
constraints
destination
address
load balancing, TE
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 might we need?
–
–
–
–
–
reliable
flow controlled
congestion controlled
sequenced
channel security (TLS)
• 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
– channel security (IPsec endpoint known; TLS)
Aside: SIP experience
• SIP went through similar evolution
• SIP can be considered an application-level
analogue (second cousin) of NSIS
– first TCP  "too slow"  UDP
– UDP  new applications of SIP emerged
• S/MIME encapsulation
• messaging
• more proxy-induced material carried in message
– TCP + UDP  hybrid transport chains
– UDP effectively deprecated
Transport
• Thus, "fork-in-the-road" question:
– re-create a transport protocol
– try to layer on top of existing transport
• are there features we don't need from
(UDP)/TCP/SCTP?
– support both:
• offer severely restricted functionality on "bare IP"
– e.g., next-node discovery only
• everything else on existing protocols
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