1. Part 1: Common network/protocol functions
Goals:
identify, study common architectural components, protocol mechanisms
synthesis: big picture
depth: important topics not covered in intro course
Overview:
signaling: telephone net, Internet, ATM net
protocols
hard state versus soft state
randomization
indirection
service location
network virtualization: overlays
Part 1

2. Common but already covered…
error control
ARQ (ACK,NAK), FEC, hybrid
checksum, CRC
flow control
congestion control
Routing
Timers
Concerns: fairness, stability
Naming and addressing
others?
Part 1

3. Signaling
signaling: exchange of messages among network entities to enable (provide service) to connection/call
before, during, after connection/call
call setup and teardown
call maintenance
measurement, billing
between:
end-user <-> network
end-user <-> end-user
network element <-> network element
Part 1

4. Telephone network: services
point-to-point POTS calls
special telephone numbers:
800 (888) number service: free call to customer
900 number service: bill caller
numbers for life
caller ID
calling card/third part charging
call routing (to end user): prespecified, by time-of-day
“follow me” service
incoming/outgoing call restrictions
support for cellular roaming: “home” number routed to current cell location
Part 1

5. Telephone network: AIN
AIN: Advanced Intelligent (phone) Network: migration from service-in-the-switch to service logic external to (on top of) switching systems
looks like Internet philosophy:
e.g., DNS is at application layer; RIP,OSPF, BGP above IP)
AIN advantages:
introduce new services rapidly
open interfaces: vendor customization, vendor independence of services
Part 1

6. Telephone network: circuit-switched voice trunks (data plane)
subscriber access lines
(twisted pair)
voice “trunk” lines
(carrying multiple calls)
Part 1

7. Telephone network: data and control planes
Part 1

8. SS7: telephone signaling network
Part 1

9. Signaling System 7: telephone network signaling
out-of-band signaling: telephony signaling carried over separate network from telephone calls (data)
allows for signaling between any switches (not just directly-connected )
allows for signaling during call (not just before/after)
allows for higher-than-voice-data-rate signaling
security: in-band tone signaling helps phone phreaks; out of band signaling more secure
SS7 network: packet-switched
calls themselves circuit-switched
lots of redundancy (for reliability) in signaling network links, elements
Part 1

10. Signaling System 7: telephone network
signaling between telephone network elements:
signaling transfer point (STP):
packet-switches of SS7 network
send/receive/route signaling messages
signaling control point (SCP):
“services” go here
e.g., database function
signaling switching point (SSP):
attach directly to end user
endpoints of SS7 network
Part 1

11. Example: signaling a POTS call
4. STP X forwards IAM SSP B
3. STP W forwards IAM to STP X
2. SSP A formulates Initial Address Message (IAM), forwards to STP W W Y
1. caller goes offhook, dials callee. SSP A determines to route call via SSP B. Assigns idle trunk A-B X A B
Part 1

12. Example: signaling a POTS call
5. B determines it serves callee, creates address completion message (ACM[A,B,trunk]), rings callee phone, sends ringing sound on trunk to A
6. AC???M routed to Z to Y to A
7. SSP A receives ACM, connects subscriber line to allocated A-B trunk (caller hears ringing) W Z Y X A B
Part 1

13. Example: signaling a POTS call
8. Callee goes off hook, B creates, sends answer message to A (ANM[A,B,trunk])
9. ANM routed to A W Z
10. SSP A receives ANM, checks caller is connected in both directions to trunk. Call is connected! Y X A B
Part 1

14. Example: signaling a 800 ca11
800 number: logical phone number
translation to physical phone number needed, e.g., CALL_ATT translates to
3. M performs lookup, sends reply to A M
2. STP W forwards request to M W
1. Caller dials 800 number, A recognizes 800 number, formulates translation query, send to STP W Y A A B
Part 1

15. Example: signaling a 800 ca11
800 number: logical phone number
translation to physical phone number needed M W Z
1. A begins signaling to set up call to number associated with 800 number X A A B
Part 1

16. Example: SS7 protocol stack
ISDN end-user signaling
TCAP: application layer protocols: 800 service, calling card, call return, cellular roaming
SCCP: demultiplexing to multiple upper layer applications
SS7-specific network, link, physical layer protocols
move to IP (RFC 2719)?
Part 1

17. Signaling: discussion
800 logical-number-to-physical number translations: looks like DNS
Q: Differences:
in DNS end system generates request; dns is transparent to IP network- network layer in phone net does 800-service location translation for you [phone net has more “smarts in net]
DNS is more decentralized: hierarchical
anyone can run a names server, but not a 800 server
Q: where is state stored?
in POTS call: SSP stores circuit allocation, start/stop time
in 800 call: STPs know where to go for 800 service; in Internet, DNS location transparent to IP routers (knowledge of where to go to DNS service is in end-systems, not in router – intelligence at the edge)
Q: Internet versus SS7/telephone network for accessing services
Part 1

18. Asynchronous Transfer Mode: ATM
1990’s/00 standard for high-speed (155Mbps to 622 Mbps and higher) Broadband Integrated Service Digital Network architecture
Goal: integrated, end-end transport to carry voice, video, data
meeting timing/QoS requirements of voice, video (versus Internet best-effort model)
“next generation” telephony: technical roots in telephone world
packet-switching (fixed length packets, called “cells”) using virtual circuits
Part 1

19. ATM networks
Part 1

20. ATM Layer: Virtual Channels
VC transport: cells carried on VC from source to dest
call setup, teardown for each call before data can flow
each packet carries VC identifier (not destination ID)
every switch on source-dest path maintain “state” for each passing connection
link, switch resources (bandwidth, buffers) may be allocated to VC: to get circuit-like perf.
Permanent VCs (PVCs)
long lasting connections
e.g., “permanent” route between two IP routers
Switched VCs (SVC):
dynamically set up on per-call basis
Part 1

21. ATM Signaling: Q.2931 PNNI (private network- network interface) UNI
(user-network
interface)
NNI
(network-
network
interface)
UNI
(user-network
interface)
Part 1

22. ATM Q.2931 Call Setup Signaling
VCI=5; VPI=0 used
as signaling channel
user
user
UNI
UNI
ATM
network
setup
call reference
addresses
traffic spec
QoS
setup
call reference
addresses
traffic spec
QoS
VPI/VCI
call
proc
call reference
VPI/VCI
call
proc
connect
connect
conn
ack
conn
ack
user-user data
Part 1

23. ATM Q.2931 Call Release Signaling
user
user
UNI
UNI
ATM
network
user-user data
call reference
cause
release
call reference
cause
call reference
cause
release
complete
release
release
complete
Part 1

24. ATM UNI Connection control messages
SETUP: initiate call estab
CALL PROCEEDING: call estab begun
CONNECT: call accepted
CONNECT ACK: call accept ACK
RELEASE: initiate call clearing
RELEASE COMPLETE: call cleared
STATUS ENQUIRY: req. status
STATUS: requested status info
RESTART: restart all VC’s
RESTART ACK: ACK RESTART
ADD PARTY: add party to existing connection
ADD PARTY ACK: ACK of ADD PARTY
ADD PARTY REJECT: REJECT of ADD PARTY
DROP PARTY: drop party from existing connection
DROP PARTY ACK: ACK of DROP PARTY
Part 1

25. ATM Q.2931 Call Setup: Timers
timers used to recover from problems
10 timers at user side, 10 times at network side
ATM
network
start T303
setup
call
proc
setup
start T303
stop T303
call
proc
start T310
stop T303
start T310
connect
start T313
connect
conn
ack
stop T310
stop T310
stop T313
conn
ack
Part 1

26. PNNI Signaling: PNNI user user UNI UNI setup setup call setup proc
“..at a specific link, one switching system plays the role of the user side, and the other plays the role of the network side, as defined in the UNI 3.1 Specification.” ATM Forum af-pnni
PNNI
user
user
UNI
UNI
setup
setup
call
proc
setup
call
proc
call
proc
connect
connect
connect
conn
ack
conn
ack
conn
ack
user-user data
Part 1

27. Signaling in the Internet
no network signaling protocols
in initial IP design
connectionless (stateless) forwarding by IP routers
best effort service + =
New requirement: reserve resources along end-to-end path (end system, routers) for QoS for multimedia applications
RSVP: Resource Reservation Protocol [RFC 2205]
“ … allow users to communicate requirements to network in robust and efficient way.” i.e., signaling !
earlier Internet Signaling protocol: ST-II [RFC 1819]
Part 1

