performance evaluation of explicit signaling for nat...

Performance evaluation of explicit signaling for NAT traversal in peer to peer communication with emphasis on P2P-TV

Jawad Hussain

Master of Science Thesis Stockholm, Sweden 2009

TRITA-ICT-EX-2009:110

Performance evaluation of explicit signaling

for NAT traversal in peer to peer

communication with emphasis on P2P-TV

Jawad Hussain ([email protected])MS (Internetworking)

This thesis is presented as degree of Masterof Science in Internetworking

Royal Institute of TechnologyNovember 2009

Abstract

Peer-to-Peer (P2P) networks have become increasingly popular and havebecome a very successful networking paradigm. Presently P2P network boostup by P2P file sharing programs such as Napster, KaZaA, TV broadcastingetc.

As network address translators (NAT) [1] and firewall devices are becom-ing increasingly ubiquitous and are unavoidable, and they pose a significantproblem for connection establishment for peer-to-peer protocols which stillin its infancy. P2P applications need to connect to each other, but are in-creasingly obstructed by NAT boxes. Some popular P2P applications do notaddress NAT traversal or do so poorly.

By taking this factor in consideration, this thesis work attempts to high-light NAT traversal problem in peer-to-peer architectures, analyze differenttechniques that can be applicable to P2P architectures and then by applyingthese concepts we have performed experiments and simulations for the via-bility of the possible solution that will be the most promising and universalwhich we have discussed in subsequent chapters and later we evaluate ourresults for the possible adaptation in P2P-IPTV.

2

Sammanfattning

Peer- to-Peer (P2P) ntverk har kat i popularitet och har blivit ett vldigtframgngsrikt paradigm. Just nu kar P2P ntverken tack vare P2P fildel-ningsprogram som t.ex. Napster, KaZaA, TV sndningar mm.

Nr ”network address translators” (NAT) och brandvggar blir en allt van-ligare syn och r oundvikliga, hotar dom att skapa problem med att skapaanslutningar fr P2P protokoll som fortfarande r i sin lida. P2P applikationerbehver skapa anslutningar till varandra, men blir mer och mer stoppade avNAT enheter. Vissa populra P2P applikationer klarar inte av NAT-traversaleller gr det dligt.

Med detta i tanke, handlar denna avhandling om att frska belysa proble-men med NAT-traversal i P2P arkitekturer, analysera olika tekniker som kanvara tillmpliga fr P2P arkitekturer och sen genom att tillmpa dessa koncepthar vi utfrt experiment och simulationer fr duglighet till en mjlig lsning vilketvi har diskuterat i pfljande kapitel och senare utvrderar vi vra resultat fr denmjliga anpassningen i P2P-IPTV.

3

Acknowledgment

I would like to thank Dr. Renato Lo Cigno from University of Trento foroffering me this working opportunity and extends his full guidance to me. Ialso like to thank Dr. Markus Hidell for his valuable comments and feedbackduring this work which make this document valuable.

I would also like to express my sincere gratitude to Asim Fareed whoalways guiding and encouraging me throughout my educational career.

Finally I must exclusively thank my family members for all their supportand motivation at every step during this work and my Masters studies atKTH.

5

Contents

1 Introduction 131.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . 141.2 Thesis Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Thesis Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Technical background 162.1 Peer to Peer communication . . . . . . . . . . . . . . . . . . . 16

2.1.1 Components involved in P2P-TV setup . . . . . . . . . 172.2 Network address translation . . . . . . . . . . . . . . . . . . . 18

2.2.1 Full cone NAT . . . . . . . . . . . . . . . . . . . . . . 182.2.2 Restricted cone NAT . . . . . . . . . . . . . . . . . . . 192.2.3 Port restricted cone NAT . . . . . . . . . . . . . . . . . 192.2.4 Symmetric NAT . . . . . . . . . . . . . . . . . . . . . . 192.2.5 NAT summary . . . . . . . . . . . . . . . . . . . . . . 202.2.6 Peer to Peer (P2P) and NAT . . . . . . . . . . . . . . 21

3 NAT traversal mechanisms in P2P networks with relation toSIP 223.1 SIP and network address translators . . . . . . . . . . . . . . 223.2 NAT traversal approaches . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Session traversal of UDP through NAT (STUN) . . . . 233.2.2 Traversal using relays around NAT (TURN) . . . . . . 253.2.3 Universal plug and play (UPnP) . . . . . . . . . . . . . 273.2.4 Interactive connectivity establishment (ICE) . . . . . . 283.2.5 SIP proxy . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.6 Extension for symmetric response routing . . . . . . . 303.2.7 Application layer gateways (ALGs) . . . . . . . . . . . 313.2.8 Session border controller (SBC) . . . . . . . . . . . . . 32

6

CONTENTS

3.2.9 MIDCOM . . . . . . . . . . . . . . . . . . . . . . . . . 323.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Analysis 344.1 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Analysis of different NAT traversal approaches . . . . . . . . . 36

4.2.1 Session traversal of UDP through NAT (STUN) . . . . 364.2.2 Traversal using relay NAT (TURN) . . . . . . . . . . . 374.2.3 Interactive connectivity establishment (ICE) . . . . . . 384.2.4 Universal plug and play (UPnP) . . . . . . . . . . . . . 384.2.5 Application layer gateways (ALG) . . . . . . . . . . . . 394.2.6 Middle box communication MIDCOM . . . . . . . . . 404.2.7 NSIS NSLP for NAT and firewall . . . . . . . . . . . . 40

4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 NSIS framework overview and NAT/FW NSLP implemen-tation 435.1 Next steps in signaling (NSIS) framework . . . . . . . . . . . . 43

5.1.1 NSIS signaling architecture . . . . . . . . . . . . . . . . 445.1.2 NSIS protocol suite model description . . . . . . . . . . 45

5.2 NAT/FW NSLP protocol . . . . . . . . . . . . . . . . . . . . . 465.2.1 NAT/FW NSLP traversal scenarios . . . . . . . . . . . 47

5.2.1.1 Firewall traversal . . . . . . . . . . . . . . . . 475.2.1.2 NAT traversal . . . . . . . . . . . . . . . . . . 47

5.3 Protocol operation . . . . . . . . . . . . . . . . . . . . . . . . 485.3.1 Network terminologies . . . . . . . . . . . . . . . . . . 485.3.2 NAT/FW message types . . . . . . . . . . . . . . . . . 48

5.3.2.1 CREATE message . . . . . . . . . . . . . . . 495.3.2.2 Signaling session with CREATE message . . . 495.3.2.3 RESERVE EXTERNAL message . . . . . . . 50

5.4 Implementation components . . . . . . . . . . . . . . . . . . . 525.4.1 Protocol state operation . . . . . . . . . . . . . . . . . 53

5.5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Testing and performance evaluation 576.1 Network testbed . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.1 Virtual machines . . . . . . . . . . . . . . . . . . . . . 58

7

CONTENTS

6.1.1.1 User mode linux (UML) . . . . . . . . . . . . 586.1.1.2 VMware . . . . . . . . . . . . . . . . . . . . . 59

6.2 Conformance test cases . . . . . . . . . . . . . . . . . . . . . . 596.3 Test methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3.0.3 Session round trip time . . . . . . . . . . . . 616.3.0.4 Throughput . . . . . . . . . . . . . . . . . . . 626.3.0.5 Utilization . . . . . . . . . . . . . . . . . . . . 62

6.4 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.5 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.6.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . 766.6.2 Result evaluation . . . . . . . . . . . . . . . . . . . . . 76

6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7 Conclusion and Future work 81Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8

List of Figures

2.1 Mesh-pull P2P live streaming architecture . . . . . . . . . . . 172.2 Full cone NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Restricted cone NAT . . . . . . . . . . . . . . . . . . . . . . . 192.4 Symmetric NAT . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 STUN SIP message flow . . . . . . . . . . . . . . . . . . . . . 243.2 SIP register rewrite message . . . . . . . . . . . . . . . . . . . 253.3 SIP rewrite invite message . . . . . . . . . . . . . . . . . . . . 253.4 TURN SIP message flow . . . . . . . . . . . . . . . . . . . . . 263.5 UPnP SIP flow . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6 ICE SIP flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7 SIP-Extension message flow . . . . . . . . . . . . . . . . . . . 31

4.1 Classification of NAT traversal solutions . . . . . . . . . . . . 35

5.1 Signaling and Data Flows . . . . . . . . . . . . . . . . . . . . 445.2 NSIS Layered Model . . . . . . . . . . . . . . . . . . . . . . . 455.3 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4 CREATE message flow . . . . . . . . . . . . . . . . . . . . . . 505.5 EXTERNAL message flow . . . . . . . . . . . . . . . . . . . . 515.6 Implementation components . . . . . . . . . . . . . . . . . . . 525.7 Protocol transition states . . . . . . . . . . . . . . . . . . . . . 535.8 Implementation Architecture [23] . . . . . . . . . . . . . . . . 55

6.1 Physical testbed . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Testbed with two NFs . . . . . . . . . . . . . . . . . . . . . . 596.3 Testbed with two NFs, NI and NR swapped . . . . . . . . . . 606.4 Testbed with two NFs at both NI and NR . . . . . . . . . . . 616.5 Session round trip time for NAT/FW sessions . . . . . . . . . 64

9

LIST OF FIGURES

6.6 Throughput for CREATE messages . . . . . . . . . . . . . . . 656.7 CPU utilization for NSLP messages . . . . . . . . . . . . . . . 666.8 Session trip time [37] . . . . . . . . . . . . . . . . . . . . . . . 676.9 Peers overlay formation . . . . . . . . . . . . . . . . . . . . . . 686.10 Peer formation in Table 6.6 . . . . . . . . . . . . . . . . . . . 746.11 Peer formation in Table 6.7 . . . . . . . . . . . . . . . . . . . 746.12 Evaluation methodology . . . . . . . . . . . . . . . . . . . . . 766.13 P2P-TV average session lifetime[29] . . . . . . . . . . . . . . . 786.14 Average signaling overhead in P2P-TV[29] . . . . . . . . . . . 79

7.1 Reserve external message sent from NR . . . . . . . . . . . . . 887.2 Port/IP reservation at NF . . . . . . . . . . . . . . . . . . . . 897.3 Create message sent by NI . . . . . . . . . . . . . . . . . . . . 897.4 Create message sent by NI . . . . . . . . . . . . . . . . . . . . 907.5 Create message at NR . . . . . . . . . . . . . . . . . . . . . . 907.6 Response response at NI . . . . . . . . . . . . . . . . . . . . . 91

10

List of Abbreviations

ALG Application Layer Gateways

API Application Programming Interface

GIMP GNU Image Manipulation Program

GIST General Internet Signaling Transport

ICE Interactive Connectivity Establishment

IP Internet Protocol

IPTV Internet Protocol Television

MIDCOM Middle box Communication Protocol

NAPT Network Address and Port Translation

NAT Network Address Translation/Translator

NAT/FW NAT and Firewall

NF Network Forwarder

NI Network Initiator

NR Network Responder

NSIS Next Steps in Signaling

NSLP Network Signaling Layer Protocol

NTLP Network Transport Layer Protocol

11

LIST OF FIGURES

P2P Peer to Peer

P2P-TV Peer-to-Peer Television

QoS Quality of Service

RFC Request for Comments

RSVP Resource Reservation Protocol

RTP Real Time Protocol

SBC Session Border Controllers

SIP Session Initialization Protocol

SLA Service Level Agreement

STUN Session Traversal of UDP through NAT

TCP Transmission Control Protocol

TURN Traversal Using Relay NAT

UDP Universal Datagram Protocol

UPnP Universal Plug and Play

12

Chapter 1

Introduction

The Peer-to-Peer (P2P) model has emerged successfully as a promising newservice provisioning paradigm over the last decade. An application designedand following the P2P paradigm in which every host participating is a clientand a server at the same time. Every peer should provide resources pro-portional to the resources it requests from others. This stands in contrastto the conventional client/server architecture, where the client usually onlyacts as a consumer and the server as a producer of services or resources andtherefore underlies an asymmetric hierarchy of hosts.

There are demands for the network to support the P2P model as wellas the client-server model. One of the main differences between these twomodels is the initiation of communication. In the client-server model, theclient always initiates a session with a server. In the P2P model, however aclient may be an initiator or a receiver. This makes it difficult to establish asession between end users.

Network Address Translation (NAT) [1] was introduced as a mean tocontinue the internet growth despite rapid depletion of IPv4 address space.Function of NAT is to hide the network topology from an external entity. Net-work Address Translation devices (NATs), which are also commonly calledmiddle-boxes separate an internal network from the broader Internet throughthe use of a separate address space in the internal network. NATs dynami-cally translate between these address spaces for each network connection. Inaddition to the IP address translation, NATs must also allocate distinct ex-ternal ports to distinct internal hosts. This allows multiple internal hosts tocommunicate with the same external host on the same source port. Another

13

CHAPTER 1. INTRODUCTION

characteristic of NATs is that they only allow connections originating fromwithin the internal network. NATs drop unsolicited connection attempts,since they have no way of knowing to which internal host the packet shouldbe forwarded.

While this translation scheme worked well for conventional client/serverbased applications, it is no longer accurate for P2P architectures and usu-ally requires some special technique either in application, in NAT boxes orexternal to these entities.

1.1 Problem Description

”P2P (peer to peer) applications suffer from NAT (Network address transla-tion) more than the traditional client/server model. The unavoidable pres-ence of NAT in the Internet for the foreseeable future impairs the properdevelopment of P2P applications and business models”

In todays world most of the P2P applications do not explicitly deal withNAT devices or do so poorly. But usually NAT devices are deployed in almostall enterprises and cannot be neglected as in P2P each and every node is acontributing resource.

By keeping above mention statement in mind which derives our motiva-tion and our work is to discover a suitable NAT traversal technique that canhelp P2P applications to become aware of NAT devices and to handle themeffectively but also scales well.

14

CHAPTER 1. INTRODUCTION

1.2 Thesis Scope

This thesis work will describe NAT traversal problems in P2P networks,analysis of the possible approaches under IETF working groups with relationand parallel to SIP based services and provide an experimental evaluation ofstrength and weakness of next steps in signaling NAT/FW traversal solutionin P2P-IPTV systems.

1.3 Thesis Layout

Thesis work consists of seven chapters and is organized as follows.

• Chapter 1 provide an brief introduction to subject and includes prob-lem statement that is the source of motivation for this work.

• Chapter 2 highlights technical background.

• Chapter 3 presents current best and promising futuristic approachesof handling NAT traversal in P2P networks and in relation to SIP basedcommunication.

• Chapter 4 include analysis of the NAT traversal mechanisms discussedin chapter 3.

• Chapter 5 describes NSIS NAT/FW NSLP framework and implemen-tation.

• Chapter 6 shows experimental performance evaluation.

• Chapter 7 presents our conclusion and suggests some of the futurework.

15

Chapter 2

Technical background

2.1 Peer to Peer communication

The new concept of P2P users providing service to other users, while obtain-ing services from the system like IPTV, would revolutionize the entertain-ment and media industries [28].

P2P streaming networks does not rely on a dedicated delivery infrastruc-ture i.e. client/server architecture and follow cooperative architecture henceoffer the possibility of rapid deployment at low cost. Cooperation in band-width can be utilized for video transmission so as to reduce the server loaddramatically. Therefore, P2P streaming networks have appeared to be themost promising driving wheel for the IPTV deployment [28].

In designing such an P2P streaming network there are two building blocks:one is overlay topology formation between peers and the other is video contentdelivery.

The two most common approaches are.

• peers form a tree-shaped overlay and video content is pushed from theorigin server to peers, namely the tree-push approach [28];

• peers form a mesh-shaped overlay and they pull video from each otherfor content delivery, namely, the mesh-pull approach [28].

P2P TV architecture based on popular mesh pull approach is shown asbelow.

16

CHAPTER 2. TECHNICAL BACKGROUND

Figure 2.1: Mesh-pull P2P live streaming architecture

2.1.1 Components involved in P2P-TV setup

• a video is divided into media chunk and is made available from an originserver for broadcast

• channel server contains video information accessible for peers. A peer,interested in viewing the video, requests from the channel server forthe available video streams step 1 in Figure 2.1.

• tracker server maintains the list of the peers who are interested inwatching the same video. After a host selects its interested video,it retrieves a list of hosts currently watching the same video, step 2marked in Figure 2.1 which peer C is contacting tracker and channelservers.

• The peers shown in Figure 2.1 where peer C establishes partner re-lationships (TCP/UDP connections) with peer A and peer E, this be-havior is shown in step 3 of Figure 2.1. These peers help each otherand deliver video traffic cooperatively.

After initial exchange procedures each peer viewing the video caches andshares chunks with other hosts viewing the same video. In particular, eachhost receives Buffer Maps from its current partners. A buffer map froma remote partner indicates the chunks that are available on that partner.

17


Using a chunk scheduling algorithm each host requests from its partners thechunks that it will need in the near future. Each host continuously seeksnew partners from which it can download chunks [28]. Before going in adiscussion how NAT breaks this P2P communication we will take a glanceon NAT and its types briefly.

2.2 Network address translation

Network Address Translation (NAT) [1] is a method by which IP addressesare mapped from one domain to another, in an attempt to provide transpar-ent routing to hosts. Traditionally, NAT devices are used to connect privateunregistered addresses to an external domain with globally unique registeredaddresses. Because it is fundamental to understand what problems can ariseby these NAT devices four types of NATs exist and described here.

2.2.1 Full cone NAT

In a full cone NAT, all requests from the same internal address and portare mapped to the same external address and port. External hosts can sendpackets to this external socket without any preceding connection attemptsfrom behind the NAT device. Figure 2.2 shows an example: Node 1 isconnected in the LAN to the NAT, which translates its internal address toan external WAN address. Node 2 and 3 can now send data packets to thepublic IP address 202.164.102.1 with port 1234, which will be forwarded tohost A by the NAT device.

Figure 2.2: Full cone NAT

18


2.2.2 Restricted cone NAT

Similar to full cone NAT, IP address information is mapped to an externalone. The difference is that here no unsolicited packets from outside willbe forwarded to the LAN. This behavior makes harder to establish peer-to-peer connections. Figure 2.3 shows the difference to the Full Cone NAT anexternal nodes can only send packets to the host behind the NAT if initialpackets have been sent to it. That is the case for node 2, but not for the hostnode 3; its connection attempts will be blocked by the NAT gateway.

Figure 2.3: Restricted cone NAT

2.2.3 Port restricted cone NAT

In a port restricted cone NAT, the constraints are even tighter than theprevious one. Here not only the IP address matters for the response hosts(Node 2 and Node 3 in Figure 2.3) from the WAN side, but also their port.Like the restricted cone but with restricted port numbers. An external hostwith source IP address X and source port Y can send a packet to the internalhost only if the internal host had sent a packet to address X and port Y.

2.2.4 Symmetric NAT

A symmetric cone NAT maps a request from an internal IP address and portto a specific host, always to the same external address and port. But whenthe same host sends a packet from the same source address to a differentdestination, a different NAT mapping is used.

19


Figure 2.4: Symmetric NAT

In addition, as with port restricted cone NATs, unsolicited packets fromthe outside are dropped. This mapping rule makes the Symmetric NAT themost difficult of all four types to handle, because it is difficult to predictwhat mapping rule the NAT device will use for a specific connection and thereliable prediction is a corner-stone for a hole punching technique later de-scribed.Table 2.1 shows the difference of the Symmetric NAT to the previousthree types.

2.2.5 NAT summary

Behavior of above mention NAT types summarized in following table.

NAT Type Internet Address External Address Remote AddressFull Cone 192.168.1.10:1234 202.164.102.1:1234 ANY

Restricted Cone 192.168.1.10:1234 202.164.102.1:1234 192.145.4.2:2345Port Restricted Cone 192.168.1.10:1234 202.164.102.1:1234 192.145.4.2:2345

Symmetric 192.168.1.10:1234202.164.102.1:1234 192.145.4.2:2345202.164.102.1:8765 212.212.3.1:4567

Table 2.1: NAT summary. ANY implies remote destination address can vary

20


2.2.6 Peer to Peer (P2P) and NAT

The problem for P2P applications in a NAT environment is that NATed peersare usually not reachable from arbitrary peers. Unsolicited connection (non-initiated) requests from outside are dropped by the NAT device because therequests are sent to the public internet address of the gateway and the NATdevice has no idea to which internal address the request should be forwardedto.

This will be different if the NAT peer already has successfully sent packetsto the other peer, since the NAT device keeps this mapping in a table for agiven time and responses from outside can be forwarded appropriately.

It is not always possible to get the targeted peer address known in advanceand also the presence of NAT is unavoidable which makes many nodes unableto participate in P2P world. Like in Figure 2.1, where peer C joins P2PTV network and is behind NAT, it gets peer A and peer E as the targetpeer addresses for the available streams and it gets the interested stream,oppositely peer A and E cannot utilize peer C useful chunks directly whichultimately disrupts one key P2P property i.e. cooperation, this imply thatpeer C unable to contribute in P2P network as unsolicited connections fromother peer will be dropped at peer C NAT. Diverse NAT traversal techniquesexist to keep the end-to-end connection virtually and we now see them indetail in the following chapter.

21

Chapter 3

NAT traversal mechanisms inP2P networks with relation toSIP

The presence of NAT devices can pose a significant problem if either thecommunication protocol encapsulates IP address information in the payloadinstead of the header or if a certain host behind a NAT device has to bereachable from within the public network. If, as in the first case, the IPaddress information (e.g. about the sender), is part of the payload, the NATdevice cannot translate the local address into the public one, reply from theendpoint therefore cannot reach the proper NAT device and communicationfails. On the other hand, if a peer behind a NAT device should be addressedfrom the outside, the NAT device does not find any entry in its translationtable and therefore cannot know to what address to send the data packageswithin the local network [9]. Presently there are several techniques to handlethis dilemma, and all of them have some advantages and disadvantages, whichwill be explained in the coming sections. It is assumed that we have to rely onSIP based infrastructure as get benefit from SIP enabled proxies for signaling.

3.1 SIP and network address translators

Session Initiation Protocol (SIP) [14] is a signaling protocol, widely used forcontrolling multimedia communication sessions such as voice and video callsover Internet Protocol (IP) is developed by the internet engineering task force

22

CHAPTER 3. NAT TRAVERSAL MECHANISMS IN P2P NETWORKSWITH RELATION TO SIP

(IETF) and has been standardized in SIP-WG of IETF.

SIP has today become the signaling protocol of choice for establishingreal-time communications, including voice and video calls. NAT also imposesproblems for Session Initiation Protocol (SIP)which has been implementedin many devices as a session management protocol.

SIP carries only data attribute information using Session Description Pro-tocol (SDP) [18] and so on. The data itself is carried by Real-time TransportProtocol (RTP) [19]. The functional separation of SIP can lead to data beingdiscarded by NAT. A user in a local private network initiates a SIP session, asthe SIP message from a private network to the public network passes througha NAT, a mapping table for the corresponding incoming messages from thepublic network is created in the NAT. As the packet moves from private topublic domain only source IP address in the IP header of the outgoing SIPmessage is changed to a public address, but the IP addresses described inthe SIP header or SDP inside the message are not changed, so these privateaddress is not routed by routers in the public network.

In the interim, several solutions have been proposed to work around thefirewall/NAT traversal issues that limit SIP-based communication and arediscussed below.

3.2 NAT traversal approaches

3.2.1 Session traversal of UDP through NAT (STUN)

