Networking Basics for Telecom

Also some basic background about telecommunications

Peter Dordal, Loyola University CS Dept

Basics of packet switching

packets
addressing
routing/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.)

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?  Eg:

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.
 
If.
 
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


see intronetworks.cs.luc.edu, chapter 1

Topology

Routing loops

Congestion

Packets as a form of multiplexing

Ethernet
Switched Ethernet
unicast/broadcast/multicast


IP
IP routing & addressing
IP quality-of-service
ARP (briefly)

Transport:
    UDP
    TCP

Abstract TCP responsibilities:


TCP is stateful. So are voice calls! What are some of the differences?

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
    protocol graphs: 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 might happen.

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: 

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.

 

UDP

(Files here are in my directory asterisk/pcaps, and are not public.)

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.
Where is the handoff to 64.194.139.61 made? The first packet involving 64.194.139.61 is #26, from the asterisk server.

In packet 20, the first SIP/SDP packet from flowroute to ulam2 (the asterisk server), in SDP=>Connection Information=>connection address, the address 64.194.139.61 appears. In this packet, flowroute is declaring to ulam2 that the actual RTP endpoint for flowroute's end of the call is at 64.194.139.61.

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 147.126.65.47.

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 the server.

Manual SMTP


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
Trying 147.126.65.47...
Connected to ulam2.
Escape character is '^]'.
220 ulam2.cs.luc.edu ESMTP Postfix
    EHLO valhal
250-ulam2.cs.luc.edu
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
    mail from: pld
250 2.1.0 Ok
    rcpt to:pld@cs.luc.edu
250 2.1.5 Ok
    data
354 End data with <CR><LF>.<CR><LF>
subject:demo
here is some text
dot line
.
250 2.0.0 Ok: queued as EEDC5186BF
    quit
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, ".<cr><lf>")l

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 24 hours.

Begin with "telnet xenon 80", and then type the GET line, the HOST line, and a blank line.

GET /index.html HTTP/1.1
HOST: xenon.cs.luc.edu
(blank line)
            --> returns Apache startup page
    HTTP/1.1 200 OK
    Date: Tue, 18 Mar 2008 19:47:59 GMT
    Server: Apache
    Last-Modified: Wed, 01 Mar 2006 01:04:31 GMT
    ETag: "2f3e2a-5a3-86bbc5c0"
    Accept-Ranges: bytes
    Content-Length: 1443
    Content-Type: text/html; charset=ISO-8859-1

    <!DOCTYPE html PUBLIC "-//Wl3C//DTD XHTML 1.1//EN"
            "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
        <head>
            <title>Test Page for Apache Installation</title>
        </head>

        <body>
            <p>If you can see this, it means that the installation of the
            <a href="http://www.apache.org/foundation/preFAQ.html">Apache web server</a>
            software on this system was successful. You may now add content to this
            directory and replace this page.</p>
        ....l
       
           
GET /foobar.html HTTP/1.1
HOST: xenon.cs.luc.edu
(blank)
            --> returns 404

   
OPTIONS * HTTP/1.1
HOST: xenon.cs.luc.edu
(blank)
-->    HTTP/1.1 200 OK
    Date: Tue, 18 Mar 2008 19:49:39 GMT
    Server: Apache/2.2.2 (Unix)
    Allow: GET,HEAD,POST,OPTIONS,TRACE
    Content-Length: 0
    Content-Type: text/plain
   
Note codes (200, 404, etc), matching "response", and the body


OSI

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).
Presentation: 
 
Session: connection bookkeeping, BILLING, 
 

Datagram Forwarding

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 connected neighbor.

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.

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.

drawback: cost proportional to # of nodes
first look at virtual circuit goals:
Packet size figure, below. Up to a point, smaller packets have better throughput!

packet size
Uniformity of delay (ie jitter) is a separate issue, but is often worse with datagram switching

Virtual Circuits

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 mechanism.

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, vciout, portout⟩
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")

Also, can be BIDIRECTIONAL

Remarks about datagram-forwarding table maintenance

continue with VC example
Example: http://intronetworks.cs.luc.edu/current/html/otherLANs.html#virtual-circuits

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 because: