ATM, MPLS intserv, diffserv · ATM Adaptation Layer ATM Layer VC VP Physical Layer ent ent HEC etc...

School of Electrical Engineering and Telecommunications

UNSW

Copyright © Copyright ©

ATM, MPLS

intserv, diffserv

TELE9751 week 11

1

16/05/2017 Tim Moors 9751QZ*

Copyright ©


UNSW


Cisco Nexus context

• “Cisco introduced Nexus ® 5000 Series Switches both as

high-bandwidth, low-latency, access-layer switches for

rack deployment and as the basis for a unified network

fabric that can help simplify data center infrastructure”

• “The classification can be based on CoS or Differentiated

Services Code Point (DSCP) bits of the incoming packet”

2

16/05/2017 Tim Moors


UNSW


3


Label Switching

Label switching: Labels of fixed length select state in switches that indicates how to switch packet (port, QOS, new label). <ZV]

Benefits:

• Simplify core network:

• switches in network core merely lookup & swap fixed-length labels

• complicated multi-field longest prefix matching to determine labels is done at edges

• need only be done once • is done where there are relatively few flows

• Traffic management

• Provide new services, e.g. Virtual Private Networks

Used in both ATM and MPLS

975167*

Copyright ©


UNSW


4


ATM

Automated Teller Machine?

Air Traffic Management?

Another Terrible Mistake? [J. Lane: “Is ATM a miracle or another terrible mistake?”, Telephony, p. 28, Oct. 24, 1994]

Another Technological Mirage? [Vadim Antonov: ATM: Another Technological Mirage, www.pluris.com/ip_vs_atm]

In a similar vein to ISDN = It Still Doesn’t Network

Asynchronous Transfer Mode – the technology underlying

Broadband Integrated Services Digital Networks. Still

(2017) in use for DSLAM interconnection/signalling.

9751UA*

Copyright ©


UNSW


5


ATM Resources

Keshav: Chapter 4 & § 15.4

Varghese: No explicit coverage. Coverage of specific issues:

4.2: Scheduling ATM flow control

4.15: ATM many-to-many VCs

Packets:

http://uluru.ee.unsw.edu.au/~tim/zoo/index.html#ATM

9751PJ*

Copyright ©

http://uluru.ee.unsw.edu.au/~tim/zoo/index.html#ATM


UNSW


6


ATM Outline

• Short fixed-size packets (“cells”)

• Where ATM aimed to fit in

• ATM cell structure

• ATM Adaptation Layers

• Switching virtual paths and channels

9751G6*

Copyright ©


UNSW


7


Asynchronous Transfer Mode

Short fixed-size packets (“cells”) carry information through the net

Sometimes called “fast packet switching”.

Reasons for fixed size:

√ switch design: speed:

√ simplicity: scheduling <XH] & buffer management <AR]

√ concurrency: space-division switches can <K7]

have multiple ports operating synchronously

Reasons for size being short:

√ minimise serialisation delays for sensitive traffic →

975131*

Copyright ©


UNSW


8


Minimising serialisation delays

48B voice

144B data

48B voice 144B data

48B voice

48B data 48B data 48B data 48B data 48B voice 48B data 48B data

Multiplexing onto a 2.048Mb/s output port

0.6ms

0.2ms

9751AU*

Copyright ©


UNSW


9


Coping with a fixed size: Too small?

Applications with larger data units (e.g. 1KB TCP segments): segment at sender, and reassemble at receiver

Too small => too much overhead per byte of payload

136B data

40B data 48B data 48B data

AAL

ATM

segmentation reassembly

40B data 48B data 48B data some waste (padding) @ tail

ATM Adaptation Layer

975105*

Copyright ©


UNSW


10


Coping with a fixed size: Too big?

Applications with smaller data units (e.g. 1B samples of

streaming voice):

• Don’t fill cell => waste

• Packetise payload: gather enough to fill a cell => delay

48B voice

AAL

ATM

48 1B voice

9751DM*

Copyright ©


UNSW


11


Deciding what fixed size

Powers-of-2 simplify implementation, e.g. memory mgt

ITU (CCITT at the time, part of UN) works on consensus:

Deadlock solved bureaucratically: split the difference: 48B Similar solution for header: 5B 5B header = 9% bit overhead, considered OK with fibre

=>ATM cells are 53B: 5B header + 48B payload pain to implement, most switches use 64B=53B+overhead

US: • Large country, long lines,

install echo cancellers. • Some audio delay OK to

increase data efficiency • Propose 64B payload

Europe: • Smaller countries, no echo

cancellers • More emphasis on audio • Propose 32B payload

9751QR*

Copyright ©


UNSW


12


Why it is the Asynchronous Transfer Mode

Predecessor, Synchronous Transfer Mode, used circuit switching

of time slots (e.g. by TSI switches)

Slots arrive “synchronously” (strictly, isochronously)

For efficient transfer of bursty media (in particular, data), want

statistical multiplexing benefits of packet switching †:

“Asynchronous” because cells need not arrive periodically

=> ATM cells have identifiers VPI/VCI that allow receivers to

associate them, despite unpredictable arrival times.

† Cell overhead has a cost (extra bits) but provides a benefit of releasing resources