Session traversal of UDP through NATs (STUN) is a process for applicationsto discover the presence and types of NATs and between them and the publicinternet. The public IP address of their NAT device can be determined andas a result with the proper setup, two applications, both behind a NATdevice, can establish a direct UDP based connection between them.

A STUN system is typically composed of a STUN server in the public IPnetwork and several STUN enabled clients in the private IP network. TheSTUN server listens on port 3478 for requests. STUN messages in Figure3.1 are exchanged between Node1 (i.e., client equipped with a STUN client)and the STUN server (with public IP address 140.113.131.62). Following isthe exchange of messages between client and server.

23


• Node1 sends a STUN binding request message to the STUN server.This message is carried by an IP packet with source IP address/port192.168.0.111:5060.

• At the NAT, the mapping is established. According to the mappingtable, the source IP address/port of the Binding Request message istranslated from 192.168.0.111:5060 to 140.113.131.88:10080.

• Upon receipt of the message, the STUN server replies a STUN bindingresponse message. In this message, the source IP address and port ofthe received packet (i.e., 140.113.131.88 and 10080) are filled in theIP and the Port fields of the MAPPED ADDRESS attribute. Thismessage is carried by an IP packet with the destination IP address/port140.113.131.88:10080 and is sent to the NAT

Figure 3.1: STUN SIP message flow

• The NAT retrieves the IP information mapping, translates the destina-tion IP address/port from 140.113.131. 88:10080 to 192.168.0.111:5060,and sends the message to Node 1. Once Node 1 retrieves the IP ad-dress/port 140.113.131.88:10080 and creates an entry in its mappingtable

24


• By getting the correct IP address and Port information node 1 ad-just its SIP and SDP parameters to the correct values and initiate itsREGISTER and INVITE messages towards the target node.

A typical REGISTER and INVITE messages are shown below after get-ting correct bindings from STUN server.

Figure 3.2: SIP register rewrite message

Figure 3.3: SIP rewrite invite message

3.2.2 Traversal using relays around NAT (TURN)

As per our above discussion when a host behind a NAT wants to communicatedirectly to other host, this can become impossible without taking some extrameasures. TURN [3] facilitate this by employing a intermediate node calledrelay. TURN protocol is still in draft mode that allows the host to controlthe operation of the relay and to exchange packets with its peers using therelay.

25


TURN client connected to private user space through one or more NATsand the TURN server which is located in public address space, TURN servercan be used by clients that are behind NATs to acts as a relay when con-necting to other clients which can also be NATed.

The client talks to the server from a (IP address, port) combination calledthe client’s Host Transport Address. The client sends TURN messages fromits host transport address to a transport address on the TURN server whichis known as the TURN Server Transport Address. Here first client generate aallocate request for transport address after receiving this request from client,TURN server replied with allocate response which contain transport addresswhich will be used by the host for receiving incoming flows. Now host willuse this transport address for future communication with all other nodes andTURN Server which serves as a relay and forwards the packets to the client[30, 3].

Figure 3.4: TURN SIP message flow

26


3.2.3 Universal plug and play (UPnP)

Universal Plug and Play (UPnP) [5] can automatically perform discoveryand configuration when a certain device (i.e., an UPnP client) is online.

IP mapping information can be automatically established by UPnP pro-tocol. UPnP and MIDCOM [10] operation is same like a client can use UPnPto discover the existence of a NAT device and ask it to map a particular in-ternal port to an external port. UPnP protocol steps consist of followingsteps.

• When user agent (UA1) is online, it sends an UPnP multicast searchrequest (with the destination IP address/port 239.255.255.250:1900) tofind the NAT (i.e., the home gateway).

• Upon receipt of the search message, the NAT returns its private location(i.e., 192.168.0.1:2869) to UA1 by filling the IP address/port in thepayload of a unicast HTTP response (i.e., 200 OK). The IP informationis then used as the destination of the messages sent from UA1 to theNAT.

• To retrieve the mapped IP address, UA1 sends an UPnP Get externalIP address request (an HTTP POST message) to the NAT.

• The NAT then replies its public IP address (i.e., 140.113.131.88) toUA1 through an HTTP 200 OK message.

• UA1 sends an UPnP new port mapping description request (an HTTPPOST message) with IP address/ports 192.168.0.111:5060 –¿ 10080 in-dicating the private IP information and the mapped public port num-ber.

• If the proposed public port (i.e., 10080) is free, the NAT confirms themapping by an HTTP 200 OK message, and the procedure is com-pleted.

27


Figure 3.5: UPnP SIP flow

3.2.4 Interactive connectivity establishment (ICE)

Interactive Connectivity Establishment (ICE) [4] provides NAT traversal formedia sessions. ICE uses both STUN and TURN and it can be used byany protocol which is based on offer/answer model like Session InitializationProtocol (SIP). In ICE, protocols end points are called agents and they willcommunicate via some signaling protocol e.g. SIP. The basic concept hereis that each user agent gather candidates addresses that be used as addressand ports in SDP that it could use to communicate with the other agent.

There are three types of candidates address and are mentioned below:

• Local candidate: a local IP address of the client.

• Reflexive or STUN candidates: an IP address of the client’s NAT (as-suming they are only behind a single NAT). These are determined fromanother entity i.e. from STUN, and then communicated back to theclient.

• Relay or TURN candidate: an address on a relay server that has beenallocated for use by the client.

28


Firstly client determines its server reflexive and relay candidate addressesby sending an allocate request to server which instructs the server to allocatean IP address and port on the STUN/TURN server (the relay candidate),then after server inform client its public IP and port as reflexive candidate.After getting those candidates clients use them in SDP with in SIP INVITEmessage then both sides perform ICE connectivity tests on obtained trans-port candidate addresses and after getting common agreed address pair callerand callee start sharing media.

Figure 3.6: ICE SIP flow

3.2.5 SIP proxy

SIP proxy technology is another way to add a level of control to the flow ofSIP media.

An external media proxy that operates in conjunction with a registrar/signalingproxy rewrites SDP as call signals pass through and remember SDP as well.The proxy then opens holes for media for an entire session. A control pro-tocol is needed for proxy to communicate with NAT so that all SIP trafficredirected to SIP proxy by NAT.

29


3.2.6 Extension for symmetric response routing

The extension to SIP [6] defines rport parameter for via header which enablesa client to request a server to send the response back to the source addressand port the request was sent from. A SIP node 1 sends an INVITE withrport parameter from source IP address.

192.168.1.10 and port 5060: INVITE sip:[email protected] SIP/2.0 Via:SIP/2.0/UDP 192.168.1.10:5060; rport

As this request is NATed, the private IP address is replaced with aroutable, 202.164101.1 and the port is rewritten to 12060. The proxy popu-lates the rport parameter appropriately and forwards the request which lookslike:

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDPproxy.domain.com Via: SIP/2.0/UDP 192.168.1.10:5060;received=202.164.101.1; rport=12060

The proxy strips its via and then forwards the request to IP address202.164.101.1 and port 12060.

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.10:5060;received=202.164.101.1; rport=12060

The NAT correctly forwards the response to source IP 192.168.1.10 at port12060, above description shown below an in diagrammatic representation.

30


Figure 3.7: SIP-Extension message flow

3.2.7 Application layer gateways (ALGs)

Application layer gateways (ALGs) can be SIP aware NAT that beyond tra-ditional functionalities, understand SIP and change SIP messages to allowendpoints to communicate through them. They parse SIP headers and SDPbodies in order to map private IP addresses and ports to public ones.

SIP-ALG typically deployed in parallel with the NAT to create the private-to-public IP information mappings and uses these mappings to translate theSIP messages, which works as follows.

• Upon detection, NAT identifies an SIP message based on the port num-bers (i.e., 5060) in the payload, it forwards the message to the SIP-ALG.

• The SIP-ALG first checks if an IP information mapping exists in theNATs mapping table. If so, the SIP-ALG translates the SIP Via and theContact header fields based on the IP information mapping retrievedfrom the mapping table. Otherwise, the SIP-ALG invokes the NATto create private-to-public IP information mapping and then uses itto translate the SIP header fields. If the SIP messages carrying SDPcomes from the private IP network, the SIP-ALG interacts with the

31


NAT to create IP information mappings for the RTP sessions and usesthe mappings to translate the SDP c and m fields [12].

3.2.8 Session border controller (SBC)

A Session Border Controller [38] is a device used in some VoIP networks toapply control over the signaling and usually also the media streams involvedin setting up, conducting, and tearing down calls.

A typical SBC consist of a signaling and media proxies. Signaling proxycan acts as a transit for all SIP traffic where as media proxy handle all RTPand RTCP stream. Media proxy also do NAT translations. SBC in thisway separates the signaling and media streams without breaking end to endcommunication.

3.2.9 MIDCOM

Another possible existing solution is MIDCOM [10] protocol. MIDCOMmakes it possible to control a middle box (MB) i.e. NAT or firewall by amiddle box agent (MA) that is MIDCOM enabled client associated with ahigh-layer application like a SIP. When the MB, an MA may be implementedin the same box with an application like SIP. When an MA receives a signalfrom an application, it asks MB for a public address in order to change theIP address described in the application layer. The MB returns a public ad-dress, which is allocated to the MB, and creates a mapping table for addresstranslation. The MIDCOM protocol between an MA and MB is now beingstandardized in MIDCOM-WG in IETF.

In MIDCOM a client A having private address sends an INVITE SIPmessage to the SIP server in order to establish a media session with clientB, client A finds that the IP addresses in the application layer like SDP arelocal addresses. Client A exchanges MIDCOM messages with MB in order toget public addresses to allow incoming media packets to pass through MB.After re-writing the SDP address into a public address, client A sends anINVITE towards target callee.

Together with MIDCOM there is another approach called NSIS signalinglayer protocol (NSLP) [17] for NATs and firewalls. This NAT/FW NSLP isthe most promising approach under next steps in signaling WG to allow hosts

32


to signal on the data path for NATs and firewalls to be configured accordingto the needs of the application data flows and is in spotlight in the followingchapters.

3.3 Conclusion

In this chapter we have highlighted the operation of different NAT traversalmechanisms in relation with SIP. One thing very clear NAT traversal is anopen problem and IETF and many other are working on standardization ofthese mechanisms.

In the following chapter we will critically analyzes these approaches andidentify out a possible long term workable solution for any P2P architecture.

33

Chapter 4

Analysis

There are quite a many solutions that have been proposed by one anotherto allow different protocols to operate through NATs. As per our classifi-cation there are two main ways to perform NAT traversal, one way is torely on an external entity to perform different actions i.e. implicit signaling(STUN/TURN/ICE) and the other way is to enhance the NAT box itself bythe provisioning of an application level entity capable of treating the signal-ing messages before the NAT operation and i.e. we called explicit signaling(NSIS/MIDCOM).

34

CHAPTER 4. ANALYSIS

4.1 Classification

Taxonomy of NAT traversal solutions can be best enumerated by us with thehelp of following diagram.

Figure 4.1: Classification of NAT traversal solutions

35

CHAPTER 4. ANALYSIS

4.2 Analysis of different NAT traversal ap-

proaches

Our performed analysis is based on the following vector of attributes.

• Power to traverse different types of NAT .

• Power to traverse different layers of NAT.

• Effect on network architecture.

• Support for transport protocols.

• Support required from middle-box.

Now we look at some of the strong and week points of the approacheswhich we classified in Figure 4.1 and have discussed in chapter 3.

4.2.1 Session traversal of UDP through NAT (STUN)

STUN [2] is a protocol that have been standardized by IETF. It allows anapplication to discover the presence and type of NATs and firewall betweenthem and the public internet. It also provides the ability to applicationsfor the determination of public Internet Protocol (IP) addresses and portsallocated to them by the NAT.

STUN permits entities that are behind a NAT to first discover the pres-ence of a NAT, type of NAT and then learn the address and port bindingsallocated by the NAT. It requires no changes to the NATs and works withany arbitrary number of NATs. Complete operation discussion in [3.2.1].

