Telematics groupUniversity of Göttingen, Germany
Overhead and Performance Study of the General Internet Signaling Transport (GIST) Protocol
Xiaoming Fu (Uni Goettingen)
Henning Schulzrinne (Columbia Uni) Hannes Tschofenig (Siemens)
Christian Dickmann, Dieter Hogrefe (Uni Goettingen)
2 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Overview
• Background• Terminology• Operation Overview• Evaluation
– Overhead– E2e performance– Scalability– Security
• Conclusions
3 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Background• Middlebox: interposed entity doing more than IP forwarding (NAT, firewall, cache, …)
– Can also be QoS and other boxes – PHB, profile meters, AQM etc…
• Not in harmony with the Internet architecture
10.1.1.4
NAT BHost A
New traffic class
Firewall
Host DC
QoS
4 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Background
• Perhaps need sort of common control plane functions for end-to-end communications– QoS is just an example of control functions– NAT, firewalls and other functions are also in consideration– One needs to perform certain configuration of such control
functions before (and during) an end-to-end communication• Actually, this is somewhat re-inventing "circuit-switching"
concept in ATM or telephony networks!• If we want to allow its use the Internet, a general
signaling function for IP is necessary– Signaling: to install, maintain, remove states in network nodes– It needs to traverse heterogeneous IP-based nodes – It needs to cater for accommodating various controlling purposes
5 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Network Control Signaling Protocol Examples
• Path-decoupled (Client/Server)– COPS– MEGACO– DIAMETER– MIDCOM
• Path-coupled– Resource Reservation Protocol (RSVP) IETF
proposed standard for QoS signaling (03/97)– IETF NSIS (Next Steps in Signaling) with QoS
signaling as first application
6 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
RSVP review
• RFC 2205 • Integrated Service QoS models: GS, CLS
– Per-flow reservation– Multicast flow– Limited extensibility (objects and semantics)– Refreshes: packet losses due to congestion, route changes– Not adapted to today’s needs
• RFC 2961: added hop-by-hop reliability and summary refreshes
• Other extensions: aggregated reservation, reservation over different networks (MPLS, 802.x)
7 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Selected issues with RSVP
• Insufficient modularity – Designed specifically for (IntServ) QoS– Difficult to accommodate new signaling applications:
firewall/NATs, network diagnostics, etc.
• No/difficult support for mobility– Node mobility has been an immense reality
• Weak security framework and AAA support– No operator today will choose to deploy a solution
without sufficient security for global Internet use
8 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
NSIS Framework (RFC 3726)
• Flexible/extendable message transport– Reliability/order provisioning– Keepalive and multiplexing– Some security services– Common transport functions
• Flexible/extendable multiple signalling application– Per flow QoS (IntServ)– Flow aggregate QoS (DiffServ)– Firewall and Network Address Translator (NAT)– Traffic meter configuration– And others
• A two-layer split– Transport layer (NTLP or GIST): message transport– Signalling layer (NSLP): QoS NSLP, NATFW NSLP, etc.
• Contains the application intelligence
9 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
NSIS Two-Layer Split
IP forwarding
SignallingAppl. Protocol
Resourcespecific layer
CommonSignalling
?
?NSIS Transport Layer (NTLP)
NSIS Signalling Layer (NSLP)
Two names for transport layer:• NTLP (the basic concept)• GIST (the protocol implementation
• General Internet Signalling Transport
10 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
GIST: NSIS Transport Layer (NTLP)• GIST responsible for
– Transport signalling message through network– Finding necessary network elements
• Abstraction of transport to NSLPs– NSLP do not care about transport at all
S e cu rityP ro to co ls
(T L S , IP se c )
S igna llingA pp lica tion - m idcom
S igna llingA pp lica tion -Q oS
NSL
Ple
vel
NTL
P le
vel
IP
S igna llingA pp lica tion - A N O
G IS TG IS T M e ssa g e E n ca p su la tio n G IS T S ta te M a in te n a n ce
U D P T C PD C C P S C T P
IP
...w h ich inc ludes m anagem en t o f a ll o f th is
F ocus o f spec ifica tionis th is
11 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
TCP connection
View on NSIS’ Layers
NSISHost A
NSISHost B
NSIS router
NetworkView
RouterwithoutNSIS
RouterwithoutNSIS
NSIS router
NTLPView
NTLPStack
NTLPStack
NTLPStack
NTLPStack
NSLPView
NSLPStack
NSLPStack
NSLPStack
NSLPStack
UDPtransport
Are you mynext node?(discovery)
Need QoS!
Here it is! Here it is!
Here it is!
Abstraction
Need QoS!Need QoS
12 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
GIST Session Setup
13 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Evaluation• Scalability
– Can it be scalable for large number of sessions and nodes?
• Extensibility and mobility– Can it be easily extended to build most signaling applications?
– Can mobility be intrinsically supported?
• Security– Can it be well protected without much performance penalty?
• Overhead– Will the overhead added by NSIS be too large?
14 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Extensibility and mobility• NSIS allows
– GIST use of any types of discovery mechanism– Definition of any new NSLPs – node mobility: thru the use of independent NSIS session identifiers
• Support a large variety of transport protocols– SCTP and PR-SCTP– TCP and its variants (both loss and delay based)– UDP (and even DCCP)
• In the implementation level:– The GIST daemon and GIST-API are developed with sufficient
modularity/independency on underlying platforms and NSLPs– Currently we support xBSD, Linux and MacOS: fairly easy to port
15 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
S1
S2
S3
R1
100mbps
BackgroundTraffic generator
H1
R2
D1
D2
BackgroundTraffic generator
100mbps 100Mbps
100Mbps
1GMbps R2100Mbps
S3
100mbps
D3
100Mbps
Performance testing: testbed
16 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Performance/scalability: 3 hops
01020304050607080
0
10
00
50
00
10
00
0
15
00
0
20
00
0
25
00
0
30
00
0
35
00
0
40
00
0
45
00
0
50
00
0
55
00
0
60
00
0Number of sessions
CP
U c
on
sum
pti
on
(%
)
GIST (C-mode) GIST (D-mode) RSVP
020406080
100120140160
0
10
00
50
00
10
00
0
15
00
0
20
00
0
25
00
0
30
00
0
35
00
0
40
00
0
45
00
0
50
00
0
55
00
0
60
00
0
Number of sessions
Mem
ory
co
nsu
mp
tio
n (
MB
)
GIST (C-mode) RSVP
0
1
2
3
4
5
6
7
0
10
00
50
00
10
00
0
15
00
0
20
00
0
25
00
0
30
00
0
35
00
0
40
00
0
45
00
0
50
00
0
55
00
0
60
00
0
Number of sessions
Av
g. R
TT
(s
ec
on
ds
)
18 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Security
• Two-layer security– Interconnected!
• Transport layer (NTLP)– Securing signaling transport– Using TCP/SCTP with TLS– Certificates– Discovery phase: use of cookies
• Signaling layer – Authentication and authorization– Policy decisions (e.g., user allowed to load filter rule?)
19 Xiaoming Fu ([email protected])
Telematics groupUniversity of Göttingen, Germany
Conclusions
• Extensible IP signaling framework (NSIS) tries to address the mobility, complexity, transport, and security issues in RSVP– Not only QoS signaling, but also generic signaling for any type
of middlebox configuration– Fundamental building block: GIST protocol
• GIST overhead is higher than RSVP but the complexity worth the added extensibility, modularity.
• GIST performance is comparable with RSVP, with good scalability
• GIST/NSIS implementation: http://user.cs.uni-goettingen.de/~nsis