that would have been left idle. e.g. if 50% of traffic is bursty with mean utilisation

of 40% then 9% cell overhead saves 50%*60% =30% of link transmission

bandwidth => justifiable. 97511W*

Copyright ©


UNSW


13


Outline

9751R5*

Copyright ©


UNSW


14


ATM protocol stack

• Separation of control & user planes

expedites payload transfer for user

(complicated signalling is separate)

• Management has an explicit plane

Management Plane

Control

Plane

User Plane

Higher Layers

ATM Adaptation Layer

ATM Layer VC VP

Physical Layer

Pla

ne M

an

ag

emen

t

La

yer M

an

ag

emen

t

HEC etc

Intended Reference

Model match

Physical

Data link

Network

Transport

Application

Effective RM match

Physical

Data link

Network

Transport

Application

AAL5

ATM

Optical

IP

TCP

apps

9751WJ*

Copyright ©


UNSW


15


ATM: network or link layer?

Vision: end-to-end transport: “ATM

from desktop to desktop”

• ATM is a network technology

Reality: used to connect IP backbone

routers

• “IP over ATM”

• ATM as switched link layer,

connecting IP routers

Slide from Kurose & Ross 97519C*

Copyright ©


UNSW


16


Why ATM failed ATM to the desktop didn’t happen: × Applications didn’t change to become QOS aware in time × Apps still used IP (over ATM) to communicate to legacy apps;

IP masked QOS improvements × Network Interface Cards never broke vicious circle of costing too much to sell

in volume to make them cheap => ATM used as a high-speed alternative to Ethernet; until Ethernet caught up.

Network service providers initially adopted ATM – e.g. see some traceroute traces.

Reasons: √ ATM’s ability to

segregate traffic √ high speed √ hedge bets

ATM’s legacy: MPLS …

e.g. May 2004: $ traceroute www.uwa.edu.au traceroute to mysource.webcluster.uwa.edu.au 1 eebu4s1.uwn.unsw.EDU.AU.92.171.149.in-addr.arpa 2 129.94.255.181 3 gig2-2.nswrnosbb.nswrno.net.au 4 203.15.123.178 5 nsw-wa.atm.net.aarnet.edu.au 6 parnet2-uwa.parnet.edu.au

e.g. May 2005: $ traceroute www.uwa.edu.au traceroute to mysource.webcluster.uwa.edu.au 1 eebu4s1.uwn.unsw.EDU.AU.92.171.149.in-addr.arpa 2 129.94.255.181 3 192.111.32.169 4 POS1-3.core1.nsw.grangenet.net 5 POS6-1.edge1.vic.grangenet.net 6 * * * ...

e.g. May 2009: $ traceroute www.uwa.edu.au

traceroute to www.uwa.edu.au (130.95.128.140), 30 hops max, 38 byte packets

1 eebu4s1.uwn.unsw.EDU.AU.92.171.149.in-addr.arpa (149.171.92.2) 0.622 ms 0.547 ms 0.543 ms

2 te-1-3.ombcr1.gw.unsw.edu.au (149.171.255.137) 0.580 ms 0.357 ms 0.329 ms

3 te-7-2.unswbr1.gw.unsw.edu.au (149.171.255.105) 1.940 ms 0.708 ms 0.383 ms

4 gigabitethernet1.er1.unsw.cpe.aarnet.net.au (202.158.202.233) 0.436 ms 0.439 ms 0.381 ms

5 ge-4-1-0.bb1.a.syd.aarnet.net.au (202.158.205.161) 0.557 ms 0.535 ms 0.524 ms

6 so-0-1-0.bb1.a.cbr.aarnet.net.au (202.158.194.41) 4.561 ms 4.658 ms 4.519 ms

7 ge-0-0-0.bb1.b.cbr.aarnet.net.au (202.158.194.206) 4.731 ms 4.689 ms 4.696 ms

8 so-0-1-0.bb1.b.mel.aarnet.net.au (202.158.194.29) 12.447 ms 12.409 ms 12.461 ms

9 ge-0-0-0.bb1.a.mel.aarnet.net.au (202.158.194.177) 12.688 ms 12.928 ms 12.652 ms

10 so-2-0-0.bb1.a.adl.aarnet.net.au (202.158.194.17) 21.737 ms 21.704 ms 21.686 ms

11 so-0-1-0.bb1.a.per.aarnet.net.au (202.158.194.5) 48.965 ms 48.976 ms 48.956 ms

12 gigabitethernet0.er1.uwa.cpe.aarnet.net.au (202.158.198.242) 49.328 ms 49.303 ms 61.982 ms

97512Z*

Copyright ©


UNSW


17


Outline

975142*

Copyright ©


UNSW


18


ATM cell structure: Key parts

Virtual Path Identifier

Virtual Channel Identifier