28. RSVP Design Goals
accommodate heterogeneous receivers (different bandwidth along paths)
accommodate different applications with different resource requirements
make multicast a first class service, with adaptation to multicast group membership
leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes
control protocol overhead to grow (at worst) linear in # receivers
modular design for heterogeneous underlying technologies
Part 1

29. RSVP: does not… specify how resources are to be reserved
rather: a mechanism for communicating needs
determine routes packets will take
that’s the job of routing protocols
signaling decoupled from routing
interact with forwarding of packets
separation of control (signaling) and data (forwarding) planes
Part 1

30. RSVP: overview of operation
senders, receiver join a multicast group
done outside of RSVP
senders need not join group
sender-to-network signaling
path message: make sender presence known to routers
path teardown: delete sender’s path state from routers
receiver-to-network signaling
reservation message: reserve resources from sender(s) to receiver
reservation teardown: remove receiver reservations
network-to-end-system signaling
path error
reservation error
Part 1

31. Path msgs: RSVP sender-to-network signaling
path message contents:
address: unicast destination, or multicast group
flowspec: bandwidth requirements spec.
filter flag: if yes, record identities of upstream senders (to allow packets filtering by source)
previous hop: upstream router/host ID
refresh time: time until this info times out
path message: communicates sender info, and reverse-path-to-sender routing info
later upstream forwarding of receiver reservations
Part 1

32. RSVP: simple audio conference
H1, H2, H3, H4, H5 both senders and receivers
multicast group m1
no filtering: packets from any sender forwarded
audio rate: b
only one multicast routing tree possible H3 H2 R1 R2 R3 H4 H1 H5
Part 1

33. RSVP: building up path state
H1, …, H5 all send path messages on m1:
(address=m1, Tspec=b, filter-spec=no-filter,refresh=100)
Suppose H1 sends first path message in
out L1 L2 L6 in
out L3 L7 L4
m1:
m1: in
out L5 L7 L6
m1: H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5
Part 1

34. RSVP: building up path state
next, H5 sends path message, creating more state in routers in
out L1 L2 L6 L6 in
out L3 L7 L4
m1:
m1: L1 in
out L5 L5 L7 L6
m1: L6 H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5
Part 1

35. RSVP: building up path state
H2, H3, H5 send path msgs, completing path state tables in
out L1 L2 L6 L2 L6 in
out L3 L7 L4 L3 L4
m1:
m1: L1 L7 in
out L5 L5 L7 L6 L7
m1: L6 H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5
Part 1

36. reservation msgs: receiver-to-network signaling
reservation message contents:
desired bandwidth:
filter type:
no filter: any packets address to multicast group can use reservation
fixed filter: only packets from specific set of senders can use reservation
dynamic filter: set of senders that can use reservation changes over time
filter spec
reservations flow upstream from receiver-to-senders, reserving resources, creating additional, receiver-related state at routers
Part 1

37. RSVP: receiver reservation example 1
H1 wants to receive audio from all other senders
H1 reservation msg flows uptree to sources
H1 only reserves enough bandwidth for 1 audio stream
reservation is of type “no filter” – any sender can use reserved bandwidth H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5
Part 1

38. RSVP: receiver reservation example 1
H1 reservation msgs flows uptree to sources
routers, hosts reserve bandwidth b needed on downstream links towards H1 L6 in
out L3 L4 L7 in
out L1 L2
m1:
m1: L1
(b) L2 L6 L3 L4 L7
(b) in
out L5 L6 L7
m1: L5 L6
(b) L7 H2 H3 b b L3 L2 b b b R1 L6 L7 b R2 R3 L4 b H4 L1 L5 H1 H5
Part 1

39. RSVP: receiver reservation example 1 (more)
next, H2 makes no-filter reservation for bandwidth b
H2 forwards to R1, R1 forwards to H1 and R2 (?)
R2 takes no action, since b already reserved on L6 L6 in
out L3 L4 L7 in
out L1 L2
m1:
m1: L1
(b) L2
(b) L6 L3 L4 L7
(b) in
out L5 L6 L7
m1: L5 L6
(b) L7 H2 H3 b b b L3 L2 b b b R1 L6 L7 b R2 R3 L4 b b H4 L1 L5 H1 H5
Part 1

