RS-2012-2013-v0.4 - 21 May - 2013-Marcaj - Patial II

RS-Sem II RST
Retele si Servicii
Sem II licenta spec. RST
(English version) Network and Services
E. Borcoci, UPB 2012-2013
Prof. E.Borcoci- UPB -2012-2013
RS-Sem II RST
CONTENTS
1 INTRODUCTION-ARCHITECTURE REVISION 1.1 NETWORKS LAYERED ARCHITECTURES 1.1.1 General Principles and Functional Layers 1.1.2 OSI Reference Model 1.1.3 Real Stack Examples. Incomplete stacks 6 6 6 7 10
1.1.3.1 TCP/IP Stack 1.1.3.2 IEEE 802.x standards for LAN, MAN 1.1.3.3 Signalling System No.7 1.1.3.4 MPLS architecture 1.1.3.4.1 MPLS IP stack
1.2 MULTIPLE PLANES ARCHITECTURES 1.2.1 Principles 1.2.2 Signalling Issues 1.2.3 Next Generation Networks Architecture- high level view 1.3 BUSINESS MODELS FOR (MULTIMEDIA) COMMUNICATION ARCHITECTURES 1.3.1 Customers and Users 1.3.2 Providers (PR) 1.3.3 Multiple Plane Architecture and Business Actors 1.3.4 Service Level Agreements/Specifications (SLA/SLS) 1.4 EXAMPLES OF MULTIPLE PLANE ARCHITECTURES 1.4.1 IEEE 802.16 multi-plane stack 1.4.2 Generic Example of a multi-plane architecture
10 14 14 15 15
16 16 17 18 21 21 21 23 23 25 25 27
1.4.2.1
1.4.3 1.4.4 2
An Architecture oriented to multimedia distribution over multiple domains networks 27

29 31 34 34 34 35 36 36 37 39
Example: Architectural stack for wireless heterogeneous mesh network Control Plane in GSM (2G)
INTERCONNECTION- REVISION 2.1 MODURI DE LUCRU CU I FR CONEXIUNE CO/CL 2.2 CERINELE UNUI SERVICIU DE INTERCONECTARE (LA NIVEL TREI) 2.3 MODUL DE LUCRU CO ( CONEXIUNE LA NIVEL REEA) 2.4 MODUL DE LUCRU CL (FARA CONEXIUNE LA NIVEL REEA) 2.5 INTERCONECTAREA DE TIP PUNTE (BRIDGE APPROACH) 2.6 EXEMPLE DE INTERCONECTRI 2.6.1 Interconectarea de reele LAN prin puni (B)
2.6.1.1 2.6.1.2
3
Puni transparente (Transparent Bridges- TB) Punti cu rutare de tip sursa
41 41
42 42 46 47 50 54 54 56 57
ROUTING PROTOCOLS 3.1 ALGORITMI DE RUTARE -SUMAR 3.2 ALGORITMI DE CAUTARE A CELUI MAI SCURT DRUM 3.2.1 Algoritmul Dijkstra (centralizat) 3.2.2 Algoritmul Ford (Fulkerson) 3.3 IP ROUTING PROTOCOLS 3.3.1 Internet Protocol reminder 3.3.2 Principles of IP routing 3.3.3 Network hierarchies
3.3.3.1 3.3.3.2 3.3.3.3

3.3.4 3.3.5 3.3.6
Multi-Tier hierarchy Autonomous System Definition ASes and Tiers
58 59 60
61 63 64
General definitions Address Resolution Protocol (ARP), Reverse ARP RARP Interior Gateway Protocols
3.3.6.1 3.3.6.2 3.3.6.3 3.3.6.4
Routing Internet Protocol (RIP) RIP Extensions Ad hoc On-Demand Distance Vector (AODV) Open Shortest Path First (OSPF)
65 67 68 74
79 81 84 3
3.3.7 Border Gateway Protocol (BGP) 3.4 IPV6 3.5 ICMPV6

RS-Sem II RST
4 IPQOS TECHNOLOGIES 4.1 INTRODUCTION 4.2 APPLICATIONS 4.2.1 Application classes 86 86 86 87
4.2.1.1 4.2.1.2
4.2.2
Elastic applications Streaming applications Traffic descriptors
87 87
87
Traffic Description
4.2.2.1
88
88 90 92
4.3 ARCHITECTURAL FRAMEWORK FOR QOS IN IP NETWORKS 4.3.1 IP Services 4.3.2 Data Plane Mechanisms
4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.3.2.6 4.3.2.7

4.3.3
Traffic Classification (TCl) Packet Marking Traffic policing (TP) Traffic Shaping (TS) Buffer (Queue) Management (QM) Queuing and Scheduling Q&S Congestion Avoidance (CA) Admission Control (AC) QoS Signalling QoS Routing Resource Reservation (RR)
93 93 93 94 94 94 95
95
Control Plane
4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4
95 96 96 96
97 97
4.4 BASIC IP QOS AND TRAFFIC CONTROL MECHANISMS- DATA PLANE 4.4.1 QoS Guarantees (I)
4.4.1.1 Types of guarantees 4.4.1.1.1 Bandwidth Guarantees 4.4.1.1.2 Other guarantees 4.4.1.2 Level of guarantees
4.4.2 4.4.3 Classical Routers, Qos Capable Routers IP Level services
97 97 97 98
98 99
4.4.3.1 Besteffort (BE) service 4.4.3.1.1 Fairness problem 4.4.3.2 Buffer (queue) management 4.4.3.2.1 Tail drop 4.4.3.2.2 Random Early Detection 4.4.3.2.3 Weighted RED 4.4.3.3 Maximum bandwidth service 4.4.3.4 Minimum bandwidth service
4.4.4 Packet Classification and Marking
99 99 100 100 100 102 102 103

104
4.4.4.1 Packet Flows defined at different layers 4.4.4.1.1 Layer 3 Flows 4.4.4.1.2 Layer 4 Flows 4.4.4.1.3 Upper layer Flows 4.4.4.2 IP Packet Marking
4.4.5 Policing and Shaping
105 105 105 105 107

108
4.4.5.1 Measuring the Rate of Incoming Flows 4.4.5.1.1 General Measuring Algorithms of Flow Rate 4.4.5.1.2 Basic Token Bucket Algorithm (TB) 4.4.5.1.3 Extensions of Token bucket 4.4.5.1.4 Leaky Bucket 4.4.5.1.5 Dual Token Bucket 4.4.5.2 Shaping Based on Token Bucket
4.4.6 4.4.7 QoS Guarantees (II) Scheduling algorithms
108 109 110 111 113 114 114

115 116
4.4.7.1 Basic Functions of a Scheduler 4.4.7.2 Scheduling Best Effort Flows 4.4.7.2.1 Round Robin (RR) 4.4.7.2.2 Deficit Round Robin (DRR) 4.4.7.3 Schedulers for Guaranteed Flow
Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined.
4
RS-Sem II RST
4.4.7.3.1 4.4.7.3.2 4.4.7.3.3
5 REFERENCES 5.1 6 GENERAL LIST OF ACRONYMS
Priority-based scheduler Weighted Round Robin (WRR) Weighted Fair Queuing
Error! Bookmark not defined. Error! Bookmark not defined. Error! Bookmark not defined.
117 127 134 134 136
ANNEX 1 6.1 6.2 ETHERNET FRAME FORMATS: AODV DETAILS
RS-Sem II RST 1 INTRODUCTION-ARCHITECTURE REVISION
1.1 Networks Layered Architectures