“Inter-ATM-user indication” [1ZE>,

Congestion Experienced, OAM?

Cell Loss Priority

Header Error Correction – CRC-8

Header (5B)

Payload (48B)

Cell (53B)

VPI (e.g.† 12b)

VCI (16b)

codes (3b)

HEC (8b)

CLP (1b)

† for NNI 97515K*

Copyright ©


UNSW


19


Outline

9751HC*

Copyright ©


UNSW


20


ATM Adaptation Layers

Adapt the cell transfer service of ATM to application requirements.

Originally there were 4. AALx, where x=

1 Connection-oriented (CO) Constant Bit Rate (CBR), e.g. circuit emulation

1B header (Sequence # + CRC), 47B payload†

2 CO Variable Bit Rate (VBR), e.g. VBR video, standardised late

3 CO VBR merged with AAL4

3/4 Connectionless (CL) VBR: each application packet is encapsulated with a 4B header and 4B trailer, then segmented into cells, each having 2B header and 2B trailer →

e2e

timing

relationship

“real-time”

no e2e

timing

relationship

9751VP*

Copyright ©

† AAL1/2 lives on in current video formats (MPEG) which encode video in

188B chunks which were designed to fit neatly into 4x47B AAL1/2 payloads


UNSW


21


AAL 3/4

Common Part Indicator = version number

Beginning(B)/End(E) tag: cells at B&E of packet should have matching B/Etags. Helps detect burst loss of last cell and 1st cell of next packet.

Buffer Allocation (BA) size: Suggests how much space the receiver should allocate to reassemble this packet. Streaming sources may only be able to estimate length => record actual length at end.

pad: so that Etag and length always start on 32b word boundaries

CPI Btag BAsize payload pad Etag len 8b 8b 16b 64KB 8b-32b 8b 16b

Packet encapsulation:

type Seq MID payload len CRC 2b 4b 10b 44B 6b 10b

+ Cell encapsulation:

Type: Beginning/End/Continuation/Single-Segment Message

Seq: Cell sequence number

MID: Multiplexing identifier (multiple packets can be interleaved on one link)

× Many piecemeal mechanisms (Length, B/Etags, cell CRC) to detect errors.

× High overhead: Common TCP ACKs (20B TCP+20B IP header) + 8B packet encapsulation = 48B > 44B => 2 cells => 40B in 106B = 38% efficiency :-(

Pay no attention to the details

The point is that it is complicated

9751LG*

Copyright ©


UNSW


22


AAL 5

A computer industry response to the inefficiency and complexity of AAL 3/4.

No cell encapsulation.

“Inter-ATM-user indication” in cell header => is this is the last cell?

Packet-level CRC can detect with high probability all errors (loss, mis-sequencing, bit errors, duplication)

Became the dominant AAL

payload Pad Res len 64KB 0-47B 8b 16b

CRC 32b

9751ZE*

Copyright ©


UNSW


23


Outline

9751F1*

Copyright ©


UNSW


24


Virtual Channels and Paths

VCs identify individual flows of information between endpoints.

Multitudes of flows through network core switches

Inefficient for core switches to handle individual flows

e.g. 622Mb/s link carries 8,800 64kb/s voice channels

average call duration of 2 minutes => 150 connection establish/release requests per second = large signalling burden

=> Virtual Path = aggregate of VCs

Commerce analogy: • core switches are like wholesalers, dealing in bulk (VPs) • edge switches are like retailers, dealing with individuals (VCs)

Resources may be assigned to the VP √ good for predictable flows (set up VC without negotiating switch resources)

– e.g. in core of network where individual variations annul one another × may waste resources when flows vary

9751WU*

Copyright ©

The SDN equivalent of this is to mask the VC bits as “don’t care”


UNSW


25


VPI 6

VPI 1

VPI 2

VPI 3 VCI 22

VCI 21

VCI 24

VCI 25 VPI 5

VCI 24

VCI 23 VPI 4

VCI 24

VCI 25

VCI 24

VCI 23

VCI 22

VCI 21

VP switch/cross-connect

VP switching

VCI 24

VCI 23

VCI 22

VCI 21

VCI

24 VCI

22

VC switch/cross-connect

VCI

23 VPI

3

VPI

1

VPI

2

VCI

21

VCI 22

VCI 21

VCI 21

VCI 22

VP switch/cross-connect

VPI 3

VPI 1 VPI 2

VPI 5 VPI 4

VP & VC switching

Switches translate identifiers

Figure based on ITU

Recommendation I.311 9751AV*

Copyright ©

This is (visually) similar to the layers of optical switching

covered earlier <6R]


UNSW


26


MultiProtocol Label Switching

(MPLS)

9751J3*

Copyright ©


UNSW


27


MPLS Resources

Varghese: S 11.2. Keshav: not covered

Packets: http://uluru.ee.unsw.edu.au/~tim/zoo/index.html#MPLS

Standards: • Primary: RFC3031 • Others: http://www.ietf.org/html.charters/mpls-charter.html

Advocate: http://www.ipmplsforum.org/

Tutorials: • Papers:

R.Winter: “The Coming of Age of MPLS”, IEEE Communications Magazine, 49(4):78-81

A. Viswanathan et al.: “Evolution of Multiprotocol Label Switching”, IEEE Communications Magazine, pp. 165-73

W. Stallings: “MPLS”, The Internet Protocol Journal 4(3): 2-14 F. Palmieri: "GMPLS Control Plane Services in the Next-Generation

Optical Internet", The Internet Protocol Journal, 11(3):2-18 • Courses: http://www.nanog.org/mtg-9905/ppt/mpls/

Book: B. Davie et al.: Switching in IP networks: IP switching, tag switching, and related technologies 9751W0*

Copyright ©

http://uluru.ee.unsw.edu.au/~tim/zoo/index.html#MPLS

http://dx.doi.org.wwwproxy0.library.unsw.edu.au/10.1109/MCOM.2011.5741150

http://dx.doi.org.wwwproxy0.library.unsw.edu.au/10.1109/35.668287


UNSW


28


MPLS outline

• Label Switching

• Multiprotocol Label Switching

• Comparison with ATM

• MPLS terminology

• MPLS label stack entries

• Stacks of labels

• Pushing & popping multiple labels

• How are labels carried?

• MultiProtocol Lambda Switching (MPS) / Generalized MPLS (GMPLS)

• Label Distribution

• Setting up Label Switched Paths

• MPLS in use

9751F2*

Copyright ©


UNSW


29


Multiprotocol Label Switching

Multiprotocol Label Switching (MPLS†):

• Initiated by desire to send IP over ATM, e.g. to

interconnect routers. (Original technique to interconnect routers was to emulate broadcast

<D5] LAN on ATM, but that required large numbers of point-to-point

VCs, unproven ATM routing protocols, & obscured QOS benefits of

ATM)

• Advocated by Cisco, IBM, Ipsilon and others – some

called “tag switching”

• Generalized in IETF to multiple protocols:

IP/IPX/NetBEUI/etc over ATM/Frame Relay/Ethernet/etc

† Like ATM, MPLS also has its detractors, e.g. “Much Preaching, Little Substance” [email to end-to-end mailing list, Mar 8 11:25:10 PST 2002] 9751KC*

Copyright ©


UNSW


30


Comparison with ATM

Similarities:

• Label switching

• Hierarchy of labels:

• ATM has 2 levels: VPs aggregate VCs

• Variable packet lengths allow more than 2 MPLS labels to be stacked

Differences (IP flavour):

• Packets have variable length

• “Routing” can be done using established IP protocols

(e.g. BGP), rather than newer ATM protocols (e.g. across P-NNI). Often described as “layer 3 routing + layer 2 switching”, where: • “Routing”: General determination of which port to send packets so that

they reach their destination, satisfy QOS requirements, and minimise network load.

• “Switching”: Using a label to index a table to determine which port to send a particular packet at a specific instant. Tables may vary over time as routing protocols discover better routes.

9751NV*

Copyright ©


UNSW


31


MPLS terminology

LER LER

LSR

LSR LSR S1

D1

S2

D2

+ -

LSP

Label Edge Router (LER) – pushes (+) / pops (-) labels

Label Switched Router (LSR) – switches using MPLS labels

Label Distribution Protocol – enables a downstream router (closer to destination) to allocate a label to an upstream router.

Label Switched Path (LSP) – similar to ATM VC/VP

Forwarding Equivalence Class (FEC): A set of packets that are all treated the same way by a router

Not necessarily by all routers – e.g. packets with different DAs may belong to same FEC in the midst of the network

Conventional IP routers determine FEC at each hop, MPLS routers (LERs) determine FEC only at entry to domain.

Normal IP net MPLS network

Normal IP net

9751JP*

Copyright ©


UNSW


32


Stacks of labels

Packet can have multiple labels (in a “stack”), each indicating how it should be switched in different domains.

Labels can be pushed onto the stack at:

• source (source routing), or

• ingress LER to domain: Helps scalability/hierarchical routing: Domain routes aggregate (common outer label of stack) rather than individual flows.

• At exit to domain, the common label is popped, and future routing is done according to next label in the stack.

• Pushing a label may extend the packet length beyond the Maximum Transmission Unit (MTU) => LERs need to determine the MTU, and be prepared to fragment packets if label pushing extends length beyond MTU (c.f. bridge which discards frames that are too long <PA])

