TECHNISCHE UNIVERSITAT ••• WIEN • • • institute of Vienna University of Technology • e • telecommunications
Lecture Notes
Technical Realization of Communication Networks
Course Number: 388.031
Part : Networking
o. Univ. Prof. Dr. Hannen R. van As
Institute of Telecommunications
Vienna University of Technology
2011
2 CONTENTS
1.5.14 Adrnii;sion control 59 l.5.15 Flow control .... 60 1.5.16 Congestion control 61 1.6 Mobility 62 1. 7 Security ...... 63
Contents 2 Source and transmission coding 65 2.1 Introduction ...... 66 2.2 Source coding ...... 67 2.3 Linc coding aJJd modulation . 68 2.3.1 Binary coding . . . . . 69 1 Networking 1 2.3.2 I3lock <.'Oding .... 70 1.1 Network architecture ...... 2 2.3.3 Convolution coding . 71 1.1.1 Network planes ...... 2 2.4 Modulation . . 72 1.1.2 Wired and wireless media 3 2.4.l OFDM ...... 73 1.1.3 Transmission . . . . . 3 2.4.2 CMSK ...... 74 1.1.4 Switching ...... 9 2.5 System-related coding and tra.nsrnh;sion 75 1.1.5 Signaling and control . 13 2.5.1 PCM ...... 76 1.1.6 Network intelligence 14 1.1.7 Network management 14 3 Tuansmission 77 1.1.8 Service transport . . . 14 3.1 Introduction . 78 1.1.9 Communication and content services 14 3.2 Transmission media . 82 1.1.10 Technological layering 14 3.2.l CoaxiaJ cable 82 1.1.11 Geographical areas 15 3.2.2 Copper twisted pair 82 1.2 Protocol Architecture 19 3.2.3 Fiber ...... 83 1.3 Network protocols 23 3.2.4 Free-space optic link 83 1.4 Network availability 27 3.2.5 Frequency spcctmrn 83 1.5 Network control . . . . 30 3.2.6 Microwave link . . . 83 1.5.1 Network control mechanisms 31 3.2.7 Mobile radio interf~ 83 1.5.2 Performance measures and measurcmeut . 32 3.2.8 Wireless intcrf~e . 83 1.5.3 Topology and routing management 37 3.2.9 Satellite interface . 83 1.5.4 Network operation policies . 38 3.3 Transmission techniques 84 1.5.5 Service level management 39 1.5.6 Buffer management . 40 4 Switching 85 1.5. 7 P~ket classification 41 1.5.8 Shaping . . 42 5 Protocols 87 1.5.9 Policing .. 43 1.5.10 Scheduling. 44 6 Addressing, naming, numbering and labeling 89 1.5.11 Monitoring 45 6.1 lnlroduction ...... 90 1.5.12 IntScrv (integrated services) . 46 6.2 IEEE addressing .... 91 1.5.13 DiffServ (differentiated services) 48 6.2.1 MAC addressing 91 CONTENTS 3 0 CONTENTS
6.2.2 Address Resolution . 94 10.3 Intcrdomain Routing with MPLS ...... 179 6.2.3 LLC addressing . 95 10.3.1 Inter-AS Bandwidth Guaranlecs 180 6.3 Internet addressing . . . 97 10.4 MPLS VPN ...... 186 6.3.1 1Pv4 addressing . 102 10.5 Layer-2 MPLS VPN ...... 187 6.3.2 1Pv6 addressing . 106 10.6 Layer-3 MPLS VPN ...... 188 6.4 Internet protocol stack internal addressing . . 110 10.7 VSAN (Virtual storage area network) . 189 6.4.1 SNAP (Subnetwork acces8 protocol .. 110 6.4.2 Ethertypes . . . . 111 11 Network systems 191 6.4.3 Protocol numbers ... 112 11.l Network Systems 192 6.4.4 Port numbers . . . . . 114 12 Standardization 195 6.5 DNS (Domain name system) . 115 12.1 Standardization in telecommu11ication1> . 196 6.5.l DNSSEC (Domain name system security) 130 12.1.1 Standard organizaLions . 196 6.5.2 ENUM (Telephone number mapping) . 131 12.1.2 Fora ... 206 6.5.3 NAT (Network addre1>1> translation) . 142 12.1.3 Alliances . 218 6.6 OSI addressing ...... 144 12.l.4 Conoortia 224 6.7 OSI protocol stack internal addressing . 146 12.1.5 Centers . 226 6.8 ATM addressing 147 12.l.6 Internet Address Registration 227 6.9 ISON .addressing . 149 6.10 GSM addressing . 151 13 Abbreviations 229 6.11 GPRS addressing . 155 6.12 WLAN addressing 156
7 Network management 159
8 Services 161
9 Multiservicc networking 163 9.1 Multiservice Networking 164
10 Virtual networks 165 10.1 VLAN (Virtual local area network) 166 10.2 VPN (Virtual private network) . 169 10.2.1 Overlay Model ...... 169 10.2.2 Peer Model ...... 171 10.2.3 BGP/ MPLS VPN Network Topology . 173 10.2.4 Routing Information Distribution . . . 173 10.2.5 VPN-1Pv4 Address Family . 175 10.2.6 BGP Operation .. 176 10.2.7 Data Flow ..... 176 10.2.8 Quality-of-Service . 178 10.2.9 Scalability .... . 179 2 Networking
1.1 N etwork architecture
Chapter 1
Access networi
Figure 1.1: Telecommunication networks (hierw-chical view)
The architecture of telecommunicat,ions net.works can roughly be divided according to two criteria: geographically partitioning in access networks, regional networks, and long-distance or wide area networks on the one hand and functionally partitioning as a layered model with two prime areas, t,ran:; port and network intelligence, on the other hand. 'fhcrcby, fixed, mobile and satellite communications play their important role in all geographic network parts of the world.
AcceM network Metro network Wide .,.. networll Metro network Access network
Figure 1.2: Tclccommwlication networks (end-to-end view)
1.1.1 Network planes
The layered structure of the transportation network is further partitioned. Transport consists of all ta.-;ks, which arc necessary for switching end-to-end connections. They are considerably coined by the switching technologies and commwtication protocols in the end systems. Similarly to the OSI rcf creucc model for protocol layering the network architecture is subdivided into network planes. In the center the switching plane is located. Here, the network components of all switching technologies are to be found. Within 1.1 Network architecture 3 4 Networking
trical end equipments particularly long distance are the SDH Transmission I Network Intelligence I Systems (SDH stands for Synchronous Digitally Hierarchy). They form an Networ11 ln4llla1111 ...... autonomous and flexible tra.rn;mission network with fast reconfiguration in case of failure of nodes and optical fiber cables. The staudardized trans mission bit rates a.re 155 Mbit/ s, 622 :Mbit/ s, 2.5 Gbit/ s, 10 Gbit/s, and 40 I Swlll:hlng - ll'llnsport I Gbit/ s.
I SDHnetwOli< I
Reg Iona I Metro
Figure 1.3: Layered network architecture ADM:~ muhlplexer I SOH: Synchronoua clgltal hierarchy I. DXC : Dlgltal er-. th.is switching plane the three hicrarch.ica.l network areas: access network, regional network (metropolitan area network, MAN), and long-di&ta.nce net Figure 1.4: SDH network structure work (wide Area network, WAN) a.re located. Between all network compo nents transmission takes place, whereby all communications equipment and communication media can be allocated either to the electrical or for op --e byte• 261 bylea t • O · ~ - tical transmission plane. In case of circuit switching, nodes communicate RSOH 3 ----·:r with another over a fail safe, independent network. This is the signaling _, Payloed-: Vc-4 e• network number 7 (SS7, Signaling system number 7). Over this signaling MSOH g "' plane also all communications between the switching, network intelligence, _____J_ and network management planes takes place. ls 125 ...
1st row 2nd row 3rd'""' 1.1.2 Wired and wireless m edia ""'""'
1.1.3 Transmission STM·l transmission frame; duration t • 126 ps .I
In the access area transmission occurs over copper wires, coaxial cables, Figure 1.5: SDH Frame format: STM-1 radio channels, or opticaJ fibers. In the long-distance network transmission takes generally place over optical fibers. The exceptions a.re radio relay links and satellite links. However, when fiber is used, optical transmission needs also electronic end equipments. Therefore, the electrical transmission plane is always linked with the optical transmission plane. Important clcc- 1.1 Network architecture 5 6 Networking
I TribularyPlone l
4 x STU-1 ••S~ 4xSTIM& 4xSTM~ l 1 1 l Low-order "'"' ST~1 STM-4 STM·16 ST~64 STU-256 oommomomm•• I Palh plane I
High-order Jl'lh DDDDD ...... 155 MblWs 622 Mbllls 2.5 Gblts 10 Gbilla 40Gb1Ws
Figure J .6: .Multiplexing in SDH
4 x270 I --• x 9-l-•x 1 4 x 2llO :I ------=--=Physical medium ------1= ------~-::~ ~~ 0 f 3 SOti Figure 1.9: Architecture for mapping of PDH bit streams 1 p p 1 P P 00 00 4xC4 II rows -- H H H H 1 1 2 ll ~ 5. SOH ·' 1 ' 4 xVC4 l • 125µs
T3: 45 Mbllls Figure l. 7: SDH Frame format: STM-4 with block-i nterleaving E3: .34 MbiWs SOH
4 x 270 i.-. x9-l 1 t-3 4 x 260 :I 0 t 3 SOti ·1~ E1: 2Mbit/s 1 p 1 0 AU Adminla1rative unit ••~ Tt: 1.5 Mblt/s - Fbred C4-'4c trows H AUG Admlnlatrative unit group 1 , TU Tributary unit 5 SOH TUG Tributary unit group r Ma~lng c Container POH VC Virtual container l 1 Pointer VC4-4c h125µs Figure 1.10: Mapping of PDH bit streams into a STM-1 transmission
Figure 1.8: SDH Frame format: STM-4c (Concatenated) 1.1 Network architecture 7 8 Networking
Europe North America
214·.ZllelVa •
... 71111Wa T3 7 T2 4 T1 .. ,24......
Figure l.13: PDH (plesiochronous digital hierarchy)
C Conlal.., VC Vlrtu91 cont•IMr TU Tributary unit C-11 Tl: 1.5 llbitls TUG Tributary unit lllOUP C-12 El: 2 llbltls AU Admln18118tlve unit C-2 T2: 6.3 Mbltla 4 AUG Admln18118tlve unit group C-3 T3: 34 Mbitla STM SynclV_ lr9...... module E3; 45 lllbit/• ... .e Concatwwted C4 E4: 140 llbltla
Figure 1.11: Mapping of bit i.treams into STM transmission frames
SOHETISOH
01N: TmnlPOll~
Flblr
ID+I Re181Ubltfal 1'11ivloed (Ublllsl STM4 11.840 50.112 Figure 1.14: GFP rnapping scheme STM·l 166.62 150.336 STM-4 622.08 601.344 STM-16 2'488.32 2'405.376 STll-64 9'953.28 9'621.604 GFP header GFP peyl<>11d STM·256 39'813.12 38'486.016 P9yload GFP p,eyloed lenglh ...... Ethernet fn11me ..,.oonll'OI llMder Figure l.12: SDH transmission and payload hit rates lnclcMor2..,... ..,... 4by!H 46 · 63631 bytH
Figure 1.15: G FP frame format 1.1 Network architecture 9 10 Networking
1.1.4 Switching Circuit awltchlng (CS) Packet awllehlng (PS) PSTN Public ...,Itched telephone ..1w0<1< IP Internet protocol ISDff Integrated servlcee digital network X.25 X.25 packet switching TOM Time dMalon mulllplexlng MPLS MUltl"i' Phy.icat connection Logical connect.Ion • Swltchecl physical c:onnec:tlon • Swllclled logical connection Figure 1.18: Packet- and circuit--swit.ching layering • Isochronous • Asynchronous or syno::hronous (real-time) · Same bit rete .ieach end • Dltterent or ume bit rate at eacll end • C onatant end-to-end dellly • Variable end-lc>-end deley · Exel- physical eonneetion • Shared pllysicll connection Figure 1.16: Properties of circuit and packet switching Figure 1.19: Combined packet- and circuit--switching Distributed addressing: Complete addressing • Data unit: Lab.el • Data unit: Destination address • Nodes: Table for label exchange • Nodes: Routing table Figure 1.17: Packet- and circuit-switching layering Ethomet (physical address) • 48-bil IEEE address • 64-bit IEEE address ATU: Aaynchronou• Tranafer Mod• 1 IP (lntemet Protocol) (Logical address) llPLS: 11-rotocol Label Swil ATM Cell: Header 5 bytes, Payload 43 bytes FR, Ethernet, Variable length frames Payload f H l 1Pv4, IP.t, X2S: Variable length packets MPLS: Variab4e length pacl Figure l.20: End--to-cnd sv.itching methods 1.1 Network architecture 11 12 Networking Tunnel bypass Figure 1.21: TWUJel Bypass IP ATM PPP ATll PPP IP ...,.,3 ATll c:elle in IP ...... ,.,2,1 ATll cells In •PLS ~ ...,.,2 ATll cells In ElNrnel ir- Alli ...,..., cells ATll (Layer 1) ~------~ ...,.,3 Elhemel ,_In IP pecll9ll ...,.,2,6 Ethemee "-In llPLS .-.... Ethernet 2 Layer Ethernet,,_ (Laye< 2) Layer 1 ElhtqatfnllMs In Alli Ciiia Figure 1.24: Ethernet and ATM over heterogeneous switching tcclmologies F,..,,. format: ITunnel Hellder I Demux. Fleld 'Peyloed ~ ATll ATll AT11 Figure 1.22: Layer-2 S"itch.ing Tunnels _...... ,.._31 .,.,... ,_ ...... ~·- __ __ - _ .. E-LAH Poc:i..t ...ilchin!l{IAl'e<2) Elhemot- ·-- ) -- (l-2) l.o9kal•- @ ,_... lleblno ~1) ~- ~-lll:biftl(-} ...,..._PllroUI•- --ln•Tlll----lSllllorTCll --ilcNng~ --llchiootl<~ ~~ ...... (Oplal) ----·one -----OllM---~•OPS ~- Figure 1.23: Ethernet End-to-End connection over heterogeneous switching technologies 1.1 Network a rchitecture 13 14 Networking 1.1.5 Signaling and control 1.1.6 Network intelligence The Intelligent Network (IN) is a network consists of a logical network of data base computers, the so-ca.lied Service Control Points (SCP). Commu nication between these SCPs as well as to and from the switching nodes oc curs over the signaling network SS7, a robust , autonomous, packet s'vitched network. Distributed net.work intelligence permits: • To optimally use network resources by representing the network status in a hierarchical data base i;yi;tcm. • To introduce new services flexibly and rapidly. Figure l .25: Signaling in telephone networks • To operate free or cost-limited number {800 number range) and market focused numbers {900 number range). SIP • To offer global servicci;, e.g., accessibility of all company locations under t he 1.;ame dialing code. SIP, H.323 • To accomplish mobility in mobile networks. SIP 1.1. 7 Network management Network management makes it possible, to supervise all networks compo Figure 1.26: Signaling i.Ll packet-switched networks nents, eit her centrally or disLributed. OAMP (operation, administration, maintenance and provisioning) forms the basis for: • Optimal network operation. • Administration of system and customer systems as well as administration of cu1:1tomer services. • Effective network rnaintenunce. • Setti1Jg-up of special network conflgurations and services as for example for company networks. 1.1.8 Ser vice t ransport 1.1.9 Communicat ion and content services 1.1.10 Tech nological layering Technology layering Circuit ru.i.d Packet Switching 1.1 Network architecture 15 16 Networking 1.1.11 Geographical areas • Access · ~ • LAN (local area network) . ~ • MA N (metro area network) •. • WAN (Wide area network) WiMax • Sky networking WIMoblle .:saie1iiie'<..''. -rieo ~ -~O ~ ·· -WlMax~ -GSM -l -WiMobile ·GPRS -UMTS Cell Size Figure 1.28: Data rates versus distance DECT Fileed Radio Acce99 FiX8d NelMJrk .Accela ·WLL -xDSL . · • ISDN, P$TN; 5GH~ -i- 11 Gltz - LAN 2,4GHz 2,4and5GHz 10-&&GHz · A·Pta'* ~~ dmerent -Aber· reglMtory domain• WPAN WLAN WMAN I WRA1' ' I Figure 1.27: Fixed and mobile radio access 20 kbit/a - 54 Mbit/a 11 Mbit/a-54 Mbit/a 70 - 134 Mbit/a !lit rate open -loom - 100- 250m - 30- 50km -SO km· Mobility WPAN Wireless personal area network 802.l&e : 15 Mbitla . WLAN Wireless local area network up to WMAN Wlreleaa metropolitan area network WRAN Wirel""" regional """' network Fi&'1lre 1.29: Heterogeneous IEEE radio technologies J 1.1 Network ar chitecture 17 18 Networking © IMU van Allen belt (aHude of 660 - 6,300 km) @ 0-,.n Allen belt (.idtude of 10.000-65,000 km) r: Propagatio11 delay of fiber: 5 11'1/ km 36,000 km 71!\~- Figure 1.32: End-to-End delay components ttttl i ttttl GEO G_.tlonaryO Height Aolalloll $peed S.teAltea p:::::r...!a if..... • LEO 700km 100min 27,000"""" s-10 ms ~·~Sn\1111 > 40 MEO 10.000km 6h 18,000"""" 70-80ms Medium 10 - 15 GEO 36,000 km 24h 11 ,000!unhl 230- 250 ms uroe 3- 4 Figure 1.30: Classification of satcllite systems ,_,- -; ;.. - ...... __ _ GftmUpnea prbjl Height 3',000 km Iridium 795 km 66 sateHites 6 orblta Motorola 1998 Globelstar 1,389 km 4ll sa1eHitea 6 orbits Loral-Qualcomm 1998 10,335 km 12 satel- 3 orbits TRW 2000 Figure 1.31: Sat.cllit.c sy&t.ems in space 1.2 Protocol Architecture 19 20 Networking 1.2 Protocol Architecture General nolation PDUs 7 ------1 ...... 'r!ci'tt~~ t---· i A-POU t·---· A -----~-....--.:::M!!!8ae==-=-..-...... ~----1 p.POIJ f----- p ·······1..I__ ...:Mea!ap=:ii:=----'L .....I &-Pou l--.... -.. s ·····4Pfl!l!!!l1Segnm!!/ ...... L •• ~ T-4'1111 l ..... T...... ,.,., T -----1 !'~el/ Pal!lgtam I Cell ~ - -· -l tu>OU f ..... N Data Link · Frame ~---·JDL·PDUf ..... DalaUnk- OL -----1 Phyojcal -----1 Transmission frame ~ ----~----- Physical PH OSI lnlen>et LAN ATM 0 0 0 OBitslrea110 0 0 0 u.c L Figure 1.33: Protocol arc.hitectures: OSI - IP - LAN - ATM Figure 1.34: Na.ming of Protocol Data Units (PDU) Stratumn Signaling USE< USE< Neiwo11< (conlrOI) oata 1 Data 2 management 2 Stratum n-1 Physical tayero1 Physical intras1n.ctt.we --·-1· layer of intras~ucture l'.,-.L-~-1...~-L.-~..J....~ - n-1 Genenc multMllack protocol refenonoe mociej Stratum concept Figure l.35: Protocol architectures: Multiple stacks and stratum concept 1.2 Protocol Architecture 21 22 Networking Appllodon SOH.Cllenta Cliont·Sys1ams di SDH Eleclrlcal inulllplexer layer - ..1 -81or layer Electrlcal Phyalcel """' Opllcalconnectionleyel' Opllcal muldple• layer SDH layered relerenoe mooei Dpllcal ._..,_,layer - Optlcel phyaical layer ISDN lntoQrale Figure 1.36: Stratwn example Figure L38: Protocol architectures: Management of SDH and optical networks RTP Ru5--time trantPQf1 protocol uw UMI' da&lgram protocol IP lntitmet protocol LLC (logolcal Ink llyet) Q~! Olgtbtt£themet MAC control loptlOnol) Ml'UI Mulll p II'"'" Pl-* . .. PhotJnic Ml'lS ,.,,....,..,..- MPLS tecMolOgy WOM Swilch componenlS Optlool--loyet Oplic ATM IP (endsysteni- 2) Cross-Connect Swit:ll ROWI< ""Yll Figure 1.37: Strat11m example Pigurc 1.39: Protocol architecture of heterogeneous technologies 1.3 Network protocols 23 24 Networking 1.3 N etwork protocols PP'111 LDP RTP RTCP SOP llOOTI' BAP LACP SIP A,. MSol' U.OP ppp OCCP TCP RTSP Ml.AP BAC .MADCAP GAE SCTP CARD RMT DHCP ICMP ICU""6 aoM ' ~ ::' RUDP UDP IClllP DHCPll'4 TCRTP RAAP l!GI' IGMP Ma . Pill-oM IGRP HSRP ~ ~- NOAll l!IG,. DHC""6 YRRf'' H.%35 NAT BCP 1'1111-5111 ..._. ROHC G8E - ROHC - PCE RSTP GTP STP - - CM.DP ~ SSll PPP - Al'MAN' Ul1' lllSTP DNS D- A~ C- ENUll MGCP Cll.JO EGP ....,,r•~ TWNll> RSVP VRfP - _,..GVRP - EIGRI' llCP-4SAP HP RSP OW. llVRP BAP - - GNP TRIP llSlll' l!GP 1'11- SSU GMRP SAP MU> - IPX MEGACO GARI' OSf'I' 11HS Rl""2 NHRP RSVP-TE SNAP MADCAP CA.PW.AP MASC XCAST ARP (address resolution protocol), ATMARP (ATM address resolution protocol), ATMRARP (ATM reverse address resolution protocol), BAP (PPP bandwidth allocation protocol), BGMP (border gateway multica8t protocol), BGP-4 (border gateway protocol version 4), CAPWAP (oon trol and provisioning of wireless 8'XleSS points), CARD (candidate 8()CC6S router discovery), CNRP (common name re10lution protocol), DCCP (data.gram oongesliou ooutrol protocol), ODDS (dy namic delegation discovery ~)'Stem) , DHCP (dynamic host oonfiguration protocol), DVMRP (dis tance vector multicast routing protoool), EGP (exterior gawway protoool}, EIGRP (enhanced interior gatewlly routing protocol), ENUM (telephone number mapping), EPP (extensible provi sioning protocol), FMIP (fast mobile IP), GARP (general attribute registration protoool), GMRP (GARP multicast registration protoool), GRE (generic routing eocaJ)6ulation), GTP (GPRS tun neling protocol), HMlP (hierarcllical mobile IP), HSRP (Cisco bot standby router protocol), ICAP {Internet oontcnt adaptation protocol), ICMP (Internet m~e oontrol protoool), IGMP (Internet group management protocol), IGRP (Interior gateway routing), lnARP (inverse addreo;s resolution protocol), 1Pv4 (Internet protocol version 4) , 1Pv6 (Internet protocol version 6), ISA TAP (intra-site automatic tunnel addressing protocol), TS-IS (intennediate system oo intermediate system), L2TP (layer-2 tunneling protoool), MADCAP (multicast address dynamic client alloca tion protocol), MASC (multicast address-set claim), MBGP (nmltiprotocol extensions for BGP), MEGACO (media gateway control protocol), MGCP (mcdia gateway control protocol), MIP (mo bile IP), MLD (multicast listener dii;covery), MSDP (multicast source discovery protocol), NAPT (network address port translation), NARP (NBMA address resolution protocol), NAT (network address translation), NHRP (next-hop resolution protoool), NORM (NACK--0riented reliable mul ticai.'t protocol), NTP (network time protocol), OSPF (open shortest path first), PIM-OM (proto ool independent multicast, dense mode), PIM.SM (protocol independent multicast, sparse mode), PPP (point.-to-point protocol), PPTP (point-to-point tunneling protocol), RAQMON {real-time application quality--0f-eervi<:e monitoring), RARP (reverse addre&a rcaolution protocol), RARP (reverse ARP), ROMA (remote direct memory access), R!Png (routing information protocol for 1Pv6), RIPv2 (routing information protocol venion 2), rlogin (CC)l'llote login in Unix systems), RMON-2 (remote monitoring ver~;on 2), R.MT {reliable multicast tra.n:;port), ROHC (robust header comprett:don), n5IP (realm specific IP), RSVP (resource reservation protocol}, RTCP (real-time oontrol protoool), EITP (real-time transport protocol), EITSP (real-time streaming pro toool), RUDP (reliable datagram protocol), SAP (session announcement protocol SCSP (server cache synclironization protocol), SCTP (8tream oontrol transmission protocol), SOP (session de scription protocol), SlP (se6Sion initiation protocol), SLP (service location protoool), SNTP (sim ple network time protocol), SRMP (selectively reliable multicast protocol), SSM (source-specific multiea8t), STUN (simple traversal of user datagram protocol (UDP)), TCP (transmiS>iion con trol protocol), TCRJ'P (tuoncling multiplexed compressed ll:rP), TFMCC (TCP-friendly mul ticast congestion oontrol), TFTP (trivial file transfer protoool), TRlP (t.eiephony routing over IP), UDP (user datagram protocol), RRP (virtual router redundancy protocol), XCAST (explicit multi-unicast) Figure 1.40: Network protocols 1.3 Network protocols 25 26 Networking Stl.IN SNTP LoST FOl\CES IRIS OPES DNS lllAP4 BEEP ICAP FTP Finger CCMP CMS ECDH TFTP NIET'COHF GSMP COPS ERP ECDSA MIOCOM pp TGREP ll'CP ESP Cf>IP ECRSA ENRP IU DDDS M081KE EAP KINK mSLP DKIM DH OCSP PEN' ISAKllP IDXP 6NTP - SOAP CM' WPA SAP RWhols Wllois NHTP PPTP n.s MSEC RSA ISAKMP CXTP XMPP DCAP. ROMA . . l2TP LDAP RADIUS S.ffTTI' MKA MIKEY !APOl SSL XMPP ACAi' OWAllP RSerPool LCT ICAP SRTP PGP IEJ'I' GICMP DNSSEC PEii RAQlllON XCAP RSA E.AP SACRED PAP SHA1 ~IME ACAP (application configuration accesK protocol), BEEP (blocks extensible excha.ugo protocol), SE~ PKCS BFCP (binary floor c:ontrol protocol), CAP (calendar access protocol), CAPWAP (oontrol and MAC.IC TESLA CHAP SSH provisioning of wireless access points), CNRP (common name resolution protoool), COPS (oom TACACS mon open policy service), CXTP (oontext transfer protocol), DNS (domain naming service), ENUM (telephone number mapping), EPP (extensible provisioning protocol), ETS (emergency AAA (authentication, authorization, and accounting), AH (authentication header), CHAP (chal telecommunications service), Finger (user information protocol), FLUTE (file delivery over uni lenge handshake authentication protocol}, Diameter (twice RADIUS), DNSSEJC (domain naming directional transport), FORCES (forwarding and oontrol clement separation), FTP (Ille tran,,fer service oocurity), EAP (extensible autb.,ntication protocol), EAPOL (eAP over local area uet· protoool), GARP (general attribute registration protocol), GMRP (CARP multicast regi~tration work), ECP (encryption control protocol), GKMP (group key management protocol), GSAKMP protocol), GSMP (general switch management protoool), HIP (host identity protocol), HTTP (hy (group secure a..' Figure 1.4 J: User and application protocols 1.4 Network availability 27 28 Networking 1.4 Network availability Dual homing Selt-Mallng rtng (SHR) prOledlon switch ,------!'.Q· I Automatic proteetlon •witching (AP$) SeH-heallng network (SHN) _." ® ',Prot.ction " ., ...... (Mllh btldge selector ~ 1 + 1 pmlecilon 1 : n protection Figure 1.44: Switching configuration in automatic protection swi~ching (APS) Figure 1.43: Network availability configurations a- ~- ..... DOMlllln9 --- 98% ao.....--7.30 clays 14.4 hours S.36 hours 7.20hours ·u• hours 9K 3.65 clay• 1 + 1 protection 1 : n ahlred wilh eldra ln16c 99.1% U3dlya 3.60"- 50.4.U.. 99.K 1.71 houn 43.2min 10.1 min 99.99% 5Umln 4.32min 1.01- 99.999% 5.26 min 25.9• 6.05. ~ 31.5• 2.59s 0.605. Protecllon awUch Table 1.1: Network availability figures 1 : n protection 1 : nah•red ahllred P Protection switch Node1 Node2 Node3 Node4 Figure 1.45: Sl1arod protection in automatic protection switching (APS) 1.4 Network availability 29 30 Networking 1.5 Network control fiber ( -wawtengfl cable c: Cable s duct Figure 1.46: Fiber hierarchy 1.5 Network control 31 32 Networking 1.5.1 Network control mechanisms 1.5.2 Performance measures and measurement Overview Longterm This section reviews the stat~of- thc- art in techniques for collecting traf Planning fic measurements in local area networks as well as in large IP backbone Interval networks. Basically we can distinguish between two different measurement approaches for gathering traffic information: active traffic monitoring and Connection passive traffic monitoring. time Interval Propagation delay in181'Val Oetaunlt time Interval Tl'afllc polk:lng Preventive control Reactive Control Figure 1.49: Traffic measurement cla-<>5ification Figure 1.47: Classification of control mechanisms 1. Passive traffic monitoring Passive traffic monitoring accumulates information about the traffic as it travels through the network. A network device passively collects packets traversing a link and records information about those. Collecting the traffic requires an effective way to tap a link in the operational network. This is relatively easy in a local area network (LAN) consisting of a shared media, such as an Ethernet. For example, the network device may be a simple network interface card plugged into a regular computer and running in promiscuous mode to get a copy of every packet. Tapping a link is more difficult in a large backbone consisting of routers connected via high-speed point-to-point links. Thinking of full duplex links, traces may be collected by splitting each unidirectional link into two parts in order to assure that a CAO (connection acceptance control), UNI (user-network interface), NNI (network-network in terface), UPC (user parameter control), TS (traffic shaping) copy of each packet is directed to the monitoring device. Alternatively, the router could include support for the various measurement architectures. As traffic reaches the router, the interface card can make a local copy of the Figure 1.48: Network control packets. But one bas to consider that copying and analyzing the contents of every packet is extremely expensive, especially on the high bandwidth links common in large backbone networks. Figure 1.50 shows how packets are captured and processed when using the passive traffic monitoring approach. It is very important to understand that there are two possibilities how pas sive traffic monitoring can be implemented. On the one hand, we can make 1.5 Network control 33 34 Networking with its NetAow feature. The lETF has made efforts to define standards for fiow level measurement. The Real-Time traffic flow Meter (RTFM) group provided a formal definition of Aows and described techniques for collect ing the measurement data. More recently, the LP Flow Information Export (IPFTX) working group is defining a format and protocol for delivering flow level data from the measurement device to other systems that archive and analyze the information. The vendor and standardization activity reflects Figure 1.50: Passive traffic monitoring a growing interest in the use of flow level measurement as a practical alter native to collecting packet level traces. use of packet based measurements, and on the other hand we can utilize Comparison flow based approaches, which are derived from packet, based measurements. Packet level ven:ms Flow level measurements Flow level measmements arc Packet level measurements Packet level measurement implementations em useful for many of the same purposes as packet level traces. A network ploy three main techniques to reduce the overhead of collecting the data. operator may use flow based statistics to compute traffic volumes by IP First, the monitor can capture and record a limited number of bytes for each addresses, port numbers, and protocols, or basic traffic characteristics such packet. For example, the monitor could record the IP header (typically 20 as average packet size. An ISP may use traffic statistics at the level of in bytes) or t he IP and T CP headers (typically 40 bytes) instead of t he entire dividual customen; to drive accounting and billing applications. However, contents of the IP packet. Second, the monitor may be configured to focus flow level measurements do not provide the fine grain timing information on a specific subset of the traffic, based on the fields in the TP and TCP or available in packet level traces. The flow measurement record provides UDP headers. For example, the monitor could capture packets ba...ed on the timestampi; for the first and last packet in the flow , without detailed in source and destination lP addrcsse::> or port numbers. Third, the monitor formation about t he spacing between successive packets. As such, packet may perform sampling t.o limit the fraction of packets that require further level measurements are much more useful for studying traffic behavior on processing. For example, the monitor could be configured to record infor a small time scale. Flow level measurements can provide some information mation for one out of every hundred packets. Routers that support packet about the throughput experienced by users, based on the number of bytes level measurement typically employ sampling to reduce the overhead on the and the time duration of a flow . However, identifying potential ca.uses of interface card. Flow level measurements Flow level measurement involves low throughput, such as lost and retransmitted packets, is difficult or even collecting aggregate traffic statistics for related packets that appear close impossible without more detailed i.nformaLion. together in time. The abstraction of a flow mimics the notion of a call or connection in circuit switched networks. Since IP networks do not retain 2. Active Traffic Monitoring states about individual data transfers, the grouping of packets into a flow Tb.is approach relics on the capability to inject test packets into the network depends on a ::;et of rules applied by the measurement device. The rule::> or send packets t.o servers and applications, following them and measuring identify the attributes that must match a.cross all the packets in a flow, as service obtained from the network. As such it does create extra traffic, and well as r'*''trictions on the spacing between packets in a flow. For example, the traffic or its parameters are artificial. The volume and other parame a flow could be defined as all packets that have the same source and des ters of the introduced traffic are fully adjustable and small traffic volumes tination IP addresses, where successive packets have an inter-arrival time are enough to obtain mcaningfu1 measw·ements. Active Traffic Monitor less than 30 seconds. Alternatively, a flow could be defined as all packets ing provides explicit control on the generation of packets for measurement that match in their IP addresses, port numbers, and protocol, and have an scenarios. T his includes control on the nature of traffic generation, the sam inter-arrival tin1e less than 60 seconds. The measurement device reports ag pling techniques, the timing, frequency, scheduling, packet sizes and types gregate information for each Aow , such as the key IP and TCP/ UDP header (to emulate various applications), statistical quality, the path and function fields that match across the packets, the total number of bytes and packets chosen to be monitored. Being active implies testing what you want, when in the flow, and the tin1e-stamps of the first and last packets. Flow level you need it. Emulation of scenarios is easy and checking if Quality of Service measurements are available from some router vendors, most notably Cisco (QoS) or Service Level Agreements (SLAs) are met is relatively straightfor- 1.5 Network control 35 36 Networking ward. The main goal of active measurements is to directly measure the Summ ary availability and performance of services provided by the network, from sim In order to clarify the differences between active and passive monitoring a ple end-to-end connectivity all the way to full web client-server exchanges or comparii;on of the most important attributes of the two approaches is shown complex e-commerce transactions. In general, active measurements provide in Table 1.2. the most authoritative verification that the network is functioning properly 1 and that it provides the services it is designed to support. As such, active !~ ~--aifna ·~ <~ ...HmtlllGlllortolrl' PIOC9Cl ..e Sending IMt trailc lnlo the n.i...,k Ot>.nling "4llwork "lfllc: measurements often provide the first indication of trouble when a failure Conftgumlon 11111.111-polnl Slnille or mull-polnl occw·s in the network. In general, active mea:;urements are generated and Dllta•la Small 1.#ge collected at the periphery of the network in general-purpose computers. NMworko,,.,.heed Adclltlonal hlllc Devlee o-'*ild One of the most difficult and potentially expensive engineering problems No oveme.c1 r ap11nar 1a ..ed is time synchronization between different measurement points. Other than !'WJIO• Nelwortc petformanc:e and a,..lablllty Tralllc uuge end chal'Kleltzatlon m011itorlng auch .. delay, pecle! '°'*• Llmlteil network Performance this, active measurements are usually implemented purely in software, and ...... lty llonhoring capellilitlae rely on an infrastructure that is considerably less costly than that required PIOCff8ing .._to modenlte ltvh for passive measurements at line speeds in the core of the network. Fig ure 1.51 shows possible scenarios how test traffic is generated by a test Table 1.2: Comparison between passive and active monitoring packet generator. In general, the goal of active measurement is fundamentally different from passive measurement methods. Active measurements complement passive ~lt:: :: ·- measurement methods; they typically are better suited for detecting per "7'"'-"="" formance problems and outages, and passive measurements arc more likely to be used in the diagnosis phase. ~""' It ~.... IP" ' ""'"--w. Figure 1.51: Active traffic mollitoring The first flow (the upper one) in Figure 1.51 is an example for a ono-way measurement which could for example be realized by injecting UDP test packets into the network, which is the task of the Test pacl 1.5.3 Topology and routing management 1.5.4 Network operation policies 1.5 Network control 39 40 Networking 1.5.5 S ervice level management 1.5.6 Buffer managem ent Appllcetlon Co~lele perttlonlng Co~lea •haring Parllal lllarlng Pigure l.53: Dasie buffor management strategies CP Complete partitioning Complete shrufog Figure 1.52: SLA (Service Level Agreement, Traffic Contract) cs SMXQ Sha.ring with ma.ximum queue length SMA Sharing with minimum allocation SMQMA Sharing with maxiu1un1 queue length and minimum allocation . ' 1.5 Network control 41 42 Networking 1.5.7 Packet classification 1.5.8 Shaping Melhoda: • LAaky Bucl ~.Time Leeky Bucket 0.18&1rNIT TokeftBucket • - -12• del...... _ • Pulftr aize dettnnlnes •lowed bunt llize of dll8 a-.i burst alze of - _,,,.al Ille Input ...... •• Ille output • 0.18 -m flows through • G-rator rate delermlnes the leeky buclcet allowed data rate • 0.18 loea In c:ese Of buffer • Dal8 stream nowe through : Dataatream · 0 overllow e0 token output control ·-~~ • Uniform eta.. a1reem at Ille 0 · O...IO&swllennotokenls ...._. .. 0 •Vlillble Dela'°" when · Smoothed dlta .i... m at No token aYllll•bla Ille output Figure 1.54: Traffic shaping with leaky and I.Oken buckets 1.5 Network control 43 44 Networking 1.5.9 Policing 1.5.10 Scheduling l l 1 1 ---~ ------l l l l Figure 1.55: Scheduling FIFO First-in first-out PRIO Priority scheduling PS Processor sharing GPS General PS RR Round-robin WRR Weighted nR ORR Deficit RR HRR Hierarchical RR FQ Fair queueing WFQ Weighted FQ SCFQ Self-clocked FQ STFQ St.art-time FQ WF2Q Worst-ca.se fair weighted FQ SFQ Stochastic FQ CSFQ Core stateless FQ EDD Earliest due-date Delay-EDD Delay EDD Jitter-EDD .Jitter EDD EDD-FB EDD for finite fuffcr SC-EDD Service curve based EDD vc Virtual clock VDQ Virtual dcsiu1atiou queueing 1.5 Network control 45 46 Networking 1.5.11 Monitoring 1.5.12 IntServ (integrated services) Figure 1.56: NeLworkControUntServ Table 1.3: Services and mechanisms in integrated services Routing and control QoS routing agent Admission control - Reservadon eelup agent Flow identification P.clret scheduler Figure 1.57: ktScrvModel 1.5 Network control 47 48 Networking 1.5.13 Difl'Serv (differentiated services) Fiiter apeclllcatlon: Flltt • Source • llddr9ee • Tntflc: apeclllcatlon TSpec (r. b, m, II) • Source port • Req.-lll*ificaloll Mpee (A) Figure l.59: NctworkConLro\Difl'Scrv Figure 1.58: lntServFlowDescriptor To avoid the scalability problems of RSVP, the concept of differentiated ser Flowsp ec: vices (DiffServ) was developed. ln contrast to RSVP differentiated services work on an aggregation of flows by marking each packet and invoking some Rspec: describes service requested from network differentiation mechanism within the nodes on the packets path. There, - Controlled-load: none depending on the marking, the packet is handled differently. Therefore - Guaranteed: delay target depending on how the packets of a specific stream a.re marked they get a certain quality of service The differentiated service (DiffServ) approach bas Tupec: describes traffic characteristic3 of flow been advanced as an efficient and scalable traffic management mechanism - Average bandwidth + burstiness: token bucket filter that guarantees QoS in a large sea.le network without using per flow re - Token rate r source reservation and per flow signalling (for instance integrated service). - Bucket depth B ln DiffServ, the resource provisioning for the core routers is performed by - Must have a token to send a byte the bandwidth broker in a centralized manner. Such a concept does not re - Must haven tokens to send n bytes quire the storage of Bow states within each backbone router as RSVP docs, - Start with no tokens but simply treats ea.ch packet according to its mark. This provisioning has a - Accumulate tokens at rate of r per second traffic class based granularity, while per-fiow policing and shaping arc done - Can accumulate no more than B tokens only at the ingress routers. As it can be seen, differentiated services are very Per-Router M echanisms: flexible, allowing the support of a wide range of scenarios. The rather static agreements between a customer and his ISP are a disadvantage. Therefore, Admission Control: one reservation may exist for several, pos.5ibly consecutive connections. The - Decide if a new fiow can be supported probability to be able to provide the requested quality of service depends - Answer depends on service class essentially on the dimensions and configuration of the network and its links. - Not the same as policing T his meand whether individual links or routers can be overloaded by high Packet Processing: priority data traffic. Though this concept cannot guarantee any QoS pa - Classification: associate each packet with the appropriate reser rameters as RSVP ca.n, it is more straightforward to be implemented than vation continuous resource reservations and it offers a better QoS than mere best - Scheduling: manage queues so each packet receives the requested effort services. service Differentiated Service Field In both protocols, 1Pv4 and 1Pv6, there is one byte, which allows supporting a kind of QoS over the Internet. The DiffServ field is designed in a way that 1.5 Network control 49 50 Networking it is backward compatible to the 3-bit-precedence field in the type of service exceeded but the user or the company can leave it idle or use it to the (ToS) byte. These already used values arc mapped into the codepoints of full extent of iti:; capacity. The holder of this line shall recognize no in the DiffScrv field. The byte is split into two parts. 1\vo biti:; (bit 6-7) are fluence from the presence or absence of other users. The implementation currently not used and have to be ignored (set to zero). The rest (bit 0-5) is of expedited forwarding service is defined by the expedited forwarding per used as the DiffServ codepoint (DSCP). The codepoint defines the service hop behaviour (EF PHB). The recommended codepoint for the EF PHJ3 is a packet should get in the network and its treatment within routers. 101110. The following propertiei:; characterize expedited forwarding service: • P eak bit rate: On flows or on agi,rregated flows . • No bursts: Only within the peak bit rate. • Low queueing delay: For real-time applications. Negotiating such a service with his ISP allows a customer to send pack ets at a specific rate to Lhc ISPs network. If a packet exceeds this rate it is, in contrast to aSl:iured i:;ervice, dropped. Like a leased line, this ser vice defines an upper limit for the allowed bandwidth but also guarantees the forwarding of packets up to this limit at a constant delay. Assw-cd Forwarding Senrice (AS) Assured forwarding service (AF) provides an ex HopUmlt ception of a certain a.mount of bandwidth to the customers. This means, 4 x 32 = that bandwidth cannot be guaranteed but packets are labeled with high pri 128 bit ority. High priority packets have a higher probability to be transmitted over Destination Add,_ 4x32 = 128 bit the network. ln congestion situations the user of assured fonvarding service should enco1lllter less bandwidth decrease than best effort users. Fom as sured forwarding service classes are defined. Each of these classes has three Figure 1.60: Differential Services Code Point (DSCP) in IPv4 and IPv6 levels of dropping precedence (low, medium and high). The classes allow Within each DiffServ capable router there is a mapping between a DSCP disting11ishing the flows from the best effort service. This means that as value and a per hop behaviour (PH13), which defines how a packet is treated sured forwarding service packets are not anymore reclassified to bei,1; effort within the router. If a PHB specifies to forward a packet preferential to all (default PHB codepoint 000000). They have only higher dropping prece others and that PHB is applied within all routers of a network this would dence. Packets of a microflow are mapped dependent on the classification result in a service providing noticeable better throughput and low delay to to a single class. The different classes will be handled independently from all packets with the appropriate DSCP. The six bit wide DSCP allows to each other. This leads to the fa.ct that within the network, we do not have differentiate between 26 = 64 different PHBs. To allow an Internet service reordering of packets belonging to the same rnicrofiow. For each class, it is provider (ISP) to provide own services only a small number of DSCPs and necessary to implement a single queue. ' ' Best Effort Service (BE) Best PHBs a.re specified. An ISP might map DSCPs at his border routers to effort is the currently used service in the Internet. There is no guarantee provide a similar PHB within his own network. Router implementations for QoS. Everybody gets the service the network is able to provide. This should support the recommended codepoint to PHB mappings. service will have the codepoint 000000 - default codepoint, default PHD. Differentiated Services Classes Differentiated Services Traffic Conditioning During the work of the IETFs DiffScrv working group, several services were Traffic conditioners are required to instantiate services in DiffServ capable proposed. Even if there were several proposals for different services, there routers and to enforce service allocation policies. These conditioners are, are currently only two standardized in RFC documents. Expedited For in general, comprnied of one or more of the followings: classifiers, markers, warding Service (EF) Expedited forwarding service (EF) is 1lllderstood as meters, policers, and shapers. When a traffic stream at the input port of a virtual leased line service (VLL). Therefore, the bandwidth cannot be a router is classified, it then might have to travel through a meter (used 1.5 Network control 51 52 Networking where appropriate) to me&.11re the traffic behavior against a traffic profile Markers: Packet. markers set the DiffServ field of a packet to which is a subset of an SLA. The meter classifies particular packets as in a particular codepoint, adding the marked packet t-0 a particular or out-of-profile depending on SLA conformance or violation. Based on the DiffServ behaviour aggregate. The marker can mark all packets state of the meter further marking, dropping, or shaping action is activated. which are mapped to a. single codepoint, or mark a packet to one Traffic conditioners can be applied at any congested network node when the of a set of code points to select a PHH in a PHil group, according total amount of in bound traffic exceeds the output capacity of the router. to the state of a met.er. The approach of DiffServ and especially As the number of routers grows in a. network, congestion increases due to the asi;urecl forwarding iservice with its different drop-precedence expanded volume of traffic and hence proper traffic conditioning becomes levels, requires specialized components. more important. Traffic conditioners might not need all four clements. If • Meters: After being classified at the input of the boundary router, no traffic profile exists, packets may only pass through a classifier and a traffic from each class is typically passed to a. met.er. The meter is marker. used to measure Lhc rate (Lornporal properties) at which the traffic of ead1 dai>s is being submitted for transmission. This is then compared against a traffic pro- file specified in traffic conditioning agreement. Based on the comparison, some particular packets are considered conforming Lo the negotiated pro- file (in-profile) or non conforming (out-of-profile). If a meter passes this state information to other conditioning functions, an appropriate action is triggered for each packet. • Shapers: The delay some packets in a traffic stream using a token bucket in order to force the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer and packets are discarded if there is not sufficient buffer space to hold the delayed packets. Shapers arc generally placed after each type of classifier. For example, shaping for EF traffic at the interior nodes helps to improve end to end performance and also prevents the other classes from being over flooded by a big EF burst. Hence, either a policer • Classifier: It categorizes packets from a. traffic stream based on or a shaper is supposed to appear in the same traffic conditioner. the content of some portion of the packet header. It matches re ceived packets to statically or dynamically allocated service profiles a.nd passes those packets to an element of a traffic conditioner for further processing. Classifiers must be configured by some man agement procedures in accordance with the appropriate traffic con ditioning agreement {negotiated between the DiffScrv provider and the DiffServ customer). There arc two types of classifiers: Behavior aggregation {B A) classifier: Works on behavior aggregates and classifies packets only based on patLerns of the DillScrv byte (DSCP). Multi-field {MF) classifier: Classifies packets based on any combination of the DiffServ field, protocol ID, source ad dress, destination address, source port, desLination porL or even applicaLion level protocol information. 1.5 Network control 53 54 Networking The network administrator interacts with the DifIScrv con.figuration and • Policer: When clasi;ified packets arrive at the policer it monitors management interface via oue or more management prot-Ocols, such as sim the dynamic behavior of the packets and discards or re-marks some ple network management protocol (S~MP) or common open policy service or aU of the packets in order Lo force the st.ream into compliance (COPS), or through other router configuration tools such as serial terminal (i.e., force them t-0 comply with oon.figured properties like rate and or telnet consoles. burst size) with a traffic profile. By setting the shaper buffer size to zero (or a few packets) a policer can be implemented as a special Optional QoS Agent Module case of a shaper. Like shapers policcrs can also be placed after each DiffScrv routers may snoop or participate in either pcr-microflow or pcr type of classifier. Policers, in gcncraJ, a.re considered suitable to po flow- aggregate signaling of QoS requirements for instance using the RSVP lice traffic between Dill'Serv domains (for instance a customer and protocol. Snooping of RSVP messages may be used, for example, lo learn a provider) and after BA classifiers in backbone routers. However, how to classify traffic without actually participating as a RSVP protocol most researchers agree that policing should not be done at interior peer. DifIScrv routers may reject or admit RSVP reservation requests to nodes since it unavoidably involves flow classification. Policcrs are provide a means of admission control to DillServ-ba.sed services or they may usually present in ingres. These clements will discard packets which exceed the TCS. The set of possible actions that can then be applied include: • DSCP marker: a.re 1:1 elements which set a codepoint (for in stance the DSCP in an IP header). DSCP Markers may also act on unmarked packets (for instance those submitted with DSCP of zero) or may re-mark previously marked packets. In particular, the model supports the application of marking based on a preced Traffic C lassification ing classifier match. The mark set in a packet will determine its Traffic classification policy identifies the subset of network traffic that may subsequent PHB treatment in downstream nodes of a network and receive differentiated service by being conditioned and/ or mapped to one or possibly also in subsequent processing stages within this router. more behavior aggregates (by DSCP remarking) within tho DiffServ domain. • Absolute dropper: It simply discard packets. There arc no par Clas5ification is performed by a classifier element. Classifiers arc 1 : n (fan rameters for these droppers. An absolute dropper is a terminating out) devices: they take a single traffic stream as input and generate n point of the dat.a path and has no outputs. logically separate traffic streams as output. Classifiers arc parameterized • M ultiplexer: This is a simple logical device for merging traffic by filters and output streams. Packets from the input stream a.re sorted into streams. It is parameterized by its number of incoming ports. various output streams by filters which match the contents of the packet or • Counter: one passive action is to account for the fact that a data possibly match other attributes associated with the packet. packet was processed. The statistics that result might be usod later for customer billing, service verification or network engineer ing purposes. Counters are 1: 1 functional data path elements which update a counter by 1 and a packet counter by 1 every time a 1- Byte sized packet passes through them. Counters can be used to count. packets about. to be dropped by an absolute dropper or to M eters count packets arriving at or departing from some other functional DiffServ network providers may choose to offer services to customers based clement. on a temporal (i.e., rate) profile within which the customer submits traffic • Null action: has one input and one output. The element performs for the service. In this event, a meter might be used to trigger real-time traf no action on the packet. Such an clement is useful to define in the fic conditioning actions (for instance marking) by routing a non-conforming event. that the configuration or management interface docs not have packet through an appropriate nextrstagc action element. Meters are logi the Aexibility to omit an action clement in a datarpath segment. cally l:n (fan-out) devices (although a multiplexer can be tIBed in front of a meter). Meters a.re parameterized by a temporal profile and by conformance levels, each of which is associated with a meter's output. Each output can be connected to another functional element. Queuing Elements Queueing clements modulate the transmi~ion of packets belonging to the different traffic streams and determine their ordering, possibly storing them temporarily or discarding them. Packets are usually stored either because there is a resource constraint (for instance available bandwidth) which pre vents immediate forwarding, or because the queueing block is being used to Action Elements alter the temporal properties of a traffic stream (i.e., shaping). The queuing The clas5ifier!l and meters described up to this point arc fan-out elements systems perform three distinct, but related, functions: they store packets, which a.re generally used to determine the appropriate action to apply to a they modulate the departure of packet!:! belonging to various traffic streams, packet. The set of possible actions that can then be applied include: and they selectively discards packets. 1.5 Network control 57 58 Networking Packets are discarded for one of the following reasons: resource management in a DiffServ domain, and some extensions to RSVP • Buffering limitations. supporting DillScrv were developed. A DillScrv cloud provides a virtual • Exceeding of a buffer thresholds. link between IntServ access networks. DiffServ works to allocate backbone • As a feedback control signal to reactive control protocols such as network resources to connect the a.cccss networks. IntServ reallocates the TCP. allocat.ed resources to ea.ch call to satisfy the resource request. Signaling • Meter exceeds a configured profile (i.e., policing). messages such as RSVP Path and R.esv-me~es arc carried as data packets in a DifIScrv backbone network. Access routers conduct admission control Traffic Conditioning Blocks (TCBs) according to instructions given by t he policy server. Resv-messages arc al The classifier, meter, action clement, algorithmic dropper, queue and sched lowed to pass the access router when reoource reservation is possible in the uler functional data path elements described above can be combined into virtual link. A OiffServ backbone nc~work may be composed of multiple traffic conditioning blocks (TCBs). These are abstractions of a set of func DiffServ administration domains in general, and resources are allocated to tional data path clements that may be used to facilitate the definition of the aggregated flows passing between the domain.s based on SLAs. When specific traffic conditioning functionality. It can be considered as a template traffic characteristics change, dynamic SLA negotiations and resource al which can be replicated multiple times for different traffic streaID8 or dif location with support of a bandwidth broker arc desirable. However, if ferent cust,omcrs. When the Diffserv treatment for a given packet needs to resource allocation between domains docs not correctly reflect the traffic have such b uilding blocks repeated, this is performed by cascading multiple characteristics of the aggregated flow, admission control for ea.ch call in the TCils: an output of one TCB may drive the input of a succeeding one. access network may not be consistent with the virtual link congestion state, and individual QoS requirements may not be satisfied. Comparison of IntServ and DiffServ When comparing the DiffServ and IntServ architectures one notices they have some features that may make them complementary. ...... ,...,, Gll&9rv OoS- Pwflow ,,__ EncMCMnd oam.in (edgHo«lge) or DiHSerl region Oo6---.....-vlllloe .. DI- Cenlnilimd - OiffSery dorMln o.dlc8ted orotocol (RSVP) a..ed on OSCP-..led In IP,,_.,.., - ~ Not lor core r-.tcs Scallible In .. parts ol nelM)lt< -~ GS, CL, BE EF,AF, BE Figure 1.61: Compw:i.son bctwt An interoperability framework for the architectures IntScrv and DiffScrv have been defined. The integrated IntServ-DiffServ model is used t,o pro vide QoS in the end-to-end relation. To avoid per microflow servicing in the core, the proposed architecture uses DilIScrv in the core to support ag gregated TntScrv microflows. The TntServ model is used in the access part of the network to provide the applications with the mecbanfams necessary to express the QoS requirements. It provides a user-network QoS signaling interface and forwards t he requests for resources to the network. The QoS signaling is end-to-end: it takes place between the communicating terminals. Apart from per-Bow resource reservation, RSVP signaling can be used to aid 1.5 Network control 59 60 Networking 1.5.14 Admission control 1.5.15 Flow control 1.5 Network control 61 62 Networking 1.5.16 Congestion control 1.6 Mobility Figure 1.62: Micro- and macro mobility 1. 7 Security 63 64 Networking 1.7 Security 66 Source and t ransmission coding 2.1 Int roduction Chapter 2 Source and transmission coding A,,.1og carrier with dlghlll s19,,.1 Figure 2.1: Coding and transmission principle 2.2 Source coding 67 68 Source and transmission coding 2.2 Source coding 2.3 Line coding and modulation 2.3 Line coding and modulation 69 10 Source and transmission co d ing 2.3.1 Binary coding 2.3.2 Block coding Local •"'* networtca S·bit code ...... 10 MblVs Ethernet : 0000 11110 --code 0001 01001 0010 10100 0011 10101 w 0100 01010 0101 01011 thernel·Swilcil 0110 01110 Optical Olier: 0111 01111 1 oo 141111/a : 41168 code 1000 10010 1 Gblla : 181011 code 1001 10011 1 o GbiL'a : 64116611 code 1010 10110 : SB10ll code (I.AN} 1011 10111 1100 11010 '4116 Ubil/s Token ring: 1101 11011 Ollferentlal mancl'lffler code 1110 11100 1111 11101 100 Ubllta FDDI: 0 (Flbet distributed dillll lnlertace) 41168eode Figure 2.2: Block codfag examples 2.3 Line coding and modulation 71 72 Source and t ransmission coding 2.3.3 Convolut ion coding 2.4 Modulation Register mt11ng value: 000 Convolution coder QDclr ~ CodlllrGrt SUr1 000 00 1 100 11 - .2 010 10 3 101 00 • 010 10 6 001 11 Register starling value: 100 Code me r • !'. ( 1 bit -+ 2 billl) Clocl< R11111lel9r Codewor1 Aegl..,alze K• 3 Start 100 11 Bit number per clock k • l Combination rule 1: o, . (111) 1 110 01 Comblnetlon rule 2: o• • (101) 2 011 01 3 101 00 Input bit•-...00101 ..... Slllr11ng velue (000): Code eequence 11,10,00,10,11 4 010 10 Slar1lng velue (100): Code_. 01,01,00,10,11 5 001 11 Figure 2.3: Principle of convolution coding 2.4 Modulation 73 74 Source and transmission coding 2.4.1 OFDM 2.4.2 GMSK Q {• t .., ...... ) XQll 1\ i i 0 0 ..... ' 0 0' F ·I f \ 0' 0 , ·• I 1' 1 1 , rd \ I\ / \ I l l\ .. v \j FOM: C-tionel frequency cllrision multiplex mulll-canler mocklllltlon ledlnlque Figure 2.5: Principle of minimum shift keying (MSK ) '-\;\) OFOM: Orthogonel fNqUency division multlplex mull-carrier -.1a11on technique Figure 2.4: OFOM spoctral overlap Application fields: WLAN Wireless local area ncLworks Figure 2.6: Time signal of MSK Wi.M.ax Worldwide interoperable microwave access LTE Long term evolution ::..-:::-·1 i o 1, :::_ ~... ll.c...·- '°"""y;l,... _____.\. :....._.!. Figure 2.7: Time signal of MSK with Gaussian filter (GMSK) 2.5 System-related coding and transmission 75 76 Source and transmission coding 2.5 System-related coding and transmission 2.5.1 PCM 78 Transmission 3.1 Introduction Chapter 3 Transmission Blt,.te I TOM: Time division multiplex 1000 ~Gblll1----·..;..... < ______ 0.1 ..______.______. . 1 -. 1 I I I I 1992 1- 2000 Veer Figure 3.1: Evolution of TOM transmission systems 3.1 Introduction 79 80 Transmission Chennel Demodulator • Comlerts clgllal 9lgnel Into .,.._ « •...... ,through whk:I\ • c~ received 10000 .______756x10Gbitl• ~ ~and....,.~led algnel pe-on Ila •Y modulated carrlet' ,.d' center trom-torto conlaining dlarwwl ,-- 160x40Gbllls • Common modlMlon acne.-: detwodulet« hnpelrments Into digiW • BPSK slgml 1000.______:=-::....:..=..::==-=..J.>------~ 160 x 10 ClbW•--' • Conwnon dlannel • OPSK lmpeln-u: • Demodul81or las!al 40 x 10 Clbills p-' r=:1 •OOPSK • ,,,.,_ noiee · ~ 1Sx 10 Clbl"• ,.,.D' 16x 2.5Gbitls ~----~ •8PSK • i,,.....no1.. oCoherent 100 • 16PSK • No!H-r emplltude 32 x 2.6 Gbltl• ,D' ,,,•' 160 Gbit/• -- clemoclulldlon •1SOAM ....,,..._ • Hard declelon 18 x 2.6 Gble/s ,0 ,,,O' 40 Gbil/s • Error controt • NofH-r pMe9 • Soft decision 10 .___ _ 4x U Gblt/a.JJ. ,1-1:-,--..:.0._l_;-~-blli------... ! "-rd-err« corl9Ctin0 codlnO retpOnM 'lllffefentlal .. H': ,: .{f£C) • NofHIMer frequency demodullltlon ,, -...... , ...... •Convolutlonal _,,,-0-,_~;Gblt/8 EDFA: Etbiu~fibeumpllfler ....,.... •0.intef1eaving I I • :Blodr . • FEC decoding •Turbo (apeci.I ol block. Mblt/8 cue • Data decoding ~ 0-us eodlng) TOM rmie division multiplex I WDM Wavelengtll dlvialon multlplex • lnterleevlng 0.1 I • Data encoding: . Direct I I I I :;':: .! Di"-1••1 1992 11196 2000 2004 Figure 3.3: Components of digital communications Figure 3.2: Evolution of TOM and WDM traru.ntlssion systems • dB (Decibel) = 10 log 10 (Pr/ Pt): Log-ratio of two signal levels. Named after Alexander Graham Bell. For example, a ca.hie has 6 dB loss or an amplifier has 15 dB of gain. System gains and losses can be added/ subtracted, especially when changes arc in several orders of magnitude. • dBm (dB milliWatt): Relative to lmW, i.e. 0 dBm is 1 mW (milliWatt). Small signals are -ve (e.g. -83dBm). Typical 802.llb WLAN cards have + 15 dBm (32 mW) of output power. They also spec a -83 dBm RX sensitivity (minimwn RX signal level required for llMbps reception). For example, 125 mW is 21 dBm and 250 mW is 24 dDm. (commonly used numbers) • dBi (dB isotropic) for EIRP (Effective Isotropic Radiated Power): The gain a given antenna has over a theoretical isotropic (point source) antenna. The gain of microwave antennas (above 1 Error rate: GHz) is generally given in dBi. • Received digital signals always contain errors • dBd (dB dipole): The gain an antenna has over a dipole antenna • Figure of merit is bit error rate (13ER) at the same frequency. A dipole antenna is the smallest, lea.<;t gain • BER= fraction of received bit;s iu error practical antenna that can be made. A dipole antenna has 2.14 dB • Expressed as an exponential gain over a 0 dBi isotropic antenna. Thus, a simple dipole antenna - 10- 10 (excellent) has a gain of 2.11 d Bi or 0 dBd and is used as a standard for - 10- s (very good) caJjbration. The term dBd (or sometimes just called dB) generally - 10-5 (good) is used to describe ant-enna gain for antennas that operate under 1 - 10-4 (marginal) GHz. 3.1 Introduction 81 82 Transmission 3.2 Transmission media Error rate improvement: • 1\vo tasks: 3.2.1 Coaxial cable o Error detection o Error correction • Basic principal of forward error coding (FEC) coui.1 wire (aaymmetric electrical wire) o At transmitter: Coa~no - Add bits D.nner~le~::.:IOf ~~Coating E - Bit state computed from data bit states I ~~- ~ )I~ o At receiver: Outer eoncluctor - - ""'L------'· ., - For ca.ch bit, compute states ihat should have been received - Identify location of bits in error and correct Figure 3.4: Coaxial wire • FEC very effective: o 10- 3 error rate before decoding o 10-8 error rate after decoding • Encoding techniques o Convolutional encoding (streaming technique) o Block coding (one block of bits at a time) • Decoding techniques o Used with convolutional encoding Quad twisted-pair - Viterbi - Trellis Coating: - Turbo product codes TWo Iron bends (each 0,1 mm strong) o Used with block encoding and ...,.. ·11enct - Reed-Solomon Figure 3.5: Mixed coaxial/ twisted-pair cable Antenna systems Television cable (CATV) Ethcmct 10Base2 and 10Base5 3.2.2 Copper twisted pair C-0pperOl 3.2 Transmission m edia 83 84 Transmission 3.2.3 Fiber 3.3 Transmission techniques 3.2.4 Free-space optic link • Bandwidth (analog and digital). • Tra.rumris.'>ion media. FreeSpaccOpticOl • Carriers. • Modulation and baseband transmission. • 'l\vo-wire, four-wire, and hybrids. 3.2.5 Frequency spectrum • Simplex - duplex; asymmetrical transmission. • Amplification - regeneration. FreqSpcctrumOl • Linc coding. • Multiplexing technique. 3.2.6 Microwave link • Synchronization technique. Microwa.veOl 3.2.7 Mobile radio interface MobilcR.adioOl 3.2.8 Wireless interface 3.2.9 Satellite interface SatelliteOl 86 Switching Chapter 4 Switching 88 P rotocols Chapter 5 Protocols 90 Addressing, naming, numbering and labeling 6.1 Introduction PSTN Public SWftched T~ NelWOftc ISDN Integrated Services Dlgl181 IMtwork Chapter 6 NSAP Netwc)rte ~ Access Point ATM Atynchronous Transfer MOde ----0...... ll'*""'--i NSAP-Add- Physlcal Em.ii Electronic mail 11"'4 Addressing, naming, numbering and ·-Protocol version 4 1Pv6 lntemet Prot~ wrsion e --1Pv4 /_Ad_ llAC·Add,_ labeling IEEE MAC IEEE Medlo.m Acceu Control fly Identifier lntemll Network adcln!Nl1111 Protocof Jaytrs· SN't!OSI-~ SAP Sentlce Acceea Point (Proeoc:ol tlv-4) p-~-modol) Figure 6.1: Numbering and addressing 6.2 IEEE addressing 91 92 Addressing, naming, numbering and labeling 6.2 IEEE addressing Use of EUI-64 identifiers: • IPv6 6.2.1 MAC addressing • FircWire (as the lcast-significan~ 64 bits of a unicast network address or link local address when staLClcss autooon6guration is used) • ZigBee / 802. 15.4 wireless personal-a.>ea networks The IEEE has built in several special address types to allow more than one network interface card to be addressed at one time: Packets sent to the broadcasL address, all one bits, arc received by all sta tions on a local area network. In hexadecimal the broadcast address would be FF: FF: FF: FF: FF: FF. Packets sent to a multicast address arc received 3by... by all stations on a LAN that have been configw·cd to receive packets sent 1 1 22 to that address. Jn addition, the EUl-64 numbering system encompasses IllG IUILI M•nut.ctu,.ldenllfler I j 48 bits both MAC-48 and EUl-48 identifiers by a simple translation mechanism. i I I I I I To convert a MAC-48 into an EUI-64, copy the OUI, append the two bytes : L_ • UIL • 0: UnllterMlly •dmlnlllerecl llddr- FF-FF, and then copy the organization-specified part. To convert an EUI- : UIL • 1: Locally -nlat91911 •dd,... By1ewlM inversion of bit MqUenee: 48 into an EUI-64, the same process is used, but the sequence inserted is L. ---• WG • 01:: GrouplncllvlMI IH!dr.- llddr9M I Internal lwiijil I I I I I ' I FF-FE. In both cases, the process can be trivially reversed when necessary. T,.nsnHslon I -j-j--,--,--j-1;.;.jMI, Organizations issuing EUI-64.s arc cautioned against issuing identifiers that could be confused with these forms. The IEEE policy is to discourage new uses of 48-bit identifiers in favor of the EUT-64 system. IPv6 which is one Figure 6.2: IEEE MAC-address of the most prominent standards thaL uses EUI-64, which means thaL it treats MAC-48 as EUl-48 instead (as it is cho:;en from t he same address pool. This results in extending MAC addresses (such as IEEE 802 MAC address) to EUl-64 using FF- FE rather than FF-FF. 1 1 22 Individual address block IWO I-1 llenuf~clenlftet I All - (l'Nfl I An Individual Address Illock comprises a 24-bit OUI managed by the IEEE : : \....______J I I -Y-- Registration Authority, followed by 12 IEEE-provided bits (identifying the 1 I "-Ion I I I I organization), and 12 bits for the owner to assign to individual devices. : :_ _ • WL • O: U...... ly ••lnl9'eted addresa An IAB is ideal for organizaLions requiring fewer than 4097 unique 48-bit 1 WL • 1: LOQ!ly-ni.t-.ct- 1 I numbers (EUI-48). • llG • o: 1nc11v1c1ue1 •dd,.. Insertion of: • FF- FF ~----•l/G . 1 : ~oup•ddreu I I · FF- FE Bit-reversed notation The standard transmission order notation for MAC addresses, as seen in the output of the ifconfig/ ipconfig co.lllllliUld for example, is also called Figure 6.3: 64-bit TEEE MAC-address within 1Pv6 addressing canonical format. However, since IEEE 802.3 (Ethernet) and IEEE 802.4 (Token Ilus) send the bits over the wire with least significant bit first, while Use of EUI-48 a.nd MAC-48 idcutifiera: IEEE 802.5 (Token Ring) aud IEEE 802.6 send the bits over the wire wiLh • MAC-48 is used for network hardware. most significant bit first, coufnsion may arise where an address in the latLer • ElJI-48 is used to identify other devices and software. Thus, by definition, EUl- 48 is not in fact a. MAC address, although it is syntactically indistinguishable scenario is represented with bits reversed from the canonical representation. from one and assigned from the same numbering space. So for instance, an address whose canonical form is 12-34-56-78-9A-IlC would 6.2 IEEE addressing 93 94 Addressing, naming, numbering and labeling be transmitted over the wire as bits OLOOlOOO 00101100 01101010 00011110 6.2.2 Address R esolution 01011001 00111101 in the standard transmission order (leabt significant bit first). But for Token Ring networks, it would be transmitted as bits 00010010 00110100 01010110 01111000 10011010 10111100 in most significant bit first order. If care is not taken to translate correctly and consistently to the Station X Slatlon 8 canonical representation, the latter might be displayed as 482C6AlE593D, I I ARP Nply I I I I 1 which could cause confusion. This would be referred to as Bit-reversed L--~~~!~~ _____L ------_; order, Non-canonical form, MSB format, IBM format, or Token Ring format as explained by RFC 2469. Canonical form is preferred, generally because IT able In RAAP•Server: I the more modern implementations do not use non-canonical form. MAC ~ - IPaddreMft I I RAAP reply I 1 : RARP request : L------l------' Figure 6.4: Basic operation of ARP and RARP Address R esolution Protocol (ARP ARP (RFC 826, 1982) performs mapping of an IP address to a physical address (MAC address for Ethernet) that is recognized in the local network. A table, usually called the ARP cache, is used to maintain a correlation between each MAC address and its corresponding IP address. ARP provides the procedure for ma.king this correlation and providing address conversion in both directions. Since protocol details differ for each type of local area. network, there are separate ARP specifications for Ethernet, Frame Relay, ATM, FDDJ, HIPP!, and other protocols. Reverse Address Resolution Protocol (RARP) RARP (RFC 903, 1981) allows a. station in a local area network to request its IP address from a. gateway server's Address Resolution Protocol (ARP) table or cache. A network administrator creates a table in a local area network's gateway router that maps the physical MAC addresses to corre sponding IP addresses. V\Tben a station is set up, its RARP client program requests from the RA RP server on the router to be sent its IP address. Assuming that an entry has been set up in the router table, the RARP server will return the lP address to the station, which can store it for future use. RARP is available for Ethernet, Fiber Distributed-Data. Interface, and Token rung LANs. 6.2 IEEE addressing 95 96 Addressing, naming, numbering and labeling 6.2.3 LLC addressing LAH&tdon Layer-'I 1ddresa ------~ Layer-2b •ddr... ------·I I I 1 !MAC 11ddr., U.C .:...ir.!-. llddr.! Ellllfnel PA DA SA IEEE802.3 .....!ri3,. , T.' • • • 2 -.a-1soo- • bytee IOUMAC ..2.2U.C MAC (Medium aooess prot.ocol), LLC (Logical link control), NSAP (Network service 8(:()eSS point). LAN (Local area network), PHY (Pby>lical layer) Figure 6.5: lEEE LAN addressing 802.2SHAP J 802.3 MAC I 1112.2 u.c: l·f" COCll 0 I TVPel ;''tik·''.:,:, 14 3 3 2 ·3'- 1492 4 I OIOO I IPP9C1o1t 2 21 10 1-1 ARP~ IPA.DI 2 2AI 10 1-1 AARPrequesW-- j PADI Figure 6.6: IEEE LAN addressing 6.3 Internet addressing 97 98 Addressing, naming, numbering and labeling 6.3 Internet addressing OHS Domain n.,,,. •V91em ENUM (telepllone number m.pplng) TLO Top level 8QGr•a81or NAPTR N8mlng •ulllorhy pointer .ml Mlll•ry units +43 , 58801 38800 ODDS Dynamic clelegetlon diacOll'llry system .gov Govemmenuil unlt9 o.o.8.e.a.1.o.e.e.1.1.3A.e164.arp9 ·"'11 0'119nirationa euc:ll •IEEE Jnt ln-liol..i Ofl'lnileliona Adol Sc:llools, lnllllutea, ...1vwa11es RFC .net ..... openoton/provldln ...... ~ . - riliml i'*-INCWNI ldenlihr ..- 3172 ,com Commercilll enterpri.a e164.erp8 E. 164 numbers to Int-I URI& 3761 •-.arP8 1Pv4 a-.- to Int-domain Nm9S 1036 lp6.arP8 IPv& .-.-to lnl9rnet domain Nm9• 3152 Cocnpeniea In genenl Alrtl,_ and lnlvallng •~neiea lrla.arp9 Loc9tlng Internet F8Qlatry Inform.lion •rvlc:a 4698 PTlwite domeln urlarpa RMol1rlng unltorm rMOUrc:e ldentlllen acconllng lo ODDS :MOS ...... ,,,...,. AeaoMng uniform rMOUrc:e narnea -ding to DOOS 340S Federations, aodetlM Contentprovar ProfeuloNll groups Figure 6.8: DNS hierarchical naming structure with a.rpa. extension ONS (domain name system), Tl,O (top level domain), gTLDs (generic TLD), ccTLO (country codeTLO) Figure 6.7: DNS hierarchical naming structure Figure 6.9: Registration domains 6.3 Internet addressing 99 100 Addressing, naming, numbering and labeling .ac Aacenelon laland = D..__rie .en China .fl< Falkland laland8 .iid Andorra .bh Bahrain .co Colombia .tm Mlcroneela IFed. .ae United Arab Emirates .bl Burundi -:> '' ;er .COSla .Rica .to Faroe lelands ... Afahenislan .bl Benin ·" .... :cu cubli· :T: .fr France .gov ~ uclu8lvely for the United S-Go...-nt (operator: US General Servlcee Admliil.ballon) .al A--"Ila .bn Brunel Darul881am .cir ~· lelancl . ;ab United Kl...... ,.m · .edu ~ :tor~ inatitutlons accredltecf by an agency on the U.S. Oepat1menl ol .al Albenla .bo Bollvla .cv .,,....;.;;:' .': : . ··. .... ,... ad Gienad8 Edueldicln'9 1191 of Nllllorwll nized Accnditi Ii lstrallon: Educe... .am Armenia .br Brazil .cz· Czeeh··R-""lc· "'· '"""' Georala ·· ':.i · Netherlancle Antllle'5 .bs Bahamae .de r---- ' '·nt French:Gulana Jnl lJMd only for regiellldng Qivanlzallon• eetabllehed by lnlemalional treali4ie ~ · ··· · · ;40· a=··· · .bl Bhutan .di Dllboutl )in Guer- emmente. . : IANO\.lnt Domain R is · ·.;..; A:ntarc:llca· .bv Bouvel Island .dk Denmark .ah ·011arw .-· AtiM'ntina ~ ...... Bola- .- Dominica .al Gibraltar ,1>om9ln for I .as American Samoa ... .tw Belarua .do Dominican a-..,;· .al G,_,._ Addren and Routing P...... ,. "'*domain and exclU91vely for lntemel-lntreatruc:Ue purpoeea, .at AU8tria .bz Belize .•dz Alaerla .am Gambia RFC 3172 (9dmlni-or: IANA) ...,. .au A ..1ra11a .ce Canada TI ,,,.,. .iii: - .an Guinee ~cHftel domains: e164 .nn Guadelou"" .aa Eauat Gulnee,, · .az Azertlallan .cf Central African °-. .eh · Western Sahara. :nr Greece Figure 6.10: US and ARPA registration dolllains .a. Sou111r-1a·· .i.t Guatemall,. · .bd Be_._..._.,, c:c · ·' .:: ·.c1 Cote d'Ivoire .et Eth...... , .au a.. m .be ....,,.um ·'' :Cle Coolie l9lend9 .eu Eu-n Union .- Guinee-Bieeau .bf Burkina Faeo .cl Chile .II Finland .av Guvana ·'* HonaKona Figure 6.12: Country code Top-Level Domains (ccTLD) - Part 1 ...... ~ . 1-Aaalgned Nunmer Aulhc!rltY ~-~·., · T.-~· - ..i DomainatccTLD' ··~ =·= - DedlC8led to preeervlng the ~. coonliialing func;tiona of the global .hm HeerdlMcDonald Isl. .kn SainU \ 6.3 Internet addressing 101 102 Addressing, naming, numbering and labeling 6.3.1 1Pv4 addr essing 11 31 c.... A ~lo~l ___7_bib __ ~ _ __8_bi_1s __ ~ _ __8_blts __ _ ~_ __8_bllS __ ~ N-octt ldentlller ------Ho.t ldenllllet ------. -Nelwork Identifier ---.---- Ho.I lclenlll•r ---- - 8 llill lblle • bib ------octt idenlller ------·---- c.... D 11I1I 1 Io I 4bll• 8bil8 8 bils 8 bits llulllceal-groupa i ~- :n.J)I ... s..IAnbia ... S.OT .to r- .¥C SM>! Ylnc:enC .ab ~ ...... -Unionloldl .ID Eat~ .... venezuei. .ac ... Bs.Nedor ... r.- .va ,,,,_,,....,. Cla• E 11'11111 1 4 bile 8 bits 8 bits 8 bits TrtnldeG'T.-... Vi... ft ...... SUdwl .ti . vi ~-lel ... Sweden .u- s---.-..SllUllllnd .IY TUv.iu .Yll .tc Turtca/C•lcos lslende .tw r--. .vu v...... iu ·-.sh s.lnl Helene .Id Ched .lz TllnUl1le .wt --Wellla/Fulune lal. ;91 Slownle .tt Frwncto Soulhetn Terr. .UI Uk..ine .we S8ln09 Fibrurc 6.15: IPv4 address classes .81 sv ..--en .... .ta r- .ua v...... _.,.,. ·* saov•--c .th Th9lllnd .Uk ·-~~ .YI .al Slernt Leone .ti T.. lldet8n .vu y.-.w. .... us lllnor lei. a.. Mlil-"8 ..... ~- .lk r-. ~~n.-- Sault\ Af1tc:a 1 .... s.n ...... a A 126 2 -2 16777'214 :za•- 2 1.0.0.0 126.0.0.0 .an ' ~ .ti ~ .... ,..._.... .zm Zembia 8 16'384 2" 65"534 211 - 2 128.0.0.0 191.255.0.0 .eo Somelle .Im T- .uz u--.. .zw Zlmllebwe ..• z21 192.0.0.0 223.255.255.0 .er Su!'l!leme •In r...i• .Ye Vllllc.ncnvs- c 2'097"152 264 2'-2 D 224.0.0.0 239.255.255.255 E 240.0.0.0 25U56.255.2S4 Fit,TUre 6.14: Cowitry code Top-Level Domains (ccTLD) - Pa.rt 3 Table 6.1: IPv4 address classes: Number of networks and ha."t.S 6.3 Inte rnet addressing 103 104 Addressing, naming, numbering and labeling All zeros (32 bits) Figure 6.16: Special 1Pv4 addresses I Subnetlng ,L,,, . '.o" .. ,., ~. IP add,_. 1 ICUP ln_t.control mesaaoe protocol 2 IGMP llllemet group me,..gement protocol • bits 3 GGP Gateway.to-gateway protocol 1 1· 1 1 :.... :...... -~ 1 11 ...... 1 00 ...... 0 IP IP en lation n bits •bits (IMI) bits :·. Su-ork •. ·! .~format Networtc identifier Subnet identifier Host ldenHer v-on. Encapsulation security poayload f« IP"6 Authentication header f« IPV6 Figure 6.17: IPv4 address subnctting Open shortest paltl Figure 6.19: IPv4-header addr€SSing tree: P rotocol numbers 0 1Paddre5S 0 ~ · NMwc>rtc = ..~I __ 1_ 1_1_1_._..._ .... _.. _ .. _ .. .._ .. _ .... _ 1__ ~ __ __0_0_ .. -_._.._o ___ __,I 0 31 V11n•l>lli· netwoc1t Not evaluated address part prefix lddresa Variable netwb.1< prefix (13 to 27 bits) I Classless address routing I Figure 6. 18: C las.~l ess routing of IPv4 addresses \ 6.3 Internet addressing 105 106 Addressing, na ming, numbering and labeling ...... _ 6.3.2 1Pv6 addressing II 255.0.0.0 16777216 112,,, ----211.240.0.0 1M8576 ....._ 255.255.0.0 15536 _____ /20 255.255.240.0 121 211.216.24&.0 F-ol- 122 255.255.252.0 -11124 123 255.255.254.0 -612 124 256.255.251.0 256 125 211.256.251.128 128 12,5% 121 211.255.255.112 6' /27 211.255.215.224 32 128 211.255.255.240 16 121 255.265.255.2q 8 3,1% /30 255.255.255.252 4 131 255.255.255.254 2 6 132 255.255.255.255 1 1, '"' 7. 0,8'1(, Table 6.2: 1Pv4 host count by prefix length 0,4% 0,2% 10 0,1'1(, Figure G.20: 1Pv6 address prefix tme 6.3 Inte rnet address ing 107 108 Addressing, naming, numbering and labeling • 112 bite ' ' Group ID Ulblta =::; I 11111111 FP Tl.A Ree NLA SL.A 1~10 • 4 • • • 64 32bila RFC 3306 I 11111111 I Reos I Scope 1---1Prefix tanoth I Network pretlx I Group ID I lllulliCaatprefix 24 bite 24 bits Sc<>Pe 0 reMl'Ved organization-local scope NL.A ! ILA I 1 node-local scope • ...... Raos:OO PT • 2 lnk~ocal acope A n bite ······ :~~-·-····· 1 i nl bite n2 bits n3 ~----..... P ,- o Normal lllultiaiat addr- NL.A I NLA1 I NLA2 I NLA3 I ~;~ ""11 Prellx·baaed lllullcaat addreaa e permenenlly·aaalgned {well· • ait..iocal acope 24-n bite 24 - (n1 +n2+n3) bite known) multlcasteddraaa • D non-permanetilly.. aalgnad E Further decompoaltton of SLA-Addrea- 16 bits (tranalent) mulll<;aat add,.aa •7 F ! SL.A FP: Format Prefix (001) Figure 6.23: U nicasi prcllx-ba.scd 1Pv6 multicast address (RFC 3306) Tl.A: Top Level AggreQlllor (Netwo Figure 6.21: 1Pv6 unicast address format ~local..,._ Ff01:0: 0:0:0:0:0:1 Al nodes addreu AFC 2373 Ff01:0:0:0:0:0:0:2 Al r-- AFC2373 Unlc-locel acope FRl2:0:0:0:0:0:0:1 Al nodasaddreu AFC 2373 FRl2:0:0:0:0:0:0:2 Air...-.- AFC2373 FF02:e:Cl:0:0:0:0-.4 OVllRP.- RFC 1C111 l'Ft2:0:0:t:O:O:O:I OSPF....-. RFC2321 fNIZ:e:O:M:O:O:I OSPF ,.,....,. RFC 2321 FFtZ:M:M:O.~ ST-. AFC 1190 FF02:e:o:M:O:O:e S T'-*9 AFC 1190 8bb '* , .... 112bila FF02:0:0:0:0:0:0:t RPr-. AFC2000 FRl2:0:0:0:0:0:0".A EIGRPr- 1111 1111 ..... I Scape I Group ldenffet FRl2:0:0:0:0:0:0:8 ...... __ .. AIPW-.S Scope FFG2:0:0:0:0:0:0:0 FFOZ:O:O:O:O:O:O:I! RSVP...... ,...•i.tlon R..,,,..i 0 • Organizaliof>.local """" FFll2:0:Cl:lt0:0:0:11 Al llLDv2-caDable routera AFC3810 1 Node-local scope • FF112:0:0:0:0:0:0:IA Al-Snoopers RFC4286 2 Unk~ocal scope A FF02:0:0:0:0:0:1:1 Unknarna Fiiio•: CIOOT 3 . a FF02:0:0:0:0:0:1 :2 Al·DHCP...,.nte AFC3315 4 . c Ff02:0:0:0:0:0:1 :3 Unk-local mullcaat n11ma IHOlullon RFC479& T• O Pet,,.nently·aNloned (wet~ known) mulllcHt adclreaa I Site.local scope 0 FF02:0:0:0:0:1:FFXX:XXXX Solicited-node addr- RFC 4291 T• 1 Non-permanently.. Nlgnad . Global acope FF02:0:0:0:0:2:FFOO::f104 Noda lnfonnatlon quarlaa RFC 4620 (t,.nalenl) mulUc•t •cldr•• •'i . ~• Reaetved Site-local """" FF05:0:0:0:0:0:0:2 Alr.,.,.ra•- RFCzsn FFOS:0:0:0:0:0:0:3 Al·DHCP._...ra RFC 3315 FF05:0:0:0:0:0:1:1000 • SIMc. locaillon m;:? 3111 FFOl:0:0:0:0:0:1 :13FF Figure 6.22: !Pv6 multicast address format Figure 6.24: 1Pv6 well-known multicast addresses 1 6.3 Internet addressing 109 110 Addressing, naming, numbering and labeling 6.4 Internet protocol stack internal a ddressing Wel~known ports Protocol ...... -S 24 31 13 NTP Network time orotocol 1 ICMP lnlemel control ,,,....ge protocol 1Pv6 20 FTP Fiie transfer orotocol • dale 2 IGMP lnlemet grouo manaaement protocol Hoplllllt 21 FTP Fiie transfer .,,.,.ocol - control data 3 GGP Ga•way..to-aatewllV orOIOCol 2S SMTP Simple IMll tr.- protocol 4 IP IP enc:apsulatlon 53 DtlS D-1n ,..... ayslem 8 EGP Enlrior gn.y pn:ilocol 80 HTTP Hyper lext tranlfer protocol 9 IGP ln-vatew•Y protocol 4x32 s 119 NNTP NetwOltc news tran.-r protocol 41 1Pv6 1Pvereion6 128 bit 50 ESP Encapaulation •curlty peyload tor 1Pv6 Well-known ports l 51 AH AU111entlcation heedar for IP"6 52 OSPF o-.. ahorte.t aeth I . ..31 :II I ~ I Protocol Base hellder and one extenalon header -\Lnumber = 6 • 17 number ------I =-~= I '=~ I ;;;;; I I • I I """ 11 AARP I - headerandtwoe- hellders ~l 806 8035 r I :::::.':o: I :: I lc\;c. ~ !lhenllti!llD.. Taun rtnl~ it.¥ i'if\\'!il Figure 6.25: 1Pv6 header addressing tree l~igurc 6.27: 1Pv4-hcader addressing tree 6.4.1 SNAP {Subnetwork access protocol The subNetwork access protocol is an a standard for the transmission of IP packets over IEEE 802 nctworfil;. SNAP is included in an extension of Lhe logic link control (LLC IEEE 802.2) header and is used for encapsulating IP option8 packets and ARP requests and repliei;. The SNAP header follows the LLC 41 header and contaius an organization code indicating that the following Lwo 43 bytes specify the EtherType code. "'51 60 50 lOC 58 59 Figure 6.26: 1Pv6 next header numbers 6.4 Internet protocol stack internal addressing 111 112 Addressing, naming, numbering and labeling 6.4.3 Protocol numbers !AIM " 0 HOPOPT 'IPvt Ir- .... ~--= 50 ESP lenc:a-ulatecl ..curllv ~loadl 1 ICUP. •Internet control --"""ocoll 51 .AH laulhentlc:atlon IMldlrl . · >•· ... 802.2SHAP 2 IGUP Unternet n"""' 11111n11gement nt040Coll 52 ·1-NLSP (lntear••d net lever~ TUBAi 3 GGPTnate-·to---- · ...... oc-,;n 53 SWIPE llP with ---onl ID2.3MAC lalUC I Orgcadlt I 1Wlfl 0.18 CRC 4 IP ftP~rHP en--·~dOftl 54 NARP INllMA ·~ reeo1ution __._...., 5 S-m lllOBILE llP mobllltvl '14 3 3 4 2 38-1492 6 TCP llNnenllulon control ...... ocoll "M TLSP tn-...... _ --...... ,.. 7 CBT 57 SKP IP pmc:la9I I SNAP (RFC 1042) I 1-1 8 EGP t.oxterlor --.. rwoeocdl 58 1Pv6-ICUP llCMP tor IPvll aubNetwonc acceee pttllocol IGPtenv _._.. Interior...._, 2 28 10 9 59 lf>v6.fjoNJl1 Ina next hMdet tor 11'1161 10 BBN-RCC-UON IBBN RCC monltonnal 60 1""6-0ple (~ -1ons Int 1Pv6) 1-1 ARP~ IPADI 11 NYP·H 1-ofll llOlce -ocoll 61 Anv hMt ~I nrotocol 2 28 10 12 PUP 62 CFTP ..... 13 ARGUS 83 Anv local netwnrtc 1-1 RARP request/re&poMe I PADI 14 EUCON 64 SAT.£XPAJC ISATNET end bacl 6.4.4 Port numbers Port numbers are divided into tbn.'C ranges: • Well-known ports are those from 0 through 1023. • Registered ports arc those from 1024 through 49151 • Dynamic and private port8 are those from 49152 through 65535 IANA--100 GlfTP 123 PrP IDelTGrlllWICI ,,.__ aratocoll 101 IF• 0Dlilon flow mena-.t Dl'Otoool) 124 ISIS0-1Pv4 102 PNNI lov.,. IPI 125 ARE 103 PIM laratoex>l lndeDendSll multieaatl 128 CRTP IComlJat raclo tr.,tDOr1 aratocoO 104 ARIS 127 CRUDP (Combet rdo - dllllaram). 1Cl5 SCl'S 128 SSCOPllCE 108 QNX 1211 IPLT 107 AMlec:he~I 130 SPS ·--~ 9hleldl 108 IPColnollP - Nntoccll 131 PIPE -1Pence--llffm IPI 109 SM' ...... -ar11a irat"""" 132 SCTP lllr-como1 •...mlUlon oratoccll 110 lCom- - NnlOCOll 133 FC !Able Cha"o-• 111 IPX-ln-IP llPX In IP) 134 RSVP-E2E-IGHORE 112 VRRP lvlrtwl roul., redundlncv arotoooll 135 llObilltv heecler 113 PGM IPGM Nll8ble lr.,aDOr1 protocol) 138 UDPLlla 114 Anv 0-hOD nmtocol 137 lllPLS-in-IP 115 L2TI' ll•wr-t-tunnellna arotocoll 138 llanfll aratoeola 1115 DDX lD-1 elm •ct.nm\ 139 HIP lho81 identltY protoccll 117 IATP llnlerKlve.....,. •alllfar iwat....,.,. 140 Shlml iwotocol 118 STP ,.,.._.,.,...... -~1occ11 141 WESP MCUritV .,....,_, 119 S RP ,...,_.,., ,,.radio arat....,,., 120 un 253 &-i-anclleflla 121 S• lalm"'"' met•ae Dl'Olocoll 254 FY-'-and (efllt 122 SM 2515 ~- (':'igure 6.31: IANA protocol numbers 6.5 D NS (Domain name system) 115 116 Addressing, naming, numbering and labeling 6.5 DNS (Domain name system) The Domain Name System includes several other functions: • Hostnames and IP addresses do not ncces.sarily match on a one-to one basis. Many hostnamcs may correspond to a single IP address: combined with virtual hosting, this allows a single machine to serve many web sites. Alternatively a single hostna.me may correspond to many lP addresses: this can facilitate fa.ult tolerance and load distribution, and also allows a site to move physical location seam lessly. • There arc many uses of DNS besides translating names to IP ad port53 dresses. For instance, Mail transfer agents use DNS to find out where to deliver e-mail for a particular address. The domain to ~ mail exchanger mapping provided by MX records accommodates ~ another layer of fauJt tolerance and load distribution on top of t he The most basic task of DJ\S is to trrulSlat.e host names to IP name to IP address mapping. addresses. DNS also performs other important tasks. Pre • Sender Policy Framework and DomainKcys instead of creating eminently, DNS makes it possible to assign Internet names their own record types were designed to take advantage of another to organizations (or concerns they represent), independently DNS record type, the TXT record. of the physical routing hierarchy represented by the numerical IP address. • To provide resilience in the event of computer failure, multiple DNS Because of this, hyper links and Internet contact. information can remain the servers a.re usually provided for coverage of each domain, and at the same, whatever the current IP routing arrangements may be, and can take top level, t hirteen very powerful root servers exist, with additional a human-readable form, which is easier to remember. People take advan copies of several of them distributed worldwide via Anycast. tage of this when they recite meaningful URLs and e-mail addresses without caring how the machine will actually locate them. The domain name sys 13 Root__.. with tem distributes the responsibility for assigning domain names and mapping • Aellabllty them to IP networks by allowing an authoritative server for each domain to -1.oed.....ing--- keep track of its own changes, avoiding the need for a central registrar to be continually consulted and updated. Institute Rl'C 1034 s Domain namea ·concept• and facllllea. 1987 1036 S Domain na_. ·Implementation and specification, 19a7 Figure 6.32: 0)1$ hierarchy 3596 D OHS enan.lona to support IP -alon 6, 2003 Table 6.3: DNS (Domain name system): Standards l 6.5 DNS (Domain name system) 117 118 Addressing, naming, numbering and labeling Domain names - concepts and facilities RFC 1034: ~I R~ -RMpoMe -RMpoMe Figure 6.35: Preferred name i,yntax (RFC 1034) Figure 6.33: Types <:i DNS req uest~ Figure ().34: Sequence of Domain Naming System Requests 6.5 DNS (Domain name system) 119 120 Addressing, naming, numbering and labeling Domain names: Implementation and specification RFC 1035: I Local host I I Local host j' .: i .)~~.~~J r----. ··•I ·· User queries •I user,.ponses Responses: I I ·;I ";;:: :::/:i I I · I I Figure 6.36: DNS configuration l (RFC 1035) Figure 6.38: DNS configuration 3 (RFC 1035) . ··; ·"\.i• .. .I . Queries · • . '· j Local Ho&t I Responses: Queries I FCMelgn I Resolfl!r 1 . i--:-:----_, : reaolvet Res~: I I Figure 6.37: DNS configuration 2 (RFC 1035) I ReferenCH 1 I I I I I I I I I I I Maintenance reapon""8 I '------' I Figure 6.39: DNS configuration 4 (RFC 1035) 6.5 DNS (Domain name system) 121 122 Addressing, naming, numbering and labeling A N$ MD 3 M811 dednatlon IObsoiek.! • uee MXI Iii:' CNA!llE ,, , .s canonical -ne tOi- a...... SOA MB . MG MR 9 Mall reneme·dOmllln name ., NULL 10 NuD RF.I' . . ,. ·.:·:: ':·:','; ·. " WK$ 11 Well-known ..,,;ce deacrinnon PTR 12 Domain - DOinler HINFO 13 Host information MINFO 14 MailbOx or mail list information MX ' " TXT AXFR. '<' :,, .. 252 TtanSterOtarl'entire zone MAl(B ,,:-_ ..,., 253 Mailbox"'"°le!l.:JI~ (MB,, !llG or MR) MAILA 254 I Local Hoel I Figure 6.41: DNS type values (RFC 1035) Recursive que RD6f8 (YI!~) ..,. Figure 6.42: RR (resource record) Format (RFC 1035) Figure 6.40: DNS configuration 5 (RFC 1035) 6.5 DNS (D omain name system) 123 124 Addressing, naming, numbering and labeling • 1 6 12 11 •... lier ' OR: Query (1); '*-12) ON Opcode (u trc IRD!RA( z IAolcol Acodo Authorilai ve .,._ v.... RFCe AA:. -A 1 Hoeleddreu 1035 ODCOUNT TC: Tn.wicallon NS 2 Aulllorb•ve ...,,,._ 1035 ANCOUNT RD: ~dMlred MD 3 Mel dedndon IObeo!Me • .-MXl 1035 RA: ~ NSCOUNT ...... MF ~,~ ..,. AD -Dele (RFC4035) ' ...... ARCOUNT CD Cheeldng Dlubled (RFC 4036) CNAllE 5 C.nonlcel - for en .... SOA g Stert of • zone of _ ...... , 1036 MB 7 QDCOUNT: Number of 9fllrleo In quoollon Mellon MeilelMlo _ x_ domain_ ...... ,. - MG ANCOUNT: Number of RRe In.,,..... eectlon • NSCOUNT: Number of neme _, RRe In •""-illf l9COrdo MCtion MR 9 Mell ,_doma in neme 1035 ARCOUNT: Number of RRe In Mlclllonel -0. Mellon NULL 10 NullRR 1035 WKS 11 Wel-llnown MNtce dncr.....,.n 1035 PTR 12 Dorneln neme """'* 1035· -~~- -0 ....lkii~ HINFO 13 Hoel lnforrnelon 1035 1 IQUERY lobeolel9dl ·-0 NoError No onor MllFO 1' M.ilbox or maU Hat Information 1031 2 Si.tue 1 FormEr r Formet error lllX 11 M.. IHCllan- 1035 3 RHerved 2 Servfal Server taHure TXT 16 TertallinM 1035 NotwV 3 NXDomaln NolMlxletent donwln RP 17 Re•-·ble- 1183 '5 u-•• -... No11mDlemenl9d AFSD8 11 AFS date b ..• location 1183 1 · 15 Avelleble for eHlanmant '5 IWUMd OuelY refuMd X25 11 X.26 PSDN lddreet 1183 ISDN 20 ISDN eddrele 1183 RT 21 Routeth--h 1183 Figure 6.43: Header section format (RFC 1035) NSAP 22 NSAP.-• NSAP*tu1aArwcord 1705 NSAP-PTR 23 SIG 24 Securttv .ianeture 2531, 3755, 403' KEY 21 2635, 3755, 403' RA; ~~- - PX 2' x..ao ...... lnlom..tlon 2163 0 Res«ved IANA GPOS 27 r~re'""""'Clll~ 1712 1 ,_.... 1035 AAAA 21 I N~ 3116 2 Unnei~ IANA LDC 29 l.oclllon lnlorrnellon 187t 3 CtleoefCH } 1035 NXT 30 Ned domlln • obaollte 2535, 3755 Hesiod(~ 1035 EID 31 ~- ldenllllllr ~ !ANA '·263' llMLDC 32 Nimrod locetor 25' None 2136 SRV S3 Mlectlon 27ta 255 •-IQc:INa _..;, 1035 s.r- ATMA 3' ATMllddreee 251 · 6463' u...... ,. !ANA NAPTR 31 . ..._..... IUlhorlllt - 2168, 2915 11131 Aeeerwd !ANA KX ti-...... - 2230 . CERT "37 CERT 2638 Table 6.4: IANA: Domain system class A6 38 Al 217• , 3226 DNAME 31 DNAME 2572 SINK SINK OPT '°41 DPT 21171 APL '2 APL 3123 DS '3 De"""'llon et- 3658 SSHFP SSH kov t1~-1n1 4255 IPSECKEY "45 IPSECKEY '°2& RRSIG 41 RRSIG 3755 NSEC 47 NSEC 3755 DNSKEY 4t DNSKEY 3755 DHCID 49 DHCID 4701 ' HIP 55 Hoel Iden-Iv """ocol SPF 99 4'08 Table 6.5: lANA: DNS type values 6.5 DNS (Domain name system) 125 126 Addressing, naming, numbering and lab eling TVIMI Value RFCe UINFO 100 IAHA-.-wd ITypet:I A ADDRESS (4 l!v!!!l I TYpe 9: I MR NEWNAME (•-) UID 101 IANA_,__ I Type2:1 NS N&DNAME(--) I Type 10: I NULL Tublc 6.6: IANA: DNS type values (continuation) ....,.__ I Type 15: I MX I PREFEREHCE (2 = l . l!XCHANGE I~ Hime RFC l Type7:l MB MADNAllE (-ieble) 0 Query 1035 1Type1S:ITXT I TXT-l>ATA,(v... l 1 ·•"'·~ lobooleledl 3425 MADNAME (.. rleble) 2 Slltu• 1035 3 Reserwd IANA 4 1996 5 -IvUpclele 2136 Figure 6.44: RDATA format.<; (RFC 1035) 6-15 Avelllble for Table 6.7: lANA: DNS operation code Acod9 -o/~ o..crt- 'H•~~ RFC. 0 NoErl'.O< No error 11131 1 FormErr Format..,or 11131 2 SelvFall Serverlalu,. 11131 3 NXDomaln NOIMJdellnl domlln 1038 4 Nollq> Not kn- 1038 5 o ..... rellltecl 103I • YXDomain Na- ex!Uo - It should not 2135 7 --YXRRSel RR Ml ellillla wl*1 ii should not 2136 NXRRSet RR Ml 11111 ahoulcl exist cloea not 2135 •ti NotAulh Servet not llUlhortlllllve for zone 2135 10 Notlone Name not contained In z.one 2136 11 - 16 ' A ••liable lot a&&1anment 16 BADVERS Bad OPllon -a1on 2671 11 BADSIG TSIG """"''-fllilure 2841 17 BADKEY Keynot..coanimd 2841 18 BADTIME 51... 1- ou1 of time window 2841 111 BADllOOE B8d TKEY mode 2930 20 BADNAllE o.-~-- 2930 21 BADALG Ala Table 6.8: IA NA: ONS response code 6.5 DNS (Domain name system) 127 128 Addressing, naming, numbering and labeling Resource Records for the DNS Security Extensions RFC 4034: Q.-lon QIMStlon for the name - Ana- RAa anewering the que9tlon 0 7 • 15 11 24 31 '3¥ Aulll!!rity RR• polnllng -rd an authority lzl Reserved isl Protocol Algorithm ,. ,t.dr,lili.l>n&' RRs holding additional information Z: Zone key flag Figure 6.45: Structure of DNS messages (RFC 1035) S: Secure entry point flag Figure 6.46: DNSKEY resource record (RFC 4034) 0 11 24 31 Type covered Original TTL Signature •pirllllon Signatuie Inception Key tag SlgnaWre (vartable) Figure 6.47: RRSIG RDATA wire format (RFC 4034) 0 7 8 15 11 24 31 lzlRI Reserved Isl * ~ Public key (veriable) Z: Zone key ftag R: Revoke flag S: Secure entry point flag Figure 6.48: NSEC RDATA wire format (RFCs 4034, 5011) 6.5 DNS (Domain name system) 129 130 Addressing, naming, numbering and labeling 6.5.1 DNSSEC (Domain name system security) 16 24 31 Figure 6.49: DS RDATA wire format (RFC 4034) 1.·-~ ~ ·/ ~ Comll*d 0 reeerved - z-- 1 RSA/1106 RSAMDS n AFC 2537 Notrwcommended 2 ~n DH n AFC2539 3 DSAISHA-1 DSA y RFC2536 o- 4 Ellinli<:C..,.. ECC 5 RSAISHA-1 RSASHAI y AFC 3110 --..... 252 Indirect 91DIRECT n 253 PRIVATEDNS y Onllnnool 254 PRIVATEDID y ~ 255 -reeerved Figure 6.50: DNSSEC algorithm types (RFC 4034) 6.5 D NS (Domain name system) 131 132 Addressing, naming, numbering and la b eling RFC 6.5.2 ENUM (Telephone number mapping) ...... - 0Def'8tion91\' OHS Database Provisioning DNS record size: Tiet'2 poovtdw • NAPTR results sets might not fit the maximum DNS packet of 512 bytes when using UDP, this is good enough for storing VolP related records but not when E'.'IUM is used for its full potential - Aemotll clenlS . fndo.v..,.or • Recommendations emerged - as a rule of thumb docs nt use more 11... 1~..... than five mappings per nwnber but still depending on actual record size • Solutions for packet fragmentation EDNSO and TCP but no stan dardized way em-ts today, eounL on UDP services only Alt -.ere In-mode • TCP queries slows down a server and from 15000/ UD P queries per second down to 1500 (10:1 ratio) and T CP is subject to easy lo perform denial of service attacks Figure 6.52: ENUM ticr-2 platform NAPTR zone management: • ENUM zones may contain large amounts of records. Using the Tier-2 platform requirements: DNS t.rce model, ENUM can be delegated on a digit boundary, a • High-availability (telecom grade) model that has also disadvantages, a zone must be first delegated • Scalability and speed (keep pace with upstream applications) and records of one zone cannot stay with two providers • Distributed provisioning interface (concurrent m;ers) • For Carrier ENUM, avoid fragmentation, populate zones efficiently. • Auditing (version control, roll-back, disaster recovery) In case of lot of numbers assigned to the system gcoup tbem into • Sta.ndarc:lized NAPTR record forreats (interoperability) smaller chunks (make zones of 10/ 100/ 1000/ 10000 numbers), oth • Capacity planning and management erwise one niight not be able to delegate a. continuous large-enough block of numbers to a large reseller • Interact.ion with other systems (gateways, SIP proxies, billing b)'S tems) • For User ENUM, it makes sense to store separate zones per ENUM number. Whois data may be attached depending on local policy • ENUM zones have attributes that go beyond DNS concepts. Such attributes should be linked by the provisioning system to the zone. DNS storage options: E164 number length (for fixed numbering plans) is an important • Flat file storage attribute which influence the number of unjque records that can DNS server requires reload of the zone files after changes be used within the zone. Reload requires increment of serial number otherwise slaves do not catch up with the master Text file management is unsuitable for tier-2 ENUM • SQL storage Capacity management: SQL data.bases have multiple client capability. This means • Capacity management is important, allocating and delegating one can concentrate on the given problem instead of dealing nwnbers requires skills (IPV4 address depiction). Provisioning en with the interaction of the DNS server gine must have up to date information about ENUM 7,one usage, Solve the mai,ter/ slave synchronization using SQL back-end record ownership, current zone population, percentage of delega replication or other AP Is like SOA P / XML tion, usage ratio, unallocated or unassigned records. 6.5 DNS (Domain name system) 135 136 Addressing, naming, numbering and labeling Operations and usage: Provisio ning issues: • Make sure each location has built-in resilience (master/ slave clus NAPTR changes should be propagated in real time in a system where: tering or load balancer). Consider hosting DNS servers next to the • New records are acquired from ENUM regh;trars SIP servers (if the ENUM provider is abo SIP provider) • Conflict::l must be resolved between concurrent request for same • There is no clear consensus about how to handle multiple ENUM number priorities in the client side (not really an ENUM problem). For • Atomicity is critical in SIP centric environments ENUM may be example SER supports Q V'd.lues which can be populated from just an a::lSOciated attribute but failure to create associate ENUM NAPTR priorities but no sequential forking was until recently records might require roll-back of the entire transaction available ( tbrnugh SER AVP module provided by Voice System) • Provisioning is done by ENUM Tier2 provider, its resellers and • Client side: make sure the DNS resolver results delivered to up end-users can change their own records stream application are used not only in the right order but also in • A mechanism should guarantee data. integrity (syntax and logical sync with SIP events (do not use the results from an early DNS correctn~.ss of the user input), auditing and data recovery query for a transaction that is in progress using target obtains from a later query) • Avoid recurring DNS queries that have been performed earlier in routing decision. VoIP related issues: • T imers: ENUM is used primarily by SIP. DNS recursive query algorithm have timeouts (up to 75 seconds) that conflict with SIP timers. If the first DNS server is not reachable by the time a second server is queried (>5 seconds), SIP request has timed-out. Question for DNS specialists, how to deal with this? • High-availability: Distributed SIP location servers may fail if used for incoming calls should clients be located behind NAT be cause only the server that handled the registration maintains an open tunnel to the client. SIP registration Expires (coming from client side) may in the end decide the maximum downtime for a fail over or a dispatcher mechanism should be built in the distributed SIP farm. 6.5 DNS (D omain name system) 137 138 Addressing, naming, numbering and la be ling ENUM globel direciory (DNS) Public User Intu structure equalH +1·202-655-1234 lo (e164.arpa} ENUM ENUM elp:MmeOclomeln.com to -ble voic. over P using SIP EEN~11J Private Enterprise 2. C.llng pei1y proxy UAC queries 3. DNS returns NAPTR r..:ord ENUM ENUM SIP URL DNS for!ocatlon of end point containing User URI tnten:onnect URI ResponM Ouety aip:Mmeedom8in.com 4.3.2.1.$. .5 .6.3.1.6.1.e164.a1p11? Figure 6.53: EJ\UM types ~-----~ 1. C.ller alqily dl91e .,..on'• normal telephone Dial number .-202-sss.1234 r;:;:, sip:Mmee domain.com ~ cau setup 41...q,1 u 'le;DI ~___. Figure 6.54: User ENUM call flow 1 ENUM Globe! Directory (DNS) equates +H l1 :H65-1234 lo aip:imc:.oclomeln.com to-ble 3. DNS returns NAPTR record Voice over IP using SIP containing SIP URL lo C.Ulng P9rty UA 2. SIP UAC queriff DNS for location of encl point ~-n-~!-__norma;J., ' I...-- -~= - ----~ llp:jmceOdomain.c°'." i::::i= . 1.. 1 :..S&S·1234 ~------~ 14. caller'• UA lnl•••ts c•• with SIP URL BAIM quety can 1111 ti""9 11J VoIP cllenl Figure 6.55: User ENUM call flow 2 6.5 DNS (Domain name system ) 139 140 Addressing, naming, numbering and labeling Figure 6.56: User ENUM with no routing possibility 1..... uctUN l!NUll ldlnltlM im.rc-1 point Figure 6.58: Routing in iuftastructure ENUM Pit- EHL.Ill n.n.i.tes E.114 - to· Ull Figure 6.57: Routing in private ENUM En•prlee ENUM can llke meny tonns Figure 6.59: Routing m enterprise ENUM 6.5 DNS (Domain name system) 141 142 Addressing, naming, numbering and labeling 6.5.3 NAT (Network address translation) Network addre8S translation (NAT) is a technique used in compuLer net working, which relics on rewriting IP addresses of network packets p~ing through a rouler or firewall. NAT became necessary because the number of IP addresse:> is too small to cover all of computers to be connected to the Internet after the number of c.'Omputers connected to the Internet exponen tially increased. There are two kinds of network address translation. What is often ca.lied simply NAT is also sometimes named NAPT, and refers lo network address translation involving the mapping of port numbers, allow Figuro 6.60: ENUM Application vCard ing multiple machines to share a single IP address. The other simpler form is also caJled NAT, or basic NAT or ::;ta.tic NAT, and involves only address translation, not pod mapping. This requires an external IP address for each simultaneous connection. The feature is ofLcn found in ADSL routers, sometimes labeled DMZ host, to allow a computer to accept all external connections even when the only available external IP address is used by the router itself. NAT with port-translation can be further distinguished to two kinds: source address translation (source NAT), where the IP ad dress of the computer, which initiated the connection is rewritten, and its counterpart: destination address translation (destination NAT). When the computer performing the NAT routes the systems behind it onto the Inter net, it transparently changes the source JP address of the internal system to Figure 6.61: ENUM Application CNAM its external (Internet) address and remembers basic data about the connec tion. The packet then traverses the Intemet to its destination as if it had e164.arpa been generated by ~he router itself. When the reply is scnL back, the router looks at the connection tracking data it stored before and determines where in-addr.arpa to send it back on the internal network. 'The benefits of NAT are great. It allows many cowputers to access the internet utilizing only a single IP ip6.arpa address on the internet. This not only saves rnoney for the organization employing NAT, but also conserves addresses on the Internet as few are still available. Another benefit of NAT is the ability to conceal the internal iris.arpa configuration of your network from ex'ternal observers such a.s hackers or your ISP. Downsides of NAT include difficulty in wing services that require uri.arpa the initiation of TCP connections from the outside network, or stateless protocols such as Lhose utilizing UDP; unless the NAT router makes spo cific effort to support such protocols, incoming connections cannot reach urn-arpa their destination. llowcvcr, Lhis also can be regarded as a form of simple firewall funct.ionalily, and many users who do not want to expose server functionality on their machines to incoming connections from the Internet sec this as an advantage. 6.5 DNS (Domain name system) 143 144 Addressing, naming, numbering and labeling Other examples of use are: 6.6 OSI addressing • Load Balancing: Destination NAT can be used to redirect con nections pointed at some server to randomly chosen servers to do load balancing. DSP 150749&-3 • Fail-over: Destination NAT can be used to setup a service re Oonwin Specific Pan ITU-T l<.213 quiring high availability. Say one has a critical server you access --- through a router, if the router notice that the server is down, it could use destination NAT to transparently rn.a.ke your connection ---::::;:::--1 arrive on a backup server. • Transparent proxying: NAT can be ui:;ed to redirect HTTP AFI IDI connections targeted at Internet to a special HTTP proxy, which · T~ll decimal ""-0c 99 ...... will be able to cache content and filter requests. This technique is : :-..:::::::::=::~~i~Qlt · :· used by some ISPs to reduce bandwidth usage without requiring ·Y-: 00·09 ,.;,.,_ 10·35 -- t heir clients to configure their browser for proxy support. 36 • 59 ITU.T and ISO 60 •H new IDI fommls (ISO) 70 •79 ..w IDI formats (ITlHl 80·99 Ref- .. Figure 6.62: OSI address i.tructure ,'~ IDP ) DSP 1...... // , ························ fl =-~~1~;~-{r!ii=·,'.:;:ORG=-l=D~Eu;::mples=Areo-ID=~=~==~=Es-c>=~ 1 =N=$AP=~.U-~ =·5;"]1! NSAP·Seleclor ~i Figure 6.63: Address structure of the network service access point (NSAP) TOP (11\itial Domain Pa.rt), OSP (Domain Specific Part), AFl (Authority a.ud Forn:tat Jd(mtificr), IDI (luitial Domain Identifier), ES (End Sys,em), NSAP (Netwol'k Servh:.e Access Point). 6.6 OSI addressing 145 146 Addressing, naming, numbering and labeling 6.7 OSI protocol stack internal addressing 20 Byte I· ·I NSAP Address . 'IDP I ' DSP I A Tll End-System Addre. (AESA) 1:31~ ~~~ Figure 6.64: Address structure of the network service access point (NSAP) AFT (Authority au 6.8 ATM addressing ATM addressing is as follows. ATM addressing is 8.'l follows: • The prefix is for the switch itself whih.1. the whole address is for the end system and there are three different types called Initial Domain Identifiers (IDI). • Designated Country Code (DCC}, which uses the ATM defined country code in which an address is registered. • International Code Designator (ICD), which uses ATM defined in ternational organization codes. • E.164 using ATM defined ISDN numbers and telephone numbers. 20 by!ff • The format being used is identified by the Authority and Format Identifier (AFI) using t he AFT codes. The Domain Specific Part (DSP) specifies the semantics, the structure, 1 3 6 1 ITU lonnat HO.CSP ESI ~1-11 II I~ IASP: ATM ....,;o91!'....icter II and the administrative requirements for the addresses: 1c1e~ • Administrative Authority (AA): A V' • R eserved: Filled with zeros. 1 2 3 7 6 1 IOTA format 1 HO.DSP ESI • Rou ting Domain (RD): Hierarchical routing inter and intra do- P•"ll .. l~ I II I~ IOTA: ldontifiOfS lor Of9jUliiations mains. for llllocommunicmlon&'a~ · , , lQ I DCC format • Area: Hierarchical routing inter and intra domains. l A~ llo~ll HO.OSP II ESI - ·· 1Lltl !occ: .o8t8 C0....1iy coclo • End System Identifier (ESI): Unique within an area. 1 12 6 1 • Selector (SEL): End systems use this for further identification. I ~Fl 11 HJ>~st '.•~ ,H ESI I~ Local format Figure 6.66: Formats of AT M End-System Addresses (AESA) IDP DIP 1 8 4 8 1 [!!!] IOI Itt0-0..-11 .Ell . I[·~ I IDP Initial domain paot ~1641onnal DSP Domain apeclftc paot / (15 digits+ F..J AR AutllO Figure 6.65: ATM End-System Address (AESA) 6.9 ISDN addressing 149 150 Addressing, naming, numbering and labeling 6.9 ISON addressing 1--- 11.::;;:11 -=- 1! 1.__ _l!llJ-_••:: _-,,_•• __. ti -number 40 digi:tw ,____.... maa.11idl... ---- -max. m ... 1s11191i. NetwortcpredelNng j mu. 1S • n digits 1-0fkcods ll~c-oun1-,., -.ods-11 om:::-11 ~ I 1 to3 digits ·i CC: Country cods NDC: Nsllonsl dstdnlllon (optional) cc NDC I N cods r I I SN: 8ub9crtber numbet n: Nu-r ol Olgltt In Ille country code Figure 6.67: ISON address structure (E.164) 1· ~number "· Glollsl ssrvicss 3dilJilS max. 12 dlgli. CC: Country c~ tor ttae glOl»l aenrice QIN cc I I GSN: Qlobsl --number I• max.15·n-lta ::.~: CC: C°"'*Y IO< 3 digils 1 • 4 die* cods ·--IC: ·--cods Su_fl_n__ t,ji--_cc_~I [TII~ __IN_ __, SN: n: Nu-of digits in the i-t;catlon cods • 3 digits 1 digit IMJI. 11 di... CC: Country cods !or group ol cou !1--"'-cc___,! ~ I IN GIC: Group--cods 0 SN:·--- Figure 6.68: ISDN address structure in E.164 networks 6.10 GSM addressing 151 152 Addressing, naming, numbering and lab eling 6.10 G SM ad d ressing been defined; they arc needed for the management of subscriber mobility and for addrcs.5ing all the remaining network elements. • International Mobile Station Equipment Identity (IMEI): The IMEI uniquely identifies mobile equipment internationally. It ~1r~=IMSI y is a kind of serial number. MSISDN IMSI • M obile Subscriber ISDN Number (MSISDN): 8SIC IMEI IMSI MSRH MSISDN Cl MSISDN M$RN The real telephone number of a mobile station is the Mobile Sub LAI MSRN LMSI TMSI TMSI scriber ISDN Numbc1·. It is assigned to the subscriber such that LAI a mobile i:;tation set can have several MSISDNs depending on the SIM Sullec:rlber Identity Module MSISON Mobile Subectlbet ISON Number SIM. With this concept, GSM is the fir~t mobile system to distin EIR Equipment ldenllftcetlon Aegl TMSI T....-.y Mobile Sui.ctlber Identity AUC Aue.nllCllllon Centre MSRN Mobile Station Roaming Nu- guish between i:;ubi:;criber identity and number to call. The sepa HLR Home LOClllon Aegl- LMSI l.oc81 Mobile Station Identity ration of call number MSISDN and subscriber identity IMSI pri VLR Vleltar Locellon Regle• IMEI lnlen*lonlll Mobile Equipment lclenllty BSC Bue 811111on C-oller IMSI ~Mobile Sublc:rlber lcl9nllty marily serves to protect the confidentiality of the IMSI. In con 8T8 a... r,..necet_ Station llSIC Beee T..-ceher Slallon lclenllty Code MSC lloblle 8wltc:hlng C- Cl Cell ldllnlity trast to the MSISDN, the lMSl need not be made public. With LAI Locldion Ania Identity this separation, one cannoL derive the i:;ubscriber identity from the MSISDN, unless the a.ssociation of IMSI and MSISDN as stored Figure 6.69: Addresses and data b=:s in GSM in the HLR has been made public. It is the rule that the IMSI used for subscriber idenLificatioa is not known, and thus providing GSM distinguishes explicitly between user and equipment and deals with a false identity is significantly more difficult. them 5epara.tely. Therefore, mobile equipment and users each receive their • International Mobile Subscriber Identity (IMSI): own internationally unique identifiers. The user identity is associated with When regi~ring for 5ervice with a mobile neLwork operator, each a mobile station by means of a. personal chip card, the Subscriber Iden subscriber receives a unique identifier, the International Mobile tity Module (SIM). This SI ~t is in form of a credit card that is portable Subscriber Identity. This IMSI is stored in the subscriber identity and therefore transferable bctwocn mobile stations. It enables distinction module (SIM). A mobile station can only be operated, if a SIM with between equipment mobility and subscriber mobility. The subscriber can a valid IMSI is inserted into equipment with a valid lMEI, since register into the locally available network with his or her SIM chip card this is the only way to correctly bill the appropriate subscriber. on different pieces of mobile station equipment, or the SIM card could be • Temporary Mob ile Subscriber Identity (TMSI): used as a normal telephone card in the fixed telephone network. However, The VLR responsible for the current location of a subscriber can he or she cannot receive calls on fixed network ports, but further devel assign a Temporary Mobile Subscriber Identity which has only local opment of the fixed networks as well as convergence of fixed and mobile significance in the area handled by the VLR. It is used in place networks could ma.kc Lhis possible, too. In that case, a mobile subscriber of the IMSI for the definite identification and addressing of the could register at an arbitrary ISDN telephone and be able to accept call$. mobile station. This way nobody can determine the identity of In addition, GSM distinguishes beLwccn subscriber identity a.nd telephone the subscriber by listening Lo Lhc radio channel, since this TMSI is number. This leaves some freedom for development of future services when only assigned • Mobile Station Roaming Number (MSR N): This is a temporary location dependent ISDN number. It is as signed by the locally responsible VLR to each mobile station in its area. Calls arc routed to the MS by using the MSRN. On request the MSIU'l is passed from the HLR to the GMSC. • Location Area Identity (LA): Ea.ch Location Arca. of a GSM network has its own identifier. The Location Area ID (LAI) is ali;o structw·ed hierarchically and inter nationally unique. Location Areas are necessary for identifying all cells where a mobile subscriber has to be paged. • Local Mobile Subscriber Identity (LMSI): The VLR can assign to a mobile station in its area an additional searching key to accelerate database a.cces.s; this is the Local Mobile I MCC I UNC I LAC I Station Identity. The LMSJ is assigned when the mobile station registers with the VLR and is also sent to the HLR. The Ll'v1Sl is LAI not used any further by the HLR, but each time messages arc sent to the VLR concerning a mobile station, the LMSI is added, so the VLR can use the short searching key for transactions concerning this MS. This kind of additional identification is only used when the MSRN is newly assigned with each call. In this case, fa.::.t processing is very important to achieve short. ti.mes for call setup. • Cell Identifier (CI): Within an LA, the individual cells a.re uniquely identified with a Cell Identifier. • Base Transceiver Station Identity Code (BSIC): In order to distinguish neighboring base stations, these receive a unique Base Transceiver Station Identity Code Identification of MSCs and Location Registers: MSCs and location registers (HLR, Figure 6.70: Network partitioning by Location Areas (LA) VLR) are addressed with ISDN numbers. In addition, they ma.y have a Signaling Point Code (SPC within a GSM network, which can be used to address them wtlquely within the Signaling System Number 7 network (SS7). The number of the VLR in whose area a mobile station is currently roaming must be stored in the HLR data for this MS, if the MSRN distribution is on a call by ca.11 basis. The MSRN can be requested for incoming calls and the ca.11 can be switched through to the MS. 6.11 GPRS addressing 155 156 Addressing, naming, numbering and labeling 6.11 GPRS addressing 6.12 WLAN addressing I UCc: I UNC I LAC (9lj AP: Access point AID: Association ldentlftcel.on Addr1 Addr2 Addr3 Addr4 BSSID: B•Sic -vice ... ldenltflif" .. FC$: Frame check 9911-.nce:!I' ' 'DA' :' . SA .. BS$1Ii· .: DS;. ,'... :., Distribution SV&le:m . DA BSSIO SA . Dk '»I'::I>Ii:)eilljridcin adD'eu SA DA u:· .'·:' s~iiddr.. TA DA SA TA: Transmltleraddresa RA: Receiver address WEP: Wired equlvalent privacy Figure 6.71: Location Areas (LA) and Routing Areas (RA) in GPRS Figure 6. 72: WLAN addresses in data frame format MAC Frame fields: • Frame control: Contains the protocol version and type informa tion as well as eight flags. • Duration identifier: Carries a duration value or in case of frames of subtype power save it contains the association identifier of the transmitting station. • Addresses 1 to 4: All four address fields contain a 48-bit MAC adcfress indicating the destination address, source address, receiver address, and transmitter address. The position of those addresses may vary and depends on the communication direction given by the to/ from flags. • Sequence control: Sequence numbers for frame loss detection. • Frame body: Contains a variable length payload including op tional WEP initialization vectors (IV). • Frame check sequence (FCS): This field contains a 32-bit cyclic redundancy code (CRC). 6.12 WLAN addressing 157 158 Addressing, naming, numbering and labeling BSSIO BSSID TA D. 00~ 00: AO-Hoc 01 : Fnim AP 10:To AP 11: Wllhln OS q Next dHtlnatlon (first -1 AP: A~polnt Addr1 Addr2 Addr3 Addr4 BSSID: Basic ..nnc. Mt ldenllllet OS: Dl&lrtbution •V- 00 DA SA BSSID OA.: Destination adchM 01 DA BSSIO SA RA: Rectitv.f addNaa 10 BSSID SA DA SA: Source addre~ 11 RA TA DA SA TA: Tranamliter•c!chea Figure 6. 73: WLAN address order 160 Network managem ent Chapter 7 Network management 162 Ser vices Chapter 8 Services 164 Multiservice networking 9.1 Multiservice Networking Chapter 9 M ultiservice networking 166 Virtual networks 10.1 VLAN (Virtual local area network) Chapter 10 Virtual networks [JJ T---dVl.AllB Figure 10.1: Virtual LANs with IEF:J:; 802.l Q tagging Virtual LAN (VLAN) is a group of devices on one or more LANs that arc configured so that they can communicate as if they were attached to the same wire, when in fact they arc located on a number of different LAN segments. Because VLANs are based on logical instead of physical connec tions, it is very flexible for user/ host management, bandwidth allocation and resource optimization. There are the following types of Virtual LANs: • Port-Based VLAN: Each physical &·witch port is configured with an access list 1>-pecify ing membership in a set of VLANs. • MAC-based VLAN: A switch is configmed with an access list mapping individual MAC addresses to VLAN membership. • Protocol-based VLAN: A switch is <.-onfigurcd with a list of mapping layer-3 protocol types to VLAN membership, thereby filtering IP traffic from nearby end stations using a particular protocol such as IPX. • ATMVLAN: It uses the LAN Emulation (LANE) protocol to map Ethernet frames into ATM cells and to deliver them to their destination by converting an Ethernet MAC address into an ATM address. 10.1 VLAN (Virtual local area network) 167 168 Virtual networks The IEEE 802.IQ specification establishes a standard method for tagging Ethemet frames with VLAN memben;hip information. The IEEE 802.lQ standard defines the operation of VLAN Bridges that permit the defini tion, operation, and administration of Virtual LAN topologies within a Bridged LAN infrastructure. The 802.lQ standard is intended to address the problem of how to break large networks into smaller parts so broad cast and multicast traffic would not obtain more bandwidth than neces sary. The standard also helps provide a higher level of security between segments of internal networks. The key for the IEEE 802.lQ to perform the above functions is in its tags. 802.lQ-compliant switch ports can be configured to transmit tagged or untagged frames. A tag field c.ontaining VLAN (and/ or 802. lp priority) information can be inserted into an Ethernet frame. If a port has an 802.lQ-compliant device attached (such as another T switch), these tagged frames can carry VLAN membership information be ~:~~5g I IJD I AC I FC I 01' I SA l Ti PCs and printers are not 802.lQ-compliant. If they receive a tagged frame, • Fra.,. tagging lot they will not understand the VLAN tag and will drop the frame. Also, Elllemet, Toon Ring undFOOI • Each frame belonp, onty to one the maximum legal Ethernet frame size for tagged frames was increased in virtual LAN (VL.AN) 802.lQ (and its companion, 802.3ac) from 1518 to 1522 bytes. This could • VLAN = Broadcell-dOm&lin • Functions for confiig:urahon cause network interface cards and older switches to drop tagged frames as and monaooment ol VL.ANs oversized. Ethernot PA PIMntble f'" so Stall dellmhr DA o..un.tton •• SA Source addr••• LEN Le1191h PAOPeddlnv- FCS Frame check sequence Figure 10.2: Frame formats of IEEE 802.lQ virtual LANs 10.2 VPN (Virtual private network) 169 170 Virtual networks 10.2 VPN (Virtual private network) VPN,1Slte2 Virtual private networks a.re an attractive possibility for big customers as well as Internet service providers. The key factor in VPNs is that all traffic from one domain (or CUl)tomer) shares the same infrastructure as other do mains, leadfog to economics of scale. The fact that routing and addressing plans within the network a.re completely independent of the routing and addressing plans of all other networks, gives the network the feature of pri vaJ;y. The VPN traffic is logically separated from other traffic by tunnelling mechanisms. The network is virtual due to the fact that the facilities used to build and operate such a network may not be dedicated just to that single company, but could be shared with other companies that want to have their own VPNs. We could say that a VPN is a set of sit.es that can communicate wiLh each other, as being on the same LAN. Except providing pure commu Figure 10.3: VPN Overlay Model nication between sites, a virtual privat.c network should of course support some other features, such as the support of multiple corporate customers. in the middle represents a VP N service provider. VPN1 consists of three In this case, the traffic from customers should be isolated. Some security sites, sitei. site2, and sii.e3 . Router R11 at sitc1 is connected via either features should be provided to ensure that packets from the public Internet Frame Relay or ATM circuits to router Ri2 at site2 and router R13 at site;i. could be taken inside a. VPN. In IP communications of today, the provi Likewise, router Ri2 at sitc2 is conneeted to router R n a.t site1 and router sion of QoS guarantees for corporate customers is for !mre one of the most R13 at sitc3. VPN2 also coru;ists of three sites, but the connectivity among challenging features that a VPN should support. Besides, a VPN service the sites is hub-and-spoke, where site1 acts as a. hub and site:? and site3 should be easy to utilize and manage, from both sides from the customer's act a.s spokes. A hub is a central site that has full knowledge for all other vie\vpoint and the service provider's viewpoint. sites, and all other sites, the so-called spokes, will sent traffic to the hub There are three types of VPN services: site for any destination of the same VPN. Note that the hub site has not one, but two routers, R2111 and Ra112, that connect that site to the other • Access VPN: Provides a secure connection for remote access between indi sites. An advantage of using two routers instead of one is that it eliminates viduals (mobile users) or corporate intranct or extranct over a shared i;crvice provider network. a single point of failure - if one of the routers fails, the other one would • Intranet VPN: Links remote offices within a corporate intranet. still be able to provide connectivity. lf there would be only one router at • Extranet VPN: Extends services to suppliers, customers, or communities of the hub site, and if that very router crashed, not only would the hub be interest over a shared infrastructure. unable to communicate with the spokes, but none of the spokes would be able to communicate with each other. Note that the address space used 10.2.1 Overlay Model by VPN 1 is the same as the one used by VPN2. There is no requirement for VPN1 to use the same routing protocol as VPN2, so one may use for With the overlay model, each site has a router that is connected via point instance OSPF while the other uses the routing information protocol (RIP). to-point links to routers in other sit.es. The technology used to offer point Although the VPN solutions bru;ed on the overlay model are predominant to-point linb could be for instance, leased lines, Frame Relay circuits, or today, these types of solution have several major drawbacks that limit large ATM circuits. The network consisting of these point-to-point links and scale VPN service deployment. Some of the drawbacks of overlay model arc routers attached to these links is called a virtual backbone. It is this virtual given below: backbone that provides connectivity among sites. • The VPN customers need to design and operate their own virtual lri Figure 10.3, a scenario with two VPNs, l and 2, is given. The domain backbone - this requirement makes it difficult for the service provider 10.2 VPN (Virtual private network) 171 172 Virtual networks 192.2116 CE - customer odge roulM P£ -~odge- Figure 10.4: Configurat.ion changes to offer services to a large number of customers. Th.is is very often almost impos.<;ible, due to very high c<>bts. • Customers that have a relatively large number of sites require com plete mesh connectivity among the sites. For instance for a VPN of N sites, a backbone router needs (N - 1) routing pccrings. 128.3116 • When a provider adds a new site to an existing VPN, the amount of configuration changes is required - if requiring full mesh connectivity VPN,!Site, among all sites, adding a new site involves changes to the configuration ce .-ec1ge,.,...., p. pnMdor,.,...... VDM ,.,.... on all of the existing sites, as each one would need an additional point PE·pnMdoredge- , ,.., _ _, to-point connection to the new site and an additional routing peering with the router in the new site Figure 10.4. Figure 10.5: VPN peer model 10.2.2 Peer Model contrast to the overlay model, where customer routers peer only with ot,her customer routers over layer-2 links or IP tunnels provided by the service The peer model aims enabling VPN senice providers to support very large provider. The peer model is more powerful. VPNs ui;ing MPLS provide scale VPN service offerings (thousands to millions of VPNs per service many of the advant,ages of permanent virtual circuits (PVC), achieved con provider), and to support a diverse population of customers, where some ventionally by the use of Frame Relay or ATM. Customers can choose their VPNs would consist of just a few sites, while others would have hundreds own addressing plans, which may or may not overlap with those of other or even thousands of sites per VPN. customers or the service provider. Each customer can be confident that the To illustrate the peer model, we consider the example shown in Figure 10.5. data will not be delivered anywhere but to sites within the customer's VPN. The middle domain is a collection of one or more service providers that, offer For this reason, encryption is often not required, what is an advantage of VPN services. In this picture, we show two VPNs, 1 and 2. VPN 1 site is this model. The MPLS virtual private network model is highly scalable connected to a VPN service provider by a customer edge (CE) router, and with increasing numbers of sites and customers. It also supports any-to it may have one or more customer edge routers. For example, sitc1 in VPN2 any communications among the sites within a VPN without requiring the has two CE routers, CE21; 1 and CE2112, while sitc2 and site3 in VPN2 have installation of a full JOcsh of PVCs. For ea.ch VPN customer, the provider's only one CE router, CE22 and CE23, respectively. We also sbow a set of network appears to provide a private IP backbone over which the customer destinations reachable within each sit,c (e.g., the set of dei;tinations reach can reach other sit,cs within the organizat,ion, but not the sites of any ot,her able within si~ ofVPN1 is covered by an IP address prefix 128.2/16). The customer. From the customer's perspective, a significant advantage is that reason for calling this a peer model is that from the routing point of view in many cases, routing can be dramaticaJly simplified relative to the PVC the service provider network act,s as a peer of the crn.tomer networks, since model. Ralhcr than managing routing over a topologically complex virtual the customer routers peer directly wilh provider routers (PE). This is in backbone composed of many PVCs, an MPLS VPN customer can gcncr- 10.2 VPN (Virtual private network) 173 174 Virtual networks ally use the service provider backbone as the default route to aJI of that VPN1/Sliet company's sites. 192.2116 10.2.3 BGP / MPLS VPN Network Topology Two fundamental traffic flows occur in a MPLS virtual private network based on the border gateway protocol (IlGP). A control flow is used for VPN route distribution and label switched path {LSP) establishment, and a data flow is used to forward customer data traffic. The control flow consists of two subflows. The first one is rcspousible for the exchange of routing information between the customer edge {CE) and the provider edge (PE) routers at the edges of the provider's backbone, as well as the information distribution between the PE routers acro:;s the provider's backbone. The second control subflow is responsible for establishment of LSPs. VPN 1/Site1 YRF • VPN roudng IO To illustrate how routing information distribution is used in the context Figure 10.6: DGP/ MPLS VPN network topology of a. virtual private network, we consider the example shown in Figure??. In this example, the provider edge router PE1 is configured. with a. VPN routing forwarding table (VRF) as the interface over which it learns routes from the customer edge router CE11. When CE11 advertises the route for prefix 128.1/16 to PE1 , the latter installs a local route to 128.1/16 in the VRF. PE1 advertises the route for 128.1/16 to PE3 using BGP. But, before BGP proccdw·cs. In step 4, at the egresi; router PE3, the route is imported advertising the route, PE lir:;t selects an MPLS label to advertise with the 1 from the provider's BGP. This is controlled by the route filtering that is route and assigns its loopback add1·ess as the BGP next hop for the route performed by PE3 and is based on the community attribute carried by the (RFC 2547). route information. Finally in step 5, the route is distributed. from PE3 to For the distribution of routing information, the technique of route filtering router CE13, at sitC3 of VPN1. This distribution could be accomplished. based on the BGP extended. community attribute is used. The BGP ex by the same protocol, in our example BGP used in step 1. In order to tended. community attribute is a.n optional identifier that may be attached. use MPLS to forward VPN traffic across the provider's backbone, a label to an advertised rout-e, and is used to control which routing information is :;witched path (LSP) must be established between the PE router that learn:; accepted, preferred, or distributed. to other neighbors. Figure 10.6 offers the route aud the PE router that advertises the route. LSPs can be estab further details of what was described above. In the first step, the route for lished aud maintained across the service provider's network u:;ing either the VPN1 with the address 128.1/16 is distribuLed frorn CE11 at sitc1 to the PE label dfatribution protocol (LDP), or the constraint based label distribu router that this site is connected to, PE1. This distribution could be accom tion protocol (CR-LOP), or the resource reservation protocol (RSVP-TE). plished for example by BGP. In t he second step, this route is exported into When a provider wants to either assign bandwidth to t he LSP or use traffic the provider's BGP, and as the route gets exported, the ingress router PE1 engineering for selecting an t>..xplicit path, RSVP-TE or CR-LDP is used. attaches the appropriate IlGP community attribute t-0 the route. Further RSVP-TE and CR-LOP support specific quality of service (QoS) guarantees on, in step 3, this route is distributed to other PE routers U8ing normal and/ or specific traffic engineering objectives. 10.2 VPN (Virtual private network) 175 176 Virtual networks 10.2.5 VPN-1Pv4 Address Family 10.2.6 BGP Operation The border gateway protocol (BGP) dil.t.ributes reachability information for VPN customers often manage their networks and use the private addres5 VPN-IPv4 prefixes for each VPN. BGP communication takes place at two space. If customers do not use globally unique IP addresses, the same 32 levels: within IP domains - interior DGP (IBCP) and between autonomous bit IPv4 address can be used to identify different systems in different VPNs systems - external BGP (EBGP). This i8 illU8trated in Figure 10.8. Provider (RFC 1918). The result can be routing difficulties because BGP assumes edge to provider edge (PE-PE) or provider edge to route reflector (PE-RR.) that each 1Pv4 address it carries, is globally unique. To solve this prol:r sessions arc IDCP sessions, and provider edge to Cllbiomer edge (PE-CE) lem, BGP/ MPLS VPNs support a mechanism that oonverts nonunique IP sessions are EBGP BeSl>ions. addresses into globally unique addresses by combining the use of the VPN- 1Pv4 address family with the deployment of multiprotocol BGP extensions (MP-13GP, RFC 2283). A VPN-JPv4 address oonta.ins 12 bytes, of which 8 bytes represent a route distinguisher (RD) followed by a 4-byte 1Pv4 ad dress prefix. An RD is an identifier used in BGP/ MPLS VPN8 to ensure uniqueness of address prefixes among VPNs when multiple VPNs use the same address space. The RDs a.re structured so that every service provider can administer its own numbering space (i.e., it can make it8 own RD as signments), without conflicting with the RD assignments made by any other service provider. An RD consists of a two-byte type field, an administrator field, and an assigned number field, as illustrated in Figure 10.7. ------Figure 10.8: BGP operations -...... - j -f The reachability information distributed by DGP is propagated by means -- of the BGP multiprotocol extensions, which define support for addres; fam ilies other than JPv4. This is done in a way that ensures that the routes --· ,,,.!. O!lmbof Hold: m.wnber uoigned by h ident-1Ulhol1ty IO< I partlculor ....,_ for a given VPN arc learned only by o~her members of that VPN, enabling ] AdnjrjM11Mpo1 l!tk!: ,__ 111 Hligned nUllller outhority memberi> of the VPN to communicate with each other. For this purpose, BGP/ MPLS VPNs use the 32-bit 13CP extended community attributes in Admjrjll!ltioo fllld: c1e11rm1 .... ""' length• of""' --·- stead of the conventional 16-bit BGP community attributes. Figure J0.7: Encoding of route distinguishers and 1Pv4 addresses 10.2.7 Data Flow The type field determines the lengths of the other two subfields, administra tor and assigned number subfield, as well as the semantics of the adrnini& It is familiar that IP uses an address of 32 bits in the packet header. The trator field. The administrator field identifies an assigned number authority, VPN IP addre88 add8 64 bit8 in front of the JP header, creating an extended and the assigned number field contains a number, which has been assigned address in routing tables that classica.1 IP cannot forward. MPLS solvei> by the identified authority for a particular pw-pose. RDs arc given this this problem by forwardi11g traffic based on labels, and it is used to bind 8tructure in order to ensure that an ISP, which provides VPN backbone VPN IP routes to label-switched routes. Since labels only exist for a valid service, can always create a. w1ique RD when it needs to do so. destination, this is how MPLS delivers both security and scalability. To 10.2 VPN (Virtual private network} 177 178 Virtual networks implement the hierarchy of routing knowledge, not just one, but two levels 10.2.8 Quality-of-Service of labels arc used. The first-level label is associated with a route to an egress PE router, and therefore provides forwarding from an ingress PE router to the egress PE router. These fiTh-t-level labels could be distributed either via LOP or, if a service provider wants to use traffic engineering, via The class of service (CoS) feature of MPLS enables network administrators RSVP-TE or CR-LOP. The second-level label controls forwarding at the to provide differentiated types of service across an MPLS network. Differen egress PE router. The second-level labcl is distributed via BGP, together tiated service satisfies a range of requirements by supplying for each packet with VPN-IP routes. transmitted the particular kind of service specified for that packet by its CoS. Service can be specified in different ways, for example, using the IP precedence bit settings in IP packets. ln supplying differentiated service, ·Pro....,. •heh tho l*I<•• MPLS CoS offers packet classification, cougcstion avoidance, as well as con bUedonlNKIP-(labljon ~ IOpOltho-1<) gestion management. At the label edge router (LER), the committed access ~ ·Penultimate hop popping ··P,IBthepenu-hopfor rate (CAR) classifier m;es IP precedence to define service classes, which are - p,a.·..-111eioplabel l!G!' """""°" copied to the CoS field in the MPLS label header. Once classified, packets are queued and scheduled for transmission. Two models arc used to describe QoS in the context of VPNs: • Pipe model: A pipe provid~ pcr:ormancc guarantees to a VPN customer for the traffic between customer's odg-c routers. It may provide perfomrn.nce ·PE,-Ppor:llol guarantees that arc close to lhat or a leased line or provide weaker performance _...,...... _.. guarantees, depending on the service level ~eements made with the provider. •____ 1.-..p .. - ...... - _ The pipe model is closc to the i nteg:ated services model. - -MD./top(PEJIB-llnugll --Coll -u.> • Hose m odel: A hose is a Oexible pipe that provides performance guarantees IGP---- · t-0 a VPN customer for the traffic that a customer sends to and receives from other edge nodes or the same VPN. Figure 10.9: Data flow (penultimate hop popping The hose model uses two parameters, the ingress committed rate (ICR) and Figure 10.9 shows the Row of VPN data traffic across the service provider's the egress committed rate (ECR). The lCR is the a.mount of traffic that a backbone from customer site1 to customer site2. As an example we a.o;sume particular CE router could i;eud to other such routers, while the ECR is the that host 128.5.7.4 wants t.o communicate with server 128.1.2.3. The packet amount of traffic that a particular CE could receive from other CEs. In other goes through CE1 , and I.hen it arrives at PE1, which determines the appro words, the ICR represents the aggregate a.mount of traffic from a particular priat.e forwarding table and then performs the lookup in that table. As a CE, while the ECR represent.s the aggregate amount of traffic to a particular result of the lookup, P81 attaches two labels to the packet and sends the CE. For a given CE, there is no requirement that its ICR should be equal packet to P1 , which, iu turn, uses I.he outer label when making its forward to its ECR. A hose provides flexibility to a VPN cui;tomcr to send traffic to ing decision and forwards the packet to P2. Since P2 is t.he penult.imate a set of endpoints without ha.vil1g to specify the detailed traffic matrix. It hop with respect to the label switched pa.th associated with a route to PE2, also provides reduction in the size of the links through multiplexing gains router P2 pops the outer label before sending the packet to PE2• When obtained from the nat.ural aggregation of the Bows between endpoints. As PE2 receives the packet, it uses the label carried by the packet (the label compared with the conventional point-to-point model for managing QoS, that PE2 distributed to PE1 via BGP) to make its forwarding decision. It hoses provide a. reduction iu the st.ate information that a. customer must then removes the label and sends the packet to CE2. maintain. 10.3 Interdomain Routing with MPLS 179 180 Virtual networks 10.2.9 Scalability and could also be a way of providing end-to-end QoS by using guaranteed LSPs as a kind of virtual leased lines across domains. MPLS TE-tunnels We have already mentioned in the introduction of this chapter that. on cre (explicit LSPs) can potentially add a degree of flexibility in the selection of ating a VPN using connection oriented, point-t The utilization of MPLS for interdomain traffic could provide two advan tages compared with traditional hop by hop IP routing (RFC 3272). First, the utilization of MPLS will allow a complete decoupling between the rout SP, AS, ing and the forwarding functions. A border router could use a modified ver sion of BGP to announce a MPLS-reachability for external prefixes. This MPLS-reachability means that a peer could send traffic towardi:i these an Figure 10.10: Virtua.1 PoP nounced prefixes provided that an LSP is first established to carry this traffic. At LSP cstablislunent time, the border router will use conncctiou In situations where end-to-encl DiffScrv paths must be maintained, both admission control to decide whether the new LSP can be accepted imide its SP networks may need to provision DiffServ per hop behaviours at each domain or not. A second advantage is that it would be easy to associate QoS hop supporting a set of traffic classes with compatible performance targets. guarantees to ioterdoma.in LSPs. These guarantees would be the first step Note also that either the SP1 or SP2 network may not be a DillServ-aware towards the extension of traffic engineering across interdomain boundaries network. In this case the scenario would btill apply to provide bandwidth 10.3 Interdomain R out ing with MPLS 181 182 Virtual networks guarantees. The SP2, on the other hand, can similarly choose to expand its reach beyond its service region over the network of SP1 via inter-AS MPLS TE paths. It is worth mentioning that these remote aggregation routers co-located in other SP's network will wilikely participate in hosting SP1 SP's IGP and BGP routing planes and will most likely maintain its own AS, AS or be part of the AS of SP 1 . In this case, such TE tunnels may cross several Autonomous Systems, but the head-end and tail-end LSRs of traffic engineering tunnel may have the same AS number, as shown in Figure 10.10. Figure 10.12: Extended or virtual - trunk case 2 Scenario 2 - Extended or Virtual Trunk to CE2 end-to-end across several SP's networks. One application example Instead of co-locating a PE router in SP2 PoP, SP 1, for example, may would be the guaranteed bandwidth for voice - or video-over-IP services. also choose to aggregate customer VPN sites onto a SP2's PE router where The diagram below illustrates another example where CE1 and CE2 are inter-AS TE tunnels can be built and signaled through SP2's MPLS network cm;tomers of SP1 with EBGP peering relationships established across the between the SP2 PoP (to which SP1 customer CEs are directly connected) CE-PE links. An inter-AS MPLS TE tunnel may then be established from and SP1 's ASBR or PE routers inside SP2's network. This allows SPt CE1 in AS 1 to CE2, which may belong to the same AS or different Au customers connected to SP2 PE router to receive a guaranteed bandwidth tonomous Systems than that of CE1 across SP1's network in AS2. service up lo the TE LSP tail-end router located in SP1's network. In this ln,_·AS llPLS Tl! tunr-. scenario, there could be two applicable cases: • Case 1: The inter-AS MPLS TE tunnel functions a.s an extended or virtual trunk aggregating SPL CE's local-loop a.ccci;s circuit on MPLS network of SPl SP, AS3 over which the bandwidth can be guaranteed to the TE LSP tail-end router located in SP1 network, as shown in Figure 10.11. • Case 2: The inter-AS l' Inter-AS MPLS TE tunnels lnler-AS MPLSDS-TI: tunnels Figure 10.14: End-to-end inter-AS MPLS TE Figure 10.16: TE a.cross multi-AS within a single SP administrative domain to deliver more customer traffic with already available capacity in the net timization and path protection/ restoration planning when coordinating all work without violating performance targets, and/or to provide better QoS network resources (not partially) as a whole. For a network which may services via an improved network utilization, operating more likely below consist of many Autonomous Systems, this could be realized via the estab congestion thresholds. It is worth noting that situations where resource lishment of inter-AS TE LSPs as shown in the Figure 10.15. The motivation provisioning is not an issue, e.g., low density in inter-AS connectivity or for inter-AS MPLS TE is even more prominent in a Diffscrv-enabled net inter-AS capacity may not require more scalable and granular TE facilities work over which statistical performance targets are to be maintained from beyond BGP routing policies since such policies could be rather simple, and any point to any point of the network as illustrated in the diagram below because inter-AS resource optimization is not an absolute requirement. with an inter-AS DS-TE LSP, Figure 10.16. For example, the iqter-AS MPLS DS-TE LSP shown in the diagram above could be used to transport lnter·AS MPLS Tl: tunnels a set of Layer-2 Pseudo Wires or VoIP traffic with corresponding QoS re quirement. F\1rthermore, fast recovery in case of ASBR-ASBR link failure or ASBR node failure is a strong requirement for such services. Scenario 5 - Transit Autonomous Systems as Primary and Redun dant Transport Scenario 5 presents another possible deployment case. SP1 with AS 1 wants to link a regional network to its core backbone by building an inter-AS MPLS TE tunnel over one or multiple transit Autonomous Systems be longing to SP2 , ... , SPn, as shown in Figure 10.17. Figure 10.15: TE acr06S multi-AS within a single SP administrative domain However many SPs, especially those with networks across multiple conti nents as well as sparsely connected, have designed their multi-AS routing policies, for example, along or within the continental or sub-continental boundaries where the number of Autonomous Systems can range from a very few to dozens. Generally, inter-continent or sub-continent capacity Figure 10.17: Tratu."it Autonomous Systems as primary and backup transport is very expensive. Some service providers have multiple Autonomous Sys tems in the same country and would like to optimize resources over their This scenario can be viewed as a broader case of Scenario 1 where Lhe VPoP inter-region links. This would demand a more scalable degree of resource could be expanded into a regional network of SP1. The inter-AS MPLS TE optimization, whlcb warrants the consideration of extending current intra. LSP in this case may also be used to backup an internal path as depicted AS MPLS TE capabilities across inter-AS links. in Figure 10.18, although this could introduce routing complexities. In addition, one may only realize higher efficiency in conducting traffic op- Summary 10.3 Interdomain Routing with MPLS 185 186 Virtual networks Primary inl8f.AS llPLS TE tunnels 10.4 MPLS VPN MPLS VPN is a family of methods for harnessing the power of Multipro tocol Label Switching (MPLS) to create Virtual Private Networks (VPNs). MPLS ii:; well suited to the task as it provides traffic isolation and differen tiation without substantial overhead. Backup inter-AS MPLS TE tunnels Figure 10. l8: Transit Autonomous Systems as primary and backup transport The major objectives of IlGP/ MPLS virtual private networks are to simplify network operations for customers while allowing the service provider to offer scalable, value-added services. These virtual private networks provide many benefits, including the fact that there are no constraints on the address plan used by each VPN customer. The customer can use either globally llllique or private IP address spaces. Another advantage is that the CE routers at each customer site do not directly exchange routing information with other CE routers. Customers do not have to deal with inter-site routing issues because inter-site routing issues arc the responsibility of the service provider. Furthermore, VPN customers do not have a backbone or a virtual backbone to administer. Thus, customers do not need management access to PE or P routers. Another benefit includes the fact that providers do not have a separate backbone or virtual backbone to administer for each customer VPN. Thus, providers do not require management access to CE routers. Also, service providers can use a common infrastructure to deliver both VPN and Internet connect.ivity services. Another very interesting feature supported by this model, is flexible and scalable QoS for customer VPN services. This is supported through the use of the experimental bits in the MPLS shim header and by the use of traffic engineering LSPs. 10.5 Layer-2 MPLS VPN 187 188 Virtual networks 10.5 L ayer-2 MPLS VPN 10.6 Laycr-3 MPLS VPN A layer-2 MPLS VPN, also known as L2VPN, is a point-to-point pseudowire A layer 3 MPLS VPN combines enhanced BGP signaling, MPLS traffic service. It can be used to replace existing physical links. The specification isolation a.nd router support for VRFs (Virtual Routing/ Forwarding) to is based on the Martini drafts, which define methods to transport layer-2 create a virtual network. This solution is more scalable and less costly than frames across MPLS networks, and methods to encapsulate transport proto classic provider-ba.-;ed frame relay or ATM-based networks, or IPsec-based cols such as ATM, Ethernet, and SONET/ SDH. The primary advantage of VP Ns. Layer-3 MPLS VPNs also support Quality of Service. this MPLS VPN type is that. it can trai:sparently replace an existing ded icated facility without reconfiguration, and that it is completely agnostic to upper-layer protocols. By contrast, in a layer-3 VPN the hosts process IP-packets. Multipoint Layer-2 MPLS VPN A multipoint layer 2 VPN for Ethernet, can be implemented using Vi rtual Private LAN Service (VPLS) a.nd MPLS pseudo wires (ATOM). It builds on the foundation of point-to-point layer 2 MPLS VPNs to extend an ethernet broadca::;t domain across multiple sites. The VPLS network appears as a. private ethernet switch to the attached MPLS end site. 10. 7 VSAN (Virtual storage area network) 189 190 Virtual networks 10.7 VSAN (Virtual storage area network) VSANs offer the following features: • '!raffle isolation Traffic is contained within VSAN boundaries and devices reside only in one A VSAN (Virtual Storage Arca NeLwork) mainly allocate ports across dif VSAN, thus ensuring absolute scpar.ition between user groups, if desired. ferent physical fabrics to create a virtual fabric. It acts as a self-contained • Scalability fabric despite :;haring hardware resources on switch/ switches. Ports within VSANs are overlaid on top of a single physical SAN. The ability to create several logical VSA N layers incrcw;cs the sotlability of the SAN. a switch can be partiLioned into multiple VSANs. Vice versa, multiple • Per-VSAN fabric services switches can join available ports to form a single VSAN. Replication of fabric services on a per-VSAN basis provides increased scalabil ity and availability. Unlike a typical fabric bound by its port limitation, a VSAN can be dy • Redundancy namically expanded or reconfigured to incorporate more or less ports. A Several VSANs created on the same physical SAN ensure redundancy. U one VSAN fails, redundant protection is provided by a configured backup pal.h VSAN resembles VLAN (Virtual LAN) in Ethernet terminology. Tue de between the host and the switch. sign was modeled after VLAN. A VSAN can offer dilferenL protocols such • Ease of configuration as FC, FCIP, FICON, iSCSI. Each VSA~ is a separat.c entity using distinc Users ca.n be added, movc:.' 11.1 Network System s Chapter 11 Transport Networks: • Metro access - SDH metro ring applications. Network systems - Multi-Service provisioning nodes. • Metro core - SDH ADM metro ring and mesh application. - Optical add/ drop multiplexers. • Long haul/ ultra-long haul - SDH ADM rings and line systems. - DWDM li.11c syi:;telIUI. _...Reglonel Figure 11.1: Network equipment cla.'iSification ATM {Aa:iynchronouis Tranafer f\.•lode), FR. (PYam• Re.lA)'), Oh& (GlstabiL Ethernet), MPLS (MPLS Mult.i-Ptotocol Lab~I Switching), MSPP (Muhl·Servlce Provletonlna rtatror,n). OXC (Optical ~Connect), OADM (Optical Add/ Drop Multlplexfrr), RPR. ( Reemem Packet R.iug) 1 WOM (\Va.velength Division Multiplexing), OWOM (Oen• W•"-elensth Olvb:lon Muhlplexlna ). ULH (Uhr-a-Lon.g Haul). 11.1 Network Systems 193 194 Network systems Metro access networks: Long Haul/ Ultra Long haul networks: • Carriers: lLECs, CT,ECs, IXCs/ local, and CATV • Carriers: IXCs, national ISPs, national operators. • Services: legacy local exchange voice, data (web hosting, Internet access, file • Services: Interconnect ISPs/lLECs/ CLECs/ corporalions, wide area VPNs. transfer, email, SAN), and video (broadcast , PPV). • Geographic Span: Over 500 km. • G Metro core networks: • Carriers: ILECs, CLECs, and MAN SPs. • Services: ILEC's voice and private lines, link backbone ISPs with access clients packet/cell traffic, enterprise services such as SANs, VPNs, VoIP, and several Ethemet-basccl services • Geographic Span: < 250 km. • Economic Sensitivities: terminal equipment costs including routers, switclu:!S, and aggregation devices. - cost associated with ~"tance and physical impairments less i;ignificant. • Traffic Characteristics: aggregated traffic from access networks and large cus tomers (enterprises) • Signal Rates/ Formats: numerous rates from 0.1 to 10 Gbit/ s carried in SONET/ SDH, CbE, RPR, ATM, and proprietary formats. • QoS; varies widely from highly reliable to best-effort. • Critical Choices: challenged to build a scalable, convergent network infrastruc ture to satisfy the needs of disparate services and chooosing among multiple architectures and products. - Currently dominated by SDH ring technologjcs optimized for TDM services (voice, private lines). 196 Standardization 12.1 Standardization in telecommunications 12.1.1 Standard organizations Chapter 12 3GPP Third Generation Partnerehi Pro· '..3GPP2 l1lird Generation P8rtnerehl Pr Standardization . ANSI American Nallonal Stanclarde lnatltute ETSI Eu n Teklcilmmul\leallon Standards lnatltute IEEE ISO lnternatlonel o; · nlZaitlon for Standarclatlon ISOC Internet Soc:iety IETF Internet E - Taak Force rru International Telecommunlcatlona Union .NIST Nallonal lnatllute of Standarda and Tec:hnology Figure 12.1: Tck.-communication standard organizations 3GPP (3rd Generation Partnership Project) The 3rd Generation Partnership Project (3GPP) is a collaboration agree ment that was established in December 1998. The collaboration agreement brings together a number of telecommunications standards bodies which are known as Organizational Partners. The current Organizational Partners a.re ARIB, CCSA, ETSI, ATIS, TTA, and TTC. The establishment of 3GPP was formalized in December 1998. The original scope of 3GPP was to pro duce globally applicable Technical Specifications and Technical Reports for a 3rd Generation Mobile System based on evolved GSM core networks and the radio accei;s technologies that they support (i.e., Universal Terrestrial Radio Access (UTRA) both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) modes). The scope was subsequently a.mended to include the mair1tenance and development of the Global System for Mobile communication (GSM) Technical Specifications and Technical Reports in cluding evolved radio access technologies; e.g., General Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE). 3GPP2 The Third Generation Partnership Project 2 (3GPP2) is a collaborative third generation (3G) telecommunications specifications-setting projed com- 12.1 Standardization in telecommunications 197 198 Standardization prising North American and Asian interests developing global specifications consensus standards and conformity asscs.sment systems, and safeguarding for Cellular Radio t~lecommunication lntersystem Operations network evo their integrity. The headquarters is in New York, NY. Major standards in lution to 30 and global specifications for the radio transmission technolo the telecommunication area are FDDI (Fiber Distributed Data Interfo.cc) gies. 3GPP2 was born out of the International Telecommunication Union'!! and FCS (Fiber Channel Standard). (ITU) International Mobile Telecommunications IMT-2000 initiative, cover ing high speed, broadband, and Internet Protocol (IP)-based mobile systems ETSI (European Telecommunication Standards Instit ute) featuring network-to-network interconnection, feature/service transparency, The European Telecommunications Standards Institute (ETSI) is an inde global roaming and seamless services independent of location. IMT-2000 is pendent, non-profit organization, whose mission is to produce telccouunu intended to bring high-quality mobile multimedia. telecommunications to nicat.ions standards for today and for the future. 13ased in Sophia Antipolis a worldwide mass market by achieving the goals of increasing the speed (France), the European Telecommwlications Standards Institute (ETSI) is and ease of wireless communications, responding to t he problems faced by officially responsible for standardization of Information and Communication the increased demand to pass data via. telecommunications, and providing Technologies (ICT) within Europe. These technologies include telecommu anytime, anywhere services. Ilaclc in 1998, when serious discussions about nications, broadcasting and related areas such as intelligent transportat.ion working on the IMT-2000 initiative began, it became evident that the goals and medical electroniC8. of globalization and convergence could not be accomplished efficiently us ing traditional f>tandards-setting processes, often characterized as too slow TacflnlClll c:.vn W I given the speed with which technology was forging ahead. Bodies such ERM (EMC and Radio EE (Environmental ATA ~ Termlftlla as the Global Standards Collaboration (GSC) and Radio Standardization Spectrum llattenl) En~ng) (RAST) helped to forge understanding of is.sues and work plans among all ..ctAcc:eM Participating Standards Organizations (PSOs). The concept of a Partner IT11 "=>Md 11 ~~8dors I DECT Digital Enhanced ship Project was pioneered by the European Telecommunications Standards CordleH Institute (ETSI) early in 1998 with the proposal to create a. Third Gener I ~ 1 I MTS.:~~~1 Telecommunlcell- ation Partnership Project (3GPP) focming on Global System for Mobile (GSM) tcclmology. Although discussions did take place between ETSI and I s::::: 11 s~~=-) I the ANSI-41 community with a view to consolidating collaboration efforts 1==. 1 for a.II ITU family members, in the end it was deemed appropriate that a. :=:, ST~=:roc::~ IPayT;.: I para.Ile! Partnership Project be established - 3GPP2, which, like its sister project 3GPP, embodies the benefits of a. collaborative effort (timely deliv SllG (Special 1,-=z..... 1 ery of output, speedy working methods), while at the same time benefiting Moblle Group) TIPHON from recognition as a specifications-developing body, providing easier ac T~ UllTS end ...... PrGIOCOI JTG ECllA TC32 Unlvenal MObile IW-imtiool cess of the outputs into t he ITU after transposition of I.he specifications in EBUICEHELECIETSI Communiclllion, Telecomrnunk:lll Joint Technlall a Standards Development. Organization (SDO) into a standard 8Jld submit Nelwoltca and s~e System Commltl.,e Interconnection 0---- tal via the national process, as applicable, into the ITU. Figure 12.2: ETSI Technical committees and projects ANSI {American National Standards Institute) The American National Standards Instit.ute (ANSI) h IEEE (Instit ute of Electrical and Electronics Engineers) ISO (International Organization for Standardization) IEEE is a non-profit, technical professional assoc.iation of more than 360,000 ISO is a network of the national standards institutes of 146 countries, on individual members in approximately 175 cowitries. Through its members, the basis of one member per country, with a Central Secretariat in Geneva, the IEEE is a leading authority in technical areas ranging from computer en Switzerland, that coordinates the r.ystcm. TSO is a non-governmental orga gineering, biomedical technology and telecommunications, to electric power, nization: its members are not, as is t he case in the United Nations system, aerospace and consumer electronics, among others. Through its technkal delegations of national governments. Nevertheless, ISO occupies a special publishing, conferences and consensus-based standards activities, the IEEE position between the public and privaLc sectors. This is because, on the one produces 30 percent of the world's published literature in electrical engi hand, many of its member institutes are part of the government.al structure neering, computers and control technology, holds annually more than 300 of their cowitrics, or are mandated by their government. On the other hand, major conferences and has nearly 900 active standards with 700 under de other members have their roots uniquely in the private sector, having been velopment. The standardization groups in bold are active. set up by national partnerships of industry associations. Therefore, ISO is able to act as a bridging organization in which a consenr.118 can be reached on solutions that meet both the requirements of business and the broader needs of society, such as the needs of stakeholder groups like consumers and users. Because International Organization for Standardization would 802.5 Toan have different abbreviations in different languages (IOS in English, OIN in 802.6 French for Organisation internationalc de normalisation), it was decided 802.7 1112.8 at the outset to use a word derived from the Greek isos, meaning equal. I02.I Therefore, whatever the country, whatever the language, the short, form of 802.10 the organization's name is always ISO. 802:·11 802.12 802.13 802.14 802.15 ISOC {Internet Society) 802.1 11 The [nternet SOCiety (ISOC) is a professional membership society with 802.17 more than 150 organization and 16,000 individual members in over 180 802.111 802.19 countries. It provides lea.dership in addressing issues that confront the fu 802.20 ture of the Internet, and is the organization home for the groups responsi 802.21 ble for Jnternet infrastructure standards, including the Internet Engineering 802.22 WI ...... - n8twoitc WAAN Task Force (IETF) and the Internet Architecture Board (JAB). Since 1992, Figure 12.3: lEEE working groups the Internet Society bas served as the international organization for global coordination and cooperation on the Internet, promoting and maintaining Reference: www.ieee.org a broad spectrum of activities focused on the Internet's development, avail ability, and associated technologies. The Internet Society acts not only as a global clearinghouse for Internet information and education but also as a facilitator and coordinator of Internet-related initiatives around the world. Through its annual International Networking (lNET) conference and other sponsored events, developing-country training workshops, tutorials, statis tical and market research, publications, public policy and trade activities, regional and local chapters, standardization activities, committees and an international secretariat, the Internet Society serves the needs of the growing global Internet community. From commerce to education to social issues, 12.1 Standardization in telecommunications 201 202 Standardization our goal is to enhance the availability and utility of the Internet on the widest possible scale. ISOC {Internet Socielyl ,....IFNC Nelworll Council ...... 1 tlolwAree 2 GenenlAree IANA - lnlernet lnlemet AMlgned Number Authortly 3 Mee 4 91111 ARI' (~ Reglnyfor 5 IETF i-1 Nurnbetsl 6 - ' Internet . Internet CNlntll , VA, USA 1 ~rel\ 8 IEfttlMetine RIPE (RMeeu IP Europeens) T TMkF Network CoorclMtlon Amsterdam, Tiie NelherUncla Wor'king Groups Figure 12.5: IETF working-group areas APNIC (Asi•n Peclftc NICI Int- Registly •Ill~ IHon, an.i.n., -'-ill I I T F NrlNIC {Alrtc. Region NICI M•1•tllu• LA.CHIC (l..dn A..nc. Mel - ClribbMn llllrlda NICI ..,.,..111c1ea, uruvuev Figure 12.4: Organization of the IntemeL Society (ISOC) IETF (Internet Engineering Task Force) The Internet Engineering Task Force (IETF) is a large open international llFCtvm Nuinbet .i:WZ cormmwity of network designers, operaton>, vendors, and researchers con s SU.nclard --""' ""' cerned with the evolution of the Lntcrnet architecture and the smooth op D Dnfl atonclard p p._.i standllrd eration of the lnLcrnet. It is open to any interested individual. The actual I lntormnlW technical work of the IETF is done in its working groups, which are orga B llestprectlae E Experlmeni.I nized by topic into several areas (Applications, General, Internet, Opera H Hlatorlc tions and Management, Routing, Security, Sub-IP, and Transport). Much of 0 Obeoleted the work is handled via mailing lists. The IETF holds meetings three times . unc111.. n1e<1 1Aor 1•t of ...... per year. The IETF working groups are grouped into arc8.'J, and managed by Area Directors. They a.re members of the Internet Engineering Steering Figure 12.6: Typei; of RFCs (request for comments) Group (lESG). The IETF secretariat is in R.eston, VA, USA. 12.1 Standardization in telecommunications 203 204 S tandardization ITU (International Telecommunications Union) The ITU, headquartered in Geneva, Switzerland is an intcrnationa.I organi zation within the United Nations System where governments and the private sector coordinate global telecom networks and services. lTU has three sec tors: Radio communication, standardization, and development. The ITU-T recommendations are identified by an alphabetic letter and a Arabic munbcr separated by a point. IT\J Te!ecommunlcatlot'!I Sector A ~of theWOfll of IT\H B ....,,. of exsw-ion: clellnlllone, aymbol9, dMdiclltlon J _ C O.-. lelecOIMl...icallon -iatlca I ~ .___~_~_:_u~-1_;.. _, ~ D Ge...i tariff princlplea E OvenlH netWOfll openlllon, lelephone -vice, .-vice opet911on and hUINln r.ctora IGf _.,.. •• 801 SGIO F NOIHMphone teleoommunlcall a«Yk:ea Service G ~~and media, dlgllill a~ lllld nlllwOOca om...__ Telewlslon n Ungmgeafor Dellnlllon lllld H ~ lllld rnulllmedla SV- lllld 111*1 Termlnahl.fot $Qlnl T~ Tr.nemlatlon tlon 1 ln19gtMlld semc:e. dlgllill netwwk 8Y9*M Telemat!C Commun1C911on Al!Picalione J Tranemleelon of televlalon, 90Und pr0Qf'9mme and Oilier muttlmedia elpla Servicte K Prolec:1lon against lnltlference L Conllnlc:tion. 1.-..ilon and proledlon of cebles and Olller .ien-al oulalde plant '812 SG14 8011 II TllN lllld net-.1c .....,__, I_,,_ tranemlMlon s~ llllephone circulta, telegnphy, fax lloclemalllld EncMo-end T.....,...... , N ~ ~-••llonel -m progi-lllld telelllalon trwmiaion drQllls Tr--..ion s,...... 1ar T•••lulon 0 Speciftcallons of W#lng equipmenl ~of Dat8, Telegraph S~lllld P Telephone tranemiNlon quallty, telephone lnslllllllliona, locll llne networtc. N-iband Equlplllenl 0 Swltc:hlng and elgnalUng . Termllwla •~c R Telegraph tranemlaelon ~ S Telegnipll ~ t«mlnal equipment T Twmlnlla lor lllelNllk: ~ Figure 12.7: Standardization in ITU-T U Telegraph swldling v !>Mii ~-the telephone networt< X o.ta networtcs and °'*' SJllfiem communlaitlon Y Olobel 1ntorinat1on lnlraatructure and Internet protocol ••peda z LaflllU9ll9S lllld llfl*lll ~ Mpecta for tMcomftlunlcatlon •yatems l~igure 12.8: ITU recommendation groups 12.1 Standardization in telecommunications 205 206 Standardization NIST (National Institute of Standards and Technology) 12.1.2 Fora Founded in 1901, NlST is a non-regulatory federal agency within the U.S. Commerce Department's Technology Administration. NIST's mission is to DE develop and promote measurement, standards, and technology to enhance ECTF ---..·-· ...... I productivity, facilitate trade, and improve the quality of life. NIST locations n.--• are in Gaithersburg, MD, and I3oulder, Co, USA METR~ ·h~!~ ..".! - l'{f :!: ~" .... Reference: www.nist.gov (((!VolceXMl. ::§FORUM Ttt..vl.m;o;;c.,.n ! .•.••h .. .-•• ~· "'..:: ,_... Aleoc:i8liollS Alll Forum ATll Forum -.111m1orum.com DECTForum DECTForum -.elect.ch ECMA Eu_,, Com.,.,,_ Manufllct...,.. Aaaoclatlon - •..,...... nlemldionel .""' ECTF Eur<>DMn Comm..,lty TeleworlnJm.com UF L-. Forum -.IOClllionloru""' MEF -..H!themet Forum -.--1oelfooun\.<>m _.meforum...... llSF llultleenlce --Forum MPF Forum www.-*'"... org~ Oii' Onti<81 lnlemelWOftdna Forum - .olforum.com SIP Forum -SIP Forum ... T11Forum TeleManegemenl Forum --.tmtorum.""' UMTSForum UMTSForum - .umi.-torum.oi'Ci Volc:eXML Forum VolceXML Forum - .volcexml.""' WAPl'onlm w1..-a Annllalllon Protocol Forum -.-orum,.oro Figure 12.9: Telecommunication fora a.nd associations ATM Forum The ATM Forum is an international non-profit organization formed with the objective of accelerating the use of ATM (Asynchronous Transfer Mode) products and services through a rapid convergence of interoperability speci fications. ln addition, the Forum promotes industry cooperation and aware ness. Since its formation in 1991, The ATM Forum has generated very strong interest within the communications industry. Currently, The ATM Forum consisls of approximately 80 member companies, and it remains open to any organization that is interested in accelerating the availability of ATM-based solutions. The ATM Forum consists of a worldwide Technical Committee, marketing awareness programs such at Broadband Exchange, and the User Committee, through which ATM end-users participate. The ATM Forum Technical Commit.I.co works with other worldwide standards bodies selecting appropriate standards, resolving differences among slan- 12.1 Standardization in telecommunications 207 208 Standardization The six areas examined in the roadmap a.re: • Emerging Applications/ Services Emerging Architectures • Ubiquitous Wireless Services ECMA International (European Com puter Manufacturers Asso • Public Safety Networks & Homeland Security ciation) • Content Delivery Services Since 1961 EC.MA facilitates the timely creation of a wide range of global • Converged Network Services Information and Communications Technology (ICT) and Consumer Elec • Next Generation Networks tronics (CE) standards. ECMA International came into existence in 1994, • Optical Network when the name was changed in order to reflect the international a.ctivities of the organization. The field of private/ corporate telecommunications in ATM has been seen as one of the most prevalent technologies in service cludes architecture, service, protocol, interoperability, management and ap provider networks over the last decade. Its role has been both as a core plication aspects of Corporate Telecommunication Networks (CNs). They networking technology to offer a resilient and predictable connection ori include narrowband and broadband Private Integrated Services Networks ented cell transport and as an aggregation and access technology where the (PISNs) and private networks based on the Internet Protocol (IP). In par QoS classes allow for service differentiation. ATM and FR services are still ticular the field includes the following: generating more revenue in today's networks than IP VPN. Over the years, The ATM Forum has had to place emphasis not just on developing ATM The DECT Forum represents the interests of the DECT industry v.;th specifications but on tackling the interworking requirements. From the mid- the following main-objectives: 90's there was a clear need to develop more intelligent IP/ ATM solutions • Computer Supported Tclecommwlications Applications (CSTA). and since 2000, the emphasis has shifted to look at how ATM and MPLS • Architecture, service and protocol aspects of narrowband and will co-exist. Whatever technology is used in the core, such as MPLS, trans broadband Private Integrated Services Networks (PISNs). parency to the end customer is required, so the encapsulation of one traffic • IP-based multimedia communications in a business environment, type across a different network must be user and application transparent. including interoperability of narrowband and broadband PISNs The ATM Forum produced some of the initial specifications in this area, with IP networks. with the key principle being that ATM/ MPLS interworking allows ATM • Near-Field Commw1ica.tion Systems, for the realization of simple users to be interconnected via a tunnel across the MPLS network. wireless communication between close coupled devices for network products and consumer equipment. 12.1 Standardization in telecommunications 209 210 Standardization ECTF (European Community Telework/Telematics Forum) IPv6 Forum The ECTF is driven by this mission to bring about its vision of interop A world-wide consortium of lea.ding Internet vendors, Research and Ed erability in the computer telephony (CT) indlll>try. The ECTF provides ucation Networks are shaping the 1Pv6 Forum, with a clear mission to services to companies at every layer of the CT Value Chain. The role of promote 1Pv6 by dramatically improving the market and user awareness of the ECTF is to serve as the ultimate authority for guidance on how to im TPv6, creating a quality and secure Next Generation Internet and allow plement CT products and solutions. The ECTF acts 8.5 an umbrella group ing world-wide equitable access to knowledge and technology, embracing a with liaisons to coordinate with more narrowly focused industry groups in moral responsibility to the world. The IPv6 Forum will not develop protocol order to provide a consolidated industry framework. standards. The Goals arc the following: Frame Relay Forum • Establish an open, international Forum of IPv6 expertise. This forum came together in 1991 to promote the use of Frame Relay and to • Sha.re IPv6 knowledge and experience among members. develop conunon ways of implementing it. The forum is made up of many • Promote new 1Pv6-ba.scd applications and global solutions. manufacturers and developers. The Frame Relay Forum has now become • Promote interoperable im plementations of Tpv6 standards. the MPLS and l<'ra.me Relay Alliance • Co-operate to achieve end-to-end quality of service. • Resolve issues that create barriers to 1Pv6 deployment. H .323 Forum LIF (Location Interoperability Forum) The H.323 protocol suite is an ITU standard addressing multimedia commu The Location Interoperability Forum (LIF) is a global industry initiative. nication. Today, H.323 enjoys the majority share of VoicEH>ver-IP market It was formed by Erk.sson, Moto1·ola and Nokia in September 2000. More and a growing share of Video-over-IP market. Carrying traffic measured in than 100 organizations have joined LIF. The purpose was to develop and billions of minutes of use per month, H.323 has proven to be an extremely promote common and ubiquitous solutions for Mobile Location Services scalable protocol that meets the needs of both service providers and en (MLS). Mobile Location Services are predicted to become remarkable valuo terprises worldwide. This offers the voice/ video industry huge opportunity added services. The use allows wireless appliance users to combine mobility and responsibility; (1) opportunity to the companies offering H.323 prod with the internet. The LIF recommendations will be network protocol and ucts and services, (2) responsibility to build a flexible network that enables positioning technology independent. services we can only imagine today. The H.323 Fornm was created under lMTC (with ITU support) to address a growing industry need to promote Main Goals of LIF focused on mobile location arc: H.323 protocol awareness. While H.323 solution,s arc widespread, inaccu rate protocol information abounds. II.323 Forum provides the needed H.323 • To promote a family of st.a.ndardized methods for location determi industry voice and meeting place. nation and their architectures. Focus in reducing the complexity and multiplicity of the current pObition methods. • To establish an open standardized API between location applica The Goals are the following: tions and wireless networks in order to facilitate the development • Maintaining this website containing both technical and marketing of new end-user applications. informatio11 . • To contribute and iniluence standard bodies and specifications to • Coordinating ongoing H.323 Forum conferences to discuss impor ward common procedures for location finding, testing and verifica tant industry issues. tion. • Defining H.323 certification criteria. by which vendor equipment can be measured in a. consistent manner. MEF (Metro-Ethernet Forum) • Representing H.323 interests in related conferences and forums. 12.1 Standardization in telecommunications 211 212 Standardization The Metro Ethernet Forum is a non-profit organization chartered with the Ethernet Forums objectives: mission of accelerating the adoption of optical Ethernet as the technology • Build consensus and unite service providers, equipment vendora of choice in met.co networks worldwide. The Forum is comprised of lead and end-customers on Ethernet service definition, technical speci ing service providers, major incumbent local exchange carriers, I.op network fications and interoperability. equipment vendors, test equipment vendors and other prominent network • Facilitate implementation of existing and new standards, Ethernet ing companies that share an interest in metro Ethernet. In 2003, the MEF service definition, test procedures and technical specifications of bylaws were amended to include membership by large Enterprise organiza the MEF to allow delivery of Ethernet services and make Ethemet tions specifically to address the growing interest by Business Enterprises. based metro networks carrier-class. The involvement of the Enterprise is seen to provide valuable customer and • Enhance worldwide awareness of the benefits of Ethernet services teclmical requirements to further guide the activities of the MEF. The MEF and Ethernet-based metro transport networks. has over 60 members as of June 2003. Ethernet is entering the metro area based on projections that data is creating a greater traffic load than voice. When data. dominates the traffic content, it is most rational to use a data The primary priorities of the MEF a.re to define: infrastructure rather than a TDM infrastructure. Ethernet is the logical • Ethernet Services for metro transport networks. Ethernet ser choice for data transmission as it is by far the most widely deployed and vices defined by the MEF arc transport agnostic. The Metro Eth mature data transport. technology. There have also been technical advances, ernet serviceii can be communicated using two umbrella service including increases in the speed and distance of Ethernet, supporting the types: Ethernet Line Services (£..Line Services - point-to-point ser migration of Ethernet into the metro area. vices) and .t'thcrnct LAN Services (E-LAN Services - multipoint to-multipoint services). Other advantages driving the deployment of Ethernet technology into • As part of the E-Line Service and E-LAN Service definitions, metro area networks include: the MEF has defined the service at.t.ribut.es and parameters rec ommended for successful implementation of these services. This • Ethernet has recognized strength as a service lechnology that means that for each servk-e based on these Service definitions, there brings lower cost, simplicity, better service granularity and rapid are associated service attributes that have parameters, which must provisioning t.o customers. be set accordingly, so as t.o meet the customer service expectations. • There are continued ease-of-use adv-antages and price/ performance Typical service attributes include performance, bandwidth, speed, improvements which arc making Ethernet an important switching mode and class of service. Within ea.ch of these attributes pa and transport technology in metro networks for data traffic in gen rametel'l) a.re recommended that provide interoperability between eral and JP traffic in particular. metro Ethernet Service Providers and vendors who implement the • End customers have broad expertise and comfort with Ethernet. services. They also have access to a wide range of low cost, high perfor • Carrier-class Ethernet-based metro traru>-port technologies. This mance Ethernet products. Thus end customers have a dramatically will be done by spccifyi11g architecture, protocols and management reduced Total Cost of Ownership with Ethernet- based services. for all metro transport networks, and supporting such Ethernet • Metro Ethernet has thus moved beyond its LAN origins to be Services come a full-duplex, switched technology capable of meeting the long-range t ransport, bandwidth, geographical and capacity re The Hecoudary priorities of the MEF arc to define: quirements of metro networking. • Work to be done by other organizations on other transport tech nologies The result. is a compelling combination of speed, scalability, operational • Non-Ethernet interfaces, if not defi ned by other organizations. simplicity, and economics that is driving Ethernet into metro networks. 12.1 Standardization in telecommunications 213 214 Standardization Number Tec:hnlcel celeratc the development of next-generation networking and tclccommwli MEF2 R~ 8nd hmework tor Ethe,,,.. .-vice protection cations product1:> based on network processing technologies. By establishing Ml!F3 Circuit emulation _..ice, lremework •nd recP.....,_ In metro Ethernet networlul MEF4 Metro Ethemet network erchileCIUre 1,.mework .-It 1: Genetic .,.mewort< common Hpecifica.tions, the NPF enables equipment manufacturers to 8ig Ml!F 8 Metro E!hernet Mrvlce• dellnlllOM plleM I nificantly reduce their design burden, while having the flexibility to use the MEF7 EMS-NMS lnlonnetlon model best components Lo fit their requirements. 'fhe organization was formed MEFI lmplement811on eg__,,t for the emuletlon of PDH dn::ulta cw. metro Ethernet nelworlta MEFI Abelrect-aulte tote ...... MMCM et Ille UNI to build on the efforts of two former industry groups, the Common Pro MEF 10.1 l!lhemetMtYiCM ·-plleM 2 gramming Interface Forum (CPIX) and I.he Common Switch Interface Con llEF 11 u-network lntert.ee (UNI) requlNmenla and lr--n: sortium (CSIX), by delivering specifications for programmable network clo llEF 12 "'*° Ethemel network erdlleec1ure 1--..It 2: Elhemel ..,,,;cee llyer MEF13 u-network ~(UHi) type 1 llnpl.,._,tdon...,_1 ments that redu<.-e equipment time-to-market, while dramatically increasing ll!F 14 Abelrect - auia tot tralllc ~ plMM 1 time-in-market. MEF15 Req'*-for n...... -of me1ro Elhernet phue1 network....,_ MEF 111 Elhemel locel ,,.__... l....,.ce MEF 17 Service OAM tremework end requl-• • Hardware Working Group MEF11 AbelrllCt - auia for clrclllt emulltlon -vice• • Software Working Group MEF19 Abelrect leat suite for UNI type 1 • Benchmarking Working Croup MEF20 u ... network lntertece {UNI) ...... 2 lmpl-llon •°'""""1t MEF21 Abelrect leat suite for UNI type 2 pelt 1: Link OAM • Technical Education and Marketing Working Group Ml!F 22 Mobile beck-I imp191nentetlon •arMrnent MEF 23 CllM or ..,,,ice pheM 1 lmplemenlatlon eoreement MEF 24 Ab&lrllCt testsuia IOr UNI type 2 pelt 2 E-ull OIF (Optical Internetworking Forum) Table 12.1: Metro Ethernet Forum: MEF technical specifications The mission of the Optical lnternetworking Forum (OJF) is to foster the development aud deployment of interoperable products and services for MSF (Multiservice Switching Forum) dat.a. switching and routing using optical networking Leclmologies. The OIF wi] encourage co-operation among telecorn industry participants including equipment manufacturers, telecom service providers and end users; promote The Multiservice Switching Forwn's mis~ion has two principle aspects: globa.I development of optical internet.working products; promote nation • To accelerate the deployment of open commwlications i>ystems that wide and worldwide compatibility and interoperability; encourage input to realize economic benefits, resulting in t he flexible support of a full appropriate nti.tionttl and international standards bodies; and identify, se range of network services using multiple infrastructw·e technolo lect, and augment as appropriate and publish optical internetworking spec gies. ifications drawn from national and international standards. I3cing the only • To focus on the development of architectures and industry agree industry group wlitiug representatives from the data and optical networks, ments that enable interoperability and innovation in a rapidly OIF's p~ is to accelerate the deployment. of interoperable, cost-effective evolving environment. and robust optical intcrnctworks and their associated technologies. Opti cal internet.works are data networks composed of routers and data switches Much of the MSF's work is directed towards developing lmplcmentation interconnected by optical networking clements. Agreements (IAs) that further I.his mission and simplify the process of ar chiLecting and integrating more modular, multivendor systems. A key as • ArchiLcctw·c aud Signaling Working Group pect of this approach is to leverage the work of other industry bodies, which • Carrier Working Group have also developed standards, and protocols that support this goal. • Interoperability Working Group • OAM& P Working Croup NPF (Network Processing Forum) • Physical and Link Layer Working Group The Network Processing Forum (NPF) was organized to facilitate and ac- • Physical Layer User Group 12.1 Standardization in telecommunications 215 216 Standardization SIP Forum UMTS Fomrn recognizes Lhe importance of all players - including new en The SIP Forum's mission is to advance the adoption of products and services trants - in the mobile value chain. As well as offering guidance to govern based on the Session Initiation Protocol. The Forum provides information mental and financial communities it also provides marketing input to tech on the benefits and capabilities of SIP, highlights successful applications and nical standardization bodies and advises on spectrum requirements both for deployments, and directs activities aimed at achieving high levels of product the present and future 3G systems. The UMTS Fornm serves the interests interoperability. The Forum promotes SIP as the technology choice for mul of all its members through educational and promotional activities in its role timedia/real-time communication session control throughout the Internet, as the voice of the 3G mobile market. corporate networks and within next generation wireless networks. The SIP Fornm is open to everyone that is willing to contribute to spread information Objectives: of SIP and accepts the architectural model that SIP relics on. Individual • To promote a common vision of the development of UMTS and to membership is free. Organizations pay a yearly fee to cover the adminis ensure its worldwide success tration c<>l>'is of the Fomrn. SIP (Session Initiation Protocol) is emerging • To express a strong, unified industry voice promoting UMTS and as the protocol of choice for setting up conferencing, telephony, multimedia WCDMA technology tlll'ough lobbying and promotional actions and other types of communication sessions on the Internet. SIP may also globally be used for new types of communications, such as instant messaging and • To forge high-level dialogue between operators and other market application level mobility across various networks, including wireless, and players that can ensure commercial success for all across user devices. Work on SIP is accomplished primarily in the IETF SIP • To present market knowledge that aids the rapid development and working group, and at SIP bake-offs. SIP has however manifold interactions uptake of new services and applications. with other areas, such as the next generation wireless internetworks, QoS, payments and security. The objective of the SIP Forum is to facilitate the integration of SIP with such other areas of work on the Internet. We are at VoiceXML Forum the beginning of an explosion of new services under development by signifi The VoiceXML Forum is an industry organization formed to create and cant Internet service providers and by vendors of Internet technology based promote the Voice Extensible Markup Language (VoiccXML). With the on SIP. The SIP Forum is the meeting place for developers of commercial backing and contributions of its diverse membership, including key industry SIP based services and Internet technology, such as IP phones, PC clients, leaders, the VoiccXML Forum has successfully driven market acceptance of SIP servers and IP telephony gateways. VoiceXML through a wide array of speech-enabled applications. TM Forum (TeleManagement Forum) WAP Forum (Wireless Application Protocol Forum) The TeleManagement Forum (TM Fornm) is a non-profit global organiza The WAP Forum promotes the \!\Tireless Application Protocol having the tion that provides leadership, strategic guidance and practical solutions to following properties: Independent of wireless network standard, open to improve the management aJld operation of information and communications all, applications scale across transport options and across device types, and services. Our open membership of over 340 companies comprises incum extensible over time to new networks and transports. WAP is applicable to bent and new-entrant service providers, computing and network equipment number of cellular mobile systems. The WAP Forum is now part of OMA suppliers, software solution suppliers and customers of communications ser (Open Mobile Alliance). vices. TM Forum has been contributing to the Information and Communi cations Services (ICS) Industry for over 15 years. WiMax Forum The WiMAX F01um is working to facilitate the deployment of broadband UMTS Forum wireless networks based 011 the IEEE 802.16 standard by helping to ensure The UMTS Forum is an open, international body for promoting the global the compatibility and inter-operability of broadband wireless access equip uptake of UMTS third generation (3G) mobile b')'stems and services. The ment. The organization is a nonprofit association formed in 2003 by equip- 12.1 Standardization in telecommnnications 217 218 Standardization ment and component suppliers to promote the adoption of IEEE 802.16 12.1.3 Alliances compUant equipment by operators of broadband wireless access systems. The Wi.MAX Forum is comprised of industry leaders who are committed to the open interoperability of all products used for broadband wireless access. illiiwuf•T""'-~~ • Support IEEE 802.16 standard ~.. .,,$\;~- • Propose and promote access profiles for their IEEE 802.16 standard Resilient Patket Ring Alliance , • Certify interoperability levels both in network and the cell • Achieve global acceptance • Promote use of broadband wireless access overall %.;~' , TeMc:Qmmunic:8llon AWaric:,e ;;.;;.,.;._ ~}11 ATIS Alliance tor Telecommunications lnduatrv Solutions -.ati9. Figure 12.10: Telecommunication alliances ATIS (Alliance for Telecommunica tions Indust ry Solutions} ATIS is a United States based body that is committed to rapidly developing and promoting technical and operations standards for the communications and related information technologies indW:>1;ry worldwide w;ing a pragrna\,ic, flexible and open approach. ATIS prioritizes the industry's most pressing, technical and operational issues, and creates interoperable, implementable, end to end solutions - standards when the indu.<>try needs them and where they need them. Over 1,100 industry professionals from more t han :350 communications companies actively participate in ATIS' 22 industry com mittees and incubator solutions programs. ATIS develops standards and solutions addres:;ing a wide range of industry issues in a manner that allo cates and coordinates industry resources and produces the greatest return for communications companies. ATIS creates solutions that suppod the rollout of new products and services into the communications marketplace. Its standardization activities for wireless and wircline networks include in terconnection standards, number portability, improved data transmission, Internet telephony, toll-free accelX>, telecorn fraud, and order and billing i<> sues, among others. ATIS is accredited by the American National Standards Institute (ANSI). 12.1 Standardization in telecommunications 219 220 Standardization ATIS Committ.ccs and Forwns: The lOCEA has successfully completed its corporate objectives: • Administrative Council for Terminal Att.achments (ACTA) • Support the 10 Gigabit Ethernet slandards effort conducted in the • Dar Code/ Standard Coding {BCSC) IEEE 802.3 working committee • Emergency Services Interconnection Forum (ESIF) • Contribute re;ources to facilitate convergence and consensus on • International Forum for ANST-41 Standards Technology {!FAST) technical specifications; • Internetwork Interoperability Test Coordination {IITC) Commit- • Promote industry awareness, acceptance, and advancement of the tee 10 Gigabit Ethernet standard • Industry Numbering Committee (INC) • Accelerate the adoption and usage of 10 Gigabit Ethernet products • IMS! Oversight Council (IOC) and services • Interactive Voice Response (IVR) Forum • Provide rei;ources to establish and demonstrate multi-vendor inter • Network lnterconnection Interoperability Forum (NIIF) operability and generally encourage and promote interoperability • Network Interface, Power and Protection Committee (NIPP) and interoperability events • Network Reliability Steering Committee (NRSC) • Committee 05 - Wood Poles (05) • Ordering and Billing Forum (OBF) Internet Home Alliance • Optical Transport and Synchronization Committee (OPTXS) Internet Home Alliance is dedicated to advancing the home technology mar • Protection Engineers Group {PEG) ket by helping member companies build a market for products and services • Network Performance, Reliability and Quality of Service Commit- that require a broadband or persistent Internet connection. We are achiev tee (PRQC) {Formerly Tl Al) ing our mission by conducting market research and real-world pilots of new • Packet Technologies and Sy:;tems Committee (PTSC) technology and sharing those learnings, developing business models, facil • Telecommunications Fraud Prevention Committee {TFPC) itating networking and collaborative activities and leading high-level dia • Telecom Management and Opera~ ions Committee (TMOC) logues designed to surface, discuss and debate critical market issues. The • Text Telephone (TTY) Forum mission of Internet Home Alliance is to accelerate the development of the • Wireless Technologies and Systems Committee (WTSC) market for home technologies that rcqwre a broadband or persistent con nection to the Internet. Internet Security Alliance The Int-eruct Security Alliance was created to provide a forum for infor mation sharing and thought leadership on information security issues. It lOGEA (EFM Alliance (Ethernet in the F irst M ile Alliance) represents industry's interest before legislators and regulators and aims to Since December 2001 identify and standardize best practices in Internet security and network survivability while creating a collaborative environment to develop and im plement information scctuity solutions. The alliance is a collaborative effort between Carnegie Mellon University's Software Engineering Institute (SEI), its CERT Coordination Center (CERT/CC), and the Electronic Industries Alliance (EIA), a federation of trade associations. With the formation of the lOGEA (10 G igabit E thernet Alliance) Internet Security Alliance, members will have a single portal for up-to-thc The 10 Gigabit Ethernet Alliance (lOGEA), a non- profit company incor minutc threat reports, best security practices, risk management strategies, porated in the State of California which supported the combined activities and more, which will give them the edge in the competitive and volatile of its member companies, has now been dissolved. environment of the Intern et. 12.1 Standardization in telecommunications 221 222 Standardization 1'11rther, the Internet Secw·ity Alliance will undertake these crucial Through the efforts of the three working committees, the Forum encour activities: ages: • Promote great.er corporate responsibility on information socurity • lnput to the development of standards throughout the various in issues dustry i;tandards groups; • Provide early warning of emerging security threats • The creation of Implementation Agreements, based upon appropri • Provide in-depth reports on vulnerabilities and threats ate standards, on how lo build and deliver MPLS and FR networks • Facilitate executive-to-executive communications about solutions and services; to threats and emerging trends • The definitiou of Interoperability test suites and coordination of • Conduct research leading to identification and resolution of root Interoperability events to demonstrate the readiness of MPLS for causes to problems network deployments; • Develop training and certification programs in information assur • The creation and delivery of educational programs to educate the ance and other fields industry about MPLS and FR technologies, services and solutions; • Initiate standard-setting activities on the fow1dation of ElA's 75- • Duilding the awareness of MPLS as a technology ready for wide year heritage in the standards world scalc deployment within service provider networks to deliver prof • Provide a coordination point for industry dialogue on self ilable services to the end-user community. regulation issues such as privacy • Develop organizationally viable models for integration and adoi> OMA (Open Mobile Alliance) tion of security practices O'MA is the leading i11dustry forum for developing market driven, interoper • Work with legislative and regulatory bodies to ensure cfficie11t link able mobile service enablers. OMA was formed in June 2002 by nearly 200 ages are maintained companies including the world's leading mobile operators, device and net • Educate senior management and boards work suppliers, information technology companies and content and service • Conduct timely seminars on emerging security issues providers. The fact that the whole value chain is represented in OMA marks a change in the way specifications for mobile services are done. Rather than keeping the traditional approach of organizing activities around technology areas, with different standards and specifications bodies representing differ ent mobile technologies, working independently, OMA is aiming to consoli date inlo one organization all specification activities in the service enabler space. OMA is the focal point for the development of mobile service en abler specifications, which support the creation of interoperable end-to-end mobile services. OMA drives service enabler architectures and open enabler interfaces that arc independent of lhe undedyi.ng wireless networks and plat MPLS and Frame Relay Alliance forms. OMA creates interoperable mobile data service enablers that work Founded in March 2000 the MPLS Forum merged with the Frame Relay across devices, service providers, operators, networks, and geographies. To Forum to create the MPLS and Frame Relay Alliance in April 2003. The ward that end, OMA will develop te:.'t specifications, encow·agc third party MPLS and Frame Relay Alliance is an industry-wide association of network tool development, and conduct test activities that allow vendors to test ing and telecommunication companies focused on advancing the deployment their implementations. A year into the formation of OMA, significant con of multi-vendor multi-service label switching networks and associated ap solidation has already been achieved with the integration of the WAP Fo plications. The Forum provides a meeting ground for companies that arc rum, Location Interoperability Forum (LIF), SyncML Initiative, MMS-IOP creating MPLS and FR products and deploying MPLS and FR networks (Multimedia Messaging Interoperability Process), Wireless Village, Mobile and services. Gaming Interoperability Forum (MGlF), and the Mobile Wireless Internet 12.1 Standardization in telecommunications 223 224 Standardization Forum (MWIF) into OMA. This consolidation promotes end-UH!nd interop 12.1.4 Consortia erability across different devices, geographies, service providers, operators, and networks, and further supports OMA's market and user requirements focus to guide the specification work. W!£ !O'lf W'PE WH The Goals of the OMA: • Deliver high quality, open technical specifications based upon mar ket requirements that drive modularity, e>.i.ensibility, and consi& Opet!GIS Consottlum tency amongst enablers to reduce industry implementation efforts. I • Ensure OMA service enabler specifications provide interoperability 1~ across different devices, geographies, service providers, operators, and networks; facilitate interoperability of the resulting product Figure 12.11: Tclocommunioation consortia implementations. • Be t he catalyst for the consolidation of standards activity within the mobile da.ta. service industry; working in conjunction with other OGC (OpenGJS Consortium) existing standards organizations and industry fora to improve in The OpenGIS Consortium (OGC) is an international industry consortium teroperability and decrease operational costs for all involved. of more than 230 <..'Ompaniei;, government agencies, and universities partici • Provide value a.nd benefits to members in O:MA from all parts of the pating. Its aim is to develop publicly available geoprocessing specifications. value chain including content and service providers, information OGC works on various specifications that arc critical to the future devel technology providers, mobile operators and wireless vendors such opment of distributed spatial systems. OpenGIS Specifications support that they elect to actively participate in the organization. interoperable solutions to make complex spatial information and services accessible and useful with all kinds of applicatioD8. These specificatiOD8 include interfaces for requesting gcospatial features, describing map styles, RPR Alliance requesting and generating maps, invoking feature coordinate transforma The Resilient Packet rung Alliance was established to promote standards tions, defining and requesting coordinate transformations, geocoding, as based Resi.lient Packet Ring technology and to encourage the utilization and well as image and map annotation. implementation of Resilient Packet Ring as a key networking technology for connectivity of various computing, data and telecommunications devices. Its mission is to nurture and help develop a broad market by promoting the VPN Consortium proliferation of Resilient Packet Rlug into the networking market broadly VPNC is the international trade as.socia.tion for manufacturers in the VPN defined including LANs, MANs, and WANs. It is also committed to pro market. moting multi-vendor interoperability. Fow1ded in 1999, the primary purposes of the VPNC are: Wi-Fi Alliance • Promote the products of its members to the press and to potential The Wi-Fi Alliance is a nonprofit international association formed in 1999 customers to certify interoperability of wireless Local Area Network products based • Increase interoperability bctwocn members by showing where the on IEEE 802.11 specification. Currently the Wi-Fi Alliance has over 200 products interopera.Lc member companies from around the world , and over 1500 products have • Serve as the forum for the VPN manufacturers and service received Wi-Fi certification since certification began in March of 2000. The providers tltroughout the world goal of the Wi-Fi Alli · members is to enhance the user experience • Help the press and pot.cntial customers w1derstand VPN technolo through product interope14lJ1lity. gies and standards • Provide publicity and support for interoperability testing events 12.1 Standardization in telecommunications 225 226 Standardization World W ide Web Consor t ium 12.1.5 Centers W3C organizes the work necessary for the development or evolution of a Web technology into Activities. Each Activity has its own structure, but an Activity typically consists of a Working Group, lntcrcst Group, and ~NT£R Coordination Group. Within the framework of an Activity, these groups generally produce Recommendations and other technical reports as well as Figure 12.12: TelocoJWnunication cent.crs sample code. Important to every W3C Activity is Quality Assurance (QA). SIP Center The SIP Center is a portal for the commercial development of the Session Initiation Protocol. Serving both the SIP community and the wider indus try, the SIP Center offers comprehensive technical and ma.rkeL resources as well as an environment for the testing of SIP implementations. To date, the industry's focus has been on the technical development of the protocol, the ironing out of all the little wrinkles that arc bound to affect a new teclmol ogy. However, after thirteen interoperability 'bake-off' tests it has become apparent that a significant nwnber of companies already offer robust SIP products and that mature SIP architectures have emerged. SIP has been torture tested in the labs and in trials is now in commercial deployment. Inevitably, until now, the commercial and marketing issues associated with SIP have been of a lower priority than the technical developments. This web site differs from other SIP sites in that we aim to bring SIP to a wider IP Communications audience and to help bring real-world services to the market. We want to educate and promote SIP as well as accelerate service deployment. The intended audience for this site is service providers, tech nology vendors and the merely curious. Tn addition to educational material and resources, we offer a free User Agent softphone and access to our SIP Network Server for testing purposes. The Network Server is intended to be a highly scalcable, resilient permanent 'bake-off' facility. It is available 24 hours a day, seven days a week. All these facilities are fully documented so that users can carry out meaningful testing (or just play around). 12.1 Standardization in telecommunications 227 228 Standardization 12.1.6 Internet Address Registration JANA preserves the central coordinal.ing functions of the global Internet by providing for instance Domain Name Services, Protocol Number Assign ment Services, and lP Address Services, :@["]~J - APNIC ICANN {Internet Corporation for Assigned Names and Numbers) lCA.NN ICANN is an internationally organized, non-profit corporation that has re • sponsibility for Internet Protocol (IP) address space allocation, protocol IAHA ' -~N1.iltlberAuth0tlty,:.: , •: . identifier assigmncnt, generic (gTLD) and country code {ccTLD) Top-Level ·Dedlceledlo~thec:enlnll~!iii\!~O . ..._ fQr die public good ' . Domain name system management, and root server system management l.oc8tlon: Marina del Rey, CA, USA functions. These services were originally performed under U.S. Govern ICANN lntemet Co ARIN (American R egistry for Internet Numbers) ARIN manages the Internet numbering resources for North America, a por tion of the Caribbean, and sub-equatorial Africa. It is located in Chantilly, VA, USA IANA (Internet Assigned Number Authority) 230 Abbreviations ATMARP ATM Addres.5 Resolution Protocol ATMRARP ATM Reversed Address Resolution Proto<:ol AU Administrative Unit (in SDH) AUC Authentication Center AUG Administrative Unit Group (in SDH} AuC Authentication Center B-ISDN Broadband Integrated Services Digital Network Chapter B-lSDN Broadband ISON 13 BC Binding Cache BC Business Co1uwction BCP Border Gateway Protocol BOOTP BOOTstra.P protocol BPDU Bridge Protocol Data Unit Abbreviations BSC Base Station Controller DSC 13isync BSC Station Controller BSS Base Station Subsystem BSS Basic Service Set BSS Broadcast Satellite 8crvice IOGEA 10 Gigabit Ethernet Alliance BSS Busines.<> Support Sylitcm 2G 2nd Generation BSSID Basic Service Set Identification 3G 3rd Generation 13T Burst Tolerance 3GPP Third Generation Partnership Project BTS Base Station Transceiver 3GPP2 Third Generation Partnership Project 2 BTS Base Transceiver Station 3R Re-amplification, Re-shaping, Re-timing BUS Broadcast and Unknown Server 8-PSK Eight Phase Shift Keying C/D Control/ data AAL ATM Adaptation Layer CA Call Ageot AAL5 ATM Adaptation Layer 5 CA Certification Authority AD Analog-Digital CA certification authority ADM Add/ Drop Multiplexer CA Collision Avoidance ADSL Asymmetric Digital Subscriber Line CAP Common Application Platform AFI Authority and Format Identifier CAP Controlled Access Phase (IEEE 802.lle) All Authentication Header CAP CTM Access Profile AID Association Identifier CATV Cable Television ANSI American National Standards Jn~titute CBR Committed Bu.r::.-t Rate ANST-41 CBR Constant Bit Rate AP Access Point cc Common Control API Application Programming Interface cc confirmation code AP NIC cc Credit Counter APON ATM over Passive Optical Network cc Cross-Connect ARIB Association of Radio Industries and Busine&;c!I CCSA China Communications Standa.rds Association ARJN CDMA Code Division Multiple Acccs.s ARP Adtlrcss Resolution Protoool CERT AS A uthcntication Server CF contention free AS Autonomous System co Call Offer ASP Application Service Provider co Central office ASTN Automatic Switched 1'ransport Network COPS Common Object Policy Services ATIS COPS Common Open Policy Server ATIS A lliancc for Telecommunications Industry Solutions COPS Common Open Policy Service ATM Asynchronous Transfer Mode CPE Cell Phase Error 231 232 Abbreviations CPE Customer Premi5e5 Equipment E-LAN Ethernet LAN Service CPU Central Processing Unit E-Line Ethernet Linc Service CR-LOP Constrained-based Routing using Label Dil.'tribution Protocol EC encryption control CR-LOP Constraint-Based Label Distribution Protocol ECMA European Association for Standardizing and Communication Syi."tems CR-LDP Constraint-based Routing Label Distribution Protocol EDGE Enhanced Data Rates fo r GSM Evolution CRC Cyclic Redundancy Check EF Expedited Forwarding CSMA/CD Carrier Sense Multiple Access with Collision Detection EFC Earth-Fixed Cell CSPF Con&'traint-ba.5Cd Shortest Path First EFM Ethernet in the First Mile CT Cull lrans!er ECP Exterior Gateway Protocol CT Computer Telephony ECPRS Enhanced GPRS CTM Call lraffic Measurement EIR Equipment Identity Register CTM Cordless Terminal Mobility EIR Excess Information Rate CWDM Coarse Wavelength Division Multiplexing ELAN Emulated Local Area Network DA Destination Address ENUM tElcphonc NUmbor Mt1pping DCC Data Communication Channel EPON Ethernet passive optical network DCC Data Country Code ERM DCE Data Circuit-terminating Equipment ES Earth Station DCE Data. Communication Equipmmt ES-ID DCF Dispersion Compensating Fiber ESl End Systelll Ident,ificr DCF Distribution Coordination Function ESP Encapsulated Security Payload DCS Digital Cross-Connect Switch ETSI European Telecommunications Sta.ndards institute DECT Digital Enhanced Cordless Telecommunications FC Fibre Ch111uiel DHCP Dynamic Host Configuration Protocol FC Fragmentation Control DHCPv6 Dynamic Host Configuration Protocol version 6 FC Frame Control DIS Disabled {ONU serial number) FCC Federal Communications Commission OLE DTM LAN emulation FCIP Fibre Channel over IP DLSw Data. Link Switching FCS Frame Check Sequence DMZ FOO Frequency Division Duplex DNlC Data Network Identification Code FDDI Fiber Distributed Data lnte:face DNS Domain Name S)'litcm FDMA Frequency Division Multiple Access DNSSEC FEC Forward Error Correction DOCS IS Data Cable Service Interface FEC Forwarding Equivalence Cla::;s DS Differentiated Services FEC Front-End Clipping OS Digital Signal FP Fixed Part DS Direct Sequence FQDN Fully Qualified Doruaiu Name OS Directory Service FR Frame RPJay DS Distribution System FRAD Frame Relay Access Device DS Domain Specific Part FRF Frame Relay Forum OS Downstream FSN fragment S<.'quonce number DS3 Digital Signal Level 3 FSN Full-Services Network DSL Digital Subscriber Linc FT fixed Termination DSLAM Digital Subscriber Linc Access Multiplexer FTP File Transfer Protocol DSLAM DSL Access Multiplexer FTIB Fiber-to-the Building DSP Digitt1l Signt1l Processing FTIC Fiber-to-th<.'-Curb DSP Digit(I) Signal ProcetJWr FTIH Fibcr-to-the-llomo DSP Domain Specific Part G-PON Gigabit Passive Optical Network on; Data Terminal Equipment GARP General Attribute Registration Protocol DTM Dynamic synchronous transfer mode GEM C-PON Encapsulation Method DWDM Dense Wavelength Division Multiplexing GEO Geostationary Earth Orbit DXC Digital Cross Connect GERAN GSM / EOG£ Radio Accesti Network 233 234 Abbreviations GERAN GSMEDGE Radio Access Network IPv6 Internet Protocol Version 6 GES Gateway Earth Station ISAKMP Internet Security AJ..-.;ociation Key Management Protocol CFP Generic Framing Procedure ISC IMS Service Control GGP Gateway-to-Gateway Protocol ISON Integrated Services Digital Network GGSN Gateway GPRS Support Node ISL Integrated Service Logic Gfu Gigahertz lSL Inter-Satellite Link G.MPLS Generalized Multi-Protocol La.be! Switching ISL Inter-Switch Link GMRP CARP Multicast Registration Protocol ISM Industrial, Scientific, and Medical GMSC Gateway Mobile Switching Center ISO l.nternational Organization for Standardization GMSC Gateway MSC ISO lnt~rnational Standards Organization GPRS General Packet Radio Service ISOC Internet Society GSM Global System for Mobile Communications ISP I ntcmet Service Provider GSM Groupe Spreiale Mobile ISPs lntcmo:.'t Service Provider GSN GPRS Support Node ISUP Integrated Services Digital Network User Part GSS ISUP ISON User Part CbE Cigabit Ethernet ITU International Telocommunication Union HDLC High-Level Data Link Control ITU-T International Telocommunicatio.n Union - Telecollllllunication Standardiiation Sector HDSL High bit rate Digital Subscriber Linc IV initialization vector HEC Header Error Check IWF lnt.crWorking Function HEC I-leader Error Control IWlJ Interworking Unit HEC Header Error Correction IntServ Integrated ServiC<.'f:I HlPPI H igb Performance Parallel Intcrface (ANSI) KOC Key Di:;tribution Center HLR Home Location Register LA Location Area HO-DSP LAC L2TP Access Concentrator HOL Head-of-the-Line LAN Local Arca NetwOl'k HSCSD lligh-Specd Circuit-Switched Data LANE LAN Emulation HSS Home Subscriber Server LAPD l,ink Access Proced ure D-Cbannel (ISON) HTTP Hyper-Text Transfer Protocol LAPF Link Access Procedure Frame Relay I/ G Individual/ Group Address (IEEE) LCS Location Service IANA Internet Assigned Numbers Authority LDAP Lightweight Directory Access Protocol IC LDP Label Distribution Protocol ICANN LE Law Enforcement ICD LEC IC.MP Internet Control Message Protocol LEC LAN Emulation Client ID Identity LEC Local Exchange Carrier IOI LECS LAN Emulation Configuration Server IDP lntcm1ptcd Deterministic Process LEO Low Earth Orbit IEEE Institute of Electrical and Electronics Engineers LEO Low Earth Orbit satellite system IETF Internet Engineering Task Force LES LAN Emulation Server IGMP Iuterne~ Group Management Protocol LES loop emulation service IGP Interior Gateway Protocol LH Long Haul IJ-I L LIF Location Interoperability Forum IMEJ lntcmational Mobile Equipment Idenlit.y LLC Link Layer Control IMS IP (Internet P rotocol} Multimedia Subsystem LLC Logical Link Control JMSI International Mobile Subscriber Identity LMDS Local Multichannel Distribution Services IMT-2000 LMOS local multipoint distribution service IMTC LMP Link Management Protocol IP Internet Protocol LMSJ Local Mobile Station Identity IPX Internet packet C." LSP Label Switched Path MTU Multiple Tenant Unit LSP Local Service Provider NAPT network address port translation LSR Label Switching Router NAPTR Naming authority pointer MA Mobile (Radio Frequency Channel (RFCH)) Allocation NAT Network Address 'ITanslation MA Mobile Allocation NCC Network Control Center MAC Medium Access Control NOC MAC Message Authentication Code NHRP next. bop resolution protocol MAN Metropolitan Arca Network NIST National Institute or Standards and Technologies MAP Markovian Arrival Process NLA MAP Mobile Applical.ion Part NLA Next Level Aggregator MAP Mobility Anchor Point NNI Network-Network Interface MAP Mobility Application Part (SS7) NNI Network-Node Interface MOC NNTP Network News Transfer Protocol MD mediation device NPF MD5 MCSMge Digest 5 NSAP Network Service Access Point MEF Metro Ethernet Forum NT Network Termination MEO Medium Earth Orbit NTP Network Time Prot-0col MFC Multi Frequency Code NTP Network Time Protocol (RFC 1305) MFR Multilink Frame Relay NctDIOS Network Dasie Input/ Output System MGCF OADM Optical Add/ Drop Multiplexer MGCF Media Gateway Control Function OAM Operations, Admllilstration ,and Ma.inte.nance MGW Media Gateway OAM P Operatioru;, Administration and Maintenance, and Provisioning MIB Management Information Base OAMP or OAM P Operatioru;, Administration, Maintenance, Provisioning MLP Mobile Location Protocol OBP On-Board Processing MLPPP Multi-Layer Point-to-Point Protocol OBS On-Board Switching l\<11\IDS Multichannel Multipoint Oistnbution System OBS Optical Burst Switching MMS-IOP OCh Optical Chrurnel MNC OCh Optical Channel Layer Network MP Multilink Protocol ODTM MPLS Multi-Protocol Label Switching ODU Optical Channel Data Unit lvlPLS Multi-Protocol Lambda Switching OGC OpenGIS Consortium MPOA Multi-Protocol Over ATM OH Overhead MS Media Server OIF Optical Internet Forum MS Minimum Sum OIF Optical lntcrnetworking Forum MS Mobile Station OIN MS Multiplexer Section OLT Optical Lino Termination MSC Mobile Services Switching Center OMA MSC Mobile Switching Center OMAP Operation, Maintenance and Administration Part MSC Multiscrvice Concentrator ONT Optical Network Termination MSCs ONU Optical Network Unit MSF Multiservicc Switching Forum OPS Optical Packet Switching MSISDN Mobile Subscriber ISDN Num~..r OSI Open Systems Interconnection MSPP Multi-Service Provisioning Platfonn OSPF Open Shorte!it Path F'i11>t MSRN Mobile Station Roaming Number oss Operation Subsystem MSTP Multiple Spanning Tree oss Operations Support System MSU MAC Service Data Unit OTDM MT Mobile Tenninal OTN Optical Transport. Network MTP Message TrruL>fer Part OUJ Organizationally Unique Identifier MTS oxc Optical Cr()ijS Connect MTU Maximum '.l'ra.nsmis.sion Uuit oxes - 237 238 Abbreviations OpenGlS RA Routeing Area PAD Pudding RA Router Advertiserucuts PAN Personal Area Network RAC PAR Parity RARP Reverse Address Resolution Protoe0l PAR Previous Access Router RF Radio Fn.-quency PBX PriVt.lte Branch Exchange RFC Request for Comments PC Personal Computer RIP Routing Information Protocol PC point coordinator RIPE PC Power Control RNC Radio Network Controller PCF Point Coordination Function ROI Rctum on i nvcstment PCM Pulse Code Modulation RPF RevcISe Path Forwarding PCS personal communications services RPR Resilient Packet Ring PCS Physical Coding Sublayer RR Receive Ready PCU Packet Control Unit RR Reset Rt'Quest PDH Plcsiochronous Digital Hierarchy RR Resource fu!servation PDP Packet Data Protocol RSA Rivest, Shamir, Adleman public-key encryption PDP Policy Decision Point RSTP Rapid Spooning 'f'rec Protocol (IEEE 8021w) POU Protocol Data Unit RSVP Resource Reservation Protocol PEP RSVP-TE RSVP with Traffic Engineering extensions PEP Policy Enforcement Point RTCP Real-Time Transport Control Protocol P H RTP Rapid Transport P rotocol PHY Pbysical Layer RTP Real-Time Transport Protocol PID Protocol Identifier RTP Resilient tclccom platform PLMN P ublic Land Mobile Network SA Sc.'Curity Association PLOAM Physical Layer OAM SA source address PLP Packet Level Procedures SAAL Signaling A AL PMA Physical Medium Attachment SAN Server Area Network P MD Physical Media Dependent SAN Storage Area Network PNNI Private Network-Network Interface SAP Service Access Point PNNI Private Network-Node Interface SAP $c8sion Announcement Protocol PON Passive Optical Network SAR Segmentation and Reassembly POP Point-of-Presence sec Satellite Control Center POP Post Office Protocol SCCP Signaling Conrwction Coutrol Part POTS Plain Old Tclepbonc Service SCP Service Control Point (IN} PPP Point-to-Point Protocol SCP Switch-Module Configuration Protocol PPV SCSI Small Computer System Interface PS Physical Slot SCTP Stream Control 'l'raru;mission Protocol PS Power Save (mode) SDH Synchronous Digital llierarc:1y PS Processor Sharing SDSl. symmetric DSL PSN Packet Switched Network SEL PSTN Public Switched Telephone Network SES PT Payload Type SF service Bow PT Portable Termination SF Signal Fail PVC Permanent Virtual Cbannel Connoction SFC Satellite-Fixed CeU PVC Permanent Virtual Circujt SG Signaling Gateway PVC Permanent Virtual Connection SG Study Group PVC P rivate Virtual Circuit SGSN Serving GPRS Support Node QoS Quality-of-Service SGSN Serving CPRS Supporting Node RA Receiver Address sew Signaling Gateway RA Resource Allocation SHDSL Symmetric lligh-Data Rate DSL 239 240 Abbreviations SIF Synchronous Optical Network (SONET) lnterop-crability Forum TE Terminal 8quipmcnt SIG Special Interest Group TE Traffic Engineering SIM Subscriber Identification Module TETRA TErrcstrial Trunked RAdio SIP Session initiation Protocol TLA Top Level Aggrcgator SLA Service Level Agrooment TLD Top Level Domain SLS Service Level Specification TLS 1ra.nsparcnt LAN Service SMDS Software Management and Delivery Systems TLS TrallllpOrt Layer Security (RFC 2246) SMG Survivable media gateway TLV Type-Length-Value SMiv2 Structure of Management Information Version 2 TM Tennina.l Multiplexer SMS Short Message Service TM Traffic Manager SMTP Simple Mail Transfer Protocol TMN Tclocommunications Management Network SN Serial Number TMSI Temporary Mobile Station Identity SN Serving Network TSIG SNAP Sub-Network Access Protocol TTA Telecommunications Techno'.ogy Association SONET Synchronous Opticu.l Netv.-ork TTC Tclccornmunications Technology Committee SP Segment Priority TTC Telemetry, Tra.cking and Command SP Service Provider TTL Time to Live SP Short.est Pa.th TU Time Unit SP Signaling Point TU Transaction User SPAN Service and Protocol for Advar.ce Networks TU Tributary Unit SPAN Switched Port Artllly-.wr TUG Tributary Unit Group SRV U/L Universally/ Locally Administered Address (IEEE) SS7 Signaling System 7 UDP User Datagram Protocol SSCF Service Specific Coordination Function UDP Uuser Datagram P rotocol SSP Service Switching Point UE User Entity SSP Storage Service Providers UE User Environment STA Station UE User Equipment STM Synchronous Transfer Mode ULH Ultra-Long Haul STM Synchronous Transport Module ULP Upper Layer Prot-0e0l STM-n Synchronous Transport Module level n (SDH) UMTS Universal Mobile Telecommunications System STP Shielded Twisted Pair UNI User-to-Network lnterfocc STP Signaling Transfer Point URI Uniform Resource Identifier STP Spamiing Tree Protocol (IEEE 802ld) URL Uniform Resource Locator STQ UTRAN UJvITS Terre:.'trial Radio Aa:ess Network SVC Switched Virtual Channel Connection VA Verbind ungliUil.forderung SVC Switched Virtual Circuit VBR Variable Bit Rate TlAl vc Validity Coru.'traint TA Terminal Adapter vc Virtual Channel TA Threshold Accepting vc Virtual Circuit TA Time Advance vc Virtual Clock (Sd1cduling) TA Trll.JlSmitter Address vc Virtual Connection TB Tail Bits vc Virtual Container TB Token Bucket vcc Virtual Channel Connection TB Transparent Bridge VCI Virtual Channel Identifier T CAP Transaction Capabilities Application Part (SS7) VDSL very high-speed digit.al subl:.criber line T CP Transmission Control Protocol VLAN Virtual LAN T CP/IP Transmission Control Protocol/ Internet Protocol VLAN Vi.rtual Local Area Network TDD Time Division 011plex VLR Visitor Location Regist.cr TOM Time Divisio11 ~ lultiplex VPC Virtual Path ConnL'l.'tion TOMA Time Division Multiple Access VPI Virtual Path Identifier 241 242 Abb reviations VPN Victual Private NcLwork VPNC VRRP Virtual Router Redundancy Protocol VSAT Very Small Aperture Terminal VoIP Voice-over-IP (Internet Protocol) Voi .--....-