(+) points for STUN

• STUN can work with simple NAT deployments.

• STUN can penetrate different layers of NAT.

• No additional update required for any middle boxes.

• STUN enjoys huge support from application vendors.

36

CHAPTER 4. ANALYSIS

(-) points for STUN

• More importantly STUN cannot work with symmetric NAT, which arewidely deployed today.

• STUN introduces new server element in network infrastructure, whichis STUN server.

• Client application stills requires up-gradation to do STUN queries.

• STUN applications have to refresh NAT mappings by sending keepalive messages which can be considered as overhead.

4.2.2 Traversal using relay NAT (TURN)

TURN [3] is a request and response protocol for TCP and UDP connectionsand share common working as of STUN and having the power to traversesymmetric NAT.

TURN provides peer reachability in a way that it introduces server el-ement like STUN in the public domain which serves as a media relay forreceiving the media from any peer that is able to send the packets to thepublic internet and forwards to peer that is behind any type of NAT. Forcomplete operation refer subsection [3.2.2].

(+) points for TURN

• TURN helps to traverse all types of NATs including symmetric NAT.

• It can penetrate multiple NAT layers.

• No additional update required for any middle boxes.

• Support for both TCP and UDP.

(-) points for TURN

• TURN introduces new server element in network infrastructure whichis TURN server.

• TURN relay server will be used as a last resort for end user applicationsand hence all traffic must be relayed through this TURN server whichcontributes to high media latency and bottlenecks.

37

CHAPTER 4. ANALYSIS

• TURN enabled applications have to refresh NAT mappings by sendingkeep alive messages which can be considered as overhead.

4.2.3 Interactive connectivity establishment (ICE)

IETF has defined the Interactive Connectivity Establishment (ICE) [4]. ICEalone is not a new mechanism by itself but a combination of different existingmechanisms like STUN [2] and TURN [3]. ICE claims of making use of theseexisting solutions in order to devise a generic mechanism for NAT traversalwhich is not topology dependent and able to dynamically determine the wayto proceed with STUN messages depending on the detected environment.For complete ICE operation refer [3.2.4].

(+) points for ICE

• It can traverse all types of NATs even symmetric NAT.

• Multiple NAT layers can be traversed.

• ICE deployment is possible in near future.

• Promising support from big vendors.


(-) points for ICE

• Client end applications are required of supporting ICE functionality.

• ICE reliance on STUN and TURN servers virtually make a client/serverarchitecture.

• Same as with TURN and STUN, refresh mechanism required for keep-ing NAT mappings UP.

4.2.4 Universal plug and play (UPnP)

UPnP [5] is a protocol for auto-configuration developed by UPnP consortium.UPnP provides auto configuration functionality that can be used for NATtraversal. UPnP is supported by Microsoft. UPnP NAT traversal technique

38

CHAPTER 4. ANALYSIS

used in Windows XP home and professional edition. For complete operationrefer subsection [3.2.3].

(+) points for UPnP

• It can traverse all type of NAT boxes.


• No additional server element introduced.

(-) points for UPnP

• UPnP support for middle box is required.

• Cannot traverse multiple NAT layers.

4.2.5 Application layer gateways (ALG)

ALGs are application engineered translation agents that sit between the net-works. ALGs examine the application protocol messages that pass throughand may modify the message according to the specification [30]. For completeoperation refer subsection [3.2.7].

(+) points for ALG

• ALG can traverse all NAT types.

• It can traverse multiple layers of NAT.


(-) points for ALG

• Typically ALG and middle-boxes run side by side which leads ALGdeployment expensive.

• ALG fails when payload is encrypted.

39

CHAPTER 4. ANALYSIS

4.2.6 Middle box communication MIDCOM

Middle-box communication (MIDCOM) [10] protocol defines a framework forcontrolling middle boxes for applications to work seamlessly. For completeoperation of the protocol refer subsection [3.2.9].

(+) points for MIDCOM

• It also can traverse all NAT types.

• Can traverse multiple NAT boxes.


(-) points for MIDCOM

• MIDCOM agent integration into applications required.

• Fails with encrypted payload.

• Middle boxes up gradation required.

4.2.7 NSIS NSLP for NAT and firewall

The next steps in signaling (NSIS) working group is considering for signalinginformation about a data flow along its path in the network. The NSIS suiteof protocols are envisioned to support various signaling applications that needto install and/or manipulate such state in the network. Complete protocoloperation discussed in chapter 5.

(+) points for NAT/FW NSLP

• It can traverse all types of NATs.

• It can traverse multiple layers of NATs.

• It can work with both TCP and UDP.

• Although this protocol requires some changes in NATs and s but itis feasible and acceptable as such changes can be used by a range ofapplications like IPTV in our case since the other most important NSISsignaling layer protocol is Quality of Service (QoS) [35].

40

CHAPTER 4. ANALYSIS

• Due to unified signaling approach it is independent of any applicationlayer protocol.

• Unlike with STUN and TURN, NSIS does not introduce any new ele-ment in topology which makes it more suitable for overlay architectures.

(-) points for NAT/FW NSLP

• All the NATs and firewalls in the data path along with end applicationare required to be NSIS compliant, so up gradation is required.

• Migration for existing middle boxes to support this new protocol is achallenge.

• How can security of a network be left on an end user application ??.

4.3 Evaluation

In this section we have critically evaluated the above stated strong and weekarguments of the selected traversal mechanisms which have discussed. In or-der to be more precise here we again narrow down our research into two typesof NAT traversal approaches one in implicit signaling (STUN/TURN/ICE)and the other is explicit signaling (NSIS NAT-FW/MIDCOM).

First we take NAT type i.e. how often any traversal approach can traversedifferent NAT flavors. Implicit approaches can traverse all types of NATexcept STUN which fails with symmetric NAT, so for ICE to work in alltest cases it is necessary it should have at least one transport relay address,where as explicit approaches will work with all kinds of NATs.

Secondly both approaches are able to penetrate multiple NAT layers.

Third and the most important one is ”conceptual view of network in-frastructure”. Almost all implicit approaches introduces server element ininfrastructure which makes this approach less suitable for P2P applicationsand virtually it look like a traditional client/server architecture. Latencyfactor matters with TURN relay server as all traffic is passing through a sin-gle node which is also susceptible to single point of failure where as explicitsignaling retain the originality of the network and the ability to work withcomplex topologies which makes it more suitable for any P2P system.

41

CHAPTER 4. ANALYSIS

One point is the support required from middle boxes for these approaches.For implicit this is not a problem as middle boxes are untouched where asfor explicit, support and migration to such middle boxes will be a challenge.However its our belief that if an approach sounds good and is technicallyfeasible then these prohibitive aspects will gradually be adapted.

We consider ICE and NAT/FW NSLP will be the most promising ap-proaches for NAT traversal in near future. There are some of the problemswith ICE like lot of delay in signaling traffic, post-to-dial is large and relianceon STUN and TURN server. Moreover, media is relayed if the communicat-ing peer is not an ICE compliant [30]. As both of these solutions are in draftphases but we consider NSIS NAT/FW solution can be robust enough forP2P or any other applications that require traversing a NAT due to protocolunified signaling nature.

4.4 Conclusion

Based on our above analysis we have seen that all of these approaches havethere own pros and cons and apart from solution they introduce other prob-lems that are generally hard to solve, such as dependencies on the type ofNAT implementation (full-cone, symmetric, etc), or work through increas-ingly complex network topologies.

NSIS path coupled NAT/FW protocol is one of the promising approachesfor NAT traversals. NSIS NAT/FW NSLP can work in most restrictive en-vironments due to its unified nature of signaling and is topologically inde-pendent.

For the remainder of our thesis work we have focused on IETF nextsteps in signaling NSIS NAT/FW approach and have evaluated its possibleadaption in P2P environment especially in IPTV.

42

Chapter 5

NSIS framework overview andNAT/FW NSLPimplementation

In this chapter we have discussed next steps in signaling (NSIS) frameworkapproach for NAT and firewall traversal. Then we presents an overview of theNAT/FW NSLP framework which has been developed by the NSIS workinggroup and in the last we have NAT/FW implementation.

5.1 Next steps in signaling (NSIS) framework

The next steps in signaling (NSIS) working group is working on protocols forsignaling information about a data flow along its path in the network. TheNSIS suite of protocols are envisioned to support various signaling applica-tions that need to install and/or manipulate such state in the network [17].

NSIS uses two layer of architecture with one lower layer transport (NTLP)and multiple upper layer application signaling protocols (NSLP). The NSISarchitecture defined by IETF NSIS working group has created a separationof network signaling transport layer (NSLP) and network signaling layer pro-tocol (NSLP). By forming such an abstraction it permits the use of multipleunderlying transport protocols.

NSIS working group has defined the next generation signaling protocol

43

CHAPTER 5. NSIS FRAMEWORK OVERVIEW AND NAT/FW NSLPIMPLEMENTATION

(NSLP) [17] for traversing NATs and firewalls uses NSIS Transport LayerProtocol (NLTP), and is a path coupled signaling protocol designed to dy-namically obtain the configurations of firewalls and NATs along the datapath.

5.1.1 NSIS signaling architecture

The NSIS suite of protocols are envisioned to support various signaling appli-cations that need to install and/or manipulate state in the network [17]. Thestate related to a data flow is installed and maintained on the NSIS entities(NEs) along the data flow path through the network also its not necessarythat every node has to contain an NE.

Two or more NSIS entities that communicate directly are said to bein a ’peer relationship’ and can be termed as ’NSIS hop’. Either or bothNEs might store some state information about the other, but there is noassumption that they necessarily establish a long-term signaling connectionbetween themselves.

Figure 5.1: Signaling and Data Flows

Above Figure 5.1 shows a simple NSIS signaling setup in which data isflowing from sender application application via different routers towards re-ceiver. Each host and two of the routers contain NEs that exchange signalingmessages related to the flow and as seen that router R3 has no NE but it cantransparently forward data where as signaling exchange is possible in bothdirections about the flow.

44


5.1.2 NSIS protocol suite model description

NSIS protocol suite structured in two layers as follows.

• A signaling transport layer (NTLP), responsible for moving signalingmessages around, which should be independent of any particular sig-naling application, for complete NTLP operation refer [22].

• A signaling application layer (NLSP) like NAT/FW, QoS etc, whichcontains functionality such as message formats and sequences, specificto a particular signaling application.

This layered approach is described in below figure.

Figure 5.2: NSIS Layered Model

NTLP in above figure can be defined when a signaling message is readyto be sent from one NE, it is given to the NTLP along with informationabout what flow it is for; it is then up to the NTLP to get it to the nextNE along the path (upstream or downstream), where it is received and theresponsibility of the NTLP ends. The key point is that the NTLP for a givenNE does not use any knowledge about addresses,capabilities, or status of anyNEs other than its direct peers.

45


The NTLP in the receiving NE either forwards the message directly or,if there is an appropriate signaling application locally, passes it upwardsfor further processing; the signaling application can then generate anothermessage to be sent via the NTLP.

5.2 NAT/FW NSLP protocol

NSIS working group is working on standardization of signaling layer in NSISprotocol suite and NAT/FW NSLP is one of the signaling layer protocol forNAT traversal.

The purpose for designing NAT/FW NSLP is to request the dynamicconfiguration of NATs and/or along the data path. Dynamic configura-tion includes enabling data flows to traverse these devices without beingobstructed. This removes the need to create and maintain application layergateways for specific protocols that have been commonly used to providetransparency in previous generations of NAT and middle boxes. It is as-sumed that these middle boxes will be statically configured in such a waythat NSIS NAT/FW signaling messages themselves are allowed to reach thelocally installed NAT/FW NSLP daemon. NSIS NAT/FW NSLP signalingis used to dynamically install additional policy rules in all NAT/FW middleboxes along the data path that will allow transmission of the applicationdata flow(s) [21].