Labels are popped off the stack by egress routers

Last label indicates protocol: IP (and in theory other protocols, e.g. IPX)

9751C1*

Copyright ©


UNSW


33


Pushing & popping multiple labels

Transit network (middle): • pushes on label (blue) as packets enter

• this label is used for switching within this network

• pops off label as packets depart

LER LER

LSR

LSR LSR S1

D1

S2

D2

+ -

LSP

null label

9751EY*

Copyright ©


UNSW


34


MPLS label stack entries (generic format) 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label

| Label | Exp |S| TTL | Stack

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

20b Label. Values [16,220-1] identify FECs. Other special values:

0: IPv4 Explicit Null Label: End of LSP, next protocol is IPv4

1: Router Alert Label: bring pkt to router’s attention, next label=FEC

2: IPv6 Explicit Null Label

3: Implicit Null Label: For LDP only, not for packets

4-15: Reserved

3b Experimental: Can be used for ECN [RFC5129]

1b S: Bottom of stack: =1 for last label in stack

8b Time-To-Live, adjusted by switches & returned to IP @ egress

This is the generic format of the “shim layer”, added when the link layer (e.g. Ethernet) cannot convey labels

Not particularly multiprotocol yet!

97519N*

Copyright ©

Copyright ©


UNSW


35


MultiProtocol Lambda Switching (MPS)

/ Generalized MPLS (GMPLS)

