Networking Basics for Telecom
Also some basic background about telecommunications
Peter Dordal, Loyola University CS Dept
Basics of packet switching
Simplest routing: every switch keeps every destination in a table
Fairness issue of packet max size. This is particularly important if
1500-byte large packets are intermixed with 80-byte voice packets. (RTP
voice packets are usually 160 data bytes.)
- This is an extreme form of datagram
- Does not scale beyond 105 hosts
Most switches work on a first-come-first-served basis. What fairness issue
does this introduce?
How does having a fixed bitrate
differ from having a designated bandwidth?
- This line has an 819.2 kbps rate
- This connection has a bandwidth of 102,400 bytes/sec, or 100 KB/sec
Two problems: fairness and queuing
delay / jitter.
PACKET "switching": users send individual bufferfuls, called PACKETS. Think
~1KB, although much smaller packets are also in common use. After one user
is done, someone else has an opportunity to send.
Consider packets: with 16 users all sharing a 1Mbps line (1 bit/microsec,
1Kb/ms), each gets 64Kbps if divided equally.
There is, in fact, no guarantee of equal division, though, with packet
switching. Ethernet does not guarantee this, IP does not guarantee this.
(Token Ring guarantees that each active sender gets an equal share of the number of packets sent, but this means
senders with smaller packets get to send less data. And besides, token ring
does not scale well.)
The whole point of packets is that you can send more if you have to:
packet-switched LANs support bursty transmission.
Furthermore, even if there were fairness, we have great irregularity at the
small scale. If soneone sends a
1.25KB (10Kb) packet, the line is tied up for 10 ms. Someone expecting
64Kbps would pile up 640 bits in that time. Yes, they can be queued, but
they will certainly arrive late.
Some delay is inevitable. But telephony users would like to see consistent
delay, not random delay whenever some other user sends off a big packet we
have to wait for.
Intro to TCP/IP
- What exactly is a protocol?
- Datagram routing
- IP routing in particular
- TCP/IP layers: how do these correspond to telephony?
Packets as a form of multiplexing
IP routing & addressing
- sequence numbers
- port numbers
Abstract TCP responsibilities:
- lost-packet recovery
- end-to-end channel
- throughput optimization (sliding windows)
- congestion management
TCP is stateful. So are voice calls! What are some of the
Why is TCP bad for real-time traffic?
TCP protocol: finite-state machine.
TCP recognizes a number of states, eg
There are specific rules as to how TCP responds to each possible packet, in
each possible state.
Firewalls & NAT
Problems with UDP
3-7 layer models
layering as software engineering
ARP, video/audio system, etc
TCP/IP 4-5 layer model
OSI 7-layer model: problems with presentation & session layer
QUESTION: is it necessary to separate the Internetwork (packet-delivery)
layer from the transport layer?
Is it a good idea?
Is an Internetwork layer needed for telephony?
Clearly, there are cases where commingling the LAN and IP layers makes
sense:if there is no need to accomodate different low-level LAN protocols.
If you are building closed systems (eg if you are The Phone Company), that
Fig 2.3, p 39 (9th edition)
What layer is ATM?
ITU v IETF standardization
ITU: Members are governments!
ISO: members include large corporations; standards are expensive!
IETF: Standards are free
2.1: protocols cover such things as:
- ordered delivery
- flow control
- error control/correction
From Peterson & Davie, Computer Networks, Chapter 9:
The characteristics of many multimedia
applications are such that, rather than try to squeeze too many calls into
a too-narrow pipe, it would be better to “block” one call while allowing
another to proceed. That is, better to have one person carrying on a
conversation successfully while another hears a busy signal, than to have
both callers experiencing unacceptable audio quality at the same time. We
sometimes refer to such applications as having a “steep utility curve”,
meaning that the utility (usefulness) of the application drops rapidly as
the quality of service provided by the network degrades. Multimedia
applications often have this property, whereas many traditional
applications do not. Email, for example, continues to work quite well even
if delays run into the hours.
This is another big difference between data networking and telecom.
(Files here are in my directory asterisk/pcaps, and are not
Let's look at a tcpdump trace of a phone call using wireshark: cisphone.pcap
Now look at a tcpdump trace of a call from the perspective of ulam2: flowtrace_outbound.pcap.
This call is from my Asterisk/Flowroute phone to my Loyola office phone.
- generated with tcpdump -v -s 0 -i
eth0 host cisphone
- packets 3 & 4 are an ARP update
- phone call starts at packet 5, time 9.545, with SIP/SDP INVITE
- RTP stream starts with packet 15.
- Encoding is G.711 (µ-law, 8 bits every 1/8000 sec)
- Packets have 160-byte payload (214-byte total), and are sent every 20
- Check port numbers
Where is the handoff to 184.108.40.206 made? The first packet involving
220.127.116.11 is #26, from the asterisk server.
- generated with tcpdump -v -s 0 -i
eth0 udp and \(port 5060 or udp[8:2] = 0x8000 \)
- the IP address 18.104.22.168 is part of flowroute.com, in Las Vegas
- the IP address 22.214.171.124 is part of Excel Telecommunications
(excel.com) in TX
In packet 20, the first SIP/SDP packet from flowroute to ulam2 (the asterisk
server), in SDP=>Connection Information=>connection address, the
address 126.96.36.199 appears. In this packet, flowroute is declaring to
ulam2 that the actual RTP endpoint for flowroute's end of the call is at
Packet 7 contains the connection address provided by the cisco phone at our
end: 10.213.119.31. This is a private address, hidden behind a NAT firewall.
Ulam2 figures this out, so packet 12, from ulam2 to flowroute, lists the
connection address as 188.8.131.52.
Why do you think flowroute routed the call through Texas? Flowroute's server
is in Nevada, but my Asterisk server is in Chicago and the destination phone
is in Chicago. Data has to travel from Chicago to Texas via the Internet,
and then back from Texas to Chicago via the PSTN. If the goal is to make the
PSTN portion of every call a local call, this did not happen.
SMTP and HTTP
These are two straightforward protocols in widespread use: the Simple Mail
Transport Protocol governs how email is sent to a server (possibly for
forwarding), and the HyperText Transport Protocol allows clients to request
URL-labeled content on web servers. Both are TCP protocols; an SMTP server
generally listens at port 25 and an HTTP server at port 80. Both protocols
are also ASCII-based, meaning that we can interact manually with the server.
Ultimately, though, SMTP is used to send data to
the server, while HTTP is used to fetch data from
Telnet to port 25. In the following, what I type is in bold,
and responses from telnet and not
from the SMTP server are in italic.
telnet ulam2 25
Connected to ulam2.
Escape character is '^]'.
220 ulam2.cs.luc.edu ESMTP Postfix
250-AUTH LOGIN PLAIN
mail from: pld
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
here is some text
250 2.0.0 Ok: queued as EEDC5186BF
221 2.0.0 Bye
Connection closed by foreign host.
Note that desipte the line tagged with 354, the mail server allowed me to
terminate my message by sending a line consisting of a single "." (that is,
Note also that there are several messages I sent: EHLO, MAIL FROM, RCPT, and
then the message itself. The curent (as of the 1980's) version of SMPT
supports "pipelining": sending these all on one line, provided I indicate
this by starting with EHLO instead of HELO.
SMTP doesn't need timeouts for data retransmission, because TCP builds that
in. However, timeouts for coping with sluggish servers (or disappearing
clients) are not uncommon; if the whole process doesn't complete within an
application-defined (but not protocol-defined) time limit then it may be
canceled. The server, in particular, does not want a large number of
"dangling" client connections around.
There's an interesting anti-spam measure based on timeouts, which is one of
the measures used by Loyola's anti-spam systems: the server deliberately
forces the client to wait. The theory is that spambots will give up rapidly,
but real mail servers will be willing to wait.
Manual HTTP queries
Note that http is generally viewed as rather more interactive than SMTP: if
you're downloading a page, you want to see the content now,
or else be told that it's unavailable. By contrast, most SMTP agents notify
you if failures last more than four hours, and don't give up for more than
Begin with "telnet xenon 80", and then type the GET line, the HOST line, and
a blank line.
GET /index.html HTTP/1.1
Apache startup page
HTTP/1.1 200 OK
Date: Tue, 18 Mar 2008 19:47:59 GMT
Last-Modified: Wed, 01 Mar 2006 01:04:31 GMT
Content-Type: text/html; charset=ISO-8859-1
<!DOCTYPE html PUBLIC "-//Wl3C//DTD XHTML 1.1//EN"
Page for Apache Installation</title>
<p>If you can
see this, it means that the installation of the
software on this
system was successful. You may now add content to this
replace this page.</p>
GET /foobar.html HTTP/1.1
--> returns 404
OPTIONS * HTTP/1.1
--> HTTP/1.1 200 OK
Date: Tue, 18 Mar 2008 19:49:39 GMT
Server: Apache/2.2.2 (Unix)
Note codes (200, 404, etc), matching "response", and the body
7 layers. In OSI, transport and network are relatively independent; TCP and
IP interact more.
OSI has 5 transport flavors; TCP/IP has 2 (TCP and UDP) (some say
TCP/IP needs more).
- byte orientation,
- other data format issues
- compression (probably really needs to be application-specific)
Session: connection bookkeeping, BILLING,
- connection-establishment part of transport
- interruption capability
- full-duplex v one-way
- grouping of data
Routers using datagram forwarding each have ⟨destination, next_hop⟩ tables.
The router looks up the destination of each packet in the table, finds the
corresponding next_hop, and sends it on to the appropriate directly
These tables are often "sparse"; some fast
lookup algorithm (eg hashing) is necessary. The IP "longest-match" rule
complicates this. For IP routing, destinations represent the network
portion of the address.
drawback: cost proportional to # of nodes
How these tables are initialized and maintained can be complicated, but
the simplest strategies involve discovering routes from neighbors. Often a
third column, for route cost, is added.
first look at virtual circuit goals:
Packet size figure, below. Up to a point, smaller packets have better
- small cells
- small header
- low per-packet cost
- still packet-switched!
Uniformity of delay (ie jitter) is a separate issue, but is often
worse with datagram switching
TDM links (SONET and DS) might in some sense be considered "virtual" as
circuits. But in practice they are considered to be genuine circuits; the
term "virtual circuit" is reserved for a specific kind of packet-forwarding
Virtual Circuits are a packet-forwarding mechanism that requires connection
setup; it is the primary alternative to datagram forwarding. The
connection-setup phase resembles the trunk-reservation problem of
circuit-switched calls. In a sense, "virtual circuit switching" means using
packets to simulate circuits.
Note that there is a big difference between circuit-switched T-carrier/SONET
and any form of packet-based switching: packets are subject to fill
time. That is, a 1000KB packet takes 125 ms to fill, at 64 Kbps,
and the voice "turnaround time" is twice that. 250 ms is annoyingly large.
When we looked at the SIP phone, we saw RTP packets with 160 B of data,
corresponding to a fill time of 20 ms. ATM (Asynchronous Transfer Mode) uses
48-byte packets, with a fill time of 6 ms.
When you lease a data connection from your telco, you might lease a virtual
circuit, which might be ATM or might be Frame Relay (older and with
larger packets). With either strategy, your IP packets would ride on top of
the virtual-circuit carrier packets. Alternatively, you might lease a bit stream, eg a DS-1 or DS-3 line or a
SONET virtual tributary.
With virtual circuits, the route between two endpoints must
be set up in advance, and is encoded by switch state.
Each switch has a table of the form ⟨vciin, portin,
vci+port are treated as a contiguous string of bits, small enough to use as
an array index, which is very fast!
Entries are typically duplicated, so given the vci+portin
we can look up vci+portout, and given vci+portout we
can find vci+portin.
This allows bidirectionality.
All this allows very compact lookup tables, generally faster on a per-packet
basis than datagram forwarding but requires setup.
smaller addresses / smaller headers
Addresses identify the PATH, not the DESTINATION
PATH address is VCI, which is not globally
unique!! VCIs are local, leading to fewer bits
What are virtual circuits good for?
=> still efficient even when packets are small! (And voice packets almost
always are small, to avoid "fill time")
- fast routing
- low per-packet overhead
- addresses are small!
Also, can be BIDIRECTIONAL
Remarks about datagram-forwarding table maintenance
continue with VC example
- assignment of link addresses
- next-hop basis for connection setup
- single-point-of-failure vulnerabilities
- supports billing
Note that with virtual-circuit routing, the header size might be very much
reduced. ATM headers are 5 bytes; IP headers are 20 bytes. Size is reduced
- VCIs are local, and hence need fewer bits
- There is no source address
- Usually there is no need to support fragmentation; packets are already