Conceptually the usage of NSIS NAT/FW works like, end hosts are posi-tioned behind middle boxes and are in private network and there is least onemiddle box present on the data path from the end host in a private networkto the external public network. Applications located at these hosts try toestablish communication with remote corresponding applications. In doingso they activate the NSIS entity at the local host to control provisioning formiddle box traversal along the prospective data path (e.g. via an API call).The NSIS entity in turn uses NSIS NAT/FW NSLP signaling to establishpolicy rules along the data path, allowing the data to travel from the senderto the receiver un opposed [21].

46


5.2.1 NAT/FW NSLP traversal scenarios

NAT/FW protocol first request the dynamic configuration of NATs and/orfirewall to traverse certain flow and then maintain a state for that given flow.Now we look them in NAT and firewall specific scenarios.

5.2.1.1 Firewall traversal

In firewall case, first signaling entity sends a signaling message towards re-mote entity that will configure all the firewalls in the path to allow a flowto traverse. Once these flow mappings are installed in the firewall, then thedata flow is allowed to travel end to end without any hindrance.

5.2.1.2 NAT traversal

In NAT case, a signaling session that includes all relevant nodes can configurethem accordingly. Apart from firewall in which a signaling session can installand release NAT mappings or mapping reservations at participating hosts.

Here we take an example of Figure 5.1 and instead of re-drawing it, weprefer doing modifications because of space constraints, we consider thatrouter 2 now also doing natting and right application entity is host B andis behind private domain where as left application entity is host A. Unlikethe case, if host A (sender) initiate a signaling session towards host B (des-tination), this signaling session fails as there is no way to reach B becauseof natting. So there is much more work to do on the receiver side, first ithad to detect whether it is behind a NAT if so then it initiates a signalingsession and in this case host B (destination) becomes network initiator forthis session. This signaling session targeted towards network host A (sender)which in this aspect is NR, this signaling must reach all the middle boxeson the path towards host A (sender) so they maintain a forwarding stateprior to the incoming flow and when actual data flow is received it shouldguarantee received by the destination. This provides a public reservation tothe host B that have to be signaled to host A via some application signalingor with NAT/FW NSLP.

Finally NI initiates a signaling session towards the public address throughwhich NR is reachable and this completes a complete session. NAT/firewall

47


NSLP uses two signaling sessions, one from receiver towards the NAT andone from the sender end-to-end to the receiver.

5.3 Protocol operation

This section we will discuss some basic working of the protocol and discusshow to CREATE a session also how an entity reserve EXTERNAL address,for complete protocol operation refer [21].

5.3.1 Network terminologies

In our following discussion we will use following network terminologies in-terchangeably. From source to destination following network elements areinvolved and named as.

• NSLP network initiator (NI)

• NSLP network forwarder (NF)

• NSLP network responder (NR)

Identification of network initiator and responder tied to the used context.

5.3.2 NAT/FW message types

There are four messages involved in whole NAT/FW NSLP protocol opera-tion and which are shown below.

• CREATE

• RESERVE EXTERNAL

• RESPONSE

• NOTIFY

Here we only stress on the importance of CREATE and RESERVE ex-ternal messages while other messages are for the response of these messagesand for network notifications.

48


5.3.2.1 CREATE message

The CREATE message is the heart of all NAT/FW NSLP messages and isused to create NAT/FW NSLP signaling sessions. Furthermore, CREATEmessages are also used to refresh NAT/FW NSLP signaling sessions and todelete them [21].

A typical contain these objects.

• Signaling Session Lifetime object (Mandatory)

• Extended flow information object (Mandatory)

• Message sequence number object (Mandatory)

• Nonce object (Mandatory) if P flag set to 1 in the NSLP header, oth-erwise (0ptional)

• ICMP Types Objects (0ptional)

This complete message is placed in NSLP header ’message type’ which isshown below and then transfered to NTLP for forwarding.

Figure 5.3: NSLP Header

5.3.2.2 Signaling session with CREATE message

NAT/FW CREATE message can be used by peers to exchange data in thepresence of NAT. Firstly NI (data sender) generate a CREATE message anddelivers to NTLP towards NR (data receiver). This message is interceptedby any number of NAT/FW enabled NFs that are in the path who processthe message and doing a reservation till this message reaches the NR. Now ifNR accept the message a successful response send towards NI following samepath. Complete operation can be summarized in pictorial representation asfollows.

49


Figure 5.4: CREATE message flow

Here NF is NAT and it received CREATE message on private side whenthe initial CREATE message is received at the private side, the NAT bindingis allocated, but not activated. The NSLP message is forwarded towards theNR with source address set to the NATs external address from the newlyremembered binding.

But if, when the initial CREATE message is received at the public sideof the NAT, it looks for a reservation made in advance by using a EXTER-NAL message then after a CREATE message from data sender is allowed totraversed inside private domain.

5.3.2.3 RESERVE EXTERNAL message

CREATE message can satisfy the needs for NI and NR but what if NI is inpublic address space there is not way this message reachable to private host.NAT/FW introduces RESERVE EXTERNAL ADDRESS though which NRobtain globally reachable public IP/port pair prior to incoming signaling.

The RESERVE EXTERNAL message consists of following objects.

• Signaling Session Lifetime object (M)

• Message sequence number object (M)

• Extended flow information object (M)

50


• Data terminal information object (M)

• Nonce object (M) if P flag set to 1 in the NSLP header, otherwise (O)

• ICMP Types Object (O)

The point here is if the NR is located behind a NAT and is addressed by NIto the allocated IP address at the NAT. If NR made some earlier reservationthen only initial CREATE will be successful other this CREATE will end upat the receiver side NAT. So data receivers must have to reserver externalpublic IP and optionally port for successful reachability. This behavior canbe summarized as below.

Figure 5.5: EXTERNAL message flow

The key here is that NR RESERVE EXTERNAL MESSAGE must haveto reach any number of NF in its address realm so that the edge-NAT deviceclosest to the public realm responds to the EXTERNAL message with asuccessful RESPONSE message.

51


5.4 Implementation components

This section define the components which we have required during imple-mentation phase and for successful testing and evaluation.

Figure 5.6: Implementation components

NAT/FW NSLP is the key component for protocol functionality testingand evaluation.

General internet signaling transport (GIST) is the transport layer forcarrying NAT/FW NSLP messages.

P2P-TV simulator is used for measuring P2P chunk sharing overheads.

While other are the two testing clients which are the event generator forNAT/FW NSLP like CREATE,RESERVE EXTERNAL etc.

52


5.4.1 Protocol state operation

NAT/FW NSLP protocol transition states are shown in Figure 5.7. A par-ticular session is supposed to maintain any of these states either on networkinitiator, network forwarder or network responder.

Figure 5.7: Protocol transition states

A event such as CREATE or RESERVE EXTERNAL will result in trig-gering the protocol activity. Here we take CREATE message that will hookCREATE state on hold once a successful response received. Refresh timer isfor refreshing the state and keep the session alive, error responses or lifetimeparameter which if reaches to zero leads to state and session tear down.

5.5 Implementation

There were very few NSIS NAT/FW working implementations along withGIST that are available, however the one we have chosen is freely availableand with some corrections we make this workable for us. NSIS NAT/FW

53


suite is maintained under GPL by institute of telematics at the universittkarlsruhe (TH) [23]. The foremost reason to go for this implementation isthat, the standard signaling transport layer for NAT/FW NSLP is GISTwhich is outside the thesis scope but a requirement for performance evalu-ation and now we have realized its better we are able to utilize a completesuite and make it workable otherwise time constraint cannot permit us fortimely completion.

GIST which is the implementation of NSIS signaling transport layer pro-tocol (NTLP) for NAT/firewall NSLP is implemented in c++ using standardUNIX socket programming and also available at [23], P2P-TV simulator isalso in c++ and available at [44].

For interacting with NAT/FW and GIST, a client named ”Test Client”is used for triggering external events, for example CREATE , RESERVEEXTERNAL WITH or WITHOUT DESTINATION ADDRESS or TEAR-DOWN. This client is used as a test application which is NAT/FW NSLPcompliant and can be replaced afterwards with a user interactive applicationwhich can be the possible future work, e.g. x-lite or any P2P application.

Here is the complete implementation hierarchy of GIST along with NSLPs.

54


Figure 5.8: Implementation Architecture [23]

A network testbed which we discuss in next chapter is designed and test-ing done by command line test client against which connectivity is checked.From that client we can put CREATE and EXTERNAL etc messages towardstargeted destination and measure signaling session trip time as overhead. Forall testing and evaluation we focused on NAT operation against following.

a) For session connectivity which means complete traversing of messagesthrough all middle boxes till final destination and vice versa, we have a testClient which acts like a network initiator or responder for triggering eventsby CREATE and EXTERNAL messages. A typical CREATE structure inc++ is shown below and same is true to EXTERNAL.

tg create(const hostaddress &ds addr, const hostaddress &dr addr,uint16 ds port, uint16 dr port, uint8 protocol,uint32 session lifetime, bool proxy)

55


b) For throughput of the NI we have stress client which is also in c++ andwe have modified it to calculate the timing of sending number of CREATEmessages so we have an idea NI efficiency, we will discuss performance resultsin later chapter. A typical function for CREATE message for

*create message(hostaddress source addr, port t source port,hostaddress dest addr, port t dest port,const char *proto name)

A lot of effort is done of running the implementation on various virtualmachines (UML and VMWare) and some common errors which are worth tomention here are.

The were some ***glibc detected *** malloc() : memory corruption er-rors which we found that it was due to different malloc implementation inglib versions. Libc versions which are Linux libc (later than 5.4.23) and GNUlibc (2.x) include a malloc implementation which is tunable via environmentvariables. When MALLOC CHECK is set, a special (less efficient) imple-mentation is used which is designed to be tolerant against simple errors, suchas double calls of free() with the same argument, or overruns of a single byte(off-by-one bugs). Not all such errors can be protected against, however, andmemory leaks can result [42].

Different kernel modules are required to link with net-filter (IP-TABLES).We found that in Fedora 5, 7 and in Ubuntu 7 flavors its a must you loadIPv4/6 queue and filter modules.

What we think our contribution to this protocol suite will gradually setup some directions where our results and experience can be taken up forrapid practical activities with in this NSIS NAT/FW NSLP.

56

Chapter 6

Testing and performanceevaluation

In the above chapter we have discussed the protocol framework and NAT/FWNSLP implementation and now we presents our testing results together withperformance evaluation.

6.1 Network testbed

The network testbed which we have started our testing and evaluation phaseis shown in Figure 6.1 and the foremost reason to first keep it simple is of thefact that we have to explore the NAT/NSLP protocol functionality as there isno such related work in this domain. Then after from our initial observationson the protocol working we have moved up to test it with various complexscenarios in virtual machines.

Figure 6.1: Physical testbed

57

CHAPTER 6. TESTING AND PERFORMANCE EVALUATION

Figure 6.1 shows the testbed. All machines are running linux ubuntukernel 4.1.3 POSIX. Machine specifications are shown below and we havenoticed a prominent factor in results.

NF:

CPU: Intel(R) Pentium(R) 4 1700 MHzHard Disk: 40GBMemory: 512MB

NI:

CPU:Intel(R) Pentium(R) 1.6GHzHard Disk: 80 GBMemory: 1.5 GB

NR:

CPU: Intel (R) Pentium (R) M processor 1.73GHzHard Disk: 40 GBMemory: 512 MB

After the initial testing on the above discussed testbed, we then built net-work topologies in virtual machines instead of a running real testbed that re-quires reserving a number of machines from production which is difficult andis unrealistic. We have validated the functionally of the corrected protocolimplementation in both User Mode Linux (UML) and VMware workstation.

6.1.1 Virtual machines

6.1.1.1 User mode linux (UML)