Traffic engineering tasks for optical networks: • Coordinating use of wavelengths, e.g. ensuring wavelength continuity • Restoration services: e.g. identify backup lightpaths that don’t share

same risks (e.g. fibre or duct)

Need a signalling protocol to allow dynamic reconfiguration of a network of devices from varied manufacturers

GMPLS generalises MPLS idea of a label to include anything that is sufficient to identify a flow. e.g. wavelength or port

Some differences from MPLS, e.g. no optical equivalents of label merging or label push/pop operations. label swapping = wavelength conversion

9751RF*

Copyright ©


UNSW


36


Label Distribution

Labels are allocated by downstream router & distributed to

upstream router using:

• a Label Distribution Protocol (LDP – RFC 3036),

a Constraint-Based LDP (RFCs 3212-3214) or

• extending routing protocols (e.g. BGP – RFC 3107), or

• signalling (e.g. RSVP) protocols to carry labels.

97510A*

Copyright ©


UNSW


37


Setting up Label Switched Paths

What causes a Label Switched Path to be set up? Either:

• Data driven: On demand by source transmitting packets

• Control driven: When routing topology changes, or

explicit signalling request to establish a LSP

How is the LSP determined?:

• Layer 3 hop-by-hop routing, of either:

• Initial packets that are transmitted & stimulate data-

driven setup

• Control signals

• an Explicit Route (source route) specified by the source 9751K0*

Copyright ©


UNSW


38


MPLS in use

[On Linux machine, ca 2012] $ traceroute nytimes.com traceroute to nytimes.com (199.239.136.200), 30 hops max, 38 byte packets 1 eebu4s1.uwn.unsw.EDU.AU.92.171.149.in-addr.arpa (149.171.92.2) 0.637 ms 1.160 ms 0.370 ms ... 6 so-2-2-0.bb1.a.pao.aarnet.net.au (202.158.194.174) 158.560 ms 158.526 ms 158.534 ms 7 140.174.28.137 (140.174.28.137) 158.811 ms 158.667 ms 158.695 ms 8 xe-0-3-0.r21.plalca01.us.bb.gin.ntt.net (129.250.4.121) 158.788 ms ae-2.r21.plalca01.us.bb.gin.ntt.net (129.250.2.217) 158.863 ms xe-0-3-0.r21.plalca01.us.bb.gin.ntt.net (129.250.4.121) 158.824 ms MPLS Label=100432 CoS=3 TTL=1 S=0 9 ae-1.r20.snjsca04.us.bb.gin.ntt.net (129.250.5.33) 159.598 ms 160.526 ms 159.620 ms MPLS Label=289930 CoS=3 TTL=1 S=0 MPLS Label=111856 CoS=0 TTL=1 S=0 10 p64-1-3-0.r21.chcgil09.us.bb.gin.ntt.net (129.250.5.21) 220.231 ms 220.177 ms 220.650 ms MPLS Label=786616 CoS=3 TTL=1 S=0 MPLS Label=111856 CoS=0 TTL=2 S=0 11 ae-0.r20.chcgil09.us.bb.gin.ntt.net (129.250.3.97) 220.204 ms 220.536 ms 220.219 ms MPLS Label=596455 CoS=3 TTL=1 S=0 MPLS Label=111856 CoS=0 TTL=3 S=0 12 as-1.r21.nycmny01.us.bb.gin.ntt.net (129.250.6.14) 243.889 ms 243.100 ms 246.222 ms MPLS Label=111856 CoS=3 TTL=1 S=0 13 * * * 14 ge-1-2.a00.nycmny01.us.da.verio.net (129.250.30.193) 240.771 ms 240.697 ms 240.375 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 *

9751U5*

Copyright ©

[May 2015]

$ traceroute www.uwa.edu.au

traceroute to www.uwa.edu.au (130.95.128.140), 30 hops max, 38 byte packets

1 eebu4s1.uwn.unsw.EDU.AU.92.171.149.in-addr.arpa (149.171.92.2) 0.604 ms 0.627 ms 0.463 ms

2 libcr1-po-5.gw.unsw.edu.au (149.171.255.165) 0.328 ms 0.328 ms ombcr1-po-5.gw.unsw.edu.au (149.171.255.197) 0.296 ms

3 unswbr1-te-8-1.gw.unsw.edu.au (149.171.255.105) 0.434 ms unswbr2-te-7-1.gw.unsw.edu.au (149.171.255.110) 0.356 ms 0.389 ms

4 bfw1-ae-1-3053.gw.unsw.edu.au (129.94.254.76) 0.600 ms 0.814 ms 0.747 ms

5 unswbr1-vl-3054.gw.unsw.edu.au (129.94.254.82) 0.840 ms 0.810 ms 0.811 ms

6 138.44.5.0 (138.44.5.0) 1.113 ms 1.152 ms 1.130 ms

7 et-1-1-0.pe1.rsby.nsw.aarnet.net.au (113.197.15.12) 2.320 ms 1.562 ms 1.546 ms

MPLS Label=321104 CoS=3 TTL=1 S=0

8 et-0-3-0.pe1.prka.sa.aarnet.net.au (113.197.15.42) 19.024 ms 19.076 ms 18.973 ms