40. RSVP: receiver reservation: issues
What if multiple senders (e.g., H3, H4, H5) over link (e.g., L6)?
arbitrary interleaving of packets
L6 flow policed by leaky bucket: if H3+H4+H5 sending rate exceeds b, packet loss will occur L6 in
out L3 L4 L7 in
out L1 L2
m1:
m1: L1
(b) L2
(b) L6 L3 L4 L7
(b) in
out L5 L6 L7
m1: L5 L6
(b) L7 H2 H3 b b b L3 L2 b b b R1 L6 L7 b R2 R3 L4 b b H4 L1 L5 H1 H5
Part 1

41. RSVP: example 2 H1, H4 are only senders
send path messages as before, indicating filtered reservation
Routers store upstream senders for each upstream link
H2 will want to receive from H4 (only) H2 H2 H3 H3 L3 L3 L2 L2 R1 L6 L7 R2 R3 L4 H4 L1 H1
Part 1

42. RSVP: example 2 H1, H4 are only senders
send path messages as before, indicating filtered reservation in
out
L1, L6
L3(H4-via-H4 ; H1-via-R3 )
L4(H1-via-R2 )
L7(H4-via-H4 ) in
out
L4, L7
L2(H1-via-H1 ; H4-via-R2 )
L6(H1-via-H1 )
L1(H4-via-R2 ) H2 H2 H3 H3 R2 L3 L3 L2 L2 R1 L6 L7 R3 L4 H4 L1 H1 in
out
L6, L7
L6(H4-via-R3 )
L7(H1-via-R1 )
Part 1

43. RSVP: example 2
receiver H2 sends reservation message for source H4 at bandwidth b
propagated upstream towards H4, reserving b in
out
L1, L6
L3(H4-via-H4 ; H1-via-R2 )
L4(H1-via )
L7(H4-via-H4 ) in
out
L4, L7
L2(H1-via-H1 ;H4-via-R2 )
L6(H1-via-H1 )
L1(H4-via-R2 )
(b)
(b) H2 H2 H3 H3 b R2 L3 L3 L2 L2 b b b R1 L6 L7 R3 L4 H4 L1 L1 H1 in
out
L6, L7
L6(H4-via-R3 )
L7(H1-via-R1 )
(b)
Part 1

44. RSVP: soft-state
senders periodically resend path msgs to refresh (maintain) state
receivers periodically resend resv msgs to refresh (maintain) state
path and resv msgs have TTL field, specifying refresh interval in
out
L1, L6
L3(H4-via-H4 ; H1-via-R3 )
L4(H1-via )
L7(H4-via-H4 ) in
out
L4, L7
L2(H1-via-H1 ;H4-via-R2 )
L6(H1-via-H1 )
L1(H4-via-R2 )
(b)
(b) H2 H2 H3 H3 b R2 L3 L3 L2 L2 b b b R1 L6 L7 R3 L4 H4 L1 L1 H1 in
out
L6, L7
L6(H4-via-R3 )
L7(H1-via-R1 )
(b)
Part 1

45. RSVP: soft-state
suppose H4 (sender) leaves without performing teardown
eventually state in routers will timeout and disappear! in
out
L1, L6
L3(H4-via-H4 ; H1-via-R3 )
L4(H1-via )
L7(H4-via-H4 ) in
out
L4, L7
L2(H1-via-H1 ;H4-via-R2 )
L6(H1-via-H1 )
L1(H4-via-R2 )
(b)
(b) H2 H2 H3 H3 b R2 L3 L3 L2 L2 b b b R1 L6 L7
gone
fishing! R3 L4 H4 L1 L1 H1 in
out
L6, L7
L6(H4-via-R3 )
L7(H1-via-R1 )
(b)
Part 1

46. The many uses of reservation/path refresh
recover from an earlier lost refresh message
expected time until refresh received must be longer than timeout interval! (short timer interval desired)
Handle receiver/sender that goes away without teardown
Sender/receiver state will timeout and disappear
Reservation refreshes will cause new reservations to be made to a receiver from a sender who has joined since receivers last reservation refresh
E.g., in previous example, H1 is only receiver, H3 only sender. Path/reservation messages complete, data flows
H4 joins as sender, nothing happens until H3 refreshes reservation, causing R3 to forward reservation to H4, which allocates bandwidth
Part 1

47. RSVP: reflections multicast as a “first class” service
receiver-oriented reservations
use of soft-state
Part 1

48. Signaling Discussion: SS7 vs Q2931 vs RSVP
Similarities
Differences
Part 1