User mode linux is a light weight virtual machine and lets you run linux insideitself. UML virtualises linux so that you can run a whole linux as the matterof running one program as a process [39]. UML provides you a way of runningparallel multiple virtual linux machines of different distributions each withdedicated configurable hardware and software resources. Disk storage forthe virtual machine is entirely contained inside a single file on your physicalmachine. One can assign its virtual machine only the hardware access youwant it to have [40]. We have used various file systems images of ubuntu,debain etc under linux ubuntu distribution.

58


6.1.1.2 VMware

VMware workstation is a virtual machine software suite for x86 systems fromVMware. This software suite allows users to set up multiple virtual comput-ers and to use one or more of these virtual machines simultaneously withthe hosting operating system. Each virtual machine instance can executeits own guest operating system, such as Windows, Linux, BSD variants, orothers [41]. Unlike user mode linux here windows XP is our host OS anddifferent linux flavors of ubuntu (xubuntu , kubuntu) etc are guest operatingsystems.

6.2 Conformance test cases

Following experimental topologies were tested under physical testbed and invirtual machines to fulfill conformance tests of the protocol, all the messagesduring testing are shown in appendix A.

Figure 6.2: Testbed with two NFs

Case a)

In this test an application entity at the data sender can be behind one ormore NATs (in our case its two). The receiver is at the public internet. Thetraffic from NI to NR has to traverse middle boxes only on the senders sideas the receiver has a public IP address. The NI sends its signaling messagedirectly to NR and NAT/FW enabled middle boxes along the path interceptthe signaling message and configure them accordingly. The data sender doesnot necessarily know whether the receiver is behind a NAT or not, hence, itis the receiving side that has to detect whether itself is behind a NAT or not[21].

59


Case b)

In the second variation the application entity at the data receiver is behindone or more NATs, simply we swap NI and NR in Figure 6.3. The successfulrequirement of the test needs that NSIS responder must discover its publiclyreachable IP address at the edge middle box (here outermost middle boxconnected to the public world) and reports the NSIS initiator of this address.One possibility is that an application level protocol is used, meaning that thepublic IP address is signaled via this protocol to the NI. Afterwards the NIcan start its signaling towards the NR and therefore establish the path viathe middle boxes in the receiver side private network [21].

Figure 6.3: Testbed with two NFs, NI and NR swapped

Case c)

In Figure 6.4, where NI and NR application entities each behind anynumber of NAT boxes, in our case its two. Here for the successful session NIhad to traverse all the middle boxes till NR. NI had to know the advancedpublic mapping for successful traversal. This NAT binding/mapping sub-sequently allows packets reaching the NAT to be forwarded to the receiverwithin the private address domain.

60


Figure 6.4: Testbed with two NFs at both NI and NR

Further to these test cases following scenarios are also applicable.

• Both end hosts behind twice-NATs.

• Both end hosts behind same NAT.

• Multi homed network with NAT.

• Multi homed network with firewall.

6.3 Test methods

Our testing have focused on measuring the signaling overhead and perfor-mance evaluation of the NAT/FW protocol and in doing so, we have mea-sured and studied below defined performance parameters.

6.3.0.3 Session round trip time

To calculate complete session round trip time, we have used GIST NTLPimplementation as we are interested to determine overall overhead includ-ing transport layer for having a complete picture. As there is no specificinteractive client application that have NAT/FW NSLP functionality andmost of the P2P-TV applications are proprietary, so we rely on non inter-active testing client NAT/FW NSLP compliant application for end to endconnectivity.

61


6.3.0.4 Throughput

Here we have measured the throughput of a testing client. We directly addedtime stamp in the client application and send thousands of packets to inspectthe processing time of these messages, here we have analyzed that whetherthe structure of the message like CREATE or RESERVE EXTERNAL issimplified enough to be processed.

6.3.0.5 Utilization

Another considerable agent that needs to be measured is the utilization ofCPU and memory taken by an application entities to process the NSLPmessages.

6.4 Tools

Netperf [43] is a testing suite that can be used to dimension the performanceof many different types of networking. It provides tests for throughput, end-to-end latency etc.

6.5 Test results

This section presents our testing results which forms the basis of conclu-sion and some part of future work have drawn. All tests are according tolatest NAT/FW draft [21] and have performed on testbed which we havediscussed in section [6.1]. Through experimental evaluation we have testedNSIS NAT/FW NSLP protocol for traversing NAT in the presence of middleboxes and have measured the defined performance metrics.

In the first experiment we have NI which is in public domain and tryingto reach NR which is NATed. As per [21] this test have to fail and it does,because there is no advance mapping. Then after we reserve external map-ping at NR end and get public IP/port info. Now we have reservation atNF. Then we again try to connect NR and at this time we succeed. All themessages during testing are shown in appendix A.

62


In the second experiment we have interchanged NI and NR positions,means NI now in private domain. NI originate a session towards NR andsuccessfully traversed NAT/FW. All the messages during testing are shownin appendix A.

In the third experiment we have both NI and NR in private domain, sinceNAT traversal solution does not need to ensure full mesh and this test casehas to pass. What we analyze here is that NR must first use REA message forreservation of flow mappings and then a proper CREATE from NI is allowedto traverse end to end.

Same scenarios have been repeatedly performed against multiple NAT/FWinstances in virtual machines for the purpose to examine the penetration rateof the protocol in complex environments. Table 6.1 shows the results for theconformance testing done for the test cases defined in section 6.2.

Case Test Description ResultA NI in private domain, NR on public side,

One NF in the path PassedB NR in private domain, NI on public side,

One NF in the path PassedC NI in private domain, NR on public side,

Two NF in the path PassedD NR in private domain, NI on public side,

Two NF in the path PassedE NR in private domain, NI on private side,

One NF in the path PassedF NR in private domain, NI on private side,

Two NF in the path Passed

Table 6.1: Conformance test results

Then after we push for testing with multiple parallel sessions, first wehave started with 1 session then gradually increases the number of sessionsto 5,10,50,100 and then average of 10,25,50 and 100 sessions. Figure 6.5shows the result.

63


Figure 6.5: Session round trip time for NAT/FW sessions

For calculating throughput, we sent thousands of CREATE messages andhave measured the throughput of sending these messages, result are shownin Figure 6.6. We have taken an average of 5 runs each.

64


Figure 6.6: Throughput for CREATE messages

With the help of Netperf we have calculated the CPU utilization forprocessing NSLP CREATE and REA messages as defined in section [5.3.2],results are shown in Figure 6.7.

65


Figure 6.7: CPU utilization for NSLP messages

We further have validated our results by one of the related work performedby [37] implementors of the protocol, however this is our assumption thatthese tests have included both NAT and firewall traversal. Displayed resultsare a part of NAT/FW signaling protocol overhead which is done all beforeactual data transmission.

66


Figure 6.8: Session trip time [37]

In section [5.4] and [6.5.1] where we have highlighted and defined theadapted methodology that forms the basis for P2P-TV simulations. Thenafter we have evaluated the contributing factor of NSIS NAT/FW in P2P-TVdevelopment and growth. Here we have first started of by creating a simplenetwork overlay of 7 peers including the source peer and 20 chunks were dif-fused from the source. All peers are of the same class LATEST RANDOMwhere each peer simply selects a random neighbor as target for the latestchunk. Peers overlay type is of GNR where each peer randomly selects acertain degree of neighbors e.g (1,2,3 etc). Complete network setup is shownin Figure 6.8 where as chunk arrival time, chunk delay time and peer distri-bution are shown in Table 6.2, Table 6.3 and Table 6.4 respectively. All timeunits are in second.

67


Figure 6.9: Peers overlay formation

Chunk arrival time and delay between peers are calculated as follows.

68


Chunk Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 Peer 60 0.00000 0.01830 inf 0.03659 0.23432 0.12631 0.418741 0.10000 0.13659 -1.00000 0.11830 0.34233 4.33874 0.603152 0.20000 0.23659 -1.00000 0.21830 4.12272 4.23073 4.383543 0.30000 0.31830 -1.00000 0.33659 4.01471 0.45034 4.199124 0.40000 0.43659 -1.00000 0.41830 0.55835 3.90670 0.787575 0.50000 0.53659 -1.00000 0.51830 0.66636 3.79869 0.971996 0.60000 0.63659 -1.00000 0.61830 3.69067 0.77437 3.951507 0.70000 0.73659 -1.00000 0.71830 3.58266 0.88238 3.767088 0.80000 0.81830 -1.00000 0.83659 0.99040 3.47465 1.174819 0.90001 0.91830 -1.00000 0.93659 1.09841 3.36664 1.3592310 1.00001 1.03659 -1.00000 1.01830 1.20642 3.25863 1.5436511 1.10001 1.11830 -1.00000 1.13660 3.15062 1.31443 3.3350412 1.20001 1.21830 -1.00000 1.23660 1.42244 3.04261 3.0189913 1.30001 1.31830 -1.00000 1.33660 1.53045 2.93460 1.7280714 1.40001 1.43660 -1.00000 1.41830 1.63846 2.82659 1.9124815 1.50001 1.53660 -1.00000 1.51830 2.61056 2.71857 2.8345716 1.60001 1.63660 -1.00000 1.61830 1.74647 2.50255 2.6501617 1.70001 1.71830 -1.00000 1.73660 1.85448 2.39454 2.0969018 1.80001 1.81830 -1.00000 1.83660 1.96250 2.28653 2.4657419 1.90001 1.93660 -1.00000 1.91830 2.07051 2.17852 2.28132

Table 6.2: Chunk arrival time between peers

69


Chunk Peer 0 Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 Peer 60 0.00000 0.01829 inf 0.03659 0.23432 0.12631 0.418731 0.00000 0.03659 -1.00000 0.01829 0.24233 4.23874 0.503152 0.00000 0.03659 -1.00000 0.01829 3.92272 4.03073 4.183543 0.00000 0.01829 -1.00000 0.03659 3.71471 0.15034 3.899124 0.00000 0.03659 -1.00000 0.01829 0.15835 3.50669 0.387575 0.00000 0.03659 -1.00000 0.01830 0.16636 3.29868 0.471996 0.00000 0.03659 -1.00000 0.01829 3.09067 0.17437 3.351507 0.00000 0.03659 -1.00000 0.01829 2.88266 0.18238 3.067088 0.00000 0.01829 -1.00000 0.03659 0.19039 2.67465 0.374819 0.00000 0.01829 -1.00000 0.03659 0.19840 2.46664 0.4592310 0.00000 0.03659 -1.00000 0.01830 0.20641 2.25862 0.5436411 0.00000 0.01829 -1.00000 0.03659 2.05061 0.21442 2.2350312 0.00000 0.01829 -1.00000 0.03659 0.22243 1.84260 1.8189913 0.00000 0.01829 -1.00000 0.03659 0.23044 1.63459 0.4280614 0.00000 0.03659 -1.00000 0.01830 0.23846 1.42658 0.5124815 0.00000 0.03659 -1.00000 0.01829 1.11056 1.21857 1.3345716 0.00000 0.03659 -1.00000 0.01829 0.14646 0.90254 1.0501517 0.00000 0.01830 -1.00000 0.03659 0.15448 0.69453 0.3968918 0.00000 0.01829 -1.00000 0.03659 0.16249 0.48652 0.6657319 0.00000 0.03659 -1.00000 0.01829 0.17050 0.27851 0.38131

Table 6.3: Chunk delay time between peers

Peer distribution is an overlay is shown as follows.

70


Source Peer Destination Peer0 10 31 01 41 52 63 04 14 65 16 26 4

Table 6.4: Peer distribution

Chunk delay time in the defined overlay of Figure 6.8 but with 11 peersand the probability of selecting 3 peers randomly for chunk sharing, resultsare shown in Table 6.5.

71