MPLS Label=300832 CoS=3 TTL=1 S=0

9 et-0-3-0.pe1.knsg.wa.aarnet.net.au (113.197.15.45) 45.889 ms 44.974 ms 44.973 ms

10 138.44.176.3 (138.44.176.3) 45.454 ms 45.390 ms 45.396 ms

11 * * *

12 * * *

tracert on Windows machines tends to not show MPLS information


UNSW


39


Quality of Service in the Internet:

Intserv and Diffserv

9751JA*

Copyright ©


UNSW


40


Broad outline

• Integrated Services (intserv): RSVP

• Differentiated Services (diffserv)

• Tying it all together

Overview papers:

X. Xiao and L. Ni: “Internet QoS: A big picture”, IEEE Network Magazine, 31(2): 8-18.

covers intserv, diffserv, MPLS

C. Metz: “IP QOS: Traveling first class on the Internet”, IEEE Internet Computing, 3(2):84-8

covers intserv, diffserv

9751Z7*

Copyright ©




UNSW


41


RSVP outline

General architecture

RSVP is separate from routing protocols

Soft state: Definition, Benefits, Costs

How RSVP supports multicast

Messages

Formats

PATH & RESV

Using RSVP

scalability

RSVP over reservationless networks

9751UR*

Copyright ©


UNSW


42


RSVP Resources

Varghese: S 14.5

Keshav: pp. 471-5

Packets:

http://uluru.ee.unsw.edu.au/~tim/zoo/index.html#RSVP

Standards: RFCs 2205-2216

Advocate: http://www.isi.edu/div7/rsvp/

Tutorials:

L. Zhang, et al.: “RSVP: A New Resource ReSerVation

Protocol”, IEEE Network Mag., 7(5):8-18

Chapter 6 of Jha and Hassan

97515C*

Copyright ©





UNSW


43


Resource reSerVation Protocol (RSVP)

• Offers 2 types of service:

• Guaranteed service [RFC 2212]: Provides firm end-to-end delay

bounds

• Controlled-load service [RFC 2211]: No firm delay bounds, but

service shouldn’t deteriorate as network load increases.

Both involve admission control.

• Separate from routing protocols →

• Uses “soft state” →

• Designed to support group communication →

9751JD*

Copyright ©


UNSW


44


RSVP is separate from routing protocols

Designed to be separate from the routing protocol

√ Simplifies RSVP

√ Allows operation with existing routing protocols

× May hinder ability to provide QOS guarantees (Route that provides necessary QOS depends on the connection’s session’s profile & requirements of traffic => depends on signalling)

9751R4*

Copyright ©


UNSW


45

2014 Tim Moors

Soft and hard state

RSVP uses soft state (PATH and RESV messages are periodically resent)

Compare with ATM, which uses “hard state” …

Under normal conditions: (“normal”: systems using state info remain available, e.g. haven’t crashed)

Hard state persists until it is explicitly released.

Soft state persists only for a moderately short interval.

It must be refreshed if it is to persist longer.

Failure to refresh implies request to release.

i.e. soft state is often refreshed, whereas hard state is not.

[Keshav pp. 108-9] 9751JM


UNSW


46

2014 Tim Moors

Soft and hard state examples

Student accounts on a computer [Keshav, p. 109]:

Hard state: Account lasts indefinitely, until student asks for it to be deleted. Account may never be deleted because the student:

• is unable to ask (e.g. dies or wins the lottery)

• forgets to ask

• doesn’t want to ask: they quite like access to the system

Soft state: Account lasts one session only. Long-term students have to renew their accounts each session.

Intermediate between virtual circuits and datagrams <NU].

9751EG


UNSW


47


Pros and cons of soft state

√ Adaptive: routing path changes redirect endpoint refresh messages,

creating new state.

√ Robust: Packets can be lost and switches can crash, but service will

continue until either there is no path (service is impossible) or end-

system loses state

Soft state simplifies signalling, since switches needn’t explicitly adapt to

changes, or recover from failures.

× Extra transmissions to refresh the state

975196*

Copyright ©


UNSW


48


RSVP supports group communication

Designed at the outset to support group communication:

1. Receiver oriented (c.f. sender-oriented ATM)

• Receivers initiate reservations (source initiates a multicast

group, but receivers initiate their connection to the group)

• Merger of reservations enables many receivers without

many requests imploding at source

• Reservations can be heterogeneous, according to

differing requirements

• It is the receiver that experiences QOS & usually pays for

service

2. State information is continually refreshed →

3. Reservations are for “sessions” →

97518T*

Copyright ©


UNSW


49


RSVP supports group communication (continued)

2. Refreshing of soft state reflects updates to group membership. Multicast membership changes more often than unicast => continuous refreshing is appropriate.

3. Reservations are for “sessions”: traffic to a particular multicast group (not from a particular source)

• A session may have multiple sources, e.g. videoconference

• Reserving resources for sessions, rather than sources, (recall “multiaccess” service <D5]) allows admission of more sessions: often only one or a few sources transmit at any instant.

9751X7*

Copyright ©


UNSW


52


RSVP message format: Header

Common header (for all message types): 0 1 2 3

+-------------+-------------+-------------+-------------+