1.1.1 General Principles and Functional Layers
Architectural Model : set of functions and relations between them, independent of implementation Objective: management of high complexity: (divide et impera) - principle interoperability among different products Tools: definition of functional layers + interfaces Network element: terminal, switching node, multiplexer, router, etc. = hierarchical set of levels -tasks: - information transport (lower layers) - high level processing of information (upper layers)
Ta Ta Tb Appl. processes
User Protocols
Tb Appl. processes
Processing functions C1 1 C2 1 Network functions
Upper layers protocols
Processing functions Network functions
N1 1
N2 1
Physical medium
Complexity/ Intelligence
Network(s)
Future Internet? (more intelligent networks) E.g. Content aware networks
a
Figure 1 Simplified architectural model for communication
RS-Sem II RST
a. Network and terminals b.Two level model : Ta, Tb = terminals
- application processes ( usually resident in Ta, Tb - they communicate through a set of rules (protocol) at user level: Protocols at different levels between: - application processes - higher layers processing functions (higher layers) - network transport functions (lower layers) - set of layers = protocol stack Layering principle is extended inside each of the two layer 1.1.2 OSI Reference Model Classical architectural mode (1970-80) ISO (International Standardization Organization): OSI - RM ("Open System Interconnection Reference Model") for layered architecture networks OSI RM defines: architectural and functional principles for open systems able to be interconnected no matter the equipment manufacturer - real world stack can be different of OSI-RM, but the same principles are applied OSI, TCP/IP model one plane architectural model
Usage examples of layered architecture networks use: - industry, administration, business, health, military, education, research, etc.
- data and multimedia networks: local (LAN), metropolitan (MAN) wide area WAN (typical example: INTERNET, Intranets, Extranets) -digital telecommunication wide area networks: - fixed communications: ISDN, BISDN, GSM ( e.g. Signalling System No.7 SS7 used to control the digital telecom networks) - networks for mobile communications 2G, 3G, - Integrated (convergent) networks - TCP/IP based, 3G, 4G- for fixed or mobile communications - Next Generation Networks ( ITU-T) ~ 1995-2000 - Future Internet: evolution/revolution for current Internet ( > 2005) Fundamental Architectural Principles: - layer N offers to N+1 a service set - that can be accessed through interfaces (SAP = Service Access Point) - service implementation is achieved by the protocol of the lower layer - service primitives - information transport between adjacent layers - protocols- specify the rules of comm between two peer entities Criteria for function distribution on layers : - homogeneity inside a layer minimal interactions between layers small number of layers
Note about word service usage

RS-Sem II RST
very general term used in a lot of contexts much confusion out of this OSI model defines very precise semantic for service Adopting such semantic we distinguish among: o Low level services , e.g: L2 service = connectivity service between two nodes L3 service = connectivity service over a network domain L4 service = E2E connectivity service o High level services , e.g: data oriented services: FTP, e-mail, web access to info, transactional services multimedia-oriented services: VoIP, video conf, A/V streaming, DVB, IPTV, etc.
Curent trends: -traditionally we want/have low coupling between layers - today this principle is no longer considered good by all professional communities - Cross-layer optimisation especially in wireless on L1-L3 - Content aware networks and Network Aware Applications - pros and cons this approach still open issue Base layers (1-3) ( network access and information transfer through network(s) Upper layers (4-7)
- higher layer processing functions (closer to user application processes) - usually layers 4-7 belong to terminals (endto-end ( E2E) protocols - Network technology, Number of networks, Fixed or mobile mode independent of:
Important Notes: o the same function name can be encountered on different layers but with different semantics o Not all functions listed must be present in a layer (large variety in practical stacks)
Layer 1 (Physical- PHY) ; Layer 2 (Data Link Layer - DL ); Layer 3 (Network) : Layer 4 (Transport T); Layer 5 (Terminal Session S); Layer 6 (Presentation); Layer 7 (Applicaion) :
RS-Sem II RST
Local Processes
User Entities
Local Processes
Communication Processes Service Primitives
Communication Processes
Ta
7 Application
Service Access Point
Different level Protocols 7 Application
Tb
E2E Protocols
6 Presentation Protocol Data Units (PDU) Transport Protocol Network node 3 Network 3 Network
6 Presentation Higher Layer Protocols
5 Session
5 Session
4 Transport
4 Transport Network Transport Protocols transport
3 Retea
2 Data Link
2 Data Link
2 Data Link Network Acces Protocols
1 Physical
1 Physical
1 Physical
Network environment OSI Environment Real systems environment
Physical transmission medium
Information flow circulation through layers
Figure 2 OSI Reference Model
RS-Sem II RST
Figure 3 Internetworking example in OSI Model Note : Service Provider = Transport Service Provider
1.1.3 1.1.3.1
Real Stack Examples. Incomplete stacks TCP/IP Stack
- TCP/IP stack different from OSI - much greater success (history, simpler stack, market driven) - WWW/Internet strengthened the usage of TCP/IP stack Important note: o o o Advances in microelectronics and huge increase of perf/cost allowed to include the full TCP/IP stack in all terminals (including small mobile devices) This naturally creates the posibility to integrate all kind of high level services based on TCP/IP stack That is why TCP/IP ( called Internet is accepted today as a basis for full network and services integration
Communication models:
Hierachy criterion Classic model: Client/server ( asymmetric one) After 2000 Peer to peer (P2P) model Symmetric model huge expansion in last years ( ~70% of the total Internet traffic)
Time criterion Synchronous communication (usually r.t: VoIP, AVC, VoD, but also FTP, etc.) Asynchronous communication : e-mail, publish/subscribe Mode to get information: push/pull
10
RS-Sem II RST
Original TCP/IP stack single architectural plain containing several protocols for data transfer and control
Application services Transport (TCP) Internetworking (IP) Subnetworks
Figure 4 Simplified view of TCP/IP stack
Application (communication between processes or applications on separate hosts) Transport (end-to-end data transfer service reliable or unreliable) Network layer ( network resources mng., routing the data to destination) Data link (acces CO or CL to network layer) Physical layer
Telnet, FTP, E-mail, SNMP, etc TCP, UDP IP, ICMP, IGMP, OSPF, etc. (LLC) + MAC
Figure 5 Simplified view of the TCP/IP protocol stack
MIME BGP (*1) FTP Telnet HTTP SMTP RTCP
TCP (Connection oriented) IP (Connectionless) RARP ARP
(LLC)+MAC (e.g.IEEE 802.x), AAL+ATM, Physical Layer
11
RS-Sem II RST
Video Voice RTP SNMP
Multicast protocols
RIP (*)
BOOTP
RSVP OSPF (*1) ICMP, IGMP (*2)
UDP (Connectionless)
IP (Connectionless)
ARP
RARP
(LLC)+MAC (e.g IEEE 802.x) , AAL+ATM, etc Physical Layer
Figure 6 Example of TCP/IP stack protocols
(*1) they are not transport protocols but cooperate with IP MIME Multipurpose Internet Mail Extensions BGP Border Gateway Protocol HTTP Hypertext Transfer Protocol SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol FTP File Transfer protocol RTP Real Time Protocol ICMP Internet Control Messages Protocol IGMP Internet Group Management Protocol OSPF Open Shortest Path First Protocol
Transport: TCP Transmission Control Protocol (connection oriented -CO)
UDP User Datagram Protocol ( connectionless CL)
Network: IP Internet Protocol + ICMP, IGMP, BGP, OSPF Data link Layer:
LLC Logical Link Control + MAC- Medium acces Control Example: AAL ATM Adaptation Layer + ATM Asynchronous Transfer Mode
Example: FTP, TCP, IP, (LLC) + MAC ( driver Ethernet)
12
RS-Sem II RST
Multicasting: IGMP Internet Group Management Protocol ( v.1, v.2, v.3) Multicast routing protocols: DVMRP Distance Vector Multicast Routing Protocol PIM-DM Protocol Independent Multicast Dense Mode PIM-SM Protocol Independent Multicast Sparse Mode CBT Core based Tree MOSPF Multicast OSPF multicast extension of OSPF MBGP Multicast BGP extension of BGP to multicast Multicast transport protocols: RMTP Reliable Multicast Transport Protocol SRM Scalable Reliable Multicast Protocol MFTP Multicast File Transfer Protocol PGM Pretty Good Multicast
Ping
FTP Telnet Rlogin SMTP X
Traceroute
DNS TFTP BOOTP SNMP NFS+RPC
User processes User process Appl
TCP ICMP ARP IP
UDP IGMP
Transport
Network RARP Data link
(LLC) MAC
Figure 7 Example of logical links between layers ARP Address Resolution Protocol RARP Reverse Address Resolution Protocol TFTP Trivial FTP, BOOTP Bootstrap Protocol NFS Network File Server
13
RS-Sem II RST
1.1.3.2 IEEE 802.x standards for LAN, MAN
Figure 8 IEEE 802 LAN/MAN Standards- examples
1.1.3.3
Signalling System No.7
SS7: - datagram virtual network for digital circuit switching network ( ex. ISDN, GSM) control Control plane for Telecom Digital Network containing the signaling protocols
Example for GSM - MSC: (MSC- Message Switching Centre main switch in GSM) - MTP 1-2-3 subsystem for message transport (layers 1-3) - Layers 4-5-6 : void - signaling applications : TUP, ISUP, MAP, etc
7 4-6 SCCP 3 MTP-3 2 1 MTP-2 MTP-1 Control Plane of Telecom Network ISUP, TUP, MAP, TCAP
Figure 9 Example of incomplete stack: SS7 signalling stack
Signalling Connections Control Part (SCCP) optionally completes the L3 (CO mode for L3)
- applications :
TCAP -"Transaction Capabilities Application Part" - realizes a common general transaction service offered to other applications
14
RS-Sem II RST
Transaction : communication of type query/response (suitable for low volume of information transfer)
Examples of signalling applications :
TUP - "Telephonic User Part"- telephonic call control ISUP - "ISDN User Part" - ISDN call control MAP - "Mobile Application Part" mobility control in GSM All these applications use the message transport part MTP1-3 in CL mode ( if they work directly over MTP 3) in CO mode ( if they work directly over SCCP)
1.1.3.4 MPLS architecture Packet Forwarding in IP Networks
IP forwarding is done independently at every hop IP forwarding decision is made on: o o Packet header, Routing algorithm output (routing table) Note: Searching in routing table- time consuming operation done for every packet
Each IP hop runs its own instance of the routing algorithm Each IP hop makes its own forwarding decisions
Figure 10 IP routing example (Cisco Systems)
MPLS ideas

1.1.3.4.1
Packet forwarding is done based on label switching (not IP addresses, no search in the forwarding table of routers) Labels are short allow indexed addressing- fast switching Labels are assigned when the packets enter into the network (edge) Assignment is result of classification at the ingress node in a MPLS domain (criteria: destination, VPN, QoS, TE, Multicast ) Labels are added in front of the IP packets
MPLS IP stack
15
RS-Sem II RST
Application Transport Internet layer MPLS sublayer Data link layer Physical layer
Figure 11 MPLS oriented IP stack
TCP, UDP IP, ICMP, IGMP, OSPF, etc. (LLC) + MAC
IP-H MPLS-H IP-H
TCP-H TCP-H
Application Data Application Data
IP Datgram Labelled IP Datagram
LABEL 20 Bit
EXP 3 32 bit
S 1
TTL 8
Header MPLS
Figure 12 MPLS label adding
1.2 Multiple Planes Architectures

1.2.1 Principles
Ongoing standardization : IETF, ITU-T ETSI, IEEE, 3GPP Telecom originated layered architectures: more than one architectural plane IETF (TCP/IP- Internet) stack originally only one plane
Nowadays- recognized the need of defining several cooperating architectural planes
Reasons: Real systems/networks deals with: - user data flow transfer network resources ( paths, links, buffers, etc. ) should be controlled short time scale, long time scale
- high level services should be controlled (short and long time scale)
Architectural Planes Data plane ( DPl)- transport of user data traffic directly:
o o
Examples of functions: traffic classification, packet marking traffic policing, traffic shaping, buffer management, congestion avoidance, queuing and scheduling transfer the user data flows and accomplish the traffic control mechanisms to assure the desired level of QoS
Control plane (CPl)
controls the pathways for user data traffic: e.g. Admission control, Routing, Resource reservation.
16
RS-Sem II RST
o short term actions for resource and traffic engineering and control, including routing. In multi-domain environment the MPl and also CPl are logically divided in two subplanes: inter-domain and intra-domain. This approach allows each domain to have its own management and control policies and mechanisms.
Management plane (MPl)
the operation, administration, and management aspects of the resources and services to serve user data traffic: Monitoring, Management Policies (management based not on fixed configuration of network elements but on set of rules), Service Management, Service and network restoration. long term actions related to resource and traffic management in order to assure the desired QoS levels for the users and also efficient utilization of the network resources
Examples of early multiple plane architectures (DPl + CPl + MPl): ISDN , GSM, BISDN
- reason: telecom design philosophy (user data have been seen long time ago - from the beginning of telecom systems as separate entities from signalling and management) data s TCP/IP : - Initially: mono-plane (data + control + management) - Currently it becomes multi-plane (DPl + CPl + MPl) New stacks- multiple plane: IEEE802.16, 3G, 4G
1.2.2
Signalling Issues
Signaling = actions performed in the control plane : - convey application (or network) performance requirements
reserve network resources across the network discover routes general control messages QoS related signalling
QoS signaling : in band or out of band.

In band - signalling info is part of the associated data traffic( typically presented in a particular header field of the data packets. (e.g., the TOS field in IPv4 as in DiffServ and 802.1p)
- Performed in the data plane neither introduces additional traffic into the network nor incurs setup delay for the data traffic. - not suitable for resource reservation or QoS routing, which needs to be done a priori before data transmission - in-band signaling by definition is path-coupled (signaling nodes must be collocated with routers)
Out of band
- signalling info - carried by dedicated packets, separate from the associated data traffic. - introduces extra traffic into the network and incurs an overhead for delivering desired network performance it entails the use of a signaling protocol and further processing above the network layer, which tends to render slower responses than in-band signaling.
17
RS-Sem II RST
- lends itself naturally to resource reservation or QoS routing. - depending on whether the signaling path is closely tied to the associated data path, signaling is pathcoupled or decoupled
Path-coupled
- signaling nodes must be collocated with routers signaling messages - routed only through the nodes that are potentially on the data path. - advantage of reduced overall signaling processing cost (since it leverages network- layer routing tasks) - disadvantage of inflexibility in upgrading routers or in integrating control entities (e.g., policy servers) not on the data path (or nontraditional routing methods) If a path-coupled mechanism involves a signaling protocol, routers need to support the protocol and be able to process related signaling messages - Example of a path-coupled signaling protocol : RSVP
Path-decoupled - signaling messages are routed through nodes that are not assumed to be on the data path
only out-of-band signaling may be path-decoupled. (to date, most out-of-band QoS signaling schemes are path coupled.) - signaling nodes should be dedicated and separate from routers - advantage of flexibility in deploying and upgrading signaling nodes independent of routers or in integrating control entities not on the data path - disadvantage of added complexity and cost in overall processing and operational tasks. Example: Session Initiation Protocol for VoIP, videoconference, etc.
Standardization Effort NSIS ( Next Step in Signalling)
- Standards efforts underway specifically dealing with QoS signaling- e.g. IETF nsis working group - developing a flexible signaling framework with path-coupled QoS signaling as its initial major application - a QoS signaling protocol defined under the framework - expected to address the limitations of RSVP On path-decoupled signaling there seems not enough support in the IETF for a new project after some explorative discussion
1.2.3
Next Generation Networks Architecture- high level view
Standardization Players ATIS NGN FG: Alliance for Telecommunication Industry Solutions, Next Generation Networks Focus Group - USA ITU-T NGN FG: International Telecommunication Union (Telecom), Next Generation Networks Focus Group ETSI TISPAN: European Telecommunications Standards Institute, Telecoms & Internet converged Services & Protocols for Advanced Networks 3GPP: Third Generation Partnership standardization in Mobile 3G networks
18
RS-Sem II RST
NGN packet-based network able to provide Telecommunication multiple services able to make use of multiple broadband, QoS-enabled transport technologies service-related functions are independent from underlying transport-related technologies. enables unfettered access for users to networks and to competing service providers and/or services of their choice. supports generalized mobility which will allow consistent and ubiquitous provision of services to users. Key requirements of an NGN Architecture Trust: Operator should be able to trust the network. User should be able to trust the operator
Reliability: Users should find it reliable Availability: Network should always be available Quality: Able to control Quality of the Service Accountability: Determine usage of the Service Legal: Comply with laws in the local jurisdictions Generalized Mobility support
Note: Classical Internet cannot respond in very controllable manner to the above requirements
NGN characteristics
NGN: new telecommunications network for broadband fixed access facilitates convergence of networks and services enables different business models across access, core network and service domains it is an IP based network IETF Session Initiation Protocol (SIP) will be used for call & session control 3GPP release 6 (2004) IMS will be the base for NGN IP Multimedia Subsystem enables any IP access to Operator IMS; from Mobile domain Home domain Enterprise domain enables service mobility enables interworking towards circuit switched networks maintains Service Operator control for IMS signaling & media traffic
19
RS-Sem II RST
SCN
Applications and Service Level
Management Plane Control Plane User (Data) Plane
Transport Level INTERNET
Figure 13 NGN Architecture
Design Principles Service is rendered in exchange for value o explicitly requested and explicitly stopped, providing a basis for charging o only delivered to authorized users o only saleable if QoS and security can be guaranteed Note : Traditional Internet does not offer this!
Dedicated VoIP infrastructure is expensive o Only a converged (packet) network that supports multiple services over one infrastructure can be commercially viable NGN will be deployed in an unbundled environment o Competition on service values other than price o Support for value-added applications Affordable multi-service architecture o Do not mix application and transport! Support service for roaming users o o Service provided from HOME service provider New Home Box concept End user as content consumer and/or content provider
Service provider determines media route o o o o Service may include in-band media events Support for Lawful Intercept Call Routing follows the money QoS flows cost money so service providers will do least cost routing on it (providing QoS can be met)
Technologies are transient: NGN is technology independent !
Clear separation of Application/Services from Transport Services o Note that this concept is in discussion today!! Provide a modular architectural framework which is easy to introduce and extend. Use a meta-protocol to specify the technology and inter-working to all applicable protocols
20
RS-Sem II RST 1.3 Business Models for (Multimedia) Communication Architectures

1.3.1 Customers and Users Customer (CST) (may be a subscriber) : entity, having legal ability to subscribe to QoS-based services offered by Providers (PR) or Resellers (RS) target recipients of QoS-based services: CST/PR or CST/RS interaction Examples of CS: Householders, SMEs, large corporations, universities or public organisations Service Level Agreements (SLA)- concluded between CS and providers CST differentiation by : size , type of business, type of services required
User (US) -
entity (human or process) - named by a CST and appropriately identified by PR for actually requesting/accessing and using the QoS-based services cf. SLAs USs are end-users of the services, they can only exist in association with a CST may be associated with one or several CST using services according to the agreed SLAs of the respective CST. (e.g. Company = Customer, End User = employee)
Note: In the current public internet, the majority of users are subscribers for Connectivity services only and maybe for a small subset of high level services (e.g e-mail) there is no SLA concluded for high level services quality; e.g for media A/V streaming, IPTV, etc. best effort access to high level services is practised but with no guarantees
1.3.2 Providers (PR)
PR types : (High Level) Service Providers (SP) IP Network Providers (NP) Physical Connectivity Providers (PHYP) (or PHY infrastructure Providers) Resellers (RS) Content Providers (CP) Network Providers (NPs) offer QoS-based plain IP connectivity services own and administer an IP network infrastructure may interact with Access Network Providers' (ANP) or CS can be connected directly to NPs Expanding the geographical span of NPs Interconnected NPs - corresponding peering agreements IP NPs differentiation: small ( e.g. for a city) , medium (region) and large ( e.g. continental) (High Level) Service Providers (HLSP or SPs) offer higher-level (possible QoS-based) services e.g. : e-mail, VoIP, VoD, IPTV, A/VC, etc. owns or not an IP network infrastructure administer a logical infrastructure to provision services (e.g. VoIP gateways, IP videoservers, content distribution servers) may rely on the connectivity services offered by NPs (SPs Providers' interact with NPs following a customer-provider paradigm based on SLAs expanding the geographical scope and augmenting the portfolio of the services offered SP may interact with each other
21
RS-Sem II RST
size : small, medium and large
Physical Connectivity Providers (PHYP) offer physical connectivity services between determined locations services may also be offered in higher layers (layer-3 e.g. IP), ( but only between specific points) distinguished by their target market: Facilities (Infrastructure) Providers (FP) Access Network Providers (ANP) (could be seen as distinct stakeholders) FPs services - are mainly offered to IP NPs (link-layer connectivity , interconnect with their peers
FPs differentiation : size of technology deployment means

ANPs - connect CST premises equipment to the SPs or NPs equipment
- own and administer appropriate infrastructure - may be differentiated by - technology (e.g. POTS, FR, ISDN, xDSL, WLAN, Ethernet, WiMAX, hybrid) - their deployment means and their size - may not be present as a distinct stakeholder in the chain of QoS-service delivery - may be distinct administrative domains, interacting at a business level with SPs /NPs and/or CSTs Interactions between Providers mainly governed by the legislations of the established legal telecom regulation framework may follow a customer-provider and/or a consumer-producer paradigm on the basis of SLAs
Reseller (RS) intermediaries in offering the QoS-based services of the PRs to the CSTs offer market-penetration services (e.g. sales force, distribution/selling points) to PRs for promoting and selling their QoS-based services in the market may promote the QoS-based services of the PRs either 'as they are' or with 'value-added', however adhering to the SLAs of the services as required by the 'Providers' interact with : CSTs on a customer-provider paradigm (SLA based) PRs based upon respective commercial agreements..
Different types RSs: according to whether they introduce value-added or not their market penetration means size ( # of of points of presence and/or sales force) RSs examples: Dealers, electronic/computers commercial chains, service portals
Content Provider (CP) an entity (organisation) gathering/creating, maintain, and distributing information. owns/operates hosts = source of downloadable content might not own any networking infrastructure to deliver the content content is offered to the customers or service providers.
digital
22
RS-Sem II RST
can contain : Content Manager(CM); several Content Servers (CS
New enties (in the perspective of Future Internet)
Virtual Network Provider (VNP) composes and configures and offer Virtual Network slices, i.e., a set of virtual resources at request of higher layers, as a consequence of its provisioning policy or during self-healing operations this approach avoids for the higher layers to establish direct relationships with infrastructure providers and to take care of inter-domain connections at physical layer. Virtual Network Operator (VNO) manages and exploits the VNEt s provided by VNPs , on behalf of HLSPs or end users Note: the same organisational entity migh play the both roles :VNP and VNO
1.3.3
Multiple Plane Architecture and Business Actors
Service Plane Management Plane Control Plane
Inter-domain manager
Data Plane
CC ANP NP SP CP/CS
Figure 14 Exemplu de arh. generica generic multi-domeniu multi-plan
Actori de Business
High Level - Service Providers (SP) Content Providers (CP) ( can own separate Content Servers- CS) Connectivity Services - Network Providers (NP) Content Consumers (CC) Access Services - Network Providers (AC) Fiecare actor poate avea una sau mai multe functionalitati- depinzand de rolul sau in arhitectura.
Service Level Agreements/Specifications (SLA/SLS)
1.3.4
SLA
it is a contract : documented result of a negotiation between a customer and a provider of a service that specifies the levels of availability, serviceability, performance, operation or other attributes of the transport service
23
RS-Sem II RST
SLA contains technical and non-technical terms and conditions May be established offline or online (using negotiation oriented-protocols)
Service Level Specification (SLS) It is a part of SLA SLS = set of technical parameters and their values, defining the service, offered by the provbider to the customer o e.g. service offered to a traffic stream by a network domain (e.g. Diffserv domain)
Content Provider
RESELLER
(HIGH LEVEL) SERVICE PROVIDER 1
HIGH LEVEL SERVICE PROVIDER N
.....
CUSTOMER
IP NETWORK PROVIDER 1
.....
IP NETWORK PROVIDER M
USER USER USER
PHYSICAL CONNECTIVITY PROVIDER 1
.....
PHYSICAL CONNECTIVITY PROVIDER P
PROVIDER/ OPERATOR 1
May be joined within the same entity
Figure 15 Generic IP Business Model (I) - and business relationships (SLA)
24
RS-Sem II RST
SERVICE PROVIDER 3.n 3.1 5 3.2 IP NETW ORK PROVIDER N 6 3.1 3.2
CONTENT M ANAGER
3.n
IP NETW ORK PROVIDER N
Data
CONTENT SERVER CUSTOM ER PHYSICAL CONNECTIVITY PROVIDER PHYSICA L CONNECTIVITY PROVIDER PROVIDER PROVIDER CONTENT PROVIDER
USER
Cascade model Hub model
4. Data pipe QoS guaranteed established through actions 3.x
Figure 16 Example: IP Business Models (II) - Hub model and Cascade model
1.4 Examples of Multiple Plane Architectures

1.4.1 IEEE 802.16 multi-plane stack
IEEE 802.16 : PHY + MAC Multiple plane architecture: Data Plane(DPl), Control Plane (CPl), Management Plane (MPl)
Figure 17 Basic IEEE 802.16 multi-plane protocol stack

25
RS-Sem II RST
Figure 18 (IEEE 802.16g-05/008r2, December 2005)
Figure 19 Relation IEEE802.16 vs. WiMAX NWG
26
RS-Sem II RST
1.4.2 Generic Example of a multi-plane architecture
Application
Data flow-user Control flow
Application
Services and session Control
1.4.2.1
Example: Enthrone European FP6 research 2006-2008 project End-to-End QoS through Integrated Management of Content, Networks and Terminals Business Actors: Includes the complex business model: CP, SP, CC, NP, ANP CC- Content consumer (Company, End users) o Customer ( org), End user CP- Content Provider o CPM content provider manager o CS1, CS2, - Content Servers SP- Service Provider (high level services) NP- Network Provider (connectivity services) ANP Access Network Providers
Stratum: Application And Services Stratum: Transport
Service Mng. (Planning provisioning, Offering, monitoring) Management Plane Data Plane Control Plan
Control Resurse Inter & Intra domain Inter-domain Resources and traffic Mng. Access & Core
Intra-domain Resources and traffic Mng. Access & Core
Figure 20 Generic example of a multi-plane architecture
An Architecture oriented to multimedia distribution over multiple domains networks
27
RS-Sem II RST
Service Provider Content Provider
SM&RM Content Consumers NP1
SM&RM NP2
NP3
Content Server
SM&RM = Service Mgmt and Resource Mgmt
SM&RM
Figure 21 Business actors and multi-domain infrastructure General objectives: to Offer high level services: Video on Demand (VoD), Streaming, E-learning, Multimedia distribution, IPTV (basically uni-directional) over heterogeneous network technology and Over multiple independent domains to manage, in an integrated way the whole chain of protected content handling transport and delivery to user terminals across heterogeneous networks, while offering QoS-enabled services o methods of QoS control: provisioning (offline and online) adaptation of flows to network capabilities
QoS adaptation loop
ENTHRONE
QoS provisioning
Content Consumers
NP1
Content Provider
NP2
AN
Figure 22 QoS assurance methods in ENTHRONE architecture
Multiple plane architecture: DPl, CPl, MPl NGN like prinnciples: separation of transport and services Creation of an service overlay over IP networks
28
RS-Sem II RST
1.4.3
Example: Architectural stack for wireless heterogeneous mesh network
WLANS and Mesh networks - Technology: 802.11, 802.16, 802.15
Figure 23 WLANs and Meshnetworks: a) WLAN-infrastructure; b) WLAN-ad hoc; c) mixedmode; d) mesh network.
Notation: MP Mesh Point; STA Station; ESS Extended Set Services Routing: - at Layer 2 ( 802.11s), or at Layer 3
Double role: Access Point and Router
Figure 24 Examples of mesh network topologies: a) 802.11 connected mesh; b) 802.11 mesh ad hoc
29
RS-Sem II RST
Example: European Research Project, FP7, 2008-2011 SMART-antenna multimode wireless mesh Network
Vertical structure of the architectural stack: Application and Service Macro-Layer (ASM) Transport Macro-Layer (TM) (layers 1-4 in the OSI terminology) ASM- contains applications (real-time or not real-time), which in their turn may use services offered by the system (e.g. a given complex application may use, among others, a VoIP service). TM- abstraction of layers providing IP connectivity services, (any PHY and MAC technologies) This view offers a complete independency to the application and service providers with respect to the transport infrastructure. The application and service providers can be third parties using connectivity services provided by the Transport Macro-Layer based on agreed Service Level Agreements (SLA) between them.
Data Plane Management and Control Plane
Application and Service M acro-Layer
Applications & Services
Services and Session Mng&Ctrl
Data Flows
QoS
Sec
Resource Mng & Control Coordinator
Acces Control
Transport M acro-Layer
TCP/IP
Network Coding
Routing
Mobility Mng
RM&C
Cross Layer Optim ization
Convergence Sublayer Multimode MAC ( 802.11, 802.16, ..)
Data Link Mng&Ctrl QoS, Mobility, RR Control, Scheduling
PHY
PHY Mng&Ctrl Smart Antennas and RAT Control
Figure 25 Multi-plane generic functional architecture
The architecture is horizontally divided into MPl, CPl, DPl. The Data Plane (DPl) processes the data packets (e.g. traffic classification and conditioning, conversion, coding/transcoding, prioritizing, marking and queuing) and transfer the multimedia flows.
30
RS-Sem II RST
At ASM level, the DPl may run mechanisms to adapt/transform media flows (fixed or scalable coding/decoding, transcoding, compression, conversion, security operations) under the control of some Media Control Middleware (MCM). At TM level DPl runs all network level data flow mechanisms which directly operates on data traffic o and assure QoS if guarantees are required from the connectivity service offered by this macro-layer
The Management Plane (MPl) performs essentially mid-long-term functions related to: At ASM: management of high level services (e.g subscription, invocation, etc.) At TM network, resources and traffic management operations.
The Control Plane (CPl) performs the short-term control functions including (at different layers): At ASM: it accomplishes the service and session control. At TM: PHY processing control, MAC processing, routing, mobility control, resource and QoS control, security, etc.
Further vertical decomposition can be seen in the TM
The lower layers covers Data Link layers and below. The upper layers cover the network and traditional Layer 4 (transport). A convergence layer will solve the compatibility with Layer 3. The MPL and CPl contains all low-layer mechanisms for PHY/MAC usually defined in the 802.x standards but also custom/proprietary management and control methods/algorithms ( (these are intentionally not specified by the standards in order to give freedom to constructors to use their best know how for them).
The QoS will be assured with several levels of guarantee (depending on application requirements), by considering two time scale approaches for resource management and control: provisioning for those applications flows where future resource consumptions can be forecasted (e.g. media distribution applications), done at aggregated levels based on Service Level Agreements/Specifications between entities; per session/flow QoS control for dynamic call requests.
1.4.4
Control Plane in GSM (2G)
PLMN Public Land Mobile Network
MS Mobile Station BTS Base Tranceiver Station BSC Base Station Controller MSC Mobile Switching Center GMSC Gateway MSC HLR/VLR Home Visitor Location Register EIR Equipment Identity Register AUC- Authentication Center ISDN Integrated Services Digital Network PSPDN Packet Switched Public Data Network
31
RS-Sem II RST
BSC
MSC VLR C
HLR
EIR
BTS GMSC MSC MS MS VLR C
AUC
PLMN
PSTN PSPDN ISDN/IN Other PLMNs
Figure 26 GSM Network General Architecture
MS
Um
BTS
Abis
BSC
A Protocol CM
MSC/VLR Relay
to MSC anchor
RIL3-CM RIL3MM DTAP RIL3RR Distrib

4-53
RIL3_RR
RIL3-CM RIL3-MM MAP/E MAP/G
Protocol MM 7 OSI-RM
Releu Relay RSM RIL3_RR BSSMAP DTAP BSSAP
BSSAP BSSMAP DTAP
RSM
4-5-6 3
Distribution
4-5-6
Distribution
4-5-6
TCAP
4-5-6 3 2 1
4-5-6 3
SCCP MTP1-3
SCCP MTP1-3
LAPDm I/F radio PHY Conections
LAPDm I/F radio
LAPD 64 kb/s
LAPD 64 kb/s
BSS
NSS
Figure 27 Control Plane in GSM RIL3 - Radio Interface Layer; CM, MM, RR - Connection, Mobility, Radio Resource - Management; Distrib distribution RSM - Radio Subsystem Management; DTAP - Data Transaction Application Part
32
RS-Sem II RST
BSSAP - Base Station Subsystem Appl. Part; BSS BS subsystem NSS Network Subsystem SS7 components:
MTP Message Transport Part ( SS7) LAPD Link Access Protocol for D channel layer 2 for ISDN LAPDm modification of LAPD for mobility SCCP - Signalling connection Control Part (CO mode for L3)
33
RS-Sem II RST
INTERCONNECTION- REVISION
(Romanian)
2.1 Moduri de lucru cu i fr conexiune CO/CL
CO/CL
4 DTE-A 3 SN1
ISa
2 SN2
1 DTE-B
1 2 ISb SN3 n
ISc DTE-C
CL PDU
CO PDU
Figura 2-1 Modul de lucru cu i fr conexiune IS Sistem intermediar; SN - subreea
CO fiecare IS joncioneaz ntre ele dou segmente de circuit virtual ( Ex. ATM, MPLS) CL - fiecare IS ia pentru fiecare PDU o decizie de dirijare ( forwarding n mod independent de cele anterioare nu se garanteaz pstrarea secvenei datelor Internet i poate baza transportul sau pe suporturi fizice ale altor reele der telecomunicatii ( PSTN, ISDN, CATV, etc.) sau pe suportul unor reele publice de pachete de arie mare
- elemente interconectabile: sisteme de capt (hosts) , sisteme intermediare (puni, comutatoare de nivel doi, comutatoare MPLS, rutere), subreele
A A B Telco P1 P3 a PN P3 P2 R
PN P P
PN
P1
P2
Figura 2-2 a. Reea public cu comutaie de pachete PN Packet Network
b. Reea Internet
2.2 Cerinele unui serviciu de interconectare (la nivel trei)

- s asigure link-uri ntre reele diferite - adresare i rutare/dirijare prin reele diferite
34
RS-Sem II RST
- contabilizarea utilizrii rersurselor pentru a ti starea fiecrui element de interconectare ( la nivel de element de reea; la nivel de domeniu administrativ) s furnizeze serviciile de mai sus astfel nct s se poat interconecta la reele de tipuri diferite fr a modifica infrastructura intern a fiecreia; deci trebuie rezolvate problemele: - scheme de adresare diferite - dimensiuni segmentatare/reasamblare) maxime diferite ale unitilor de date (este necesar
- mecanisme de acces la reea diferite - valori diferite de expirare pentru diverse temporizatoare ( timers ) - diferite metode (sau inexistente) de recuperare a erorilor - rapoarte de stare - tehnici de rutare diferite - controlul accesului utilizatorilor mecanisme diferite - mod de lucru CO/CL
ES/H
T
NSAP_1
IS Releu + rutare: SNICP SNDCP SNDCP SNDAP SNDAP DL DL PHY PHY
SNICP Nivel N=3 SNDCP SNDAP DL PHY Retea 1
Retea 2
Figura 2-3 Architectura generic a nivelului de reea soluie pentru acomodarea diferitelor reele: divizarea nivelului reea n trei subnivele: SNICP, SNDCP, SNDAP
SNICP Subnetwork Independent Convergence Protocol SNDCP - Subnetwork Dependent Convergence Protocol SNDAP - Subnetwork Dependent Access Protocol (can be void) Exemplu de SNICP: IP
2.3
Modul de lucru CO ( conexiune la nivel reea)

- faze: stabilire, meninere, eliberare de VC - este nevoie ca toate subreelele sa cunoasca acelai protocol CO pentru a putea construi VC multi-reea - deci presupunem c fiecare subreea ofer acelai serviciu de conectivitate (de nivel trei) de tip CO; rezultatul final este concatenarea unor segmente de VC (virtual circuits) - Figura 2-4.a: - mod de lucru CO - accesul la subreele se face prin intermediul aceluiai protocol de reea nu este nevoie de mai multe subnivele
35
RS-Sem II RST
- funciunile unui ruter CO : o o o funcie de releu pentru unitile de date de la o reea la alta ( forwarding) selectarea iniial a rutei (nod cu nod) are loc n faza de stabilire a conexiunii fiecare ruter jonctioneaz ntre ele segmente de VC (conexiuni logice)
2.4 Modul de lucru CL (fara conexiune la nivel reea)

- tratare independent a fiecarei uniti de date n fiecare nod de reea (ruter) - este util a defini un protocol de reea comun, independent de diferite tipuri de subreea particulare: IP = SNICP (RFC 791) ; ISO 8473 Connectionless Network Protocol (CLNP) are funciuni similare accesul la subreele particulare se face prin subnivelul de adaptare dependent de tehnologia specific (SNDAP= N1, N2, N3; SNDCP poate fi necesar sau nu, depinde de caz) Figura 2-4.b exemplu de stiv robustete (datorit tratrii independente a unitilor de date - datagrame); flexibilitate (poate lucra peste subreele CO sau CL); adaptare naturala la rutare dinamica ofer cel mai potrivit serviciu pentru un nivel transport de tip CL Servicul nativ este fr garanii ( best effort ) relativ la band, pierderi, ntrzieri de transfer, fluctuaia de intrziere, secvenialitate
- Avantaje CL:
- Dezavantaje CL: -
2.5 Interconectarea de tip punte (Bridge approach)

Punte = bridge = releu de nivel MAC lucrnd n mod CL Nu se analizeaz adresele de nivel trei Utilizate de regul pentru interconectare de LAN-uri
36
RS-Sem II RST
A T N N L1 P1 T I N1 L1 P1 T I LLC MAC1 P1 Relay MAC1 MAC2 P1 P2 Relay MAC2 MAC3 P2 P3 L1 P1 SN1 ISa SN2 ISb SN3 B T N N L3 P3 a L3 P3 T I N3 L3 P3 T I LLC MAC3 P3
R N L2 P2 N L2 P2
I N1 L1 P1 N2 L2 P2 N2 L2 P2
I N3 L3 P3
Figura 2-4 Arhitecturi de interconectare a. mod CO b. mod CL c. Mod de lucru de tip punte ( Bridge operation)
2.6 Exemple de interconectri

Examplu 1: Conexiune FTP client-server
Client FTP TCP IP MAC1 ETH PHY1
IP MAC1 ETH PHY1 MAC2 TR PHY2
Server FTP TCP IP MAC2 TR PHY2
Figura 2-5 Acces FTP acces ntre dou reele LAN via un ruter
Examplu 2: IP peste o configuraie de subrutele: LAN-reea public de pachete -LAN
37
RS-Sem II RST
Tunel X.25 A TCP IP LLC 1 2 MAC 3 P1 6 LLC 5 MAC 4 P1 LAN1 R1 WAN X.25 R2 LAN2 B TCP IP LLC MAC P3 LLC MAC P3
IP X.25-3 X.25-2 P2 7 8 9
IP X.25-3 X.25-2 P2
3,4 9
2, 5 MAC1-H 8 DL-H
1,6, 7 LLC1-H LLC1-H P-H P-H
IP-H IP-H IP-H IP-H IP-H
TCP-H TCP-H TCP-H TCP-H TCP-H
Date Date Date Date Date
MAC1-T DL-T
Figura 2-6 Operarea protocolului Internet via reea public de pachete (WAN ex. X.25) Note: - avem acelai nivel IP ( SNICP) n toate sistemele ( A, R1, R2, B) - au loc ncapsulri/decapsulri succesive n timp ce PDU traverseaz in sus i in jos nivelele funcionale (vezi figura) - se face segmentare/reasamblare daca e necesar - informatie de rutare: necesara in R1 i R2 - R1 sau R2 ofera un serviciu de conectivitate nefiabil (best effort) - congestii posibile (deoarece banda unui VC este limitat n reeaua X.25) - intarziere de transfer variabil Examplu 3: Interconectare de tip punte (distant) peste o reea de pachete
38
RS-Sem II RST
\ WAN X.25
A 3 LLC MAC P1
LAN1
B1
B2
LAN2
B 3 LLC MAC P3
1 2 3
Releu X.25-3 MAC X.25-2 4 P1 P2
5 6
Releu X.25-3 X.25-2 MAC P2 P3
1 2 5 6 DL-H 3,4 X.25-H X.25-H MAC-H MAC-H MAC-H LLC-H LLC-H P-H P-H
Data Data Data Data Data
MAC-T MAC-T MAC-T
DL-T
Figura 2-7 Operarea protocolului Internet prin puni interconectate la nivel doi printr-o reea de pachete ( exemplu: X.25 WAN ) presupunem c avem n LAN1 si LAN2 acelai MAC dei nu este obligatoriu diferena fa de interconectarea IP/WAN este ca in acest caz cadrele de nivel doi sunt transportate prin tunelul X.25 i nu datgramele IP Interconectarea de reele LAN prin puni (B) Interconectarea de nivel 1 ( prin repetor): o o o o o o Permite extinderea distantei fizice Stiva arhitectural este aceeai n toate sistemele (nivel 1- nivel 7) Repetorul: obiect de interconectare de nivel fizic care regenereaza formatul electric al semnalului Repetor: cost sczut, dar non-inteligent Efect general aceeai reea dar cu extindere pe dimensiuni fizice mai mari Exemplu clasic: reea Ethernet cu repetoare (Hub)
2.6.1
Interconectarea la nivel 2 a retelelor locale (LAN ): prin punti (B =Bridge)
- Interconectri pentru reele cu MAC diferit; LLC i nivele >2 aceleai
39
RS-Sem II RST
Aplicatie TCP/UDP IP (LLC)* MAC1-ETH PHY1 Releu (LLC partial) MAC1-ETH PHY1 MAC2-TR PHY2 Aplicatie TCP/UDP IP (LLC)* MAC2 TR PHY2
LAN 1
LAN 2
Figura 2-8 Arhitectura de interconectare prin puni (*) n principiu LLC poate lipsi Cadrele recepionate de ctre B pe un port (de la un segment de LAN) : memorate, verificate CRC, convertite la formatul noului MAC, redirijate Are loc o filtrare a adreselor locale (adrese MAC) Avantaje ale punilor (sunt mai importante dect dezavantajele) o o o o o o o o Memorare + retransmisie MAC1 poate fi diferit de MAC2. Exemplu : 802.3 802.5 posibile extensii gradate spre tehnologii diferite Elimin constrngerile de distan fizic (repetorul interconectare de nivel 1 nu face asta) B este releu pe baz de adres MAC- transparent la nivele superioare Uureaz gestionarea reelelor mai mari (dac n B se include SW de management) Crete securitatea reelelor (datorit filtrrii traficului local/extern) Creste fiabilitatea /disponibilitatea segmentelor Conceptul de B se extinde imediat la comutatoare de nivel 2 ( Layer 2 switch) Permit crearea de LAN-uri virtuale (VLAN) foarte important in practic
Dezavantaje ale punilor (Problemele de principiu greu rezolvabile/netriviale) o o o o Lungime diferit de cadre Lucru diferit cu prioriti Incompatibilitate ntre valorile timerelor utilizate probleme de gestiune a configuraiei mixte
Alte probleme: lipsa de control de flux la nivel MAC posibilitatea suprancrcrii memoriei din B memorare + retransmisie ntrzieri mai mari dect la interconectarea repetoare probleme cu expirri de timere n MAC-uri diferite dac distana este mare modificarea cadrelor la traversarea B + calculul pentru noul CRC erori eventuale n timpul translatrii (releu) care rmn nedetectate
Concluzii : avantajele sunt mai mari dect dezavantajele B utilizate foarte frecvent ( azi sub form de comutatoare de nivel 2) Exemple de standarde: IEEE 802.1 - puni transparente
40
RS-Sem II RST
IEEE 802.5 conine o parte referitoare la B cu rutare de tip surs 2.6.1.1 Puni transparente (Transparent Bridges- TB)
Caracteristici generale

prezena n reea a (n>1) puni - transparena pentru staiile ce intercomunic TB- se iniializeaz i configureaz automat la introducerea n reea (fr o intervenie special din partea restului reelei) reconfigurarea dinamic n timpul funcionrii sunt prevzute cu n 2 porturi pentru n 2 LAN-uri fiecare port are chip-set-uri corespunztor MAC corespunztoare tipului de LAN i SW de gestiune
( SW initializeaz chip-set-ul; gestioneaz memoria (buffere) aloc buffere pentru chip-set MAC din MAC de recepie ; paseaz buffere pline spre chip-set MAC de transmisie ). Extensie 1: comutatoare de nivel 2 ( punti cu n > 2 porturi) eventual cu tehnologii diferite Extensie 2 : VLAN 2.6.1.2 Punti cu rutare de tip sursa Punti transparente : B participa in mod colectiv la rutare intr-un mod transparent pentru statii . Statiile comunica intre ele ca i cum ar fi pe acelasi LAN. Punti cu rutare sursa : statia src include in cadrele emise informatii de rutare pana la destinatie . Info- rutare in antetul cadrului folosita de punti pentru rutare (fiecare B determina daca acel cadru trebuie dirijat spre alt segment sau nu) Informatia de rutare = secventa de perechi ( S- B ) unde S= segment ( adresa LAN) B= id punte Observatie Rutarea sursa se utilizeaza in special in IEEE 802.5 ( fiind o parte a acestui standard) Exemplu cadru 802.5
41
RS-Sem II RST
ROUTING PROTOCOLS
(Romanian + english) Not complete
3.1 Algoritmi de rutare -sumar

Protocol de rutare = algoritm + mecanism de schimb de nesaje intre nodurile retelei Retea-abstractizata printr-un graf orientat/neorientat
asimetric
1 A 2 3
B 2 1 D 1 C
asimetric
Figura 3-1 Exemplu simplu de graf orientat
G(V,E); V- set de noduri; E edge set set de link-uri Ponderi/costuri asociate link-urilor
Problema de rutare: gasirea unui arbore cu cost minim de la orice nod considerat ca sursa catre orice nod considerat ca destinatie costul oricarei cai = minim ( SPT = Shortest path tree) cost total al arborelui = minim (arbori de tip Steiner) Centralizati /distribuiti/ de tip mixt metrica simpla (1 criteriu) compusa mai multe criterii statice: nr. de noduri traversate, 1/Banda_link, cost administrativ, cost total al unui arbore, dinamice ( costul se modifica odata cu incrac area retelei cu trafic): grad de incarcare a unui link, intarziere pe link/ ruta, numar mediu de erori de transmisie per link
Clasificarea algoritmilor de rutare Criterii de cost/metrica:
Exemple de metrici:
Obs: n>1 metrici => probleme NP - complete; se cauta solutii aproximante quasi-optime Se poate demonstra in unele cazuri particulare care este departarea (procentuala - d.p.d.v al costului obtinut) unei solutii aproxiomative fata de optimul teoretic.
42
RS-Sem II RST
Exemple de grafuri:
2
2 5 8 11 1
11 1
1
1 10 S 3 6 9 4 7
10 S 3 6 9 4 7
M= {1,5,6,9,11} Cost/link =1
a. Network graph
M= {1,5,6,9,11} Cost/link =1
b. Shortest Path Tree (SPT) Source Specific Tree C=8 Dmax = 3 Dav =2.5
Figura 3-2 Exemplu de graf si SPT
M= submultime de noduri inregistrate la un grup de multicast
11 1
1 10 S 3 6 9 4 7
M= {1,5,6,9,11} Cost/link =1
Group Shared Tree Example of Steiner Tree
Figura 3-3 Arbore Steiner- exemplu
43
RS-Sem II RST
Steiner Tree Problem in Networks (SPN) - NP-complete problem
Given: G = (V,E) undirected M = multicast group included in V cuv = cost of link (u,v); u,v V Required: t = (VT, ET), which spans M so that
c
( u ,v )ET
Example
uv
= min imum
Steiner nodes = nodes u,v VT but they do not belong to M Steiner nodes= {4,7} M = {1,5,6,9,11}
CT = 6 !! less than in SPT

DSav = (2 + 3 + 4 + 3)/4 = 12/4 = 3 Greater than for SPT!!
Constrangeri:
Constraints
to a link (e.g bandwidth, available buffer, etc.). to a path or to the whole tree, additive (e.g.
Tree constraints can be ( m = metric)
E2E delay on every path from source to destination number of hops 1/B_link m(u,v) = m(u,i) + m(i,j) + m(pv), for a path P( u,i,j, ..v) Sum of the costs on all edges of the tree
multiplicative ( e.g : m= the probability that a packet will reach the destination, being given the correctness probability on each link) m(u,v) = m(u,i) *m(i,j) * m(pv), for a path P( u,I,j, ..v) the cost of the path could be expressed as [1- m(u,v)] m(u,v) = Min{ m(u,i), m(i,j), m(pv)}, for a path P( u,I,j, ..v)
concave (e.g. minimum bandwidth on a chain of links on a path)
Moduri de lucru ale protocolului:
Proactiv
44
RS-Sem II RST
o o o o
Algoritmul lucreaza in permanenta ( background) si caluleaza rute; Info de rutare exista in permanenta in tabelul de fwd. Rutele pot sa nu mai fie actuale daca intervalul temporal de calcul e mare in comparatie cu modificarile de topologie sau costuri ( ex. retele cu mobilitate) Daca perioada de calcul este f. Micaatunci rezulta un overhead cu trafic de control De ex. in retele ad-hoc Alg. Poate rula in stil proactiv in anumite conditii si in mod reactiv in altele
Reactiv ( on demand) o ruta se caluleaza la cererea unei statii
De tip mixt
Clasificare d.p.d.v cunoasterea topologiei:
vectori de distanta (distance vector)
un nod nu cunoaste topologia completa a retelei ci numai informatii de tip distante intre anumite puncte
cu stari ale link-urilor (link state)
Probleme suplimentare in calculul rutelor:
mobilitatea; inteferente in radio; refacerea rutelor deteriorate problema link-urilor asimetrice problema cailor diferite in cele doua sensuri.
Caracteristici dorite ale protocolului: convegenta, optimalitate, complexitate redusa, robustete, extensibilitate, echitate, fiabilitate, etc. (unele sunt contradictorii)
45
RS-Sem II RST
Unidirectional tree One tree per source S1 rooted tree (SPT) S2 rooted tree (SPT) Optimised for source specific mc communication
S1
R2
R3 R4
R1
S1
S2
R3
R5
Unidirectional Shared (by all sources) tree Components: Shared tree Data path S1RP Data path S2 RP
R2
R4
RP
R1
S1
Bidirectional Shared Tree Distribution of S1 data Distribution of S2 data
S2
R2
R5
R3
R4
R1
S2
R5
Figura 3-4 Exermple de tipuri de arbori
3.2 Algoritmi de baza pentru cautarea celui mai scurt drum

Retea- echiv cu un graf Caut drumul cel mai scurt intre doua noduri d.p.d.v cost Cost de tip aditiv proportional cu cu : nr. Noduri/dist./t. intarziere/ inversul benzii
k1 i k2 j
Figura 3-5 Cautarea drumului minim intre nodurile i si j (graf simplificat)
dij min = min { dik + dkj} k

46
RS-Sem II RST
unde k este un nod oarecare prin care exista drum spre nodul j.
3.2.1
Algoritmul Dijkstra (centralizat)
Se cauta toate drumurile minime de la un nod sursa catre toate celelalte. Rezulta un arbore de acoperire cu radacina in nodul sursa. Se repeta alg. ptr. fiecare nod al retelei.
- date de intrare : lista nodurilor, lista interconectarilor, costurile link-urilor.
Algoritm:
Fie un nod A Se construieste arborele drumurilor minime cu radacina in A extinzandu-l succesiv pana ce toate nodurile apartin arborelui.
Notatii:
Fie v, w, noduri ale grafului D(v) = distanta intre A si nodul v ( suma costurilor pe un drum intre A si v) l (v, w) = distanta ( costul arcului) intre v si w N = multimea nodurilor din arbore
Nota : alg se poate aplica in principiu pentru grafuri orientate sau nu.
1 A 2 3
B 2 1 D Graf initial (orientat) 1 2 C 3 A
B 2 C D 1
Graf orientat pentru calculul unui arbore cu radacina in sursa A
Figura 3-6 Exemple de cazuri pentru grafuri neorientate sau orientate
Algoritm de baza pentru graf neorientat N={A}
1. Initializare:
Ptr. v N se eticheteaza nodul v astfel : v(NH,D(v)), unde NH este (next hop) nodul din arbore prin care v are acces spre A. In particular avem: v(A, D(v)) pentru nodurile legate direct la A
47
RS-Sem II RST
v(-, ) pentru nodurile care nu sunt legate direct la A 2. Se completeaza arborele cu un nod nou , astfel: - se cauta w N, pentru care D(w) = minim - N= N {w} se include in arbore nodul w - Se reeticheteaza fiecare vecin v (care nu apartine lui N) al lui w, prin recalcularea dist. la A tinand seama de noul nod inclus in arbore , astfel: D(v) = min{ D(v), D(w) + l(w, v)}, v N, v V(w) unde V(w) este multimea vecinilor lui w. Ca urmare a reetichetarii, NH din eticheta v(NH, D(v)): - va ramane NH ( valoarea care era deja) - sau va deveni w daca prin w se obtine un nou drum mai scurt spre A. 3. Se repeta etapa 2 pana ce toate nodurile apartin arborelui. Exemplu:
48
RS-Sem II RST
B(A,1) Initial: N={A} 1 A 3 4 6 1 C(A,6) costuri = dist. recalculate V(B) C (N) C (N)= complement al lui N 2 3 E(-,) 6 1 C(B,5) 1 D(A,3) Pas 1: N={A,B} Se adauga B 1 A 3 4 2 3 E(-,) B(A,1) 1 D(B,2)
Pas (2): N= {A,B,D} Se adauga D
B(A,1) 1
Pas (3): N= {A,B,D,C} Se adauga C 1 D(B,2) A 3 4 6 E(D,5) 1
B(A,1) 1 D(B,2) 2 1 3 E(D,5)
1 A 3 4 6 2
C(D,4)
C(D,4)
Pas (4): N= {A,B,D,C, E} Se adauga E 1 A 3 4 6
B(A,1) 1 Arbore de drumuri minime de la A la B,C,D,E D(B,2) 2 1 C(D,4) 3 E(D,5)
Figura 3-7 Exemplu de calcul pentru algoritmul Dijkstra
Arborele de dirijare pentru nodul A va fi cel din tabelul de mai jos : Destinatia B C D E Nodul urmator B B B B
49
RS-Sem II RST
3.2.2 Algoritmul Ford (Fulkerson) - cauta drumurile de cost minim - nodul radacina ( fie A) este considerat ca destinatie - rularea algoritmului este gata - dupa etichetarea tuturor nodurilor cu dist. fata de A si cu eticheta nodului urmator pe drumul cu cost minim catre A - constructia tab. rutare = repetarea alg. pentru fiecare nod destinatie.
Eticheta are aceeasi forma ca la alg Dijkstra . Ex B(5, C) este eticheta nodului B care arata ca distanta pana la A este 5, via nodul vecin C
1. Initializare Fie nodul A = destinatie, D(A) = 0. Se eticheteaza toate celelelte noduri cu ( -, ). 2. Etichetarea tuturor nodurilor cu distantele minime pana la A Pentru nod v A executa: - actualizeaza distantele D(v) pana la destinatia A, pentru fiecare nod, prin utilizarea valorilor curente D(w) ale tuturor vecinilor w ai lui v, adica pentru toti w V(v). Se face atribuirea: D(v) = min{D(w) + l(w,v)} w V(v) - se actualizeaza eticheta de nod cu nr. nodului vecin care minimizeaza expresia de mai sus si cu noua distanta D(v). 3. Repeta etapa 2 pana cand nu mai apar modificari.
Comparatie: (lau + duA) < > (lat + dtA) < > (law + dwA) lau lat
v u duA
t Vv dtA dwA A
law
w
Figure 28 Actualizarea distantelor lui v fata de A
Exemplu problema. 1.Sa se determine arborele drumurilor minime in raport cu nodul A ptr. reteaua din fig. 1. Sa se scrie tab de rutare din nodul A pentru host-urile Hi, I < > 1. 2. Folosind drumurile de lungime minima sa se aloce numere de circuite virtuale pentru conexiunile (solicitate temporal in ordinea data) H1 - H7, H3 - H7, H2 - H6, H1 H6, H1 H5.
50
RS-Sem II RST
A 1 H2 B 2 1 7
H1 ` C H3 `
2 3 H4 D 8 V( B) H7 ` H4 4 E
F 4 G
H6 `
Figure 29 Configuratia retelei. Nodul A este destinatie.
Lista etichetelor initiale B (-, ) C (-, ) D (-, ) E (-, ) F (-, ) G (-, )
Pasul 1.1 : v = B
Nod w
D(w)
l (v,w)
D(w) + l (v,w)
Noua eticheta ptr. nodul B
A C D
1 1 2
(A, 1)
Lista etichetelor dupa pasul 1.1
B (A,1)
C (-, )
D (-, )
E (-, )
F (-, )
G (-, )
Pasul 1.2 : v = C
Nod w
D(w)
l (v,w)
D(w) + l (v,w)
Noua eticheta ptr. nodul C
(A, 2)
51
RS-Sem II RST
B D F G 1

1 3* 3* 2*
* = se poate inlocui cu x ( nu conteaza)
Lista etichetelor dupa pasul 1.2 B (A,1) C (A,2) D (-, ) E (-, ) F (-, ) G (-, )
Pasul 1.3 : v = D
Nod w
D(w)
l (v,w)
D(w) + l (v,w)
Noua eticheta ptr. nodul D
B C G
1 2
2 3 x
3 5
(B,3)
Lista etichetelor dupa pasul 1.3 B (A,1) C (A,2) D (B,3) E (-, ) F (-, ) G (-, )
Pasul 1.4 : v = E
Nod w
D(w)
l (v,w)
D(w) + l (v,w)
Noua eticheta ptr. nodul E
A G
7 x
(A,7)
52
RS-Sem II RST
Lista etichetelor dupa pasul 1.4 B (A,1) C (A,2) D (B,3) E (A,7) F (-, ) G (-, )
Pasul 1.5 : v = F
Nod w
D(w)
l (v,w)
D(w) + l (v,w)
Noua eticheta ptr. nodul F
C G
3 x
(C,5)
Lista etichetelor dupa pasul 1.5 B (A,1) C (A,2) D (B,3) E (A,7) F (C,5 ) G (-, )
Pasul 1.6 : v = G
Nod w
D(w)
l (v,w)
D(w) + l (v,w)
Noua eticheta ptr. nodul G
C D E F
2 3 7 5
2 8 4 4
4 11 11 9
(C,4)
Lista etichetelor dupa pasul 1.6 B (A,1) C (A,2) D (B,3) E (A,7) F (C,5) G (C,4)
Repetand pasul doi se constata ca nu mai apar modificari.

Atentie: rezolvarea completa presupune si terminarea pasului 2 ( adica 2.1 2.6).
53
RS-Sem II RST
A 1 H2 B 2 1
H1
C 7
H3
2 3 H4 D 8 H4 4 E
F 4 G
H6
H7 `
Figure 30 Arborele drumurilor minime pana la nodul A
Tabelul de rutare pentru nodul A este :
Destinatia H2 H3 H4 H5 H6 H7
Ruta ( via) B C B E C C
Cost 1 2 3 7 5 4
Algoritmul se repeta pentru fiecare nod pentru care se construieste tabelul de rutare.
3.3 IP Routing Protocols

3.3.1 Internet Protocol reminder
- connectionless style, RFC 791- official specification of IP - best effort protocol no guarantees- problems for real time traffic - if problems appear rejection of datagrams (IP-DGs) - functions: - segmentation / reassembly (segmentation at the input of first subnetwork and reassembly only at the end destination machine)
- routing hop-by-hop principle - error reporting IP services
54
RS-Sem II RST
- two service primitives : send( ), deliver( )
- primitive parameters: - source and destination IP addresses ( IPa_src, IPa_dst) - protocol ( recipient of IP-DGs)
- type of service indicator specifies data treatment
- identifier used in combination with IPa_src, IPa_dst and protocol field to uniquely identify data unit
- dont fragment segmentation indication

- time to live life time of DG measured in network hops - data length length of data being transmitted
- optional data option request by the IP user - security allow a security label attached to IP-DG - source routing list of routers - route recording field allocated to record the sequence of routers
- stream identification names reserved used for stream service
- time-stamping source IP entity and some or all intermediate routers add a timestamp ( precision - ms) to the data unit
- data data to be transmitted
IP Service quality options - precedence eight levels of importance (3 bits) - reliability two levels (normal / high)
- delay two levels ( normal/high) - throughput two levels ( normal/high)

Note ToS has been re-defined in the DiffServ Technology as DSCP = DiffServ Code Point showing the packet priority
IP v4 Datagram format
- version indicates version number - Internet header length (IHL) in 32 bits words; (minimum IP-H 20 octets) - type of service precedence, reliability, delay, throughput - identifier ( 16 bits) together with IPa_src, IPa_dst uniquely identifies the IP-DG - flags ( more bit, dont fragment bit) used in segmentation - fragment offset ( measured in 64 bit units) used in segmentation - time to live (TTL) measured in router hops
55
RS-Sem II RST
0 Version 8 16 IHL Type of service Total length ( in octets) Identification Flags Fragment offset Time to live (TTL) Protocol Header checksum Source IP adress (x1.y1.z1.w1) Destination IP adress (x2.y2.z2.w2) Options Information 4 31 20 oct.
Figure 31 IP datagram format - protocol indicates the higher level protocol - header checksum- error detecting code for header only re-verified at each router (1 complement addition of all 16 bit words in IP-H) - options (variable) encodes the options requested by the user - padding to assure multiple of 32 bits
- data field integer multiple of 32 bits, 65 535 octets
3.3.2
Principles of IP routing
- if source and destination are on same local network then IP-DG sent arrives directly to the destination ( broadcast medium or serial line) - if not, the IP-DG is sent to a router charged to forward the IP-DG (based on forwarding tables) - to another router (next hop) up to the destination
- forwarding table is consulted for each IP-DG
- routing protocols are executed to build the routing tables - one may have several routing tables(RT) - one of them is selected as forwarding table (FT) - if there is only one routing table then the two are the same - usual principle of routing: hop by hop - one machine can be configured to function as a router also ( that is to retransmit the received IP-DGs which are not addressed to itself)
one entry in the routing table (RT/FT) :
- IPa_dst - destination IP address (machine addr. or network addr.) - next hop router address or an address of a network directly connected - flags - indicates if IPa_dst belongs to a machine or a network, etc. - interface specification of the output I/F where the IP_DG must be sent
IP forwarding operation
- search best match in RT (actually FT) of an entry corresponding to:

56
RS-Sem II RST
- full destination address (if found then route to next hop router or to I/F directly connected ( depending on flags) - or, destination network address (prefix) - similar actions - or default entry
Routing protocol demon update
route command
netstat command
UDP
TCP
ICMP Routing table redirection no
yes
packet for this dest?
forwarding (compute the next hop)
Retransmission (if valid) Source routing
IP process options
IP layer
Network interface
Figure 32 IP actions on the received datagrams 3.3.3 Network hierarchies
57
RS-Sem II RST
Figure 33 Internet global view
3.3.3.1
Multi-Tier hierarchy
The Internet today operates as a hierarchy Thousands of small, local, regional and small country ISPs operate at the bottom of an Internet pyramid. These operators typically have to pay for access to the networks and customers operated by larger ISPs. At the middle of the pyramid are several dozen Tier-2 ISPs that typically pay to transit the networks of the largest ISPs. Tier-2 ISPs seek to interconnect on a "peering" basis with other, Tier-2 ISPs. At the top of the pyramid are a handful of Tier-1 ISPs that typically peer with other Tier-1 ISPs.
58
RS-Sem II RST
Figure 34 Hierarchical Structure of the Internet
The diversification of ISPs has increased the number of locations where ISPs exchange traffic. When the Internet comprised a small number of Tier-1 ISPs, these ventures could exchange traffic at relatively few locations. Over time the number of network interconnection points has grown. These interconnection points are commonly referred to as Internet Exchange Points (IXPs). The increased number of IXPs results from:

The proliferation of ISPs, and The fact that many ISPs now operate networks within only a small geographic area.
With more networks lacking complete national and international coverage, more ISPs need to interconnect with and access the transit services of other ISPs. IXPs enable even small, regional ISPs to offer global Internet access to their subscribers.
3.3.3.2
Autonomous System Definition
The current Internet is a decentralized collection of computer networks from all around the world. Each of these networks is typically known as a domain or an autonomous system (AS) AS = network or group of networks under a common routing policy, and managed by a single authority.
Today, the Internet is basically the interconnection of more than 20,000 ASes [4].
Intra-domain routing: Every one of these ASes usually uses one or more interior gateway protocols (IGPs), such as Intermediate System to Intermediate System (IS-IS) or Open Shortest Path First (OSPF), to exchange routing information within the AS. Inter-domain routing focuses on the exchange of routes to allow the transmission of packets between different ASes.
59
RS-Sem II RST
Single-homed stub AS
Multi-homed stub AS Transit AS
Tier-3
Tier-1, Tier-2
Figure 35 A simplified inter-domain scenario
When an AS is connected to multiple different ASes, it is referred to as a multihomed AS. Types: single-homed, multi-homed, transit AS. Note a transit AS could be sometimes considered as multi-homed stub AS. ( e.g. AS 2).
3.3.3.3
ASes and Tiers
Todays Internet : hierarchy of transit ASes . This hierarchical structure consists in two different types of relationships that could exist between ASes - customer-provider - peer-to-peer Thus, for each transit AS any directly connected AS is either a customer or peer.
Level 1: the top of this hierarchy we found the largest ISPs, (Tier-1 ISPs). - There are about 20 Tier-1s at present which represents less than 0.1 percent of the total number of ASes in the Internet - Tier-1s are directly interconnected in almost a full mesh and compose the Internet core. In the core all relationships between Tier-1s are peer-to-peer, so a Tier-1 is any ISP lacking an upstream provider. Second level of the hierarchy is composed of Tier-2 ISPs ( national ISPs) - A Tier-2 is any transit AS that is a customer of one or more Tier-1 ISPs
60
RS-Sem II RST
A representative example of a Tier-2 ISP is a national service provider. Tier-2 ISPs tend to establish peer-to-peer relationships with other neighboring Tier-2s for both economical and performance reasons (SLA-s can be negotiated) This is typically the case for geographically close Tier-2 ISPs that exchange large amounts of traffic.
Tier-3 ISPs : those transit ASes in the hierarchy that are customers of one or more Tier-2 ISP, such as regional or local ISPs within a country.
Stub ASes are non-transit ASes that are customers of any ISP (Tier-1, Tier-2, or Tier-3) Example: In Figure 3-6 - ISPs such as AS11, AS12, AS21, AS23, and AS31 would be classified as Tier-2 ISPs, - while AS22 represents a Tier-3 ISP. An important corollary of this hierarchical structure is that the diameter of the Internet is very small in terms of AS hops.
3.3.4
General definitions Hierarchy: - backbone network, - autonomous systems, - networks, subnetworks, hosts - Autonomous System (AS) ( Domain) logical portion of larger IP networks administered by a single authority. The AS would normally comprise the internetwork within an organization, and would be designated as such to allow communication over public IP networks with ASs belonging to other organizations. It is mandatory to register an organization's internetwork as an AS in order to use these public IP services. - Gateways (Routers): IG Interior Gateway( Router), EG - Exterior(Border) Gateway - Protocols: IGP, EGP - Interior Gateway Protocol, Exterior Gateway Protocol (e.g. Border Gateway Protocol- BGP)
- AS-s can be organised on more than one level ( nets, subnets, etc.) - IP address global address equivalent to NSAP addresses different from Network Point of Attachment (NPA) which depends on particular subnetwork mapping: IP_addr NPA - routing based on IP_addr requires finding the NPA (MAC address) which corresponds to IP_addr - Adress Resolution Protocol (ARP) , Reverse Address Resolution Protocol (RARP) solve the problem
61
RS-Sem II RST
EGP EG EG iEGP Backbone net EG EG EGP IGP IGP IG N2 IG
N1
IG
N3
AS3
SN1 SN1
AS2
AS1
second level IG router host
Figure 36 Generic hierarchical Internet topology
Protocol scopes
- ARP used in one network to find the NPA_dst address corresponding to IPa_dst Hi ARP Hk Hi ARP IGj ARP Hk
- IGP, EGP used between routers
IGi IGP IGj IGP EGk EGP EGn
Daemon
Interior Gateway Protocol (IGP) HELLO RIP V1 V1 V1, V2 V2 OSPF
Exterior Gateway Protocol EGP EGP BGP
routed gated V.2 gated V.3
V1 V2, V3
Table 3-1 Routing protocols supported by routed and gated daemons
[Note: In Unix and other computer multitasking operating systems, a daemon is a computer program that runs in the background, not under the direct control of a user they are usually initiated as background processes.
Typically daemons have names that end with the letter "d": for example, syslogd, the daemon that handles the system log, or sshd, which handles incoming SSH connections.] In TCP/IP software operating systems, routing protocols are often implemented using one of two daemons: Routed: Pronounced route D. : basic routing daemon for interior routing supplied with the majority of TCP/IP implementations. It uses the RIP protocol
Gated
62
RS-Sem II RST
Pronounced gate D. : more sophisticated daemon on UNIX-based systems for interior and exterior routing. It can support a number of additional protocols such as OSPF, BGP In TCP/IP the routing protocols are implemented in the operating system.
3.3.5 Address Resolution Protocol (ARP), Reverse ARP RARP
-RFC 826 ARP specifications - ARP, RARP - integral part of IP

A RP R AR P
IP_add r (32 bits)
NPA _addr (e.g. M AC _addr 48 bits)
Figure 37 ARP and RARP actions ARP
machine name DNS (1) IP address (IP_a) source (client) ARP
(0) FTP
machine name
(2) setup connection with IP addr = IP_a TCP (3) send IP dg(IP_a) (conn-req) (8) send IP dg(IP-a, MAC_a) (conn-req)
(4) IP (6) (7)
Ethernet LAN
driver Ethernet
ARP_req(IP_a) (5)
driver Ethernet ARP
driver Ethernet
ARP
destination (server)
IP TCP
Figure 38 Example of ARP role in sending IP datagrams
- ARP of a host maintains a table hostid/NPA address pairs for all hosts connected to this network with which host communicates - IP-DGs comes from upper layer, ARP table is consulted - if IPa_dst entry exists then NPA_addr is red and a pointer to address of IP-DGs is passed (together with NPA_addr) to SNDAP sublayer protocol
63
RS-Sem II RST
- if not, then an ARP_reqt(IPa_src, NPA_src, IPa_dst) is broadcasted or sent to the default IG - in the second case the ARP in IG relays the ARP_request to the destination host - the destination host replies with ARP_reply(NPA_addr), using the NPA_addr of source to return the result - the source host stores the result of ARP_reply and sends IP-DG to SNDAP - cache ARP increase efficiency, limited life time of entries - proxy ARP IGP responds on behalf and instead of some machines linked behind it ; the source does not see the real configuration
RARP
- obtains the IP_addr associated to a given NPA_addr - useful in diskless machines at start-up
3.3.6 Interior Gateway Protocols - function: finding the routing information within an AS
- distributed protocols messages between routers ( nodes) - dynamic routing -proactive/on-demand protocols
Distance Vector Algorithm (DVA) based protocols - examples
most used: Routing Information Protocol (RIP) each node bases its routing decisions only on neighbours information on distances (one node does not know the whole domain topology) Extensions of RIP:

AODV ( Adhoc on demand Distance vector protocol) used on WLANSMANET DVMRP Distance Vector Multicast Routing Protocol extension to mcast
Link state Protcol
- Open Shortest Path First (OSPF) link-state algorithm - examples - each node gets messages from neighbours ( info about links, costs) and builds a network graph - on this graph it determines the shortest path to the destination by applying some shortest path algorithm (Dijkstra, Ford, etc.) using a given metric - Optimized Link State Routing Protocol (OLSR)- used in MANET
- Multicast OSPF (MOSPF) extension of OSPF multicast
64
RS-Sem II RST
I/F Packets I/F

. .
Switch ( bus, matrix, etc.)
Control Plane Routing Protocols
Figure 39 Generic Router diagram
3.3.6.1
Routing Internet Protocol (RIP)
Distance vector-based protocol: The distances in the tables are computed from information provided by neighbor routers. Each router transmits its own distance vector table across the shared network. The sequence of operations :
Each router is configured with an identifier and a cost for each of its network links. The cost is normally fixed at 1, reflecting a single hop, but can reflect some other measurement taken for the link such as the traffic, speed, etc. Each router initializes with a distance vector table containing
o o o
zero for itself one for directly attached networks and infinity for every other destination.
Each router either o periodically (typically every ~30 seconds) transmits its distance vector table to each of its neighbors. o Or, it can also transmit the table when a link first comes up or when the table changes (event triggered updates). Each router saves the most recent table it receives from each neighbor and uses the information to calculate its own distance vector table (Ford distributed algorithm). The total cost to each destination is calculated by adding the cost reported in a neighbor's distance vector table to the cost of the link to that neighbor. The distance vector table (the routing table) for the router is then created by taking the lowest cost calculated for each destination
65
RS-Sem II RST
Comparison: (lau + duD) < > (lav + dvD) < > (law + dwD) lau lav
a
duD
v dvD D
law
Message : Routing table of w: (D, dWD) w dwD
Figure 40 Principle of RIP distance vector based counting of costs - RFC 1058/1988 official specification of RIP
- very used as a simple distributed intra-domain routing protocol - RIP messages between nodes are transported in UDP datagrams (Non reliable):
IP-H, UDP-H, RIP_message = IP-DG format for RIP
Destination NetB NetA
Next hop Router 2 Router1
Distance 3 (in hop count) 5
Timers t1, t2, t3 t1, t2, t3
Flags x,y x,y
Table 3-2 Typical RIP Routing Table
Note: in RIP the RT is the same as Forwarding Table
- RIP maintains only the best route to a destination - messages exchanged at request or periodically ( e.g. ~30 sec) - newer implementations- event triggered updates
RIP packet format
- command - specifies a request or response message
- version number- specifies RIP implementation - up to 25 routes having the format: - address family ID shows the address family used (e.g. IP_addr) - address IP destination address (4 octets), - metric Hop count ( how many routers) up to the destination - a RIP message can contain the whole or part of the source RT - update timer 30 sec ( each router sends its RT to neighbours each 30 sec) - route invalid timer when expires, a route is marked invalid ( e.g. 90 sec), neighbours are notified of this fact
- route flush timer when expires route is erased from RT
66
RS-Sem II RST
Figure 41 RIP packet format

Stability features
- Hop count limit ( < 16) prevents count to infinity routing loops - Hold down routers hold down any changes reported by neighbours regarding a route which was just removed route (prevent oscillations) - Split horizon avoids loops - Poison reverse updates increasing metric indicates loops; therefore a node detecting this sends a reverse messages to remove that route
(Net A, cost) Net A R1 R2
directions to which R2 may forward and advertise its route to NetA via R1
Figure 42 Split horizon-prevent loops between adjacent routers
3.3.6.2
RIP Extensions
RIP-2 RIP-2 is a draft standard protocol. Its status is elective (RFC 1723).
RIP-2 extends RIP-1. It is less powerful than OSPF but it has the advantages of easy implementation and lower overheads. It can replace for RIP that can be used on small to medium-sized networks - can be employed in the presence of variable subnetting Classless Inter-Domain Routing (CIDR) - can interoperate with RIP-1
RIPng for IPv6: intended to allow routers to exchange information for computing routes through an IPv6-based network (RFC2080 )
67
RS-Sem II RST
Material pentru partial II incepe aici. Zonele marcate cu fond gri nu se cer
3.3.6.3 Ad hoc On-Demand Distance Vector (AODV)
AODV RFC 3561- is originally a reactive ( i.e. on demand) distance-vector routing protocol for mobile ad hoc networks (MANETs) and other wireless ad-hoc networks. AODV is capable of both unicast and multicast routing. The usual metric is hop count. Other usage: in mesh networks.
General characteristics
The network is silent until a connection is needed. A network node that needs a connection broadcasts a request for connection.
Other AODV nodes forward this message, and record the node that they heard it from, creating an explosion of temporary routes back to the needy node.
When a node receives such a message and already has a route to the desired node, it sends a message backwards through a temporary route to the requesting node The needy node then begins using the route that has the least number of hops through other nodes Unused entries in the routing tables are recycled after a time. When a link fails, a routing error is passed back to a transmitting node, and the process repeats. The protocol lowers the number of messages to conserve the capacity of the network.
o o
For example, each request for a route has a sequence number. Nodes use this seq_no so that they do not repeat route requests that they have already passed on. The route requests have a "time to live" number that limits how many times they can be retransmitted. If a route request fails, another route request may not be sent until twice as much time has passed as the timeout of the previous route request.
o AODV uses symmetric links between neighboring nodes. AODV Advantages :

it creates no extra traffic for communication along existing links. distance vector routing is simple, and doesn't require much memory or calculation
route info is always fresh AODV is capable of both unicast and multicast routing.

AODV Drawback:
o o
requires more time to establish a connection than a proactive protocol the initial communication to establish a route is heavier than some other approaches.
AODV functional details
68
RS-Sem II RST
The AODV algorithm enables dynamic, self-starting, multihop routing between mobile nodes in an ad hoc network. allows nodes to obtain routes quickly for new destinations, does not require nodes to maintain routes to inactive destinations allows nodes to respond to link breakages and topology changes in a timely manner is loop-free, and by avoiding the Bellman-Ford "counting to infinity" problem by using:

destination sequence numbers (dst_seq_no) on route updates- to measure the freshness of a route
and originator seq-no for a node issuing a message
offers quick convergence when the network topology changes (e.g. node move) If links break, AODV causes the affected set of nodes to be notified so that they are able to invalidate the routes using the lost link.
AODV message types are :
Route Requests (RREQs; Route Replies (RREPs); Route Errors (RERRs)
Notes: They are received via UDP, and normal IP header processing applies The requesting node uses its IP address as the Originator IP address for the messages For broadcast messages, the IP limited broadcast address (255.255.255.255) is used. So, such messages are not blindly forwarded. Certain messages (e.g., RREQ) should to be disseminated widely, perhaps throughout the ad hoc network. The range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation is typically not required.
RREQ message (RFC 3561)

Route Request (RREQ) Message Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type |J|R|G|D|U| Reserved RREQ ID | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Destination IP Address Destination Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Originator Sequence Number
|
69
RS-Sem II RST
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Request message is illustrated above, and Type J R G D U Reserved Hop Count request.
Fields Semantics: RREQ ID A sequence number uniquely identifying the conjunction with the originating node's IP address.
contains the following fields:
1 Join flag; reserved for multicast. Repair flag; reserved for multicast. Gratuitous RREP flag; indicates whether a gratuitous RREP should be unicast to the node specified in the Destination IP Address field Destination only flag; indicates only the destination may respond to this RREQ Unknown sequence number; indicates the destination sequence number is unknown Sent as 0; ignored on reception. The number of hops from the Originator IP Address to the node handling the
particular RREQ when taken in
Destination IP Address: The IP addr. of the destination for which a route is desired. Destination Sequence Number: The latest seq_no received in the past by the originator ( of this message) for any route towards the destination. Originator IP Address: The IP address of the node which originated the Route Request. Originator Sequence Number: The current seq_no to be used in the route entry pointing towards the originator of the route request.
The range of dissemination of such RREQs is indicated by the TTL in the IP header.
Route Reply (RREP) Message Format
01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Type |R|A| Reserved |Prefix Sz| Hop Count | | | | |

70
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination IP address Destination Sequence Number Originator IP address Lifetime +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RS-Sem II RST
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Route Reply message is illustrated above, and contains the following fields:
Type R A
Reserved
2 Repair flag; used for multicast. Acknowledgment required; see sections 5.4 and 6.7. Sent as 0; ignored on reception.
Prefix Size If nonzero, the 5-bit Prefix Size specifies that the indicated next hop may be used for any nodes with the same routing prefix (as defined by the Prefix Size) as the requested destination. Hop Count : The number of hops from the Originator IP Address to the Destination IP Address. For multicast route requests this indicates the number of hops to the multicast tree member sending the RREP. Destination IP Address: The IP address of the destination for which a route is supplied. Destination Sequence Number: The destination sequence number associated to the route. Originator IP Address: The IP address of the node which originated the RREQ for which the route is supplied. Lifetime : The time in milliseconds for which nodes receiving the RREP consider the route to be valid. Maintaining Sequence Numbers
Every route table entry at every node MUST include the latest information available about the seq_no for the IP address of the destination node for which the route table entry is maintained. This sequence number is called the "destination sequence number".
Equivalent: DestSeqNum indicates the freshness of the route that is accepted by the source.
When an intermediate node receives a RREQ ,
it either forwards it or prepares a RREP if it has a valid route to the destination.
The validity of a route at the intermediate node is determined by comparing the seq_no at the intermediate node
with the destination seq_no in the RouteRequest packet.
It is updated : whenever a node receives new (i.e., not stale) information about the sequence number from RREQ, RREP, or RERR messages that may be received related to that destination.
- AODV depends on each node in the network to own and maintain its destination sequence number to guarantee the loop-freedom of all routes towards that node. A destination node increments its own sequence number in two circumstances:
- Immediately before a node originates a route discovery, it MUST increment its own sequence number. This prevents conflicts with previously established reverse routes towards the
71
RS-Sem II RST
originator of a RREQ. - Immediately before a destination node originates a RREP in response to a RREQ, it MUST update its own sequence number to the : maximum of its current seq_no and the destination seq_no in the RREQ packet.
Generating RREQ
A node disseminates a RREQ when it determines that it needs a route have one available. This can happen - if the destination is previously unknown to the node,
to a destination and does not
- or if a previously valid route to the destination expires or is marked as invalid. The Destination Seq_No field in the RREQ message is the last known destination seq_no for this destination and is copied from the DestSeqNum field in the routing table. If no sequence number is known, the unknown sequence number flag MUST be set. The Originator Sequence Number in the RREQ message is the node's own sequence number, which is incremented prior to insertion in a RREQ. The RREQ ID field is incremented by one from the last RREQ ID used by the current node. Each node maintains only one RREQ ID. The Hop Count field is set to zero
Hello Messages Hello Message = RREP with TTL = 1
This message is used for broadcasting connectivity information. Ex: If a neighbor node does not receive any packets (Hello messages or otherwise) for more than ALLOWED_HELLO_LOSS * HELLO_INTERVAL mseconds, the node will assume that the link to this neighbor is currently lost. A node should use Hello messages only if it is part of an active route.
Sequence of Actions:
When a route to a new destination D, is needed
the node wanting it broadcasts a RREQ a route can be determined when

the RREQ reaches either the D itself or an intermediate node with a 'fresh enough' route to D is touched
(i.e. a valid route entry for the D, whose associated dst_seq_no is at least as great as that contained in the RREQ)
The route is made available by unicasting a RREP back to the origination of the RREQ Each node receiving the request caches a route back to the originator of the request, so that the RREP can be unicast from D along a path to that originator, or likewise from any intermediate node that is able to satisfy the request
The requesting node selects among anwers the route with minimum number of hops.
Unused entries in the routing tables are recycled after a time. When a link fails, a routing error is returned to a transmitting node, and the process repeats.
72
RS-Sem II RST
Figure 43 AODV route finding (1): RREQ
Figure 44 AODV route finding (2): RREP
Enhancements w.r.t Distance Vector (DV) traditional algorithm
AODV uses dst_seq_no for each route entry The dst_seq_no is created by the D to be included along with any route information it sends to requesting nodes
Using dst_seq_no ensures loop freedom and is simple to program
Given the choice between two routes to a destination, a requesting node is required to select the one with the greatest sequence number. This method reduces the control overhead Also the route requests have a TTL number used as in IP. If a route request fails, another route request may not be sent until twice as much time has passed as the timeout of the previous route request.
Nodes monitor the link status of next hops in active routes
When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations (possibly subnets) which are no longer reachable by way of the broken link.
73
RS-Sem II RST
In order to enable this reporting mechanism, each node keeps a "precursor list", containing the IP address for each its neighbors that are likely to use it as a next hop towards each destination.The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in a precursor list. If the RREP has a nonzero prefix length, then the originator of the RREQ which solicited the RREP information is included among the precursors for the subnet route (not specifically for the particular destination)
AODV deals with route table management. Route table information must be kept even for shortlived routes, such as are created to temporarily store reverse paths towards nodes originating RREQs.
AODV uses the following fields with each route table entry:
- Destination IP Address - Destination Sequence Number - Valid Destination Sequence Number flag - Other state and routing flags (e.g., valid, invalid, repairable, being repaired) - Network Interface - Hop Count (number of hops needed to reach destination) - Next Hop - List of Precursors (described previously) - Lifetime (expiration or deletion time of the route)
Conclusions:
The advantage of AODV is that it creates no extra traffic for communication along existing links. Also, distance vector routing is simple, and doesn't require much memory or calculation. Drawback: AODV requires- (relative to proactive protocols) high time to establish a route.
3.3.6.4
Open Shortest Path First (OSPF)
OSPF (basic link-state protocol) dynamic, proactive, link-state based routing protocol designed as an intra-domain routing protocol for Internet most widely-used IG in large enterprise networks; IS-IS, another link-state routing protocol, is more common in large service provider networks.
OSPF is for use in Internet Protocol (IP) networks. It falls into the group of interior gateway protocols, operating within an autonomous system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4. The updates for IPv6 are specified as OSPF Version 3 in RFC 5340 - 2008.
74
RS-Sem II RST
OSPF features: Support for type of service (Type of Service-based -TOS) routing Provides load balancing ( OSPF Equal-Cost Multipath) Allows site partitioning into subsets by using areas (used in large domains) Information exchange between routers requires authentication Support for host-specific routes as well as network-specific routes Reduces table maintenance overhead to a minimum by implementing a designated router Allows definition of virtual links to provide support to a non-contiguous area Allows the usage of variable length subnet masks (also present in RIP-2) Will import RIP and EGP routes into its database OSPF routes packets based on the destination IP address found in IP packets. It supports variablelength subnet masking (VLSM, CIDR). The (simplified) ideas of OSPF are: - each node detects its link status and distribute this information to neighbours (flooding) - these messages (Link updates) are sent when necessary - each neighbour does the same (relaying information) - eventually each node finally gets complete knowledge about network topology - each node runs an SPF algorithm ( e.g. Dijkstra) to compute routes to any destination - each nodes fill a forwarding table (several tables based on different metrics can be computed)
Comparison of routing philosophies
Distance vector routing
Link state routing
Each R sends distance information (to reach Each R sends link state information to all other different destinations/networks) to its routers ( flooding the area) neighbours and not topological info!! Info sent = estimate destinations/networks of cost to each Info sent by a R is the exact cost of its links/segments to other networks Info sent when changes appear
Different metrics are possible
Info sent (usually) periodically or at events Metric = no of hops
R determines next hop info by using Bellman R gets a graph of the network, computes SPF Ford algorithm on the received estimated path and builds RT costs
Table 3-3 DVA and LS comparison

Link state routing algorithm link state advertisement (LSA) are sent between nodes
The link-state information is maintained on each router as a link-state database (LSDB) which is a tree-image of the entire network topology. Identical copies of the LSDB are periodically updated through flooding on all OSPF routers. Routing hierarchy
- unlike RIP, OSPF can operate with a hierarchy; OSPF works directly on top of IP not on top
of UDP - the largest entity within the hierarchy: - Autonomous System AS - OSPF is intra-AS routing protocol ( but is able to send/receive messages to/from other AS) - AS can be divided into areas (contiguous set of nets hosts and routers) connected by a
75
RS-Sem II RST
backbone (contiguous set of nets not contained in any area, their attached routers and routers belonging to multiple areas)
- each router has a database - the known topology of its area and summary of outside areas of the same AS - border router (BR) are used between areas - inter-area routing and intra-area routing
- each area runs an OSPF algorithm
- backbone network the same - designated router for multi-access networks (such a network may have more than one router) charged with generating LSAs for the entire multi-access network - OSPF : least cost route based on a user-configurable metric By convention, area 0 : represents the core or "backbone" region of an OSPF-enabled network and other OSPF area numbers may be designated to serve other regions of an enterprise (large, business) network - however every additional OSPF area must have a direct or virtual connection to the backbone OSPF area. The backbone area has the identifier 0.0.0.0. Inter-area routing goes via the backbone.
The identifications of other areas may be chosen at will; often, administrators select the IP address of a main router in an area as the area's identification. Each additional area must have a direct or virtual connection to the backbone OSPF area. Such connections are maintained by an interconnecting router, known as area border router (ABR). An ABR maintains separate link state databases for each area it serves and maintains summarized routes for all areas in the network.
76
RS-Sem II RST
Figure 45 OSPF Network- example
Stub area
A stub area is an area which does not receive route advertisements external to the (AS) and routing from within the area is based entirely on a default route.
Intra-Area Routers (IA) - situated entirely within an OSPF area; are called intra-area routers. - They flood router LSAs into the area to define the links they are attached to If they are elected Designated or Backup-designated routers (see Designated and Backup Designated Router), they also flood network links advertisements to define the identity of all routers attached to the network - maintain a topology database for the area in which they are situated. Area Border Routers (AB) - connect two or more areas - maintain topology databases for each area to which they are attached - and exchange link state information with other routers in those areas - AB routers also flood summary LSA into each area to inform them of inter-area routes. AS Boundary Routers - situated at the periphery of an OSPF internetwork - exchange reachability information with routers in other ASs using exterior gateway protocols (that is why they are called AS boundary routers) - Routers that import static routes or routes from other IGPs, such as RIP, into an OSPF network are also AS boundary routers - AS boundary routers are responsible for flooding AS external link state advertisements into all areas within the AS to inform them of external routes. Area ID: A 32-bit number identifying a particular area. The backbone has an area ID of zero. Router ID: A 32-bit number identifying a particular router. Each router within the AS has a single router ID. One possible implementation is to use the lowest numbered IP address belonging to a router as its router ID. Router Priority: An 8-bit unsigned integer, configurable on a per-interface basis indicating this router's priority in the selection of the (backup) designated router. A router priority of zero indicates that this router is ineligible to be the designated router.
Networks and connections supported
- point to point links; - multiple access broadcasting networks (e.g. LANs) - multiple access non- broadcasting networks (e.g. WANs)
Route computing
- cost criteria examples: inverse of bandwidth, delay, hop count, geographical distance, monetary cost, throughput, etc.
- several routes (to a dest) can be computed depending on cost criteria - network graph: - nodes (vertices) : routers, networks (transit or stubs) - edges between routers or between routers and subnetworks
77
RS-Sem II RST
o
SN 1 3 R1 SN2 3 R2 2 SN 3 R3 2 8 1 1 SN4 1 6 R6 1 SN 5 1 R5 R4 4 4 SN8 7 8 SN7 8
SN6
Figure 46 A sample of autonomous system (AS)
SN1 SN2
3 R1 3 R2 2 1
SN5 1 8 SN4 1 1 R3 8 6 R6 1 5 R4 4 7 4 SN8 R5 8 SN7 SN6
SN3
Figure 47 Directed graph of AS
SN subnetwork
R - Router
Destination Next hop Distance
SN1 R3 11
SN2 R3 11
SN3 R3 8
SN4 R3 7
SN5 R3 9
SN6 R5 15
SN7 R5 15
SN8 R6 4
Table 3-4 Example: routing table of the R6 router
- each router applies a Dijkstra shortest path algorithm to get the routes to each destination
Types of OSPF messages
Hello sent at regular intervals to establish and maintain neighbour relationship Hello packets are sent directly to neighbors on point-to-point links and non-broadcast networks. On LANs, hello packets are sent to a predefined group or multicast IP address that can be received by all routers. Neighbors who receive hellos from a router should reply with hello packets that include the identity of that originating router.
78
RS-Sem II RST
Database description describes the contents of the topological database, exchanged at initialisation Link state request requests pieces of neighbours topological data base (requested for
update)
Link state update response to link state request ; contains LSAs Link state ack- acknowledges link state update packets
LSA types
o o o o
Router links advertisement (RLA) collected states of R links to a specific area Network links advertisement (NLA) sent by designated Rs, describe all routers linked to the multi-access network and are flooded into the area containing the multi-access network Summary links Advertisements (SLA) - sent by area border routers, summarises routes to destination outside the area but within AS AS External links Advertisements describe a route to a dest external to the AS; are generated by AS boundary routers
LSAs are normally sent only under the following specific circumstances: When a router discovers a new neighbor When a link to a neighbor goes down When the cost of a link changes Basic refresh packets are sent every 30 minutes
boundary AS routers communicate via EGP or BGP additional OSPF features
- multipath routing (based on TOS requests) - more than one metric
- accepts variable length subnet mask
3.3.7
Border Gateway Protocol (BGP)
- preferred exterior routing protocol for INTERNET

- cannot use RIP for EGP: - different metrics in different AS
- there can be restrictions/priorities/policies w.r.t. some AS; RIP does not take into account these characteristics
- cannot use OSPF for EGP: - different metrics in different AS
- flooding inter AS is not manageable - lack of sufficient policy capabilities

key feature: path-vector routing
- path vector does not contains a cost - each block of routing info lists all AS-s to be transited up to the destination; - the source can introduce some selection/filtering policies
79
RS-Sem II RST
- eBGP, iBGP
BGP-4 messages
Open - open relationship with another router Update Keepalive Notification
(1) transmit info about a single router (2) lists multiple routes to be withdrawn (1) Ack to open (2) periodically confirm the neighbour relationship sent when an error condition is encountered
functional procedures
- neighbour acquisition because the border router (BR)s are in different AS-s the neighbour relationship must be agreed by both parts
- neighbour reachability- to maintain the relationship
- network reachability each BR maintains a database of the subnets that it can reach and preferred route to each SN. If a change is made the BR sends an Update message to other BRs and then flooding is done within BRs.
Update message information can be
- about a single route through Internet; the recipient must add this information to its database - list of routes previously advertised by this router that are being withdrawn
16 2 1 1
Marker Length Type Version
Marker Length Type 2 Unfeasible routes length var Withdrawn routes 2 Total path attributes length var Path attributes var Network layer reachability info Update message
Marker Length Type Keepalive message
1 1 var
Marker Length Type Error code Error subcode Data
My Autonomous System Hold time
Notification message Hold time minimum time between two successive messages (Update or Keep alive) Keep alive prevents Hold Time to expire
4 1 var
BGP ID Opt param. length Optional parameters Open message
Figure 48 Border Gateway Protocol message format

80
RS-Sem II RST
-marker- reserved for authentication -length- message length in octets - type open, etc.
Update message information can be
- about a single route through Internet; the recipient must add this information to its database - list of routes previously advertised by this router that are being withdrawn
3.4 IPv6
- Ipv6 IPNG Internet Protocol Next Generation
- RFC 1883 (year 1995), 1809, 1884, 1886, 1887

reasons to develop a new IP specification
- IPv4 limited by - 32 bit address too small for large networks - two level structure( network, host) is wasteful - increase in routing table dimension of EG routers - need of multiple address per host - not sufficient security support - not sufficient multicast support
IPv6 features
- extension of addresses (128 bits) - improved option mechanism separate optional headers located in IP-H and transport-H; most of these are not examined by routers simplifies and speeds up router processing - address autoconfiguration dynamic assignment of addresses - increased addressing flexibility ( anycast addresses, scalability of multicast routing improved) - support for resource allocation - increased security ( authentication and privacy)
IPv6 Header (basic)
Extension header
...
Extension header
Transport level PDU
40 octets
0 or more
Figure 49 General IPv6 datagram format
81
RS-Sem II RST
IPv6 datagram format Ipv6-Header the only mandatory header ( 40 octets)
- version the value is 6 - priority priority value of DGs - flow label packet labeling for special handling - payload length rest of IP-DG in octets - next header identifies the next extension header - hop limit the remaining number of allowable hops for this packet; packet is discard if hop limit reach zero - source and destination addresses
Ipv6-Extension Headers
- Hop-by-Hop Options Header - special options that require hop-by hop processing
- Routing Header - extended routing similar to IPv4 source routing - Authentication Header packet integrity and authentication - Encapsulating Security Payload Header provides privacy
- Destination Options Header optional info to be examined by the destination node
Length (octets) (40) IPv6 H (40) (var) Hop-by-hop Options H (var) Routing Header (8) Fragment Header (var) Authentication Header Encapsulation security Payload H Destination Options H TCP Header Application Data (var) (var) (20)- opt var. part (var) Next header field IPv6 Header: Version (4 bits) Priority (4) Flow label (24) Payload length (16) Next Header (8) Hop limit(8) Source address ( 128) Destination address ( 128)
4 octets
4 octets
32 octets
Figure 50 IPv6 datagram extension headers
Priority field
- enables the source to identify the desired transmit and delivery priority of each packet (relative to others of the same source)
82
RS-Sem II RST
- traffic categories
- congestion controlled the source backs off in response to congestion status of network
- non-congestion controlled constant data rate and constant
delivery delay are desirable ( real time video, audio, voice) - have higher priority than congestion controlled traffic
- congestion controlled (decreasing priorities) : internet control traffic, interactive traffic, attended bulk transfer (e.g. FTP, HTTP), unattended data transfer (e.g. e-mail), filler traffic, uncharacterised traffic - non-congestion controlled traffic
-low fidelity audio ( e.g. voice) has highest priority (loss of some packets is apparent as clicks and buzzes on the lines) - high fidelity video ( the other end of the range) lowest priority
Flow label
- source can label all packets of one flow ( e.g. one TCP connection) with the same flow label - source point of view: all packets of a flow have similar transfer requirements - router point of view : similar treatment of the packets of a flow : (path, resource allocation, discard requirements, accounting, security, etc.) - if router does not know to treat flow label then set the field to zero
- flow label reduces the processing amount in routers
- options of a flow in extension headers significant processing overhead for each packet - solution- flow label passed through a hashing function addresses a look-up table containing processing info - this table is initially filled up by first flow label and optional fields of the packet)
IPv6 addresses
- assigned to interfaces not to node itself - IPv4 addresses does not have a structure to assist routing routers can have huge tables to maintain routing paths - longer Internet addresses allow for aggregating addresses by hierarchies of networks, access providers, corporation, etc.
- address types
- unicast address for a single interface ( provider-based global,

83
RS-Sem II RST
link-local, site-local, embedded Ipv4, loopback) - anycast addresses ID for a set of I/Fs belonging to different nodes; the IP-Dg is delivered to one only ( the nearest one according to a distance criterion) - multicast ID for a set of I/Fs belonging to different nodes; the IP-Dg is delivered to all IF/s
- address autoconfiguration
- IPv4 users or managers must manually configure IPv4 addresses on nodes ( error prone activity) - IPv6 allows autoconfiguration enabling a host to configure automatically one or more addresses per interface - allow plug and play capability (a host attaches to a network and the IPv6 addresses are automatically assigned to its interfaces)
- address models: local scope, stateless server, stateful server
Hop-by-hop Option Header - carries info which is processed by
every router on the path
Fragment Header
- fragmentation can be performed only at the source nodes - a node must discover the maximum transmission unit (MTU) supported by any network on the path - the source can fragment differently for different addresses - fields: fragment offset, more-bit, identification (original packet)
Routing Header (if source routing is desired)
- contains a list of one or more intermediate nodes to be visited by the packet on the way to destination - fields: next-header-field, routing-type, routing-specific-data - if a router does not recognise the routing-type value then it discards the packet
3.5 ICMPv6
-new version of ICMP (RFC 1885) compliant to IPv6
- key features
- new protocol number different from ICMPv4 - both protocols use the same header format
84
RS-Sem II RST
- some little used messages of ICMPv4 omitted in ICMPv6 - maximum size of ICMPv6 is larger as to exploit the larger - packet size that IPv6 permits without fragmentation
85
RS-Sem II RST 4 IPQOS TECHNOLOGIES
4.1 Introduction
The concept of Quality of Service (QoS):
- a way of prioritizing certain types of network traffic.

Why QoS control?
Applications are sensitive to delay, jitter and packet loss
Components: o non-adjustable (e.g. propagation delay, switching delay, CRC errors) o adjustable associated with link congestion (buffering delay and packet loss) Some congestion is likely in most networks Over-provisioning is NOT the solution:
Traditional Internet
Best effort data delivery
Complexity in the end-hosts Network core simple routers Increasing demands exceeding capacity of service degrades gracefully (increased jitter, etc.) Delivery delays : problems to real-time applications Provide better predictability and control beyond the current IP best-effort service several levels of guarantees)
Basic principle IP-QoS Technologies goals
keep the network core simple while allowing complexity at the edges
Performance attributes (generic QoS parameters- seen at network level)

Delay/latency Delay variation (jitter) Degree of throughput/bandwidth assurance ( note that the bandwidth itself is not a QoS criterion) Packet loss rate Service availability o Mean Time Between Failures (MTBF) o Mean Time to Restoration of Service (MTRS)
Service Level Agreement (SLA)
Between customer-provider Specifies various levels of performance and guarantees
4.2 Applications
86
RS-Sem II RST
4.2.1 Figure 51 4.2.2 classes Application
Two main applications classes (from TC/QoS point of view)

Elastic (opportunistic) applications
Try to consume the available if resources wait without being severely affected if resources are not temporarily available Examples: www , email, ftp, news, ... Streaming applications a minimum amount of resources is needed for each streaming application to work at acceptable level
4.2.2.1 Elastic applications
Elastic applications examples Requestresponse client server, NFS, RPC, distributed computing, ... Interactive, reliable short www transactions, telnet, database access, ftpcontrol, Xwindow, Batch ftp, remote backup, long http transactions, news transfers, ...
4.2.2.2 Examples Streaming applications
Conversational multimedia applications voice over IP (VoIP), or videconference over IP Interactive multimedia applications distributed simulations, network games Noninteractive multimedia applications (continuous flow of multimedia information) distance learning, audio/video broadcasts, news on demand, ...
4.2.3
Traffic Description
To design, control & manage a network, we should know traffic: Traffic modelling tries to capture the (statistic) characteristics / pattern of traffic and to model it (mathematically). - Source/transient, individual/aggregate, regular/random
- Peak rate, mean rate, burst length, distribution of
Well-known traffic models: - Poisson for telephone call arrivals; - On-Off for bursty traffic in B-ISDN (e.g., voice);
87
RS-Sem II RST
- Self-similar for Ethernet / Internet traffic; - Bounded model: deterministic/statistical bound. Granularity/Difficulties: it is difficult to model precisely the traffic in multimedia networks due to its varieties and dynamics.
4.2.3.1
Traffic descriptors - traffic descriptors overall set of traffic parameters - traffic parameter- describes a particular qualitative or quantitative aspect of the traffic
Requirements for traffic descriptors: - usable by the network to compute the necessary resources, - comprehensible for the source- to determine if itself is conformant with the traffic contract and required QoS - network verify if the source violates the previously declared value of the parameter
Verification of the traffic parameters - complex task :

- complexity of the definition itself - Usage Parameter Control function receives a modified version of the source traffic
Traffic / QoS Parameters of Bearer Service among IP Routers
Traffic parameters Peak Data Rate (PDR)
Average Data Rate, Sustainable Data Rate with burst tolerance Minimum Data Rate Frame rate with max. frame size
QoS Parameters
End-to-end transfer Delay Delay variance (Jitter) tolerance Bit/Packet/Frame loss ratio
4.3 Architectural Framework for QoS in IP networks

Ongoing standardization : IETF, ITU-T SG 13 ( Y.qosar) , ETSI, IEEE Identify a set of generic QoS network mechanisms the network mechanisms will be used in combination to collectively deliver satisfactory service performance.
88
RS-Sem II RST
Different services (or applications), however, may have quite different needs.
Architectural Planes (see the previous chapter) Mechanisms dealing with: Control plane - pathways for user data traffic: Admission control, QoS routing, and resource reservation. Data plane- transport of user data traffic directly: traffic classification, packet marking, traffic policing, traffic shaping, buffer management, congestion avoidance, queuing and scheduling Management plane- the operation, administration, and management aspects of the user data traffic: metering, policy, service level agreement (SLA), and service restoration.
Figure 52 QoS functional building blocks (ITU-T)
QoS building block may be specific - to a network node (e.g. buffer management)
89
RS-Sem II RST
- applicable to a network segment (e.g. QoS routing) The latter, in particular, requires signaling between network nodes: end to end, end to edge, edge to edge, or network to network.
Signaling can take place in any of the three logical planes
For CPl or MPlane, signaling -> use of a signaling protocol. For DPL- inband signalling is used.
4.3.1 IP Services Best Effort (BE)
Classical internet (TCP/IP stack) Characteristics - lowest complexity, lowest service differentiation (and level of guarantees), best scalability fairness between different flows is an objective behaviour of applications/transport protocols can influence the obtained QoS - no priorities of some flows, no service guarantees o the network should do its best to carry packets towards their destination without any guarantee o BE QoS highly depend on current network load o possible network load control by:
utilisation of traffic engineering tools routing policies for interdomain traffic utilisation of scheduling mechanisms utilisation of buffer acceptance mechanisms
Degree of service differentiation IntServ

Per class QoS processing Per flow: QoS processing
DiffServ Complexity Best Effort

No QoS processing
Scalability
Figure 53 IP Services
Differentiated Services (DiffServ) QoS Technology

90
Characteristics:
RS-Sem II RST
Differential treatment of packets based on some marking of them No distinction between flows inside the core netwwork Medium scalability Medium level of differentiation between services Medium complexity Diffserv: -
treates a packet based on its class of service as encoded in its IP header the SP establishes with each user a SLA/SLS ( specifies how much traffic a user may send within any given class of service the traffic is then policed at the border of the service providers network Once the traffic enters the network, routers provide it with differentiated treatment (In contrast to the IntServ approach, the treatment is based not on a perflow basis, but solely on the indicated class of service) the overall network is set up to meet all SLAs.
The building blocks relevant to DiffServ: packet marking buffer management, SLA traffic metering and recording, policing, shaping, scheduling. The relevant building blocks for MPLS: buffer management, packet marking, QoS routing, queuing, resource reservation, traffic classification, and traffic shaping. Diffserv advantages Simple implementable mechanisms Good scalability Can cooperate with L2 technologies Preserve classic concepts of TCP/IP ( complexity at the network edge only) Maintain stateless routers Extendable to multicast No out-of band signalling Diffserv problems/drawbacks No reservation Diffserv is not a complete QoS technology, but only a set of relative prioritisation mechanisms o To become a full QoS technology a resource (domain) manager and AC function is needed Rough granularity Integrated Services ( IntServ )Technology
Characteristics:
Basic idea: Differential treatment of different micro-flows

91
RS-Sem II RST
Reservation based Fine granularity distinction between flows inside the core netwwork Low scalability High level of differentiation between services and hard guarantees possible High complexity Intserv: - Support of real-time delay-sensitive applications - a flow serviced at a rate slightly higher than its data rate has a bounded delay - the network can guarantee the delay bound of a flow by per-flow resource reservation Phases: - application before sending data, first signals to the network the desired service request (traffic profile, bandwidth and delay requirements) - The network then determines whether it can allocate adequate resources (e.g., bandwidth or buffer space) to deliver the desired performance of the service request - Only after the request is granted can the application start to send data As long as the application honors its traffic profile, the network meets its service commitment by maintaining per-flow state and using advanced queuing disciplines (e.g.,WFQ) for link sharing. Building blocks relevant to the IntServ: - admission control (AC) - queuing - resource reservation (RR) ( RR protocol - RSVP) traffic classification and traffic policing. Intserv advantages Can offer E2E guarantees (e.g. bandwidth, ) per flow - emulate the telecom channel ( but not fixed allocation) Can cooperate with L2 technologies Preserve classic concepts of TCP/IP ( complexity at the network edge only) Extendable to multicast Dynamic- the reservation follows the routes if the latter are cahanged Follows the route changes Diffserv problems/drawbacks Complex implementable mechanisms It is a complete E2E QoS technology, Fine granularity (per-flow) Need statefull routers Low scalability ( statefull routers- per flow image stored, Reservation refresh needed Combined technologies: Integrated Services ( IntServ )T + Diffserv
4.3.2
Data Plane Mechanisms

92
RS-Sem II RST
4.3.2.1 Traffic Classification (TCl)
Traffic classification can be done at the flow or packet level At network edge : - the entity responsible for TCl typically looks at multi-fields (i.e., a combination of header fields, including: src_addr, dst_addr, src_port, dst_port, protocol number, and DSCP code point) of a packet - determines the aggregate to which the packet belongs and the associated SLS - according to the SLS, classifiers steer packets to an appropriate traffic conditioning element for further processing. 4.3.2.2 Packet Marking
Packets are marked according to specific service classes they will receive in the network on a per-packet basis. Typically performed by an edge node: assigning a value to a designated header field of a packet in a standard way Examples: - Type of Service byte (ToS) - in the IP header - EXP bits ( 3 bit field used to tag packets) of the MPLS shim header) is used to codify externally observable behaviors of routers in the DiffServ or MPLS-DiffServ. Marking can be done by a host/source: it should be checked and may be changed (either promoted or demoted) by an edge node according to SLAs or local policies. Sometimes, special values may be used to mark non-conformant packets, which may be dropped later due to congestion. 4.3.2.3 Traffic policing (TP) TP verifies the conformance of the input traffic to the contract The user has a QoS contract with the network the network must police all input traffic to detect contract violation = policy function Action taken by policy function: - conforming traffic pass - nonconforming traffic: allow traffic emntering into the network with reduced priority or, drop Policing parameters: - peak rate ( for policers verifying peak rate, e.g. for CBR flows ) - peak rate, average rate, burst size ( for policers verifying VBR flows conformance) Policing algorithms: - Leaky Bucket (LB) - Token Bucket (TB
LB measures the peak rate rate of the traffic entering a node. Any excessive packets is declared nonconformant (will be marked or discarded by the policy function) Two main parameters: - data bucket size (usually smal value) transmission rate
93
RS-Sem II RST
4.3.2.4 Traffic Shaping (TS) TS controls the rate and volume of traffic entering the network Entity responsible for TS buffers nonconformant packets until it brings the respective aggregate in compliance with the traffic The resulted traffic thus is not as bursty as the original and is more predictable Shaping often needs to be performed between the egress and ingress nodes Two key methods/algorithms for traffic shaping: - Leaky Bucket (LB) - Token Bucket (TB LB and TB are used now as shaping algorithms
4.3.2.5
Buffer (Queue) Management (QM)
QM decides which packets, awaiting transmission, to store or drop. Important goals: - minimize the steady-state queue size - while not underutilizing links - preventing a single flow from monopolizing the queue space. QM schemes differ mainly in the criteria for dropping packets and what packets (e.g., the front or tail of the queue) to drop. The use of multiple queues introduces further variation
Note: for example, in the way packets are distributed among the queues.
Common criterion for dropping packets: - reaching a queues maximum size (tends to keep the queue in the full state for a relatively long period of time, which can cause severe network congestion in case of bursty traffic. This explains why queue management is often associated with congestion control. - Active QM more dynamic criterion : Random Early Detection (RED) [9] Note: RED drops incoming packets probabilistically based on an estimated average queue size. 4.3.2.6 Queuing and Scheduling Q&S
Q&S: selection of packets for transmission on an outgoing link FIFO: all packets are treated equally, and a sender can obtain more than a fair share of network bandwidth by simply transmitting packets excessively Need for some other more flexible and fair treatment of packets Fair queuing (FQ): Packets are classified into flows and assigned to queues dedicated to respective flows. Queues are then serviced round-robin. FQ is also called per-flow or flow-based queuing.
94
RS-Sem II RST
Priority queuing: Packets are classified and put into different priority queues, then scheduled from the head of a given queue only if all queues of higher priority are empty. Weighted fair queuing: Packets are classified into flows and assigned to queues dedicated to respective flows. A queue is assigned a percentage of output bandwidth according to the bandwidth need of the corresponding flow. By distinguishing variable-length packets, this approach also prevents flows with larger packets from being allocated more bandwidth than those with smaller packets Class-based queuing: Packets are classified into various service classes and then assigned to queues dedicated to the respective service classes. Each queue can be assigned a different percentage of the output bandwidth and is serviced round-robin.
4.3.2.7
Congestion Avoidance (CA)
CA keeps the load of the network under its capacity so that it can operate at an acceptable performance level. Traditionally, CA require that the sender reduce the amount of traffic entering the network when network congestion occurs (or is about to occur) Avoiding the potential for excessive delays due to retransmissions after packet losses: explicit congestion notification (ECN) schemes ( e.g. IETF RFC 3168 - ECN scheme for IP and TCP) (Note 2)
4.3.3
Control Plane Admission Control (AC)
4.3.3.1
It controls the traffic to be admitted into the network, (newly admitted traffic should not overload network or degrade the service to existing traffic Normally admission control is policy driven [3]. Policies: set of rules for administering, managing, and controlling access to network resources can be specific to the needs of the SP or reflect the agreement between the customer and SP (may include reliability and availability requirements over a period of time and other QoS requirements).
- AC decision also depend on adequate network resources available to meet the perf. objectives of a particular service request. - two common approaches: - parameter-based: derives the worst case bounds for a set of metrics (e.g., packet loss, delay, and jitter) from traffic parameters appropriate for providing hard QoS for real-time services often used in conjunction with resource reservation in order to effect the guaranteed bounds measurement-based: uses measurements of existing traffic for making an admission decision does not guarantee throughput or hard bounds on certain metrics appropriate for providing soft or relative QoS generally has higher network resource utilization than the parameter based one.
95
RS-Sem II RST
4.3.3.2 See Chapter 1 QoS signaling : - convey application (or network) performance requirements reserve network resources across the network discover QoS routes. QoS signaling : in band or out of band. In band Out of band Path-coupled Path-decoupled QoS Signalling
4.3.3.3
QoS Routing
Selection of a path satisfying the QoS requirements of a flow The path selected most likely is not the traditional shortest path Depending on the specifics and the no. of QoS metrics involved, computation required for path selection can become prohibitively expensive as the network size grows. Practical QoS routing schemes consider mainly cases for: - a single QoS metric (e.g., bandwidth or delay) or, for dual QoS metrics (e.g., cost-delay, cost-bandwidth, and bandwidthdelay). Routing strategies to reduce the complexity of path computation exist. - criteria of classification: how the state information is maintained how the search of feasible paths is carried out Strategies: source routing, distributed routing, and hierarchical routing [4]
Generalization of QoS routing: constraint- based routing
4.3.3.4
Resource Reservation (RR)
Sets aside required network resources on demand for delivering desired network performance Reservation request is granted/rejected by AC mechanism All the considerations for admission control therefore apply General, necessary condition for granting a reservation request is that the network has sufficient resources. The exact nature of a resource reservation depends on: - on network performance requirements - the specific network approach to satisfying them
96
RS-Sem II RST
Example: IntServ - simplex flows - characterized in terms of parameters describing a token bucket - and receiver-initiated reservations are done on demand according to peak rate requirements to guarantee delay bounds. Important for SPs: to be able to charge for the use of reserved resources RR needs support for authentication, authorization, and accounting and settlement between different SPs RR typically supported by special protocol (e.g. RSVP [ ]) To date, however, no existing RR protocol is regarded suitable for large-scale deployment IETF effort for an improved RR protocol
4.4 Basic IP QoS and Traffic Control Mechanisms- Data Plane

4.4.1 4.4.1.1 QoS Guarantees (I) Types of guarantees
4.4.1.1.1 Bandwidth Guarantees _ Best effort (BE - no guaranteed bandwidth)) - applied in classical Internet, suitable for non-critical, elastic applications Maximum guaranteed bandwidth for a flow - peak bandwidth required by the flow is reserved - no more bandwidth than this maximum is allowed for the traffic flow - used in CBR, non-adaptive streaming applications Minimum guaranteed bandwidth for a flow - at any time a minimum guaranteed bandwidth is offered to the flow - maybe more in some interval of time - flow may use more bandwidth if network is not congested - used for for critical elastic applications and adaptive streaming applications 4.4.1.1.2 Other guarantees maximum delay, delay jitter, packet loss - different cases, usually associated to the bandwidth guarantee level Maximum delay and delay jitter guarantees
BE flow : no guarantee for delay or delay jitter
Maximum guaranteed bandwidth - flow maximum delay guarantee

- e.g. VoIP, interactive voice communications
Minimum guaranteed bandwidth - flow maximum delay guarantee - e.g. adaptive streaming applications - delay jitter - not relevant ( if kept in given limits)
97
RS-Sem II RST
4.4.1.2 Level of guarantees the required levels of QoS guarantees depends on the category of end-users and on the price they are willing to pay for in order to get a certain level of QoS guarantees end users have different requirements for the topological scope of their SLS and will behave differently from the point of virew invocation of services. A range of guarantees levels and associated service options are: Statistical Qualitative Guarantees: globally aims at providing better then BE based services, but does not provide any strong guarantees (qualitative E2E QoS performance: delay, jitter, loss; no bandwidth guarantee, usually any reachable destination is allowed) Statistical Guarantees: statistical QoS performance guarantees for specific destinations, some loose end-to-end bandwidth guarantees, while restricted to some specific destinations. Hard Guarantees: quantitative end-to-end QoS guarantees, bandwidth guarantee, specific dstinations. -
- The problem of co-existence of several levels of guarantees in one AS should be solved - In inter-domain case an additional problem appears if the chaining ASs offer different types of guarantees.
4.4.2
Classical Routers, Qos Capable Routers

IPRouting Routing protocol messages (logical view) Routing Protocol Routing protocol messages (logical view)
Routing Table IP
I/F Packets
. .
Forwarding Table
Packet processing
I/F
Figure 54 Block diagram of a Classical IP Router

Placement of the function in a router: - input - output
98
RS-Sem II RST
Figure 55 QoS capable router generic diagram
In practice, the shaper could also be located on the output link, but we dont address this issue here to keep the picture simple and understandable.
4.4.3
IP Level services 4.4.3.1 Besteffort (BE) service
Simple BE router functions (data plane functions - for M input ports and one output)) - accepts packets from M ports - store them in a single output queue - extract in FIFO order No guarantees of bandwidth, delay etc but fairness is required 4.4.3.1.1 Fairness problem
What means fairness at network level - maximise the amount of bandwidth seen by the users - but also want to maximize utilization of network resources Max-min fairness principle Fairness definition for networks
each users throughput is at least as large as that of all other users which have the same bottleneck
Property: - a max-min fair allocation : each source get such a bandwidth (throughput) value so that in order to further increase the bandwidth allocated to one source, it would be necessary to decrease the bandwidth allocated to another source which already received an allocation
99
RS-Sem II RST
4.4.3.2 Buffer (queue) management
4.4.3.2.1 Tail drop - packet arriving in a full buffer are discarded - Advantages: easy to implement, can limit the number of packet losses for large buffer - Disadvantages: no distinction between flows- not the best solution for TCP traffic 4.4.3.2.2 Random Early Detection
Objectives - Simple implementations in routers with a single logical queue - provide nonzero buffer fill in order to assure link efficiency
- provide average buffer fill (to offer low delay for r.t or interactive applications and ensure fast TCP response) - approximate a fair discard of packets among the active flows without identifying them - TCP friendliness when dropping packets (avoid discarding bursts which determines severe reduction of TCP windows when burst loss appears) RED principle - congestion detected by measuring the average buffer fill ( lowpass filter is needed) and compare it with a (configurable) threshold Th( frequently 1-20% of buffer dimension) - above Th value the buffer is considered congested and the incoming probabilistically dropped ( increasing probability with congestion level) - drop will determine TCP sources to slow down - probabilistic drop for fairness, that is to avoid dropping burst of packets from single flow - drop packets for each flow- proportional to network usage, in different moments to avoid the effects of TCP sources synchronization Basic RED scheme packets begin to be
- suitable for routers with a single queue
Pd 1
Pmax Avg min_th

accept Probabilistic drop Drop Min_th Max_th Buf_Size
Max_th
Drop all
100
RS-Sem II RST Figure 56 RED- basic algorithm

Avg = average fill of the buffer Pd = probability of discard
Packet arrival : Compute(avg); if (avg < min_th) then { /*no congestion, accept packet*/} else if (min_th avg < Max_th ) then {/* near congestion, probabilistic drop*/} Compute_prob(Pd); Discard_packet_with_probability(Pd);} else if (Max_th avg) then {discard packet;} RED problems - RED advantages: a better network utilization, a lower queuing delay - RED disadvantages: complexity of tuning RED ( min_th, Max_th, Pmax, etc.) - Dependence on link speed, type of traffic, ..? - Problems with chain of routers with different settings (a bad choice of the RED parameters may provide a worse performance than taildrop) RED with two levels of packet priorities high and low priority packets (High and Low) drop earlier low-priority packets
- define a threshold Th Arrival of packet: if (Pack.Type = H) then { /* high priority packet*/ if (Buf.Fill < Buf.Size) then accept_pack();} else discard_pack();} else {/* low priority */ if (Buf.Fill < Buf.Th) then accept_pack(); else discard_pack();}
H+L
Th Buf_Size
Figure 57 RED buffer with two level of priorities

101
RS-Sem II RST
4.4.3.2.3
Weighted RED
WRED is an extension of RED to support several N packet discard preferences Principle : - N RED algorithms run in parallel - the first one decides the acceptance of priority N packets that should only be discarded in case of severe congestion - the second one decides the acceptance of priority N1 packets that should be discarded earlier than high priority packets and so on, - the Nth RED algorithm decides the acceptance of packets with no priority Two priorities WRED - several variants are possible
Variant 1 - two priorities High (H) and Low (L) - compute two separate averages for buffer fill: avg(H) and avg(H+L) - apply conservative RED for H packets (large thresholds) - apply aggressive RED for L packets (small thresholds)
Pd 1 Pmax(L) avg(L+H) min_th(L) Max_th(L) The average buffer fill is computed for all packets ( H and L) 1 Pmax(H)
Pd
Avg(H) min_th(H) Max_th(H)
The average buffer fill is computed for packets H only
Figure 58 Variant 1 of WRED diagrams of dropping the packets

4.4.3.3 Maximum bandwidth service - want to guarantee a maximum bandwidth for a flow of packets - a required amount of bandwidth is reserved for the flow - the flow is not allowed send faster than its maximum bandwidth How to implement? - have to identify the applications flows by classification - provide bandwidth guarantees by measuring the rate of an input flow
102
RS-Sem II RST
4.4.3.4 limiting rate of incoming flows to the value agreed (special mechanisms needed e.g. Token Bucket (TB) mechanisms for measuring and shaping) marking appropriately the flows in order to be recognized (ToS, MPLS, etc.) assuring that an output link of a router is offering sufficient bandwidth for the incoming flows (provided that the incoming individual rates are limited) Minimum bandwidth service Identification of guaranteed packets Probabilistic or deterministic marking TB measuring algorithms (two colors, three colors) Packet discarding, RED want to guarantee a minimum bandwidth only for a flow of packets
How to implement? - suppose that one want to guarantee a minimum bandwidth for one flow Problem: within this flow, there exist: - packets that are part of the minimum guaranteed bandwidth (they cannot be discarded inside the router) - excess packets ( above the minimum guaranteed bandwidth) they will be treated in BE way (dropped if necessary to preserve the guarantees) Principle of solution: - identify the two types of packets - discard if necessary the excess packets (if congestion occurs inside a router) Identification of the guaranteed packets - measure the incoming flow rate - identify the packets belonging to minimum bandwidth part of the flow - identify the packets in excess of the min. bandwidth - the packets may be explicitly or internally marked - in deterministic mode or probabilistic mode
Input flows Classifier
Policing Meter and Marker
Buffer acceptance algorithm
Output buffer
Identified flows
Identified guaranteed or excess packets
Dropped packets
103
RS-Sem II RST Figure 59 Identifying the guaranteed and excess (above a minimum bandwidth value) packets
a measuring scheme exist ( e.g. Token Bucket algorithm) which measure the average flow rate mark the packets as conformant or non-conformant
Deterministic marking o each time when a packet arrives, the average rate is computed; if found greater than the minimum rate then the corresponding packet is marked as non-conformant (excess) - see later the TB algorithm- used for this case o The deterministic marker can be extended to support more types of packets than only guaranteed and in excess packets, e.g.: Single rate three color marker Two rates three colors marker o Characteristics of deterministic marking: simple implementation supported by mathematical models similar mechanisms are used in other technologies not the best solution for TCP ( the TCP traffic may be more bursty than accepted by TB)
Probabilistic marking : o mark the excess packets in a probabilistic way that is proportionally to the excess amount w.r.t minimum rate o Characteristics: - approximately mark packets in function of rate - adapted to TCP behavior o - difficult to find mathematical models to prove its bounds The probabilistic marker can also be extended to support more types of packets than only guaranteed and in excess packets.
Example of Probabilistic marking algorithm:
if (Ravg Rmin) then { /* packet is guaranteed */ } else { Pdrop= (Ravg Rmin)/ Ravg ; /*mark with Pdrop probability packet the packet as being in excess */}
References
[ ] Fang et al., A Time sliding window three color marker (TSWTCM), Internet draft draftfangdiffservtctswtcm00.txt, October 1999 [ ] Clark and Fang, Explicit Allocation of Best Effort packet delivery service, IEEE/ACM transactions on networking, August 1998, vol 6, N 4,pp.362373
4.4.4
Packet Classification and Marking - similar treatment of a subset of packets classification of input packets into flows
Why need classification of packets?
104
RS-Sem II RST
Flow : sequence of packets with one common "characteristic" - based on any field of the packets LayerN flow - sequence of packets with one common layerN characteristic Life time of flows limited
Classifier: identify a flow of packets to which an arriving packet belongs - classification function placed at the input ports of a router - identification may be a complex operation- depending on the complexity of classification criterion - store the classification information internally (to be used by other functional blocks of the router) Where to perform classification in the network ( in some routers, in all routers) ? - Classification on each core router of an AS - expensive - Alternative solution: - execute classification at the ingress of the network - explicitly mark the classified packets - advantage: the intermediate core classifying action for each packet) routers recognize the marking (no need of a new
4.4.4.1
Packet Flows defined at different layers L2 flows - ATM or FR virtual circuits L3 - flow - IP related L4 flow- TCP or UDP related L7 flow - application level flow
4.4.4.1.1
Layer 3 Flows
Identification of L3 flows: - src_addr, dst_addr with or without associated netmasks (e.g. all traffic from 141.85.0.0/16 - all IP traffic with same route or BGP next hop (recognizing such a flow requires a route table lookup by the classifier)
4.4.4.1.2
Layer 4 Flows
Usually identified by : (source_IP_address, destination_IP_address, Protocol, source_port, destination_port)
4.4.4.1.3
Upper layer Flows
How to identify a specific application flow? Cases: a. if the application uses a standard well known port number - then identify the application by examining port number
105
RS-Sem II RST
Examples: Application Transport protocol Port number
DHCPBootp UDP DNS HTTP IMAP LDAP MSSQL NFS NNTP POP SMTP SNMP SSH Syslog Telnet X Windows TCP/UDP TCP TCP/UDP TCP/UDP TCP TCP/UDP TCP/UDP TCP/UDP TCP TCP/UDP TCP UDP TCP TCP
67, 68 53 80 143, 220 389 1433 2049 119 109/110 25 161, 162 22 14 23 60006003
b. if applications do not use wellknown port numbers - then analyse the contents of control packets for these applications Examples FTP: server and client may negotiate other nondefault port numbers than 20/21 for some file transfers RTP (RFC1890): can use any even port number, RTCP uses an odd port number (frequently the UDP ports 50045005 are used, but this is not mandatory) Additional problems in identifying the application flows
- can exist applications not enough known to be easily identified - usage of security related tunnels (encrypted tunnels e.g. IPSEC, L2TP, PPTP) will produce hiding of TCP and UDP headers to intermediate routers What layer is more appropriate for classification? No general solution yet, no consensus
106
RS-Sem II RST
4.4.4.2 IP Packet Marking
Using Type of Service octet in IP header
Simple method: Use one field of the IP header- ToS : Type of Service Octet, easy to implement, number of possible marked flows limited by the field length ToS defines the relative importance of the IP packet and the type of service required for this packet Current status - definition of ToS Octet changed several times - precedence is used in some networks - not used in other ToS field is rarely used
0 Precedence
3 Type of Service
7 0
Relative priority
1000 minimize delay 0100 maximize throughput 0010 maximize reliability 0001 minimize monetary cost 0000 normal service
Figure 60 Using ToS octet for packet marking at IP level
Multiprotocol Label Switching (MPLS) Packet Marking
Insert a new header containing a label, in front of the IP packet Principle: - edge routers perform classification of packets and add one 32 bits MPLS header in front of each IP packet from each flow - core routers use label swapping to forward the IP packets Label swapping: on packet arrival, router analyses Packet Label, Input Port and based on label forwarding table , router decides Output Port and Packet Label for outgoing packet This way one can build MLS tunnels having some QoS related properties
Use of QoS capable L2 protocols - L3 flows mapped on different layer 2 flows
- QoS will be provided by layer 2
107
RS-Sem II RST
4.4.5
Policing and Shaping Why policing and shaping?
One goal of QoS based services is to provide bandwidth guarantees In order to be able to do this the amount of input traffic in the network should be controlled ( measured, and limited by dropping, marking and dropping or shaping ) Functional blocks needed: Traffic Policing o Verifies by measuring whether the incoming flow follows obey some limits (are conformant) established previously by a traffic contract and proceed accordingly if not ( drop, mark, change priority, etc.) o does not modify the traffic characteristics
Input traffic
TP Non-conforming packets Conforming packets
Figure 61 Traffic policing (TP) function Typical policing paramters - Peak Rate ( PR), Average Rate (AR), Burst Size (BS),
- one policer may use one or several parameters, dpending on the type of traffic contract Traffic Shaping - method to limit the input traffic rate by delaying the packets whose parameters are not conformant with some limits
4.4.5.1
Measuring the Rate of Incoming Flows
To provide bandwidth guarantees in a router one must : - assure enough capacity on the output :
Rk < Rout
where Rk is the mean rate on a input k and Rout is the capacity of an output port - assure enough memory buffers in the router This means: - control and ensure that the output link will not be a bottleneck (for a given output throughput one must limit the rate of incoming flows) - ensure that the buffers of the router will not overflow (must limit the amount of buffer consumed by the flows on the input links)
Problem: defining the flow rate for a traffic contract

108
RS-Sem II RST
- variable length packets no_of_packets/time_unit is relevant only if accompanied by information of packet length - no_of_packets/time_unit is more accurate - need to specify the time_unit used - packet flows are not fluid flows- more complex treatment is necessary Method of limiting the input rate: - measure the input rate and discard the non-conforming packets
4.4.5.1.1 General Measuring Algorithms of Flow Rate Jumping window rate measuring algorithm - time divided in fixed windows of length T (timer expires each T) - Mean rate limit of the traffic contract is defined as Rm =B/ T [bytes/s] Algorithm Initially: credit=B;
/*credit represent the amount of bytes allowed to enter until the end of T*/ Every T [sec] do {if credit > 0 then credit = B;/* the previous unused credit is lost*/ else credit = credit + B; }
Arrival of Packet P of length L:
If credit-L > -l /it may be allowed a certain amountof debt within a T interval*/ then { /* accept the packet*/ credit = credit L;} else{ /*discard the packet*/}
Drawbacks Traffic anvelope: A(t) = 2B + t/T*B - total amount of bytes accepted by the algorithm in a time interval [0, t) only limits the mean value of rate at Rm=B/T, but no instantaneous rate possible fast increase of the amount of traffic with 2B octetes
- start instant of the first T may influence over which packets are accepted
Sliding window rate measuring algorithm (1) - at arrival of the packet, the rate R is computed taking into account the last time window of W [sec] before the instant when a packet arrives R= (no_bytes_rec_in_last_W)/W
109
RS-Sem II RST
Time window W t1 New arrival Older packet arrivals t1
Figure 62 Sliding window algorithm for measuring the rate of the input flow
Packet of length L arrives at t instant:
a=compute_amount_accepted_bytes [t-W, t] if (a+L)<=N { store_instant_and_length[t,L]; /* accept packet */ } else { /* discard packet */}
Problem difficult implementation (necessary to remember all [t, L] peers )
Sliding window rate measuring algorithm (2) - avoid remembering all packet arrival instants - estimate average rate assume that flow was fluid - on packet arrival, and sending at estimated average rate during the last W sec
4.4.5.1.2
Basic Token Bucket Algorithm (TB)
TB - formal definition of a rate of transfer. TB components: a burst size, a mean rate, and a time interval (Tc).
mean rate = burst size / time interval
Mean rate also called Committed Information Rate (CIR): forwarded per unit time on average.
how much data can be sent or
Burst size - also called the Committed Burst (Bc) size: specifies in bits (or bytes) per burst how much traffic can be sent within a given unit of time to not create scheduling concerns. Time interval - also called the measurement interval: the time quantum in seconds per burst. TB - Simple implementable scheme to control (measure) the input rate R - average rate in bytes/sec T=1/R period between two successive tokens B - size of the token bucket [bytes] c- current fill of TB = credit, c B
110
RS-Sem II RST
token generator M= measuring algorithm rate R Bucket size B Current fill (c= credit) arriving packets Conforming packets (pass) M Non-conforming packets Discard/mark
Figure 63 Basic Token Bucket scheme Token generation process:

Initialization: c=B;
every T second do { if(c<B) then c=c+1;}

Arrival of packet P of length L: if (L c) then { /* packet is accepted */ c=c-L;} else { /* packet is discarded-basic treatment of non conforming packets */}
Traffic anvelope A(t) = B+ Rt maximum traffic accepted by TB in t seconds
TB advantages - simple implementation - usable in traffic contract to detect conforming/nonconforming packets - R is a bound on average rate - B is the maximum busrt size for this flow - Traffic anvelope provide a maximum limit of traffic in any time interval (useful to dimension the data buffers size in the router) Deterministic Marking
Same algorithm but mark as in-excess the non conforming packets instead of discarding
See J. Heinanen and R. Guerin, A Single Rate Three Color Marker, RFC 2697, Sept. 1999 J. Heinanen and R. Guerin, A Two Rate Three Color Marker, RFC 2698, Sept. 1999
4.4.5.1.3 Extensions of Token bucket Single rate three color marker

'
111
RS-Sem II RST
Parameters: Committed Information Rate (CIR) Committed Burst Size (CBS) Excess Burst Size (EBS)
token generator rate CIR M= measuring and marking algorithm EBS ce arriving packets M Packets in excess burst (yellow) Non conforming packets ( red) CBS c Conforming packets (green)
Figure 64 Single rate three color marker

Notes: this type of TB usually admits packets with size CBS and sometimes admits also longer packets with size EBS there is a single flow of tokens filling the CBS size buffer or if this is full the EBS size buffer
Algorithms:
Token Bucket filling Initialization: C=CBS; CE=EBS; Every 1/CIR second do { if(c<CBS) then { c=c+1; } else if (CE<EBS) then { ce=ce+1; } else { /* nothing */ }
}
Colour Blind Mode
In this mode the colour of the input packet does not matter
Arrival of packet P of length L : if (L c) then { /* packet is conformant and marked green) */ c=c-L; } else if (L ce) then { /* packet is marked yellow */ ce=ce-L; }
112
RS-Sem II RST
else { /* packet is non conformant marked red */ }
Colour Aware Mode
In this mode the colour of the input packet is also analysed
Arrival of packet P of length L : if (L c and P is green) then { /* packet is marked green) */ c=c-L; } else if (L ce and P is green or yellow) then { /* Pis marked yellow */ ce=ce-L; } else { /*P is marked red */ }
References O.Bonaventure and S.De Cnodder. A rate adaptive shaper for differentiated services. Internet RFC2963, October 2000. for a shaper that can be used to improve the performance of TCP with such markers Cisco routers have a different way to implement this kind of token bucket with two burst sizes. See S. Vegesna, IP Quality of Service, Cisco Press, 2001
4.4.5.1.4
Leaky Bucket
Algorithm to measure if the packet flow are conformant to a Peak Rate (PR) value Initially used in ATM for constant length packets (ATM cells)
Principle - small buffer for data packets ( at limit K =0 ) to accomodate small variations around PR - increasing in K will increase the variation admitted around PR rate - tokens ariving at rate = Peak Rate = PR [bytes/sec], no token bucket memory - extraction speed from buffer = PR ( at each token, one byte) - if packets found the buffer full then they are marked non conformant
token generator arriving packets rate PR K
conformant packets peak rate PR
Non conformant packets

Figure 65 Leaky Bucket principle Implementation ( equivalent algorithm no real buffer required)
Variable c is a counter Prof. E.Borcoci- UPB -2012-2013
113
RS-Sem II RST
decreased ( if c > 0) periodically (1/PR sec) at each token arrival increased with the length L [bytes] of a packet at its arrival c is bounded: always 0 c K
Initialization: c=0;
Every 1/PR second do { if(c>0 ) then c=c-1; } /* periodical decrese equivalent to extraction from buffer of one byte each 1/PR seconds*/
Arrival of packet P of length L: if (c+L K ) then { c = c+L; /* packet is conformant*/ } else {/* packet is not conformant*/}
4.4.5.1.5
Dual Token Bucket BS - Burst Size
If want to measure/police a flow conforming the parameters PR - Peak Pate, AR - Average Rate, we can use a cascade of LB(PR) + TB( AR, BS)
token generator rate AR Bucket size BS token generator rate PR arriving packets Non-conformant (AR or BS) packets Conformant packets (AR and BS) K conformant packets AR, BS, PR Non conformant packets (PR)
Figure 66 Dual token bucket ( TB + LB) for policing traffic for AR, BS and PR conformance
4.4.5.2
Shaping Based on Token Bucket
Shaping used to make a flow conformant to a given rate R Method- delaying non conforming packets Modify TB by adding a data buffer
Shaping a single flow

114
RS-Sem II RST
rate R token generator arriving packets c Control B departing packets ( conformant flow)
capacity K
Figure 67 Token Bucket for traffic shaping Algorithm: Arrival of packet of size L: if (L c) then { /* conformant packet*/c=c-L; send_packet(); } else {/* too early arrival; delay packet until enough tokens */ while (c<L) { /* wait */ } /* now c=L and packet is conforming */ c=c-L; send_packet(); }
4.4.6
QoS Guarantees (II)
Requirements: - to multiplex on a single link through one router BE and guaranteed traffic - not allow that guaranteed flows be perturbed by BE traffic - BE packets allowed to utilize the output link when there is no guaranteed traffic - bandwidth and delay delay guarantees Conventional simple router case
Policing Input flows Classifier Shaping Meter and Marker Buffer acceptance algorithm Output buffer
Dropped packets
Figure 68 Functional diagram of a simple router

115
RS-Sem II RST
Router components and their general functions Classifier- identify to which flow an arriving packet belongs Policer- vertify ( by measuring) if the incoming flows respects a set of parameters Shaper- delay flow non-conformant with some rules imposed to the traffic flow Shaping can exist also at the output if want to shape the output flows Buffer acceptance algorithm- accepts or reject packets based on an algorithm ( e.g tail-drop, RED, WRED, etc.) Output buffer with FIFO scheduling stores and outputs the packets on link
Roles of simple router components when multiplexing: 1.BE, 2. min bandwidth and
3. max bandwidth flows
Classifier- identifies the three types of flows adds internal flow identifier to packet Policer- based on classification results (flow identifier) and own metering it marks: - BE packets with lowest priority packets in excess from min bandwidth flows with low priority - non-excess (conformant) packets from min bandwidth flows with high priority - max bandwidth packets with high priority Shaper- delay flow non-conformant with some traffic rules imposed to the flow. Shaping can exist also at the output if want to shape the output flows Buffer acceptance algorithm- discard earlier some low priority packets then high priority ones Output buffer- with simple FIFO serving policy it cannot contribute to bandwidth and delay guarantees fulfillment; some other sophisticated scheduling will be necessary in routers
Delay guarantees- requirements - necessary to have delay differentiation between flows sending some packets on output link should consider the priorities - some packets should be sent earlier than others - replace FIFO buffer by set of N output queues and scheduler (for each flow a separate queue and a scheduler at the output); the scheduling policy select which packet are transmitted first on the output link
4.4.7
Scheduling algorithms Role: Selecting the current output packets
116
RS-Sem II RST
Buffer acceptance algorithm Output buffers (queues)
Policing Input flows Meter and Marker Classifier Shaping
Dropped packets
Scheduler
Figure 69 Functional components of a Router system

Limba Romana Planificarea extragerii pachetelor Aceasta sectiune va prezenta principiile planificarii (scheduling) extragerii pachetelor pe interfetele de iesire ale unui nod de retea astfel incat sa se poata oferi garantii de QoS anumitor fluxuri. In ruterele capabile QoS la interfetele de iesire exista mai multe cozi logice avand pachete cu prioritati egale sau diferite. Sarcina unui planificator este de a aplica o politica de explorare a cozilor astfel incat sa sartisfaca cerintele cat mai multoor fluxuri si sa asigure echitate in folosirea resurselor. 4.4.8.1 Functiuni de baza ale unui planificator Exista doua tipuri de baza de planificatoare, [ ], [ ]: - work-conserving cu conservarea sarciniidaca exista pachete in cozi le extrage spre iesire; - non-work-conserving poate fi inactiv si daca exista cozi nevide. Acesta din urma creste predictibilitatea traficului extras pe link; reduce dimensiunea buffer-ului si fluctuatia de intarziere; transmite un pachet numai daca acesta este eligibil; in schimb este mai complicat de implementat. Functia de baza a planificatorului este sa selectez un pachet de trimis pe link-ul de iesire dintr-o coada de asteptare, conform politicii de planificare. Cerintele generale impuse unui planificator sunt: sa fie usor de implementat in HW; sa suporte BE dar si garantii QoS; sa asigure echitate intre fluxuri (de exemplu dupa principiul max-min) ; sa sigure protectie intre fluxuri; sa poata oferi garantii deterministe sau statistice asupra parametrilor QoS (bandwidth, delay, jitter, packet loss). 4.4.8.2 Planificatoare pentru fluxuri Best Effort Planificatoarele BE (toate fluxurile au aceeasi prioritate) trebuie sa indeplineasca mai multe cerinte: sa fie implementabile pentru viteze mari; sa asigure o distributie echitabila a benzii intrte fluxuruile active (principiul max-min), independent de gradul da congestie al nodului in cauza sau de mecanismele de control de flux existebnte in terminalele de capat; sa asigure protectie intre fluxuri: 1. un flux care se comporta mai agresiv sa nu poata periclita banda alocata altora; mecanismul de eliminare a unor pachete trebuie sa asigure faptrul ca un flux nu poate monopoliza un buffer de iesire. In caz de congestie intr-un nod, pachetele trebuie eliminate in mod echitabil. Pentru a determina eventual care flux a provocat congestia trebuie examinate cozile asociate tuturor fluxurilor; in mod natural, fluxul avand asocuiata cea mai lunga coada poate fi considerat respomnsabil de congestie. O solutie este de a elimina din pachetel acestei cozi (de la inceput, sau de la sfarsit, sau chiar toata coada). 4.4.8.2.1 Partajarea procesorului Principiul partajarii procesorului processor sharing- pentru planificare in stil BE , [ ], [ ], [ ], reprezinta o schem teoretica de tip workconserving bazata pe modele de fluid. Planificatorul are M cozi logice ( Figura 4-1) in parallel iar fiecare coada e servita ca si cum ar contine un flux de fluid. Va
4.4.8
117
RS-Sem II RST
fi numit flux activ acela pentru care coada asociata contine fluid ( seste nevida) . Debitul binar (rata) pe link-ul de iesire se imparte in orice moment intre fluxurile active, in mod egal. Daca In momentul t avem n fluxuri active atunci o coada Qk e servita la rata Rk, unde Rk = Rout/n, cu Rour rata pe linkul de iesire.
Algoritm de acceptare in Buffer F1 F2 Fluxuri de intrare
Cozi de iesire
Fluxuri inactive Algoritm de planificare Qk R Rout
Fk
FM Flux activ
Figura 4-1 Principiul de planificare Processor Sharing Exemplu Consideram ( trei fluxuri F1, F2, F3 in paralel; B = banda totala (normata) pe link = 1; L = lungime relativa pentru a transmite un pachet daca ar avea alocata intreaga banda = 1; T = interval de timp conventional necesar sa transmitem un pachet de lungime L, daca banda alocata ar fi = 1 ( timpul real creste daca banda alocata fluxului va fi mai mica decat 1); Ipoteze simplificatoare: omente de sosire: T, 2T, 3T, Se observa ca planificatorul imparte debitul conductei in mod egal intre fluxurile active. Totusi, modelul fluid este mai flexibil decat se poate implementa in realitate. Intr-o implementare reala, inprimul rand pachetele nu se transmit in paralel ci secvential. Deci un planificator real nu poate fi decat cu aproximatie reprezentat de un model bazat pe fluide. In al doile rand, flyxurile reale de pachete sunt discontinue deci diferite de fluide. Planificatorul PS prezinta avanatjul ca in lipsa pierederilor realizeaza principiul max-min. In schimb daca anumite pachete sunt eliminate atunci va fi nevoie de masuri suplimentare pentru a a sigura echitatea. Dezavantajul sau major consta in dificultatea implementarii, deci in practica se recurge la aproximari.
118
RS-Sem II RST
P0 L=1 F1
P1
P2
P3
P0 L=2 F2
P1
timp
P0 L=1 F3 B 1 P0/F 1 2./3 1/2 1/3 P0/F2 P0/F2 0 P0/F3 P1/F2 P1/F1 P2/F1 P3/F1 P1/F 2 T
Datorita modelului fluid rata de transmisie se poate modifica in cursul transmisiei unui pachet (volum de fluid)
Figura 4-2 Exemplu de planificare pentru Processor Sharing bazat pe model de fluide 4.4.8.2.2 Planificator circular Planificatorul cu politica circulara (Round Robin-RR) presupune N cozi Q1, Q2, QN pentru N fluxuri F1, F2, FN, iar acestea vor fi servite circular dupa regula: Q1 Q2 QN Q1 Algoritmul RR este usor de implementat, ofera protectie si echitate pentru trafic BE dar numai daca daca pachetele sunt de lungimi comparabile. Echitatea este de fapt asigurata doar in medie pe intervale mai mari de timp decat durata unui pachet. Dezavantajul sau este ca pachetele lungi pot monopoliza coada unica deci si capacitatea link-ului. Exemplu Se considera trei fluxuri F1, F2, F3 active in paralel; L este lungimea relativa pentru a transmite un pachet pe link; T = timpul necesar de transmisie pentru un pachet cu L=1. Pentru simplitate s-a presupus ca momentele de socire ale pachetelor in cozile associate fluxurilor sunt : T, 2T, 3T, Se observa ca fluxul F2 care are pachete mai lungi beneficiaza de o proportie mai mare din capacitatea totala a linkului- deci nu avem echitate desi fluxurile sunt echi-prioritare.
119
RS-Sem II RST
P0 L=1 F1
P1
P2
P3 Inechitate: un flux cu pachete mai lungi monopolizeaza linkul
P0 L=2 F2
P1
P0 L=1 F3
P0 F1
P0 F2
P0 F3
P1 F1
P1 F2
P2 F1
P3 F1
timp
Figura 4-3 Exemplu de planificare circulara (Round Robin). 4.4.8.2.3 Planificator circular cu control individual de credit Planificatorul circular cu credit (Deficit Round Robin DRR) asociaxa o variabila de credit pentru fiecare coada. Se defineste Ci = contor de credit cumulativ pentru coada Qi. Cozile sunt vizitate circular. Vizitarea unei cozi Qi Ci = Ci + ( cuanta de credit quantum of credit). Un pachet nu poate fi transmis decat daca in coada sa exista credit sufficient, altfel asteapata in coada acumulare de credit.
F1 F1 F2 F2 Fluxuri de intrare FN credit Nu poate fi inca transmis Vizitarea ciclica a cozilor (aduce credit nou)
FN
Poate fi transmis (credit suficient)
Figura 4-4 Exemplu pentru planificatorul Deficit Round Robin

Algoritmul de planificare Initializare: For i=1 to N do { Ci = 0; } Repeat forever { For i=1 to N do {Ci = Ci + ; /*creste creditul la fiecare vizitare a unei cozi*/ while [(Ci > 0) and not_empty(Qi ) and length(first_pachet) < Ci) do
120
RS-Sem II RST
{move_first_packet_in_output_link_queue( ); Ci = Ci- length(first_pachet); } if (empty(Qi)) then Ci =0; /* creditul nefolosit este anulat*/ } }
Exemplu N= 4 fluxuri; C1, ..C4 contori de deficit (credit conteiners) Cuanta de credit = 1000 [bytes] Initial: continutul cozilor este reprezentat prin lungimile pachetelor existente Runda 1 de explorare : Q1 are 3 pachete cu lungimi 200, 600, 1300: Primul increment de credit aduce 1000 unitati , deci se pot extrage succesiv din Q1: 200, 600; credit ramas = 200, deci al treilea pachet nu poate fi inca transmis Q2 vid nu primeste credit Q3 are 2 pachete cu lungimi 600, 1100; se poate transmite 600 iar 1100 inca asteapta nou credit ( credit ramas dupa transmisia primului pachet = 400) etc.
Runda 1 1000 F1 C1 1200= credit insufficient pentru 1300 pachet cu lungime 1300 2200
200- ramas dupa trs. 200, 600 1000
F2
C2
Q2- vid > credit e zero 1000 1400
400
F3
C3 1000
F4
1000
C4 1 200 600
1300
Q4vida -> credit e anulat 2 3 600

1100
4 400
1
1300
2 500
3
1100
4 800
1
1300
Q1
Q2 50
Q3
Q4
Q1
Q2
Q3
Q4
Q1
80 Pachete noi
Nu poate fi trs. Nu este sufficient credit Acum se poate trs.
Figura 4-5 Exemple de planificare cu algoritmul DRR
121
RS-Sem II RST
4.4.8.3 Planificatoare pentru fluxuri cu garantii
Scopul acestor planificatoare este de a asigura anumitor fluxuri prioritate concretizata prin indicator de prioritate propriu-zis sau prin garanatii de banda alocata. Ele trebuie sa ofere si garantii de intarziere, precum si protectie intre fluxuri. SE doreste sa fie implementabile pentru viteze mari. Remarcam ca aceste cerinte sunt greu de satisfacut in totalitatea lor. 4.4.8.3.1 Planificator cu prioritati absolute Planificatorul cu prioritati absolute (Priority-based scheduler) aloca prioritati fluxurilor dintr-o anume clasa de calitate a servciilor si ca atare va avea N cozi cu prioritati diferite, fiecare reprezentand o clasa C1, C2, ..CN. Un flux oarecare va apartine unei anumite clase iar pachetele sale vor fi plasate in coada asociata clasei. Clasele sunt servite in ordinea stricta a prioritatilor ( pana devin vide) iar fiecare coada e servita in ordine FIFO. Algoritmul este usor de implementat si ofera performante rifdicate pentru fluxurile prioritare. Are in schimb dezavantajul ca daca nu se limiteaza trafuicul pentru fluxurile prioritare celelalte pot sa stagneze. De aceea in implementari acest tip de planificator este asociat cu existenta unui policer la intrarea nodului de retea care sa limiteze la valori cunoscute traficul pe fluxurile prioritare.
Algoritmul de planificare: Repeat { For i=1 to N do {if (QCi not empty) then serve_QCi; else i= i+1;} } until all_queues_void( )
4.4.8.3.2 Procesor partajat generalizat Procesorul partajat generalizat generalizat (Generalized Processor Sharing GPS) este o generalizare a procesorului partajat, cu conservare a sarcinii, bazat pe modelarea fluxurilor ca fluide, prezentat in sectiunile precedente dar prevazut cau capabilitati suplimentare. Diferenta esentiala fata de PS este ca se aloca o pondere Wk asociata cu o coada Qk . Fiecare coada este servita ca si cum ar contine un flux fluid. Debitul binar al linkului se imparte intre fluxurile active proportional cu ponderile acestora. La momentul t coada Qk este servita la rata
Rk = Rout (Wk/Wi),
unde suma Wi este calculata numai asupra ponderilor fluxurilor active . Aici apare un aspect deosebit de important al tehnologoiei IP> Chiar daca s-a promis unui flux prin rezervare o anumita banda, in intervalele de timp in care acesta nu este activ, banda respectiva se aloca altor fluxuri care sunt active. Deci uitilizarea resurselor este mult mai buna decat in cazul unei provizionari fixe. GPS asigura: o banda garantata per flux printr-un GPS sau un lant de GPS; garantii de intarziere per flux, daca fluxul e constrans de un model token bucket TB(R,B). Un planificator GPS se poate demonstra ca ofera o limita de intarziere delay_bound= B/R iar printr-un lant de planificatoare de asemenea se poate garanta o limita de intarziere precum si o gama de variatie a fluctuatiei de intarziere ([0,Dmax]). GPS asigura protectie intre fluxuri. Problema majora este ca acest GPS descris printr-un model matematic nu se poate implementa in mod strict. De aceea se cauta modele aproximative. 4.4.8.3.3 Planificator circular cu ponderi Acest tip de planificator (Weighted Round Robin-WRR) aplica o politica circulara de explorare neuniforma a cozilor intr-un mod care tine cont de ponderea fiecarei cozi. Vor exista: N fluxuri, un flux activ Fk are ponderea Wk (procentaj de banda)) Wi,= 1, i=1 ..N; numarul de vizitari pentru Fk este proportional cu Wk Exemplu : Se defineste un macro-ciclu compus din M cicluri in fiecare ciclu unele cozi sunt vizitate, altele nu
122
RS-Sem II RST
se defineste un vector de vizitare: vi= (wi1, wi2, wiN), cu wik = 1 daca coada Fk este vizitata wik = 0 daca Fk nu e vizitat V = {v1, v2, ..vM}; Wk = (wi k , i =1, ..M) /(wi k , i =1, ..M, k = 1,..N) Exemplu numeric: N=4, M=3, V = {(1,0,1,0), (1,1,1,0), (1,1,0,1)}
wi k = 8, for i =1, ..M, k = 1,..N

W1 = 3/8, W2= 2/8, W3 = 2/8, W4 = 1/8 Avantajele WRR sunt: implementare simpla daca macrociclul este relativ scurt, asigura benzi diferite si protectie intre fluxuri. Dezavantajul sau este ca in cazul unui numar mare de fluxuri fiecare avand alocata o mica portiune de banda, rezulta un ciclu M cu lungime mare, ceea ce creste complexitatea.
4.4.8.3.4 Planificator cu echitate si cozi ponderate Planificatorul cu echitate si cozi ponderate "Weighted Fair Queuing WFQ, defineste un model GPS implemntabil. Ideea este ca se emuleaza GPS considerand unitatile de trafic de tip pachet (nu model de tip-fluid) si se servesc pachetele aproximativ in aceeasi ordine pe care un GPS ideal ar stabili-o. Pentru implementare se defineste ceasuri virtuale care calculeaza momentele de timp la care un GPS ideal ar termina servirea unui pachet si se servesc pachetele in ordinea acestor valori de timp.
Referinte A.Parekh and R.Gallagher. A generalized processor sharing approach to flow control : the single node case. IEEE/ACM Transactions on Networking,1(3):346357, 1993. A.Parekh and R.Gallagher. A generalized processor sharing approach to flow control the multiple node case. IEEE/ACM Transactions on Networking, 2(2):137150, 1996. Planificatorul cu ceas virtual - varianta 1 Acest algoritm Weighted Fair Queuing este o aproximare pentru GPS. Se aloca o marca de timp (stampila temporala time stamp) pentru fiercare pachet sosit. Planificatorul selecteaza (intre cozi) pentru transmisie, pachetul cu cea mai mica stampila temporala (politica de planioficare Earliest Deadline First EDF). Se vor nota: Bi banda pentru Qi; Vi : variabila de stare ( ceas virtual) asociata cu Qi.
La sosirea in Qi a unui pachet P cu L bytes se executa: Vi = Vi + ( L / Bi); se asociaza Vi cu pachetul si se pune pachetul in coada asociata; exploratorul cicklic va face transmisia in ordinea EDF.
L.Zhang. VirtualClock: A new traffic control algorithm for packet switching.ACM Transactions on Computing Systems, 9(2):101124, May 1991.
In Figura 4-6 se prezinta un exemplu simplificat al comportamentului unui WFQ(1) pentru trei fluxuri de pachete F1, F2, F3. S-au presupus lungimi egale L1=L2=L3=L=3 pentru toate pachetele. Alocarea de band este de asemenea egala si avem B1=B2=B3 = 3. Observam ca timpul virtual de transmisie al unui pachet din fluxul Fi este Li/Bi = 3. Deci ceasurile virtuale (V1, V2, V3) vor avansa cu incrementul 3 la fiecare sosire de nou pachet. Totusi atunci cand se extrage un pachet, el beneficiaza de toata banda linkului care este egala cu B1+B2 + B3 = 3. Deci durata transmisiei oricarui pachet din exemplul nostru este Tt =L/B= 1. In desen se observa evolutia ceasurilor virtuale pentru fiecare flux. Pentru simplificare s-a presupus ca momentele de sosire ale pachetelor sunt la momente de timp t=k, k intreg. SE observa ca la t= 5 sosesc trei pachete, P2(F1), P2(F2) si respectiv P1(F3). Deoarece ceasul lui F3 area cea mai mica valoare ( V3=6), se va transmite intai P1(F3) si apoi
123
RS-Sem II RST
celelalte.
0+3/1 =3 L1=3 B1=1 L2=3 B2=1 L3=3 B3=1 F1 P0 0+3 =3 F2 0+3 =3 F3 P0 P1 P0 3+3=6 P1 3+3 =6 P1 6+3=9 P2 6+3 =9 P2 3+3 =6
Output B=3
P0 F1
P0 F3
P0 F2
P1 F1
P1 F2
P1 F3
P2 F1
P2 F2
timp
0 Tt=L/B=3/3=1
Figura 4-6 WFQ (1) exemplu simplificat de planificare (pachete de lungimi egale si alocarea de banda aceeasi)
In Figura 4-7 se prezinta un exemplu in care pachetele din cele trei fluxuri au lungimi diferite respeciv ( 2, 8, 4) iar alocarile de banda sunt de asemenea diferite si anume B1=1, B2=2, B3=1, cu banda totala B=4. Se observa ca desi F2 are pachete mai lungi, el nu poate monopoliza linkul deorece ceasul sau virtual avanseaza cu incremente mai mari. De aceea putem spune ca acest planificator tine seama de ponderi dar este fair.
0+2/1 =2 L1=2 B1=1 L2=8 B2=2 L3=4 B3=1 F1 P0 0+4 =4 F2 0+4 =4 F3 P0
P 0 F 1 P0 F3
2+2=4 P1 4+4 =8 P1
4+2=6 P2 8+4 =12 P2 4+4 =8 P1
P0
timp
Output B=4
P0 F2
P 1 F 1
P1 F2
P 2 F 1
P0 F3
P1 F2
Tt1= 2/4= 1/2; Tt2= 8/4= 2; Tt3= 4/4= 1;
Figura 4-7WFQ (1) exemplu de planificare cu pachete de lungimi inegale si alocari diferite de banda
Dezavantajul acestui planificator (posibil) este acela ca daca un flux a fost mult timp inactiv si deodata incepe sa produca rafale de pachete, el va monopoliza pentru un timp linkul deoarece ceasul sau a stagnat in timp ce ale altor fluxuri au avansat. Deci se poate spune ca un flux inactiv totusi
124
RS-Sem II RST
capitalizeaza credit pe care il va putea folosi in rafale de trafic in viitor. Figura 4-8 prezinta un asemenea exemplu.
0+3/1 =3 L1=3 B1=1 L2=3 B2=1 L3=3 B3=1 F1 P0 0+3 =3 F2 P0 3+3=6 P1 3+3 =6 P1 V3 = 0 F3 0+3 =3 3+3 =6 P0 P1 6+3 =9 P2 V3 6+3=9 P2 6+3 =9 9+3=12 P3 V2 V1
Output B=3
P0 F1
P0 F2
P1 F1
P1 F2
P0 F3
P1 F3
P2 F1
P2 F3
P3 F1
0 Tt= L/B = 3/3 = 1
timp 8
Aceste pachete au prioritate EDF la transmisie caci V3 < V1, V2
Figura 4-8 WFQ (1) Exemplu de acaparare a link-ului de catre fluxul F3 care devine activ dupa un interval lung de inactivitate
Planificatorul cu ceas virtual - varianta 2 Diferenta fata de varianta 1 este ca pentru fluxurile inactive, creditul neutilizat se pierde. Asadar, un flux inactiv nu poate capitaliza credit in intervalul de inactivitate (asa cum se intampla in varianta 1)
Presupunem ca fluxul Fi are alocata o banda Bi. Incrementarea ceasului sau virtual la sosirea (in momentul t) unui pachet de lungime L se va face conform relatiei: Vi = max (t , Vi) + ( L / Bi). Se observa ca pentru un flux inactiv care devine activ la un moment t=tk, ceasul sau virtual va lua valoarea timpului curent, daca aceasta este mai mare decat valoarea anterioara a ceasului virtual (care a stat pe loc din momentul sosirea celui mai recent (ultim) pachet anterior si pana in prezent la momentul t). De aceea creditul nefolosit se pierde( a se vedea cazul fluxului F3 din Figura 4-9).
0+3/1 =3 L=3 B1=1 L=3 B2=1 L=3 B3=1 F1 P0
max (2,3)+3=6 P1
max(4,6)+3=9 P2
max(5,9)+3=12 P3
V1
max (1,0) +3 =4 F2 P0
max(2,4)+3 =7 P1 V3=0
max(4,7) +3 =10 P2
V2
max(5,0) +3=8 max(6,8) +3 =11 max(7,11) +3 =14 P0 P1 P2
V3
F3
Output B=3 0
P0 F1
P0 F2
P1 F1
P1 F2
P2 F1
P0 F3
P2 F2
P1 F3
P3 F1
P2 F3
timp
125
RS-Sem II RST
Figura 4-9 WFQ (2) exemplu de planificare In Figura 4-10 se prezinta un exemplu al unei rafale de trafic pe fluxul F1 in timp ce F2 si F3 sunt inactive. DE aceea ceasul lui virtual creste mai rapid decat timpul natural t. Daca F2 si F3 devin quasi-simultan active, ceasurile lor vor avea valori mai mici decat cel al lui F1 si ca urmare se vor transmite cu precadere pachete din F2 si F3.
timp F1 Aceasta rafala va creste puternic ceasul lui F1 (mai rapid decat incrementarea timpul ui t) Q1 V2=0 Q2
F2
V3 =0 F3 Q3 F2 si F3 vor avea prioritate fata de F1 pana cand valorile ceasuril e lor devin compara bil e cu cel al lui F1
Figura 4-10 WFQ (2) Exemplu in care fluxurile F2 si F3 pot monopoliza pentru un timp linkul din momentul in care devin active
Spatiere virtuala Planificatorul cu spatiere virtuala (SCFQ) difera de cele anterioare WFQ prin introducerea in plus unui ceas global V. Aici V este o variabila de stare, egala cu marca de timp a pachetului curent transmis. Valoarea sa joaca rolul valorii de timp curent din metodele precedente, cu deosebirea ca V variaza in salturi si nu liiniar. La La sosirea unui pachet P de lungime L pentru fluxul Fi se executa Vi = max (V, Vi) + ( L / Bi) iar apoi se aplica o politica EDF. In Figura 4-11 se da un exemplu al unei planificari SCFQ.
12
15
15
15
18
21
0+3/1 =3 L=3 B1=1 L=6 B2=1 L=3 B3=1
max (9,3)+3=12 P1
max(12,12)+3=15 P2
max(15,15) +3=18 P3 max(15,15) +6 =21 P2
V1
F1 F2 F3
P0
max (3,0) +6/1 =9 max(9,9)+6 =15 P0 P1
V2 V3
max(15,0) +3 =18
V3=0
max(15,18) +3 =21 P1
P0
Output B=3 0
P0 F1
1
P0 F2
2 3
P1 F1
4
P1 F2
5 6
P2 F1
7
P0 F3
P2 F2 timp
P1 F3
126
RS-Sem II RST
Figura 4-11 Exemplu de planificare SCFQ
J.Roberts. Virtual spacing for flexible traffic control. International Journal of Communication Systems, 7:307--318, 1994. J.Roberts, U.Mocci, and J.Virtamo, editors. Weighted Fair Queueing, chapter6, pages 173--187. Number 1155 in Lecture Notes in Computer Science. Springer Verlag, 1996. S.Golestani. A self-clocked fair queuing scheme for broadband applications. In IEEE INFOCOM94, pages 636--646, 1994.
REFERENCES
[WS97] William Stalling, Data and Computer Communication, Prentice Hall, New-York, 1997, ISBN 0-02-415425-3 [WS98] William Stalling, High-Speed Networks: TCP/IP and ATM Design Principles, Prentice Hall, New York, 1998, ISBN 0-13-525965-7 [TA97] A.Tanenbaum, Retele de calculatoare, Ed. IV, Ed. Agora , 2004 [SR96] R.Stevens, TCP/IP Illustrated, Vol.1. , Addison Wesley, 1996.
[IBM-05] Martin W. Murhammer, et.al., TCP/IP Tutorial and Technical Overview, 2005 [FA04] A. FARREL The Internet and Its Protocols A Comparative Approach Ed, Morgan Kaufmann, 2004
5.1 General list of acronyms

AAA ABR AC AF AN ANG AP API AQ&S AQM AR ARP AS ATM BA BB BE Authentication, Authorisation and Accounting Available Bit Rate Admission Control Assured Forwarding Access Network Access Network Gateway Access Point Application Programming Interface Advanced Queuing and Scheduling Advanced (Queue) Management Access Router Address Resolution Protocol Autonomous System Asynchronous Transfer Mode Behaviour Aggregate Bandwidth Broker Best Effort
127
RS-Sem II RST
BGP B-ICI BISDN BR CA CAC CAS CBQ CBR CBR CC CDMA CDV CER CES CIM CL CLI CLP CLR CMR CO COPS CP CPCS CPE CR CS cSLA cSLS cSLS DB DCCP DI DiffServ DLCI DNS DS DSCP Border Gateway Protocol Broadband Intercarrier Interface Broadband Integrated Services Digital Network Border Router Congestion Avoidance Connection Admission Control Channel Associated Signalling Class Based Queuing Constraint-based Routing Constant Bit Rate Content Consumer Code Division Multiple Access Cell Delay Variation Cell Error Rate Circuit Emulation Service Common Information Model Connectionless Command Line Interface Cell Loss Priority Cell Loss Rate Cell Misinsertion Rate Connection Oriented Common Open Policy Service Protocol Content Provider Common Part Convergence Sublayer Customer Premises Equipment Core Router Convergence sublayer (adaptation) Customer Service Level Agreement SLS between customers and providers Customer Service Level Specification Database Datagram Congestion Control Protocol Digital Item Differentiated Services Data Link Connection Identifier Domain Name Service Differentiated Services (DiffServ), IETF Working Group Differentiated Services Code Point
128
RS-Sem II RST
DSL DSLAM DVA DVB-S DVB-T E2E ECN EF EFSM EG ER ES/H FCFS FDM FDMA FEC FEC FIFO FR GFC GK GOP GPS GRED GSM GW HDSL HEC HTML HTTP H-WRR IAB ICMP IE IEEE IETF IG IMA IMS Digital Subscriber Line Digital Subscriber Line Access Multiplexer Distance Vector Algorithm Digital Video Broadcast- Sattelite Digital Video Broadcast- Terrestrial End-to-End Explicit Congestion Notification Expedited Forwarding Extended Finite State Machines Exterior(Border) Gateway Edge Router End System/Host First Come First Served Frequency Division Multiplexing Frequency Division Multiple Access Forward Error Control Forwarding Equivalence Class First-In First-Out (queue) Frame Relay Generic Flow Control Gate Keeper Group of Pictures Global Position System Generalized RED Global System for Mobile Communication Gateway High bit-rate Digital Subscriber Line Header Error Check Hypertext Mark-up Language Hyper Text Transfer Protocol (IETF, W3C) Hierarchical WRR Internet Architecture Board Internet Control Messages Protocol Information Element Institute of Electrical and Electronics Engineers Internet Engineering Task Force Interior Gateway( Router) Inverse Multiplexing ATM Integrated Multimedia Subsystem
129
RS-Sem II RST
IntServ IP IPC IRTF IS IS LAN LANE LAPD LB LDAP LDP LLC LSP LSR LVC MAC MAN MCTD MDT MF MGCP MGW MIB MIB MPEG MPLS MPOA MSC MT MTTR NC NE NGN NLRI NM NNI NP NPA Integrated Services Internet Protocol Inter Process Communication Internet Research Task Force Intermediate System see IntServ Local Area Network LAN emulation Link Access Procedure for D Channel Leaky Bucket Large Directories Access Protocol Label Distribution Protocol Logical Link Control Label Switched Path Label Switched Route Label Virtual Circuit Medium Access Control Metropolitan Area Network Mean Cell Transfer Delay Mean down-time Multi Field Media Gateway Control Protocol Media Gateway Management Information Base Management Information Base Moving Picture Experts Group Multiprotocol Label Switching Multiprotocol over ATM Message Sequence Chart Mobile Terminal Mean time to repair/patch Network Controller Network Element Next Generation Network Network Layer Reachability Information Network Manager Network Network Interface Network Provider Network Point of Attachment ( Physical Address)
130
RS-Sem II RST
NQoS nrt-VBR NSAP NSIS NTP OA OAM OFDM OSF OSI - RM OSPF PBM PBNM PCM PDB PDH PDP PDU PDV PEP PHB PHP PID PIM PMD PMT PNNI POSIX POTS PPP PQ PQoS PR PRIO pSLA pSLS pSLS PSTN PT Network QoS Non-real-time Variable Bit Rate Network Service Access Point Next Steps in Signalling Network Time Protocol Ordered Aggregate Operation and Maintenance Orthogonal Frequency Division Multiplexing Open Software Foundation Open System Interconnection - Reference Model Open Shortest Path First Policy Based Management Policy Based Network Management Pulse Code Modulation Per Domain Behaviour Plesiochronous Digital Hierarchy Policy Decision Point Protocol Data Unit Packet Delay Variation Policy Enforcement Point Per Hop Behaviour Penultimate Hop Popping Program Identifier Protocol Independent Multicast Physical Medium Dependent Policy management tool Private Network-Network Interface Portable Operating System Interface Plain Old Telephone Service Point to Point Protocol Priority Queuing Perceived QoS Policy Repository Priority Provider Service Level Agreement SLS between providers Provider Service Level Specification Public Switched Telephone Network Payload Type
131
RS-Sem II RST
PTD QC QoS RARP RED RFC RIP RM RM RSVP Packet Transfer Delay Quality of Service Class Quality of Services Reverse Address Resolution Protocol Random Early Drop Request for Comments Routing Information Protocol Resource Manager Resource Manager Resource reservation protocol
rt -VBRReal-time Variable Bit Rate RTCP RTD RTP RTT SAC SAP SAR SCTP SDH SDR SDU SIP SLA SLS SM SMDS SMI SMTP SNDAP SNDCP SNMP SOAP SONET SP SQL SS7 SSCOP SSCS Realtime Control Protocol Round Trip Delay Realtime Transport Protocol Round Trip Time Subscription Admission Control Service Access Point Segmentation/reassembling Stream Control Transmission Protocol Synchronous Digital Hierarchy Service Discovery Repository Service Data Unit Session Initiation Protocol Service Level Agreement Service Level Specification Service Manager Switched Multimegabit Data Service Structure of Management Information Simple Mail Transfer Protocol Subnetwork Dependent Network Access Protocol Subnetwork Dependent Convergence Protocol Simple Network Management Protocol Simple Object Access Protocol Synchronous Optical Network Service Provider Structured Query Language Signalling System No.7 Service Specific Connection Oriented Protocol Service Specific Convergence Sublayer
132
RS-Sem II RST
STP SVC TBF TC TCP TCS TD TDM TDM TE TLI TME TMN TP TS TSAP Signaling Transfer Point Signalling Virtual Channels Token Bucket Flow Traffic Control Transmission Control Protocol Traffic Conditioning Specification Traffic Demand Time Division Multiplexing Terminal Device Manager Traffic Engineering Transport Layer Interface Existing Subscriptions TM New Subscriptions TM Traffic Policing Traffic Shaping Transport Service Access Point
TSPEC Traffic Specification TT UBR UDP UED UNI UPC UTRAN VBR VC VCC VCI VoD VoIP VP VPC VPI VPN WAN WDM WFQ WRR XML Traffic Trunk Unspecified Bit Rate User Datagram Protocol User Environment Description User network Interface Usage Parameter Control Universal Terrestrial Radio Access Network Variable Bit Rate Virtual Channel Virtual Channel Connection Virtual Channel Identifier Video on-demand Voice over IP Virtual Path Virtual Path Connection Virtual Path Identifier Virtual Private Network Wide Area Network Wavelength Division Multiplexing Weighted Fair Queuing Weighted Round Robin Extensible mark-up language
133
RS-Sem II RST
ANNEX 1
6.1 Ethernet Frame Formats:

Ethernet (a.k.a. Ethernet II) +---------+---------+---------+---------| Dst | Src | Type | Data... +---------+---------+---------+---------<-- 6 --> <-- 6 --> <-- 2 --> <-46-1500-> Type 0x80 0x00 = TCP/IP Type 0x06 0x00 = XNS Type 0x81 0x37 = Novell NetWare
802.3 +---------+---------+---------+---------| Dst | Src | Length | Data... +---------+---------+---------+---------<-- 6 --> <-- 6 --> <-- 2 --> <-46-1500->
802.2 (802.3 with 802.2 header) +---------+---------+---------+-------+-------+-------+---------| Dst | Src | Length | DSAP | SSAP |Control| Data... +---------+---------+---------+-------+-------+-------+---------<- 1 -> <- 1 -> <- 1 -> <-43-1497-> SNAP (802.3 with 802.2 and SNAP headers) +---------+---------+---------+-------+-------+-------+-----------+---------+----------| Dst | Src | Length | 0xAA | 0xAA | 0x03 | Org Code | Type | Data... +---------+---------+---------+-------+-------+-------+-----------+---------+----------<-- 3 --> <-- 2 --> <-38-1492->
At the physical layer, the Dst field is preceded by a 7-byte preamble and a 1-byte start of frame delimiter. At the end of the Data field is a 4 byte checksum. So, the minimum and maximum frame sizes on Ethernet are: Field Name Preamble Min Size Max Size Min w/o Preamble Max w/o Preamble 7 7
134
RS-Sem II RST
Start of frame delimiter 1 Dst Src Type/Length Data Checksum Total 6 6 2 46 4 72 1 6 6 2 1500 4 1526 6 6 2 46 4 64 6 6 2 1500 4 1518
Dst is a 6-byte destination address. Src is a 6-byte source address. For Ethernet II frames, Type is the protocol type of the packet. 0x80 0x00 is TCP/IP, etc... For 802.3 frames, Length is the number of bytes in the Data field. Ethernet uses the type field to determine the packet protocol. 802.3/802.2 use the DSAP and SSAP fields. Since there are only 256 possible SAP values, they are fairly hard to get. The special SAP number of 0xAA was assigned to indicate that there are further headers after the 802.2 header that must be parsed to determine the network level protocol. This is the SNAP header which uses the same type field used by V2 Ethernet. For its Ethernet_802.3 packet format, Novell uses the 802.3 frame type without adding an IEEE 802.2 LLC header (in this case, NetWare adds its own proprietary higher-level information). This type of packet can be called an 802.3 Raw format. NetWare's 802.3 format is the only CSMA/CD packet type that doesn't incorporate a corresponding standard header for logical-link control or data-link control information. While this may seem to make Ethernet II and IEEE 802.3 packets incompatible on the same wire, they can coexist quite well. This is possible due to the 1,518-byte limit (destination address field to checksum field) on the size of an Ethernet or 802.3 frame and the fact that all Ethernet II Frame Types (assigned and managed by Xerox) are values greater than 1,500 decimal (i.e. the maximum value that can appear in the 802.3 type/length field). Thus, if a packet has a value of 1,500 decimal (05 DC hexadecimal) or less in byte positions 13 to 14, it will be considered an 802.3 packet. Ethernet II uses one bit to indicate multicast addresses, 802.3 uses two bits. On 802.3, the first bit is similar to the multicast bit in that it indicates whether the address is for an individual or for a group, and the second bit indicates whether the address is locally or universally assigned. The second bit is rarely used on Ethernet (CSMA/CD) networks. In Novell's 802.3 Raw format, the Data field begins with IPX header information. The first two bytes in this header (for this format) are always hexadecimal FF FF. These two bytes help confirm that an 802.3 Raw packet contains encapsulated IPX information, but they correspond to IPX's Checksum field. Because this static information interferes with use of the IPX Checksum field, 802.3 Raw packets will not be able to use the security features, such as packet signing, planned for the IPX format. Packets incorporating 802.2 link information are free to use the IPX Checksum feature. Note that IEEE does not recognize Novell's 802.3 Raw
135
RS-Sem II RST
format; it recognizes only 802.3 packets encoded with 802.2 and 802.2 SNAP headers. Adding IEEE 802.2 LLC information to an 802.3 physical packet format requires three additional fields at the beginning of the Data field: a one-byte Destination Service Access Point (DSAP) field, a one-byte Source Service Access Point (SSAP) field, and a one-byte Control field. IEEE assigns Service Access Point numbers (SAPs); among those currently defined are E0 for Novell, F0 for NetBIOS, 06 for TCP/IP, and AA for the Subnetwork Access Protocol (SNAP). NetWare packets using the Ethernet_802.2 format have DSAP and SSAP values of E0, and the Control field is set to 03 (denoting the 802.2 unnumbered format). Examples: IP on an "Ethernet" can be indicated by Ethernet V2 type 0x0800, 802.2 SAP code 0x06, or a SAP code of 0xAA followed by a SNAP type code of 0x0800. AppleTalk can be indicated by either Ethernet V2 type 0x809B (Phase I), or a SAP code of 0xAA followed by a SNAP type code of 0x809B (Phase II). AppleTalk is currently never sent as an 802.3/802.2 packet with a unique SAP code. Novell can be found as either Ethernet type 0x8137, or a raw 802.3 packet. It is not sent as an 802.3/802.2 packet with a unique SAP code. There are only a few SAP values that you are likely to run across. They are:
04 - IBM SNA 06 - IP 80 - 3Com AA - SNAP BC - Banyan E0 - Novell (TR) F4 - Lan Manager FE - CLNS
100BaseT is the IEEE specification for the 100-Mbps Ethernet implementation over unshielded twisted-pair (UTP) and shielded twisted-pair (STP) cabling. The Media Access Control (MAC) layer is compatible with the IEEE 802.3 MAC layer. 100VG-AnyLAN is an IEEE specification for 100-Mbps Token Ring and Ethernet implementations over 4-pair UTP. The MAC layer is not compatible with the IEEE 802.3 MAC layer. 100VG-AnyLAN was developed by Hewlett-Packard (HP) to support newer time-sensitive applications, such as multimedia. A version of HP's implementation is standardized in the IEEE 802.12 specification.
6.2 AODV Details

RFC 3561 AODV Routing July 2003
5. Message Formats
5.1. Route Request (RREQ) Message Format
136
RS-Sem II RST
0 1 2 3 01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Request message is illustrated above, and
Type
J R G
Join flag; reserved for multicast. Repair flag; reserved for multicast. Gratuitous RREP flag; indicates whether a gratuitous RREP should be unicast to the node specified in the Destination IP Address field
D U Reserved
Destination only flag; indicates only the destination may respond to this RREQ Unknown sequence number; indicates the destination sequence number is unknown Sent as 0; ignored on reception. The number of hops from the Originator IP Address to the node handling the request.
Hop Count
RREQ ID A sequence number uniquely identifying the with the originating node's IP address.
particular RREQ when taken in conjunction
Destination IP Address The IP address of the destination for which a route is desired. Destination Sequence Number The latest sequence number received in the past by the originator for any route towards the destination. Originator IP Address The IP address of the node which originated the Route Request. Originator Sequence Number of the route The current sequence number to be used in the route entry pointing towards the originator request. 137
RS-Sem II RST
5.2. Route Reply (RREP) Message Format
01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Reply message is illustrated above, and
Type
R A
Repair flag; used for multicast. Acknowledgment required; see sections 5.4 and 6.7.
Reserved
Sent as 0; ignored on reception.
Prefix Size If nonzero, the 5-bit Prefix Size specifies that the indicated next hop may be used for any nodes with the same routing prefix (as defined by the Prefix Size) as the requested destination. Hop Count The number of hops from the Originator IP Address to the Destination IP Address. For multicast route requests this indicates the number of hops to the multicast tree member sending the RREP. Destination IP Address The IP address of the destination for which a route is supplied. Destination Sequence Number The destination sequence number associated to the route. Originator IP Address The IP address of the node which originated the RREQ Lifetime for which the route is supplied.
The time in milliseconds for which nodes receiving the RREP consider the route to be valid.
138

RS-2012-2013-v0.4 - 21 May - 2013-Marcaj - Patial II

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RS-2012-2013-v0.4 - 21 May - 2013-Marcaj - Patial II

Загружено:

Авторское право:

Доступные форматы

RS-Sem II RST

(English version) Network and Services

E. Borcoci, UPB 2012-2013

Prof. E.Borcoci- UPB -2012-2013

An Architecture oriented to multimedia distribution over multiple domains networks 27

Puni transparente (Transparent Bridges- TB) Punti cu rutare de tip sursa

3.3.3.1 3.3.3.2 3.3.3.3

Multi-Tier hierarchy Autonomous System Definition ASes and Tiers

3.3.6.1 3.3.6.2 3.3.6.3 3.3.6.4

3.3.7 Border Gateway Protocol (BGP) 3.4 IPV6 3.5 ICMPV6

Elastic applications Streaming applications Traffic descriptors

4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.3.2.6 4.3.2.7

4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4

99 99 100 100 100 102 102 103

105 105 105 105 107

108 109 110 111 113 114 114

Priority-based scheduler Weighted Round Robin (WRR) Weighted Fair Queuing

ANNEX 1 6.1 6.2 ETHERNET FRAME FORMATS: AODV DETAILS

Prof. E.Borcoci- UPB -2012-2013

RS-Sem II RST 1 INTRODUCTION-ARCHITECTURE REVISION

1.1 Networks Layered Architectures

Processing functions C1 1 C2 1 Network functions

Upper layers protocols

Processing functions Network functions

Note about word service usage

Prof. E.Borcoci- UPB -2012-2013

Communication Processes Service Primitives

Service Access Point

Different level Protocols 7 Application

6 Presentation Higher Layer Protocols

4 Transport Network Transport Protocols transport

2 Data Link Network Acces Protocols

Network environment OSI Environment Real systems environment

Physical transmission medium

Information flow circulation through layers

Figure 2 OSI Reference Model

Prof. E.Borcoci- UPB -2012-2013

Real Stack Examples. Incomplete stacks TCP/IP Stack

Prof. E.Borcoci- UPB -2012-2013

Application services Transport (TCP) Internetworking (IP) Subnetworks

Figure 4 Simplified view of TCP/IP stack

Figure 5 Simplified view of the TCP/IP protocol stack

MIME BGP (*1) FTP Telnet HTTP SMTP RTCP

TCP (Connection oriented) IP (Connectionless) RARP ARP

(LLC)+MAC (e.g.IEEE 802.x), AAL+ATM, Physical Layer

Prof. E.Borcoci- UPB -2012-2013

RSVP OSPF (*1) ICMP, IGMP (*2)

(LLC)+MAC (e.g IEEE 802.x) , AAL+ATM, etc Physical Layer

Figure 6 Example of TCP/IP stack protocols

UDP User Datagram Protocol ( connectionless CL)

FTP Telnet Rlogin SMTP X

DNS TFTP BOOTP SNMP NFS+RPC

User processes User process Appl

TCP ICMP ARP IP

Network RARP Data link

Prof. E.Borcoci- UPB -2012-2013

Figure 8 IEEE 802 LAN/MAN Standards- examples

Signalling System No.7

Figure 9 Example of incomplete stack: SS7 signalling stack

Figure 10 IP routing example (Cisco Systems)

Prof. E.Borcoci- UPB -2012-2013

TCP, UDP IP, ICMP, IGMP, OSPF, etc. (LLC) + MAC

IP-H MPLS-H IP-H

RSVP OSPF (1) ICMP, IGMP (2)