ChunkPeer 0Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 Peer 6 Peer 7 Peer 8 Peer 9 Peer 100 0.000 0.303800.054880.252360.018290.202710.315120.036590.346260.110500.163331 0.000 0.194920.054880.595320.07318inf 0.171770.018291.036580.390700.036592 0.000 0.187130.054880.562760.073180.268140.180210.036590.369230.509630.018303 0.000 0.370310.073180.179340.054880.188660.273230.036590.471400.554910.018294 0.000 1.281200.018290.171550.073180.283910.197100.054880.361010.267120.036595 0.000 0.163750.073180.428560.036590.205540.185360.018300.372490.647500.054886 0.000 0.373580.018300.504300.054880.213990.356290.073180.155960.299680.036597 0.000 0.374670.073180.148170.054880.222430.248790.018290.342690.240380.036598 0.000 0.679020.018290.508990.073180.230870.696770.036590.315460.602880.054889 0.000 0.376840.073180.602520.036590.132590.429410.018290.275760.224800.0548810 0.000 0.366430.018290.535840.054880.388030.139320.073180.629740.331230.0365911 0.000 0.277930.036590.789590.018300.117010.147760.073180.209210.999190.0548812 0.000 0.385360.018290.347000.036590.444920.156200.073180.201420.523630.0548813 0.000 0.280110.054880.396060.018290.164650.301710.036590.193630.517520.0731814 0.000 0.185840.054880.362780.073180.223310.173090.036590.404290.605300.0182915 0.000 0.178050.054880.776650.036590.199650.181530.073180.300740.961090.0183016 0.000 0.423220.054880.170260.073180.483120.189980.036590.262470.311410.0182917 0.000 0.623510.036590.483160.073180.710100.198420.018290.577060.278550.0548818 0.000 0.154670.036590.442150.018300.176280.206870.054880.277370.246880.0731819 0.000 0.316400.018290.331300.054880.215310.323750.073180.239090.294320.03659

Table 6.5: Chunk delay in an overlay with randomly selecting 3 peers

Same simulations have been repeated with network overlay type of FULLand TREE structures. In FULL structure every peer is connected to everyother peer of the network i.e. n − 1 where as TREE structure exhibitsparent child relationship among the peers. Table 6.6 and Table 6.7 showsthe delay values in the TREE and FULL overlay configurations, where aspeer formation in those configurations are displayed in Figure 6.9 and Figure6.10.

72


ChunkPeer 0Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 Peer 6 Peer 7 Peer 8 Peer 9 Peer 100 0.000 0.091470.036590.113080.054880.145030.211830.147090.018290.073180.277791 0.000 0.036590.155970.101400.079790.054880.091470.073180.058190.018290.288952 0.000 0.110500.296090.157060.018290.036590.109770.054890.073180.091470.266713 0.000 0.121960.301880.028060.304730.046360.082950.06465inf 0.158150.101244 0.000 0.148340.019540.037830.056130.127980.131720.074420.315620.111010.092725 0.000 0.084190.047600.102480.196380.127390.065890.320810.105790.156040.029316 0.000 0.093960.140160.020780.057370.039070.075660.115560.112250.190270.149587 0.000 0.204820.067140.267790.175580.103730.278960.048840.085430.264610.030558 0.000 0.205900.040310.184020.076900.022020.058610.299810.113490.095200.277549 0.000 0.160000.181600.086670.031790.050080.104960.274450.180560.068380.2069910 0.000 0.186590.078140.235090.059850.114730.023260.152200.041550.296470.0964411 0.000 0.237640.087910.196360.152410.051320.069620.106210.253500.033030.3219812 0.000 0.079380.097680.116710.024500.100990.206120.115970.042800.061090.2363313 0.000 0.201340.342250.107450.034270.218690.070860.126480.089150.289790.0525614 0.000 0.117210.138820.080620.062330.025740.126830.098920.248650.044040.1952315 0.000 0.108690.090390.308720.358020.151890.053800.035510.198840.072100.1302916 0.000 0.302340.026980.315720.201250.100160.081870.063570.045280.238810.2072817 0.000 0.055040.073340.128960.036750.091630.098250.018450.119850.109930.0766518 0.000 0.302040.193610.064810.101400.158700.083110.240050.046520.028220.2328419 0.000 0.219610.111170.185820.074580.129460.253770.037990.056290.019700.09288

Table 6.6: Chunk delay in FULL structure

73


Figure 6.10: Peer formation in Table 6.6

Figure 6.11: Peer formation in Table 6.7

74


ChunkPeer 0Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 Peer 6 Peer 7 Peer 8 Peer 9 Peer 100 0.000 0.018290.036590.083100.061500.104710.039900.145034.374360.176993.838781 0.000 0.036590.018290.058190.123000.079800.101400.153484.165910.170890.264782 0.000 0.018290.036590.109410.044600.066210.087810.161923.957473.544880.258673 0.000 0.018290.036590.104700.039900.083100.061500.170363.749020.252563.350994 0.000 0.018290.036590.083100.104710.039900.061503.540580.178813.063213.157105 0.000 0.018290.036590.039900.061500.104710.083103.332130.187250.146452.869326 0.000 0.018290.036590.039900.104710.083100.061503.123690.195700.140340.234247 0.000 0.018290.036590.083100.039900.061500.104700.204142.915250.228132.575428 0.000 0.018300.036590.039900.104710.083100.061502.706800.212582.381530.222029 0.000 0.018290.036590.039900.083100.061500.104700.221032.498360.215912.1876410 0.000 0.018290.036590.039900.083100.061500.104712.289910.229471.993740.2098011 0.000 0.018290.036590.061500.039900.083100.104701.973022.081461.799850.2036912 0.000 0.036590.018290.058190.101400.123000.079790.137911.764580.291470.1975813 0.000 0.036590.018290.123000.101400.058190.079791.556130.146361.505961.4120714 0.000 0.018290.036590.044600.066200.109410.087810.154801.347690.185371.2181815 0.000 0.018300.036590.039900.104700.061500.083100.163241.139241.024280.1792616 0.000 0.018300.036590.061500.083100.039900.104710.171690.930800.267040.1731517 0.000 0.018290.036590.104710.039900.061500.083100.180130.722350.730390.6365018 0.000 0.018290.036590.061500.039900.083100.104710.188570.513910.254820.1609319 0.000 0.018290.036590.061500.083100.039900.104700.305460.197020.248710.34261

Table 6.7: Chunk delay in TREE structure

75


6.6 Evaluation

6.6.1 Methodology

From the start to implementation and then to evaluation we adhere logicalseparation between signaling and data as shown in Figure 6.11. The foremostreason in doing so, is the analysis and evaluation of signaling overhead of theNSIS NAT/FW protocol prior to data distribution which is based on chunkscheduling algorithm and varies. Also this NAT check has to be performedonce or with the probability of peers that are behind NATs.

Figure 6.12: Evaluation methodology

6.6.2 Result evaluation

The results which we have obtained in section 6.4 are now analyzed andcompared with some of the related work. First we take session round triptime and once we have succeeded to traverse NAT/FW, we have increasedthe number of sessions. Figure 6.5 shows the session round trip time valuesand we have analyzed that session round trip time for 10 sessions rangingbetween 0 - 100 ms except one hype which we have excluded. Then after wehave increased the number of sessions to 25, 50 and 100, the resultant values

76


are shown in Figure 6.5. We have noticed that average delay for 100 sessionsranging from 0 - 200 ms and for 25 sessions delay shifting around 1̃73ms.

For measuring throughput for NSLP packets, we have calculated through-put for about 30000 NSLP CREATE packets. It is of the fact that a peerhave to perform a connectivity check only once, so for a medium overlay of10000 peers and from our result values throughput is still under a secondwhich is the value we have benchmarked during our evaluation.

CPU utilization for 1000 and 2000 NSLP messages is about 20 % whereas for increasing sessions it also increases linearly.

Refer to Figure 6.11 the methodology which we have adapted for our eval-uation criteria and from P2P-TV simulations we have tried to demonstratedirect chunk sharing delay in an environment where all node are intercon-nected and private address are not a problem. Refer to Table 6.4 wheresource 1 randomly selects peer 1 and 3 for chunk distribution and from Ta-ble 6.3 it forward chunk 0 at 0.0000 to peer 1 and 3. Peer 1 and Peer 3receive chunk 0 at 0.018300 & 0.03659 respectively. Similarly peer 1 forwardit to peer 4 and 5 at the particular time instances. For peer 4 and 5 thehigher delay values ranging between 3-4 seconds and peer 2 never receivesthe chunk. In Table 6.5 the delay vales are less than a second, since a peercan randomly select 3 peers for chunk sharing thus increases the probabilityof chunk source. Table 6.6 and Table 6.7 discuss delay values in an overlayof TREE and FULL structures and it can be seen in FULL overlay delay isless than a second as every peer is connected to each other peer where asTREE structure exhibits higher delay vales because of TREE structure.

In P2P-TV, peers are contributing flows to each other and it is also a factthat peers are not dedicated to stay in the networks all time, they can join orleave the network whenever they want and are prone to suffer failures. P2P-IPTV systems have to deal with the arrivals and departures of peers (churnof peer). It is a challenging issue because live video has to respect playbackinstant to get smooth playback quality. A high churn of peers will involveadditional delays or jitter variations for packet delivery, which will decreaseoverall video quality[29]. We now evaluate this churning rate of P2P-IPTVsystems and trying to find the average time one peer stays during an overlaynetwork means to prove the point, if a peer doing 1-5 seconds of signalingNAT/FW NSLP overhead and then after 1 minute leaves the system it willdefinitely not help out the cause.

77


Figure 6.13: P2P-TV average session lifetime[29]

We put NAT/FW NSLP signaling overhead threshold to 1 sec duringour testing and in [29] a similar study related to different P2P-IPTV averagesessions lifetime and are shown in Figure 6.12. Here you will see that averagesession lifetime for ppstream is 1222s where as for pplive is 393s, so from oursignaling overhead results values it can be deduced that NAT/FW signalingwill not cut down session lifetime and it will be acceptable. Also sessionlifetime heavily depends on the popularity of the channel and many relatedstudies shows that P2P-IPTV session are relatively higher than other P2Psystems.

Signaling overhead in which a peer will iteratively discover other peers andwould establish new signaling or video sessions incurred during P2P sessiondiscussed in [29] and shown below confirm that signaling overhead is less then15% of the total data traffic and if we take NAT/FW overhead in accountthis could not contribute the increase of signaling overhead dramatically.

From the architectural point of view this approach is well suited for P2Pparadigm although it was not designed by keeping peer to peer approach inmind and neither it adapts P2P rule.

NAT/FW is not a two entity protocol and can span over multiple admin-

78


Figure 6.14: Average signaling overhead in P2P-TV[29]

istrative domain. The operation of NAT/firewall NSLP usually spans overtwo administrative domains, one at the sender, another one at the receiverside. The path might traverse additional domains in the global space, butusually there are no NATs deployed. It can also reach with more than two ad-ministrative domains if cascaded NATs are controlled by different operators[26].

For P2P relationship there is an assumption that neighboring nodes areable to authenticate and authorize each other and to establish long termkeys between inside the administrative domain which is already there whereas for inter-domain, this authentication and authorization is problem sinceNAT/FW is closer to a configuration protocol so what if a signaling messagefrom a different domain and required to manipulate NAT/FW configurationat receiver side, so there has to be some trust relationship be be establishedlike service level agreements (SLA).

NAT/FW deployment in the near future is unlikely to happen becauseof forcible migration constraints of existing middle boxes, but for testingpurpose and experimentation there is a provision that the implementationcan be deployed with proxy modes in which not all NAT/FW nodes need tobe NAT/FW compliant.

Real time streaming as for IPTV, it is deduced that such applicationsare sensitive to delay, jitter, bandwidth constraints and require high level ofquality of service. Within next steps in signaling there is a QoS frameworkthat provide QoS signaling to applications that requires to reserve some spe-cial treatment for the particular flow similar to resource reservation protocol[36]. Standardization of such one or two protocols like NAT/FW and QoScan ultimately benefit real time applications for participating in an overlayand then pulling QoS for applications.

As stated above NSIS NAT/FW is still in its preliminary phase, thereare activities related to its standardization and by the time of writing this

79


thesis work its last draft [21] is valid. If NSIS NAT/FW is used conse-quently enough, it has to be integrated inside the applications or within acommon lower layer interface, such as operating systems socket API. Then,NAT/firewall NSLP could be used in conjunction with a session setup pro-tocol to configure all middle boxes along the data path [26].

6.7 Conclusion

In this chapter we have discussed NAT/FW NSLP testing results and per-formance evaluation. From the achieved results and comparisons we foundthat protocol signaling for traversing NATs and firewalls does not endangerany type of communication and by the virtue of unified nature it can be ap-plicable and suitable for both P2P and client/server architectures. Protocoladaption and migration of the existing middle boxes seems to be the mostchallenging part where as clients are required to upgrade their applicationstack and embed NAT/FW NSLP functionality.

80

Chapter 7

Conclusion and Future work

Network Address Translation (NAT) [1] was introduced as a mean to continuethe internet growth despite rapid depletion of IPv4 address space. P2Papplications suffer from NAT more than the traditional client/server model.The unavoidable presence of NAT in the internet for the foreseeable futureimpairs the proper development of P2P applications and business models. Intodays world most of the P2P applications do not explicitly deal with NATdevices or do so poorly. The increasing complexity of both protocols andnetwork topologies calls for a unified middle box signaling protocol [37] andsomething to be done on either of client side or middle box or on both.

There are different types of NATs and firewalls traversal mechanismswhich we have classified and discussed. We have seen in our analysis that allof these approaches have there own pros and cons and apart from solutionthey introduce other problems that are generally hard to solve.

The objective of this thesis work was to analyze different IETF NATtraversal mechanisms and to evaluate a solution that is technically strong,can work in most restrictive environments and from architectural point ofview is well suited for P2P especially IPTV.

Excerpt from section 6.4 and 6.5 where we have measured signaling andchunk delivery overhead. For signaling we have set the threshold of 1 secondand the resultant data set shows that on physical testbed the average wasabout 200 - 300 ms. Throughput for thousands of session CREATE messagesranging between 1 - 4 seconds. The CPU utilization time for these messagesvarying between 18 % - 43 %. Average signaling overhead for PPlive is

81

CHAPTER 7. CONCLUSION AND FUTURE WORK

4.1 % where as for TVAnts it was 19 %. Through performance evaluationand testing we got some hints on signaling overheads and it can be deducedhere protocol signaling does not poses threat for any type of communicationeither for client/server or P2P as chunk distribution depends on schedulingalgorithm and overlay structure as we have seen in our results.

NAT manipulation approach based on path-coupled NSIS NAT/firewallNSLP offers a powerful unified NAT traversal mechanism and can be the fu-turistic and promising solution recently under development in NSIS workinggroup. Due to protocol behavior and upgrade requirement on middle boxeswe will not likely to see NAT/FW NSLP deployment in mid term future andwe have to rely on approaches from implicit signaling where we consider ICEwill continue to provide partial NAT traversal until IPv6 fully deployed.

This thesis work shows that a path-coupled signaling protocol for NAT/FWtraversal is a sound proposal, which enables communication in all problemscenarios, even in scenarios where other protocol fails. One drawback whencompared with the other solutions is that both end hosts and middle boxesmust be modified to adapt this path-coupled protocol [37].

This work is performed according to the draft specification of NAT/FWNSLP [21]. Its our belief in future NSIS NAT/FW solution will be able toprovide unified and robust NAT traversal solution. Here we present some ofour suggestions for NAT/FW NSLP framework that can also be applicablefor this thesis as a future work.

• Due to the nature of the protocol we recommend there should be aseparate security framework for the protocol in terms of some draftdocument.

• Proposals for more effort towards standardization of the protocol draftinto RFC.

• Proposals for some efforts towards other standardization bodies like3gpp etc as NAT traversal is an open issue over there since traversingNATs brings additional complexity and constraints for mobile terminalsin terms of mobility [30].

• Integration of NAT/FW NSLP compatibility into some interactive clientapplications, P2P-TV client application are all propriety.

82

CHAPTER 7. CONCLUSION AND FUTURE WORK

• Migration of existing middle boxes for the induction of this new proto-col will be a challenge.

• More research and testing with other NAT implementations will besignificant.

83

Bibliography

[1] Egevang, K., and P. Francis, ”The IP Network Address Translator(NAT),” RFC 1631, May 1994.

[2] J. Rosenberg, J. Weinberger etc, ”STUN - Simple Traversal of User Data-gram Protocol (UDP) Through Network Address Translators (NAT’s) ”,RFC 3489, March 2003.

[3] J. Rosenberg, R. Mahy etc, ”Traversal Using Relays around NAT(TURN): Relay Extensions to Session Traversal Utilities for NAT(STUNdraft-ietf-behave-turn-12) ”, Internet Draft, November 2008.

[4] J. Rosenberg, ”Interactive Connectivity Establishment (ICE): A Proto-col for Network Address Translator (NAT) Traversal for Offer/AnswerProtocols draft-ietf-mmusic-ice-19”, Internet Draft, October 2007.

[5] UPnP Forum, http://www.upnp.org, last visited December 2008.

[6] J.Rosenberg, J.Weinberger, H.Schulzrinne, ”SIP Extensions for NATTraversal ”, Internet Draft, November 2001.

[7] P. Srisuresh, Kazeon Systems etc, ” State of Peer-to-Peer (P2P) Com-munication across Network Address Translators (NAT’s)”, Internet RFC5128, March 2008.

[8] Enterprise Communication, ”ELMEG Solution - Inte-gration into existing networks ”, http://www.funkwerk-ec.com/scripts/info cd/solutionsheets/en/83-Einbindung-in-vorhandene-LANs en.pdf, Last visited on December 2008.

[9] Daniel Eichhorn, ”A Peer-to-Peer Network Framework with NetworkAddress Translation Traversal”, http://www.csg.uzh.ch/theses/p2pnat ,Last visited on December 2008.

84

BIBLIOGRAPHY

[10] Yosuke ITOH and Yoshimi FUKUDA , ”A study on the applicability ofMIDCOM method and a solution to its topology discovery problem ” ,IEEE 2003

[11] Zhou Hu, ”NAT Traversal Techniques and Peer-to-Peer Applications ”,www.tml.tkk.fi/Publications/C/18/hu.pd , Last visited December 2008.

[12] Whai-En Chen, Ya-Lin Huang, and Han-Chieh Chao , ”NAT TraversingSolutions for SIP Applications” , Hindawi Publishing Corporation, March2008.

[13] Eye ball Any Firewall Technology, ” NAT Traversal for VoIPand Internet Communications using STUN, TURN and ICE ”,http://www.eyeball.com, Last visited December 2008.

[14] J. Rosenberg, et al, ” SIP: Session Initiation Protocol ”, IETF RFC3261,June, 2002.

[15] Ingate Systems, ” Solving the Firewall/NAT Traversal Issue of SIP:”,http://www.ingate.com/files/Solving Firewall-NAT Traversal.pdf, lastvisited December 2008.

[16] Ditech Networks, ” Practical Far-End NAT Traversal for VOIP ”, March2006.

[17] M. Stiemerling, H. Tschofenig, Nokia Siemens Networks, C. Aoun andE. Davies, ” NAT/Firewall NSIS Signaling Layer Protocol (NSLP) ”,Internet Draft, November 2008.

[18] M. Handley, V. Jacobson, C. Perkins, ” SDP: Session Description Pro-tocol ”, RFC 4566, July 2006

[19] H. Schulzrinne, GMD Fokus etc, ” A Transport Protocol for Real-TimeApplications ”, RFC 1889, January 1996.

[20] R. Hancock, G. Karagiannis etc, ” Next Steps in Signaling (NSIS):Framework ”, RFC 4080, June 2005.

[21] Martin Stiemerling etc, ” NAT/Firewall NSIS Signaling Layer Protocol(NSLP) ”, Internet Draft, November 3, 2008.

85

BIBLIOGRAPHY

[22] H. Schulzrinne etc, ” GIST: General Internet Signalling Transport ”,Internet Draft, November 3, 2008.

[23] NSIS Protocol suite implementation, Institute of Telematics at the Uni-versitt Karlsruhe (TH), last visited March 26.

[24] GNUPLOT Homepage http://www.gnuplot.info/, last visited on March27.

[25] Nikalas Steinleitner, ” Implementation and Performance Testing of theNAT/FW NSIS Signalling layer protocol ”, December 2005.

[26] Henning Peters, ”Analysis of NAT approaches and explicit signalling forNAT traversal” , April2006.

[27] D. Ciullo, M. Mellia, M. Meo, E. Leonardi, ”Understading P2P-TVsystems through on field measurements”, Feburary 2008.

[28] Xiaojun Hei, Yong Liuz and Keith W. Ross, ”IPTV over P2P StreamingNetworks the Mesh-pull Approach”, IEEE communication magazine, July2008.

[29] Thomas Silverston and Olivier Fourmaux, ”P2P IPTV Measurement: AComparison Study”, ACM , April 2007.

[30] Haresh Chandani, ”Client Network Address Translator Traversal in Ses-sion Initiation Protocol”, May 2006, www.tml.tkk.fi/ anttiyj/Chandani-sipnat.pdf

[31] LaTeX - A document preparation system, http://www.latex-project.org/, last visited November 29.

[32] GIMP 2.6 - GNU Image Manipulation Program, http://www.gimp.org/,last visited November 29.

[33] GNU plot homepage, http://www.gnuplot.info/, last visited November29.

[34] GSview, http://pages.cs.wisc.edu/ ghost/gsview/, last visited Novem-ber 29.

86

BIBLIOGRAPHY

[35] J.Manner, G.Karagiannis,A. McDonald, ”NSLP for Quality-of-ServiceSignaling”, Internet Draft, Febraury 2008.

[36] R. Braden, Ed, L. Zhang, S. Berson, S. Herzog, S. Jamin, ”ResourceReSerVation Protocol (RSVP) Version 1 Functional Specification”, In-ternet RFC, September 1997.

[37] Miquel Martin, Marcus Brunner, Martin Stiemerling, Ali Fessi, ” Path-coupled signaling for NAT/Firewall traversal”, IEEE 2005.

[38] Newport Networks, http://www.newport-networks.com/pages/session-border-controller.html, last visited November 29.

[39] User Mode Linux HOWTO,http://user-mode-linux.sourceforge.net/old/UserModeLinux-HOWTO-1.html#ss1.1,last visited November 29.

[40] The User-mode Linux Kernel Home Page, http://user-mode-linux.sourceforge.net/, last visited november 29.

[41] VMware Workstation, http://en.wikipedia.org/wiki/VMware Workstation,last visited November 29.

[42] Linux Questions, http://www.linuxquestions.org/questions/linux-general-1/why-malloccheck-628856/, last visited November 29.

[43] Welcome to netperf homepage, http://www.netperf.org/netperf/, lastvisited November 29.

[44] P2PTV Simulator, http://napa-wine.eu/cgi-bin/twiki/view/Public/P2PTVSim, last visited November 29.

87

Appendix A

Here we presents some common traces which we captured during testingphase.

A. Where NR behind NAT

a)

Figure 7.1: Reserve external message sent from NR

88

APPENDIX

b)

Figure 7.2: Port/IP reservation at NF

c)

Figure 7.3: Create message sent by NI

89

APPENDIX

B. Where NI in behind NAT

a)

Figure 7.4: Create message sent by NI

b)

Figure 7.5: Create message at NR

90

APPENDIX

c)

Figure 7.6: Response response at NI

91

performance evaluation of explicit signaling for nat...

Documents