| Vers | Flags| Msg Type | RSVP Checksum |

+-------------+-------------+-------------+-------------+

| Send_TTL | (Reserved) | RSVP Length |

+-------------+-------------+-------------+-------------+

Flags: only 1b ever used to control refresh overhead – see RFC 2961

Message types: See next slide [171>

TTL: Compared with IP’s TTL to detect non-RSVP hops on path.

Objects follow the header, encoded as Type-Length-Value triplets

97511E*

Copyright ©


UNSW


53


RSVP message types

Path: Gathers information about path from source

Resv: Reserves resources

*Tear: Release resources before soft-state timeout

*Err: Error interpreting message, or honouring

reservation

Transmission

direction

Commands Responses Errors

Downstream Path,

PathTear

ResvConf ResvErr

Upstream Resv,

ResvTear

PathErr

S D

Path,

PathTear

Resv,

ResvTear PathErr

ResvConf,

ResvErr

downstream

975171*

Copyright ©


UNSW


54


PATH message 4 roles: • records network capacity on path from source (AD_SPEC) • informs receivers of source’s capabilities (SENDER_TSPEC) • refreshes state in routers (e.g. sent every 30 seconds) • marks the path from the source (RSVP_HOP), for return of

RESV … <Path Message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> IDs session, e.g. multicast IP address <RSVP_HOP> IDs previous node for RESV return <TIME_VALUES> specifies refresh rate†

[ <POLICY_DATA> ... ] e.g. access credentials [ <sender descriptor> ] describes path state <sender descriptor> ::=

<SENDER_TEMPLATE> IP address & port of source <SENDER_TSPEC> Leaky Bucket spec. of source traffic [ <ADSPEC> ] summary of upstream capabilities (Receivers use IGMP to join group, informing routers of route for PATH msg)

† Larger TIME_VALUES => lower overhead, but less responsive to network changes. Receivers may send RESVs with period ∝ # rx for scalability => router needs to know period.

9751TG*

Copyright ©


UNSW


55


RESV message

Role: makes reservation & acks PATH message

• Default is for no explicit confirmation for RESV: Receiver knows of success through payload delivery

• RESV error messages (in case reservation isn’t possible) <Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] IP address of receiver requesting confirmation [ <SCOPE> ] Lists targets of this RESV [ <POLICY_DATA> ... ] <STYLE> Indicates if RESV is for all or some sources in session <flow descriptor list> <flow descriptor list> ::= <empty> | <flow descriptor list> <flow descriptor> Defines flow & source that it applies to

9751U4*

Copyright ©


UNSW


57


RSVP scalability

• Scales well in terms of source overhead for increasing numbers

of receivers.

• Scales poorly in terms of switch overhead for increasing

numbers of sessions through that switch:

Each switch on the end-to-end path must process signalling,

not just to establish & release the state, but also continuous

refresh messages.

RSVP is best at edges of network, where there are few flows

97513C*

Copyright ©


UNSW


58


RSVP over reservationless networks May need to connect networks supporting reservations with

reservationless networks (LANs, or IP) • RSVP messages still pass over these networks • QOS can only be assured if the reservationless networks are

not the bottleneck

Common arrangement: interconnect RSVP networks with a diffserv network => • edges (where scalability isn’t critical) have per-flow state • network core only has state for aggregates (e.g. all video packets)

Need to map between services:

intserv diffserv

Guaranteed ↔ Expedited (premium)

Controlled load ↔ Assured

For details, see RFC 2998 975190*

Copyright ©


UNSW


60


diffserv resources Varghese: S 14.8.2, Keshav: not covered

Standards: Primary: RFC2475 Others: RFC 2597 (Assured Forwarding),

RFC 3246 (Expedited Forwarding) http://www.ietf.org/html.charters/diffserv-charter.html

Introductory papers:

F. Baumgartner et al.: “Differentiated Services: A new approach

for Quality of Service in the Internet”, Proc. High Performance

Networks

Cisco Systems: DiffServ - The Scalable End-to-End QoS Model http://www.cisco.com/warp/public/cc/pd/iosw/ioft/iofwft/prodlit/difse_wp.htm

9751Y5*

Copyright ©

http://dx.doi.org/10.1007/978-0-387-35388-3_15

http://dx.doi.org/10.1007/978-0-387-35388-3_15


UNSW


61


Diffserv terminology

Per Hop Behavior (PHB): Defines the behaviour of a switch when

forwarding certain packets, e.g. what service they receive

Behavior Aggregate (BA): A group of packets passing through a

common network point that have a common label (DSCP) so

that they experience the same PHB at that point.

Different BAs experience different behavior => “Differentiated Services”

Differentiated Services Code Point (DSCP): Replaces IP ToS field 0 1 2 3 4 5 6 7

+---+---+---+---+---+---+---+---+

| DSCP | ECN |

+---+---+---+---+---+---+---+---+

DSCP interpretation can be customized for specific domains (i.e. Autonomous

Systems/Networks) => remarking at domain boundary

For more details, see RFC 2475 9751GF*

Copyright ©


UNSW


62


Per Hop Behaviors Best-effort service (DSCP=000000); may be lost or delayed

Assured Forwarding (AF) (aka “assured service”) (DSCP=x1x2x3y1y20)

• ‘Assured’: gets lower loss rate than normal ‘best effort’ (no mention of delay)

• Policed <FM]: Excess traffic is converted to best effort

• Theoretically assured for a source (not S-D pair), but that leads to inefficient

provisioning, since source may transmit to arbitrary destination – allocate

resources on all possible links?!

12 types (AFxy) (x1x2x3=001,010,011 or 100, y1y2= 01,10 or 11†)

• 4 classes (x), each assigned separate resources (buffer&transmission capacity) • 3 drop precedences (y) per class. Prob(drop)∝1/y

Expedited Forwarding (EF) (aka “premium service”) (DSCP=101110)

• low loss (like AF) and low delay, e.g. for voice/video

• Traffic entering network must be rate limited, e.g. through a shaper <FM]

† y1y2=00 is reserved for backward compatibility with traffic that uses IP precedence 9751YN*

Copyright ©


UNSW


63


Diffserv entities Domains: Contiguous network regions, with common administrative

ownership, set of service provisioning policies and PHB definitions.

Boundary node: Point of entry (ingress) or exit (egress) from domain. They regulate traffic & set DSCP labels (like MPLS LER)

Interior nodes: Within a domain, but not a boundary node Forward transit traffic, with service determined by label (like MPLS LSRs) May mark locally generated traffic (may also be done by source)

Boundary node Interior node Domain

S

1st hop router for S

D

9751GD*

Copyright ©


UNSW


64


Bandwidth Brokers Each Domain has a Bandwidth Broker (BB), responsible for

admission control for that domain (c.f. ATM/MPLS/RSVP where

admission control is distributed amongst switches in domains)

Signalling between BBs is done using a protocol such as RSVP

or LDAP (Lightweight Directory Access Protocol – RFC 1777)

BBs can aggregate multiple requests before forwarding an

aggregated request to the next BB. Fig. from Xiao

PATH

5.5 RESV

3

2

4

6 6

13 12

11

10

8,9 15 16

5 7 1

ER1 BR1

Host S CN1

BR2 ER2

CN2 ISP1

Host D

CN2-BB ISP-BB CN1-BB

7

8: S receives RESV from CN1-BB 9: S starts transmitting 10: LR1 classifies & forwards

LR1

9751FT*

Copyright ©



UNSW


65


Multicasting complicates diffserv

Diffserv is source oriented

But source may not know locations of multicast

members & membership may change rapidly

=> difficult for network to anticipate load that a

multicast flow will create

=> difficult to assure performance

For details, see Internet Draft draft-bless-diffserv-multicat-03.txt: R. Bless & K.

Wehrle: IP Multicast in Differentiated Services Networks

9751JR*

Copyright ©


UNSW


67


Intserv diffserv

Unit of operation

=> granularity of isolation & guarantees

individual sessions aggregates

Signalling frequency frequently refreshed for each flow

rarely (SLAs)

Based on reservation for rx prioritization of sources

Able to guarantee absolute service to end-users?

yes no

Service scope (end-to-end requires extensive network upgrade)

end-to-end domains

Complexity routers must process signals for individual flows => poor scalability

simple internal nodes, boundary nodes must classify & regulate traffic

Compatibility with multicast traffic

good problematic

9751QL*

Copyright ©


UNSW


68


Tying it all together

MPLS

Label Switched Router

Label Edge Router

Forwarding Equiv. Class

may distribute labels

RSVP

session

reserves

for rx

diffserv

Interior Node

Boundary Node

Behavior Aggregate

may reserve

for source/domain

RSVP can be used with all of the above (not intended to confuse you!)

Ter

min

olo

gy

R

ole

of

R

SV

P

9751VD*

Copyright ©


UNSW


Things to think about

• Critical thinking: What lessons can be learned from repeated

unsuccessful attempts to provide network QOS (eg. ATM) and how

might they be avoided in current/future protocols?

• Engineering methods: Each of these protocols have defined

interfaces for accessing the service provided by the system and a

procedure for signalling desired service across the interface.

• Links to other areas: • Several systems offer both connectionless and connection-oriented

control, e.g. MPLS’s “Data driven” and “control driven” setup <1K0], and

“Tell and go” and “Tell and wait” setup for optical burst switching <RJ]

• HTTP cookies are another example of soft state

• Independent learning: Read about how Carrier Ethernet offers QoS

across Metro Ethernet Networks, and how a Stream Reservation

Protocol (like RSVP) has been added to IEEE 802.1Q

Tele9751!!!!

2017 Tim Moors

69

http://mef.net/Assets/Technical_Specifications/PDF/MEF_23.1.pdf

http://mef.net/Assets/Technical_Specifications/PDF/MEF_23.1.pdf

http://mef.net/

https://standards.ieee.org/getieee802/download/802-1Q-2014.pdf

https://standards.ieee.org/getieee802/download/802-1Q-2014.pdf

ATM, MPLS intserv, diffserv · ATM Adaptation Layer ATM Layer VC VP Physical Layer ent ent HEC etc...

Documents

Transcript of ATM, MPLS intserv, diffserv · ATM Adaptation Layer ATM Layer VC VP Physical Layer ent ent HEC etc...