rs-2011-2012-v0.5-8mai 2012

RS-Sem II – RST

Prof. E.Borcoci- UPB -2011-2012 2

Retele si Servicii

Sem II licenta spec. RST

(English version)

Network and Services

E. Borcoci, UPB

2011-2012

RS-Sem II – RST


CONTENTS

1 INTRODUCTION-ARCHITECTURE REVISION 6

1.1 NETWORKS LAYERED ARCHITECTURES 6 1.1.1 General Principles and Functional Layers 6 1.1.2 OSI Reference Model 7 1.1.3 Real Stack Examples. Incomplete stacks 10

1.1.3.1 TCP/IP Stack 10 1.1.3.2 IEEE 802.x standards for LAN, MAN 14 1.1.3.3 Signalling System No.7 14 1.1.3.4 MPLS architecture 15

1.1.3.4.1 MPLS IP stack 15 1.2 MULTIPLE PLANES ARCHITECTURES 16

1.2.1 Principles 16 1.2.2 Signalling Issues 17 1.2.3 Next Generation Networks Architecture- high level view 18

1.3 BUSINESS MODELS FOR (MULTIMEDIA) COMMUNICATION ARCHITECTURES 21 1.3.1 Customers and Users 21 1.3.2 Providers (PR) 21 1.3.3 Multiple Plane Architecture and Business Actors 23 1.3.4 Service Level Agreements/Specifications (SLA/SLS) 23

1.4 EXAMPLES OF MULTIPLE PLANE ARCHITECTURES 25 1.4.1 IEEE 802.16 multi-plane stack 25 1.4.2 Generic Example of a multi-plane architecture 27

1.4.2.1 An Architecture oriented to multimedia distribution over multiple domains networks

27 1.4.3 Example: Architectural stack for wireless heterogeneous mesh network 29 1.4.4 Control Plane in GSM (2G) 31

2 INTERCONNECTION- REVISION 34

2.1 MODURI DE LUCRU CU ŞI FĂRĂ CONEXIUNE CO/CL 34 2.2 CERINŢELE UNUI SERVICIU DE INTERCONECTARE (LA NIVEL TREI) 34 2.3 MODUL DE LUCRU CO ( CONEXIUNE LA NIVEL REŢEA) 35 2.4 MODUL DE LUCRU CL (FARA CONEXIUNE LA NIVEL REŢEA) 36 2.5 INTERCONECTAREA DE TIP PUNTE (“BRIDGE APPROACH”) 36 2.6 EXEMPLE DE INTERCONECTĂRI 37

2.6.1 Interconectarea de reţele LAN prin punţi (B) 39 2.6.1.1 Punţi transparente (Transparent Bridges- TB) 41 2.6.1.2 Punti cu rutare de tip sursa 41

3 ROUTING PROTOCOLS 41

3.1 ALGORITMI DE RUTARE -SUMAR 41 3.2 ALGORITMI DE CAUTARE A CELUI MAI SCURT DRUM 45

3.2.1 Algoritmul Dijkstra (centralizat) 46 3.2.2 Algoritmul Ford (Fulkerson) 48

3.3 IP ROUTING PROTOCOLS 52 3.3.1 Internet Protocol reminder 52 3.3.2 Principles of IP routing 54 3.3.3 Network hierarchies 55

3.3.3.1 Multi-Tier hierarchy 56 3.3.3.2 Autonomous System Definition 57 3.3.3.3 ASes and Tiers 58

3.3.4 General definitions 59 3.3.5 Address Resolution Protocol (ARP), Reverse ARP – RARP 61 3.3.6 Interior Gateway Protocols 62

3.3.6.1 Routing Internet Protocol (RIP) 63 3.3.6.2 RIP Extensions 65 3.3.6.3 Ad hoc On-Demand Distance Vector (AODV) 66 3.3.6.4 Open Shortest Path First (OSPF) 70

3.3.7 Border Gateway Protocol (BGP) 75 3.4 IPV6 77 3.5 ICMPV6 80

RS-Sem II – RST


4 IPQOS TECHNOLOGIES 82

4.1 INTRODUCTION 82 4.2 APPLICATIONS 82

4.2.1 Application classes 83 4.2.1.1 Elastic applications 83 4.2.1.2 Streaming applications 83

4.2.2 Traffic Description 83 4.2.2.1 Traffic descriptors 84

4.3 ARCHITECTURAL FRAMEWORK FOR QOS IN IP NETWORKS 84 4.3.1 IP Services 86 4.3.2 Data Plane Mechanisms 88

4.3.2.1 Traffic Classification (TCl) 88 4.3.2.2 Packet Marking 89 4.3.2.3 Traffic policing (TP) 89 4.3.2.4 Traffic Shaping (TS) 90 4.3.2.5 Buffer (Queue) Management (QM) 90 4.3.2.6 Queuing and Scheduling Q&S 90 4.3.2.7 Congestion Avoidance (CA) 91

4.3.3 Control Plane 91 4.3.3.1 Admission Control (AC) 91 4.3.3.2 QoS Signalling 92 4.3.3.3 QoS Routing 92 4.3.3.4 Resource Reservation (RR) 92

4.4 BASIC IP QOS AND TRAFFIC CONTROL MECHANISMS- DATA PLANE 93 4.4.1 QoS Guarantees (I) 93

4.4.1.1 Types of guarantees 93 4.4.1.1.1 Bandwidth Guarantees 93 4.4.1.1.2 Other guarantees 93

4.4.1.2 Level of guarantees 94 4.4.2 Classical Routers, Qos Capable Routers 94 4.4.3 IP Level services 95

4.4.3.1 Best−effort (BE) service 95 4.4.3.1.1 Fairness problem 95

4.4.3.2 Buffer (queue) management 96 4.4.3.2.1 Tail drop 96 4.4.3.2.2 Random Early Detection 96 4.4.3.2.3 Weighted RED 98

4.4.3.3 Maximum bandwidth service 98 4.4.3.4 Minimum bandwidth service 99

4.4.4 Packet Classification and Marking 100 4.4.4.1 Packet Flows defined at different layers 101

4.4.4.1.1 Layer 3 Flows 101 4.4.4.1.2 Layer 4 Flows 101 4.4.4.1.3 Upper layer Flows 101

4.4.4.2 IP Packet Marking 103 4.4.5 Policing and Shaping 104

4.4.5.1 Measuring the Rate of Incoming Flows 104 4.4.5.1.1 General Measuring Algorithms of Flow Rate 105 4.4.5.1.2 Basic Token Bucket Algorithm (TB) 106 4.4.5.1.3 Extensions of Token bucket 107 4.4.5.1.4 Leaky Bucket 109 4.4.5.1.5 Dual Token Bucket 110

4.4.5.2 Shaping Based on Token Bucket 110 4.4.6 QoS Guarantees (II) 111 4.4.7 Scheduling algorithms 112

4.4.7.1 Basic Functions of a Scheduler 113 4.4.7.2 Scheduling Best Effort Flows 113

4.4.7.2.1 Round Robin (RR) 114 4.4.7.2.2 Deficit Round Robin (DRR) 115

4.4.7.3 Schedulers for Guaranteed Flow 117

RS-Sem II – RST


4.4.7.3.1 Priority-based scheduler 117 4.4.7.3.2 Weighted Round Robin (WRR) 118 4.4.7.3.3 Weighted Fair Queuing 119

5 REFERENCES 121

5.1 GENERAL LIST OF ACRONYMS 122

6 ANNEX 1 128

6.1 ETHERNET FRAME FORMATS: 128 6.2 AODV DETAILS 131

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 Tb

Processing

functions

Network

functions

Appl.

processes

Processing

functions

Network

functions

Appl.

processes

C1

1 C2

1

N2

1

N1

1

Ta

Tb

Network(s)

User

Protocols

Physical medium

Upper layers

protocols

Complexity/

Intelligence Future Internet?

(more intelligent networks)

E.g. Content aware networks

a b

Figure 1-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 (end–to-end ( E2E) protocols – independent of:

- Network technology, Number of networks, Fixed or mobile mode

• 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 (Applicaţion) :

RS-Sem II – RST


Local Processes

Communication

Processes

Ta

7 Application

6 Presentation

5 Session

4 Transport

3 Network

2 Data Link

1 Physical

Local Processes

Communication

Processes

Tb

7 Application

6 Presentation

5 Session

4 Transport

3 Retea

2 Data Link

1 Physical

Different level

Protocols

3 Network

2 Data Link

1 Physical

Transport Protocol

Network node

Physical transmission

medium

User Entities

Service Access

Point

Service Primitives

Protocol Data

Units (PDU)

Information flow circulation

through layers

E2E

Protocols

Network

Transport

Protocols

transport

Higher

Layer

Protocols

Network

Acces

Protocols

Network

environment

OSI Environment

Real systems environment

Figure 1-2 OSI Reference Model

RS-Sem II – RST


Figure 1-3 Internetworking example in OSI Model

Note : Service Provider = Transport Service Provider

1.1.3 Real Stack Examples. Incomplete stacks

1.1.3.1 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 Advances in microelectronics and huge increase of perf/cost allowed to include the

full TCP/IP stack in all terminals (including small mobile devices)

o This naturally creates the posibility to integrate all kind of high level services based

on TCP/IP stack

o That is why TCP/IP ( called “Internet” is accepted today as a basis for full network

and services integration

• Communication models:

o 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)

o Time criterion

� Synchronous communication (usually r.t: VoIP, AVC, VoD, but also FTP,

etc.)

� Asynchronous communication : e-mail, publish/subscribe

o Mode to get information: push/pull

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 1-4 Simplified view of TCP/IP stack

Application

(communication between processes or

applications on separate hosts)

Telnet, FTP, E-mail,

SNMP, etc

Transport (end-to-end data transfer service reliable or unreliable)

TCP, UDP

Network layer ( network resources mng.,

routing the data to destination)

IP, ICMP, IGMP,

OSPF, etc.

Data link

(acces CO or CL to network layer)

(LLC) + MAC

Physical layer

Figure 1-5 Simplified view of the TCP/IP protocol stack

MIME

BGP (*1)

FTP Telnet

HTTP

SMTP

RTCP

TCP (Connection oriented)

IP (Connectionless)

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

Physical Layer

ARP RARP

RS-Sem II – RST


Video

Voice

RTP

SNMP

Multicast

protocols

RIP

(*)

BOOTP

RSVP

UDP (Connectionless)

OSPF

(*1)

ICMP,

IGMP (*2)

IP (Connectionless)

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

Physical Layer

ARP RARP

Figure 1-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)

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

Trace-

route

DNS

TFTP

BOOTP

SNMP

NFS+RPC

User

process

UDPTCP

IP

IGMP

ARP RARP

ICMP

(LLC) MAC

Appl

Transport

Data link

Network

User

processes

Figure 1-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

RS-Sem II – RST


1.1.3.2 IEEE 802.x standards for LAN, MAN

Figure 1-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

ISUP, TUP, MAP, TCAP

MTP-1

MTP-2

MTP-3

7

4-6

3

2

1

Control Plane

of Telecom

Network

SCCP

Figure 1-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

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 Packet header, Routing algorithm output (routing table)

o 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 1-10 IP routing example (Cisco Systems)

• MPLS ideas

• 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

1.1.3.4.1 MPLS IP stack

RS-Sem II – RST


Application

Transport TCP, UDP

Internet layer

IP, ICMP, IGMP,

OSPF, etc.

MPLS sublayer

Data link layer (LLC) + MAC

Physical layer

Figure 1-11 MPLS oriented IP stack

IP-H TCP-H Application Data IP Datgram

MPLS-H IP-H TCP-H Application Data Labelled IP

Datagram

LABEL EXP S TTL Header MPLS

20 Bit 3 1 8

32 bit

Figure 1-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 Examples of functions: traffic classification, packet marking traffic policing, traffic

shaping, buffer management, congestion avoidance, queuing and scheduling

o transfer the user data flows and accomplish the traffic control mechanisms to assure

the desired level of QoS

• Control plane (CPl)

o controls the pathways for user data traffic: e.g. Admission control, Routing, Resource

reservation.

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 sub-

planes: inter-domain and intra-domain. This approach allows each domain to have its

own management and control policies and mechanisms.

• Management plane (MPl)

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

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

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 path-

coupled 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

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

RS-Sem II – RST


Transport Level

Applications and

Service Level

Management Plane

User (Data)

Plane

Control Plane

INTERNET

SCN

Figure 1-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 Service provided from HOME service provider

o New “Home Box” concept

� End user as content consumer and/or content provider

• Service provider determines media route

o Service may include in-band media events

o Support for Lawful Intercept

o Call Routing follows the money

o 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

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

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 digital

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.

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

Control Plane

Management Plane

Data Plane

CC ANP CP/CS SP NP

Inter-domain

manager

Figure 1-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.

1.3.4 Service Level Agreements/Specifications (SLA/SLS)

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

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)

(HIGH LEVEL)

SERVICE

PROVIDER 1

USER

RESELLER

CUSTOMER IP NETWORK

PROVIDER 1

PHYSICAL

CONNECTIVITY

PROVIDER 1

PROVIDER/

OPERATOR 1

HIGH LEVEL

SERVICE

PROVIDER N

IP NETWORK

PROVIDER M

PHYSICAL

CONNECTIVITY

PROVIDER P

. . . . .

May be joined

within the same

entity

. . . . .

. . . . .

Content

Provider

USER

USER

Figure 1-15 Generic IP Business Model (I) - and business relationships (SLA)

RS-Sem II – RST


SERVICE

PROVIDER

USER

CUSTOM ER

CONTENT

PROVIDER

CONTENT

M ANAGER

CONTENT

SERVER

IP NETWORK

PROVIDER N

PROVIDER

1

3.n 3.2 3.1

2

5

6 IP NETWORK

PROVIDER N

PHYSICAL

CONNECTIVITY

PROVIDER

PROVIDER

PHYSICAL

CONNECTIVITY

PROVIDER

Data

4. Data pipe QoS guaranteed

established through actions 3.x

…

…

3.1

3.2 3.n

Cascade model

Hub model

Figure 1-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 1-17 Basic IEEE 802.16 multi-plane protocol stack

RS-Sem II – RST


Figure 1-18 (IEEE 802.16g-05/008r2, December 2005)

Figure 1-19 Relation IEEE802.16 vs. WiMAX NWG

RS-Sem II – RST


1.4.2 Generic Example of a multi-plane architecture

Stra

tum

: Ap

plic

atio

n

An

d S

erv

ice

s S

tratu

m: T

ran

sp

ort

Da

ta P

lan

e

Application

Application

Data flow-user

Inter-domain

Resources and traffic Mng. Access & “Core”

Intra-domain Resources and traffic Mng.

Access & “Core”

Services and session Control

Co

ntro

l Pla

n

Control Resurse

Inter & Intra domain

Service Mng. (Planning provisioning,

Offering, monitoring)

Ma

na

ge

me

nt P

lan

e

Control flow

Figure 1-20 Generic example of a multi-plane architecture

1.4.2.1 An Architecture oriented to multimedia distribution over multiple domains networks

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

RS-Sem II – RST


NP3

SM&RM

Content

Provider

Content

Server

Service

Provider

NP1

SM&RM NP2

SM&RM

Content

Consumers

SM&RM = Service Mgmt and

Resource Mgmt

Figure 1-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

NP1

ENTHRONE

NP2

AN

Content

Consumers

Content

Provider

QoS provisioning

QoS adaptation loop

Figure 1-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

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 1-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 1-24 Examples of mesh network topologies:

a) 802.11 connected mesh; b) 802.11 mesh ad hoc

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.

Applications & Services

PHY

Multimode MAC ( 802.11, 802.16, ..)

Convergence Sublayer

TCP/IP

Services and Session

Mng&Ctrl

PHY Mng&Ctrl

Smart Antennas and RAT Control

Data Plane Management and Control Plane

Resource Mng & Control

Coordinator

Acces Control

Mobility Mng

QoS

Data Link Mng&Ctrl QoS, Mobility, RR Control,

Scheduling

Network Coding

Cro

ss L

ayer

Optim

izatio

n

Tra

nsport M

acro

-Layer

Applic

atio

n a

nd

Serv

ice M

acro

-Layer

Data Flows

Routing

Sec

RM&C

Figure 1-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.

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

RS-Sem II – RST


EIR BSC

MS

HLR

GMSC

MSC

VLR

C

MSC

VLR

C PLMN

AUC

ISDN/IN

PSTN

PSPDN Other PLMNs

MS

BTS

Figure 1-26 GSM Network General Architecture

Distribution

DTAP BSSMAP

BSSAP

MS BTS BSC

RIL3-CM

RIL3-

MM

DTAP

RIL3-

RR

I/F radio

LAPDm

4-5-

3

Distrib

Um Abis

RSM

LAPD

64 kb/s

4-5-6

3

RIL3_RR

SCCP

4-5-6

MTP1-3

Releu

LAPDm

I/F radio

4-5-6

3

LAPD

64 kb/s

4-5-6

3

RIL3_RR RSM

Relay

to MSC

anchor

Protocol MM

Protocol CM

PHY Conections

7 OSI-RM

2

1

BSS

MSC/VLR

Relay

A

SCCP

4-5-6

MTP1-3

Distribution

DTAP BSSMAP

BSSAP

RIL3-CM

RIL3-MM

MAP/E

MAP/G

TCAP

NSS

Figure 1-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

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)

RS-Sem II – RST


2 INTERCONNECTION- REVISION

(Romanian)

2.1 Moduri de lucru cu şi fără conexiune CO/CL

• CO/CL

DTE-A DTE-B

ISa

SN3

SN2 SN1

ISc

ISb DTE-C

1 4 3 2

n CO PDU

3 2

1

1 CL PDU

Figura 2-1 Modul de lucru cu şi fără conexiune

IS – Sistem intermediar; SN - subreţea

- CO – fiecare IS joncţionează î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ă păstrarea secvenţei datelor

- Internet îşi poate baza transportul sau pe suporturi fizice ale altor reţele der telecomunicatii (

PSTN, ISDN, CATV, etc.) sau pe suportul unor reţele publice de pachete de arie mare

- elemente interconectabile: sisteme de capăt (“hosts”) , sisteme intermediare (punţi, comutatoare de nivel doi, comutatoare MPLS, rutere), subreţele

A B

P2

P3

P1

P P R

R R

A B

P2

P3

P1

PN

PN

PN

Telco

a b

Figura 2-2 a. Reţea publică cu comutaţie de pachete b. Reţea Internet

PN – Packet Network

2.2 Cerinţele unui serviciu de interconectare (la nivel trei)

- să asigure link-uri între reţele diferite

- adresare şi rutare/dirijare prin reţele diferite

RS-Sem II – RST


- contabilizarea utilizării rersurselor pentru a şti starea fiecărui element de interconectare ( la

nivel de element de reţea; la nivel de domeniu administrativ)

- să furnizeze serviciile de mai sus astfel încât să se poată interconecta la reţele de tipuri diferite

fără a modifica infrastructura internă a fiecăreia; deci trebuie rezolvate problemele:

- scheme de adresare diferite

- dimensiuni maxime diferite ale unităţilor de date (este necesară segmentatare/reasamblare)

- mecanisme de acces la reţea 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

NSAP_1

SNICP

SNDCP

SNDAP

DL’

PHY’

SNDCP

’ SNDAP

’ DL’

PHY’

SNDCP’

’ SNDAP’

’ DL’’

PHY’’

Releu + rutare: SNICP

T

IS

ES/H

Nivel

N = 3

Retea 1 Retea 2

Figura 2-3 Architectura generică a nivelului de reţea

• soluţie pentru acomodarea diferitelor reţele: divizarea nivelului reţea î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 reţea)

- faze: stabilire, menţinere, eliberare de VC

- este nevoie ca toate subreţelele sa cunoasca acelaşi protocol CO pentru a putea construi VC

multi-reţea

- deci presupunem că fiecare subreţea oferă acelaşi 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 subreţele se face prin intermediul aceluiaşi protocol de reţea – nu este nevoie de mai multe subnivele

RS-Sem II – RST


- funcţiunile unui ruter CO :

o funcţie de releu pentru unităţile de date de la o reţea la alta ( “forwarding”)

o selectarea iniţială a rutei (nod cu nod) – are loc în faza de stabilire a conexiunii

o fiecare ruter jonctionează între ele segmente de VC (conexiuni logice)

2.4 Modul de lucru CL (fara conexiune la nivel reţea)

- tratare independentă a fiecarei unităţi de date în fiecare nod de reţea (ruter)

- este util a defini un protocol de reţea comun, independent de diferite tipuri de subreţea

particulare: IP = SNICP (RFC 791) ; ISO 8473 Connectionless Network Protocol (CLNP) -

are funcţiuni similare

- accesul la subreţele 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ă

- Avantaje CL:

- robustete (datorită tratării independente a unităţilor de date - datagrame);

- flexibilitate (poate lucra peste subreţele CO sau CL);

- adaptare naturala la rutare dinamica

- oferă cel mai potrivit serviciu pentru un nivel transport de tip CL

- Dezavantaje CL:

- Servicul nativ este fără garanţii ( “best effort” ) – relativ la bandă, pierderi, întârzieri de transfer, fluctuaţia de intârziere, secvenţialitate

2.5 Interconectarea de tip punte (“Bridge approach”)

- Punte = “bridge” = releu de nivel MAC lucrând în mod CL

- Nu se analizează adresele de nivel trei

- Utilizate de regulă pentru interconectare de LAN-uri

RS-Sem II – RST


A B SN2 SN1 SN3

T

N

L1

P1

R

N N

L1 L2

P1 P2

R

N N

L2 L3

P2 P3

T

N

L3

P3

T

I

N1

L1

P1

I

N1 N2

L1 L2

P1 P2

I

N2 N3

L2 L3

P2 P3

T

I

N3

L3

P3

T

I

LLC

MAC1

P1

Relay

MAC1 MAC2

P1 P2

T

I

LLC

MAC3

P3

Relay

MAC2 MAC3

P2 P3

a

c

b

ISb ISa

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 interconectări

Examplu 1: Conexiune FTP client-server

Client

FTP

TCP

IP

MAC1

ETH

PHY1

IP

MAC1

ETH

MAC2

TR

PHY1 PHY2

Server

FTP

TCP

IP

MAC2

TR

PHY2

Figura 2-5 Acces FTP acces între două reţele LAN via un ruter

Examplu 2: IP peste o configuraţie de subrutele: LAN-reţea publică de pachete -LAN

RS-Sem II – RST


TCP

IP

LLC

MAC

P1

IP

X.25-3

LLC

MAC

X.25-2

P1 P2

A B LAN1 LAN2 WAN

X.25 R1 R2

IP

X.25-3

LLC X.25-2

MAC

P2 P3

TCP

IP

LLC

MAC

P3

1 2

3 4

7 8 6

5

1,6, 7 IP-H TCP-H Date

2, 5 LLC1-H IP-H TCP-H Date

MAC1-H LLC1-H IP-H TCP-H Date MAC1-T

8 P-H IP-H TCP-H Date

DL-H P-H IP-H TCP-H Date DL-T

9

3,4

9

Tunel X.25

Figura 2-6 Operarea protocolului Internet via reţea publică de pachete (WAN ex.

X.25)

Note: - avem acelaşi nivel IP ( SNICP) în toate sistemele ( A, R1, R2, B)

- au loc încapsulări/decapsulări succesive în timp ce PDU traversează in sus şi in jos nivelele

funcţionale (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 reţeaua X.25)

- intarziere de transfer variabilă

Examplu 3: Interconectare de tip punte (distantă) peste o reţea de pachete

RS-Sem II – RST


\

≥ 3

LLC

MAC

P1

Releu

X.25-3

MAC X.25-2

P1 P2

A B LAN1 LAN2 WAN

X.25 B1 B2

Releu

X.25-3

X.25-2

MAC

P2 P3

≥ 3

LLC

MAC

P3

1

2

3 4 6

5

1 Data

2 LLC-H Data

3,4 MAC-H LLC-H Data MAC-T

5 X.25-H MAC-H P-H Data MAC-T

DL-H X.25-H MAC-H P-H Data MAC-T DL-T

6

Figura 2-7 Operarea protocolului Internet prin punţi interconectate la nivel doi printr-o reţea

de pachete ( exemplu: X.25 WAN )

- presupunem că avem în LAN1 si LAN2 acelaşi MAC deşi nu este obligatoriu

- diferenţa faţă de interconectarea IP/WAN este ca in acest caz cadrele de nivel doi sunt

transportate prin tunelul X.25 şi nu datgramele IP

2.6.1 Interconectarea de reţele LAN prin punţi (B)

• Interconectarea de nivel 1 ( prin repetor):

o Permite extinderea distantei fizice

o Stiva arhitecturală este aceeaşi în toate sistemele (nivel 1- nivel 7)

o Repetorul: obiect de interconectare de nivel fizic care regenereaza formatul electric al

semnalului

o Repetor: cost scăzut, dar non-inteligent

o Efect general – aceeaşi reţea dar cu extindere pe dimensiuni fizice mai mari

o Exemplu clasic: reţea Ethernet cu repetoare (Hub)

• Interconectarea la nivel 2 a retelelor locale (LAN ): prin punti (B =Bridge)

- Interconectări pentru reţele cu MAC diferit; LLC şi nivele >2 – aceleaşi

RS-Sem II – RST


Aplicatie

TCP/UDP

IP

(LLC)*

MAC1-ETH

PHY1

Aplicatie

TCP/UDP

IP

(LLC)*

MAC2 –TR

PHY2

Releu (LLC partial)

MAC1-ETH MAC2-TR

PHY1

PHY2

LAN 1 LAN 2

Figura 2-8 Arhitectura de interconectare prin punţi

(*) în principiu LLC poate lipsi

• Cadrele recepţionate de către 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 punţilor (sunt mai importante decât dezavantajele)

o Memorare + retransmisie ⇒ MAC1 poate fi diferit de MAC2. Exemplu : 802.3 –

802.5 – posibile extensii gradate spre tehnologii diferite

o Elimină constrângerile de distanţă fizic (repetorul – interconectare de nivel 1 nu face

asta)

o B este releu pe bază de adresă MAC- transparent la nivele superioare

o Uşurează gestionarea reţelelor mai mari (dacă în B se include SW de management)

o Creşte securitatea reţelelor (datorită filtrării traficului local/extern)

o Creste fiabilitatea /disponibilitatea segmentelor

o Conceptul de B se extinde imediat la comutatoare de nivel 2 ( „Layer 2 switch”)

o Permit crearea de LAN-uri virtuale (VLAN) – foarte important in practică

• Dezavantaje ale punţilor (Problemele de principiu greu rezolvabile/netriviale)

o Lungime diferită de cadre

o Lucru diferit cu priorităţi

o Incompatibilitate între valorile timerelor utilizate

o probleme de gestiune a configuraţiei mixte

Alte probleme:

- lipsa de control de flux la nivel MAC ⇒ posibilitatea supraîncărcării memoriei din B

- memorare + retransmisie ⇒ întârzieri mai mari decăt la interconectarea repetoare

- probleme cu expirări de timere în MAC-uri diferite dacă distanţa este mare

- modificarea cadrelor la traversarea B + calculul pentru noul CRC ⇒ erori eventuale în timpul

translatării (releu) care rămân nedetectate

Concluzii : avantajele sunt mai mari decât dezavantajele ⇒⇒⇒⇒ B utilizate foarte frecvent ( azi sub

formă de comutatoare de nivel 2)

Exemple de standarde:

IEEE 802.1 - punţi transparente

RS-Sem II – RST


IEEE 802.5 – conţine o parte referitoare la B cu rutare de tip sursă

2.6.1.1 Punţi transparente (Transparent Bridges- TB)

Caracteristici generale

• prezenţa în reţea a (n>1) punţi - transparenţa pentru staţiile ce intercomunică

• TB- se iniţializează şi configurează automat la introducerea în reţea (fără o intervenţie specială din partea restului reţelei)

• reconfigurarea dinamică în timpul funcţionării

• sunt prevăzute cu n ≥ 2 porturi pentru n ≥ 2 LAN-uri

• fiecare port are chip-set-uri MAC corespunzătoare tipului de LAN şi SW de gestiune

corespunzător

( SW initializează chip-set-ul; gestionează memoria (buffere) –alocă buffere pentru chip-set MAC din

MAC de recepţie ; 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

3 ROUTING PROTOCOLS

(Romanian)

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

A

D

C

B 2

1 2

1

3

1

asimetric

asimetric

RS-Sem II – RST


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 minm de la un nod sursa catre orice destinatie

- costul oricarei cai = minim ( SPT = Shortest path tree”)

- cost total al arborelui = minim (arbori Steiner)

Clasificarea algoritmilor de rutare

- Centralizati /distribuiti de tip mixt

Criterii de cost/metrica:

- metrica simpla ( 1 criteriu)

- compusa – mai multe criterii

Exemple de metrici: nr. de noduri traversate, intarziere (dinamic) , 1/B, cost admin., grad de incarcare

a unui link (dinamic), cost total al unui arbore, etc.

Obs: n>1 metrici => probleme NP-hard; se cauta solutii aproximante quasi-optime

Se poate dem. in unele cazuri care este departarea fata de optimul teoretic

• Exemple:

2 5 8 11

1

3

7

9

10

4

6

M= {1,5,6,9,11}

Cost/link =1

S

a.

Network graph

1

2 5 8 11

1

3

7

9

10

4

6

M= {1,5,6,9,11}

Cost/link =1

S

b.

Shortest Path Tree (SPT)

Source Specific Tree

C = 8

Dmax = 3

Dav =2.5

1

Figura 3-2 Exemplu de graf si SPT

RS-Sem II – RST


2 5 8 11

1

3

7

9

10

4

6

M= {1,5,6,9,11}

Cost/link =1

S

Group Shared Tree

Example of Steiner Tree

1

Figura 3-3 Arbore Steiner- exemplu

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

imumcT

uv

Evu

min),(

=∑∈

• Steiner nodes = nodes u,v ∈∈∈∈ VT but they do not belong to M

Example

• 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

Constrangeri:

RS-Sem II – RST


• Constraints

– to a link (e.g bandwidth, available buffer, etc.).

– to a path or to the whole tree,

• Tree constraints can be ( m = metric)

– additive (e.g. E2E delay on every path from source to destination)

• 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 the probability that a packet will reach the destination,

being given the loss probability on each link)

• m(u,v) = 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)

• m(u,v) = Min{ m(u,i), m(i,j), …m(pv)}, for a path P( u,I,j, ..v)

Moduri de lucru ale protocolului:

- Proactiv/reactiv/mixt

Clasificare d.p.d.v cunoasterea topologiei:

- vectori de distanta

- link state

Probleme suplimentare:

- 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)

RS-Sem II – RST


S2

S1

R4

R3 R2

R1 R5

RP

S2

S1

R4

R3 R2

R1 R5

S2

S1

R4

R3 R2

R1 R5

Unidirectional tree One tree per source

S1 rooted tree (SPT)

S2 rooted tree (SPT)

Optimised for source specific mc

communication

Unidirectional Shared (by all sources) tree

Components:

Shared tree

Data path S1→RP

Data path S2 → RP

Bidirectional Shared Tree Distribution of S1 data

Distribution of S2 data

Figura 3-4 Tipuri de arbori

3.2 Algoritmi de cautare a celui mai scurt drum

- Retea- echiv cu un graf

- Caut drumul cel mai scurt intre doua noduri d.p.d.v cost

- Cost cu : nr. Noduri/dist./t. intarziere/ inversul benzii

i

k1

k2

j

Figura 3-5 Cautarea drumului minim intre nodurile I si j

dij min = min { dik + dkj}

k

RS-Sem II – RST


unde k este un nod oarecare prin careexista 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: 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

1. Initializare:

N={A}

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

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:

RS-Sem II – RST


A

B(A,1)

D(A,3)

C(A,6)

E(-,∞)

1 1

3

6

3

1

2 4

Initial: N={A}

A

B(A,1)

D(B,2)

C(D,4)

E(D,5)

1 1

3

6

3

1

2 4

Pas (2): N= {A,B,D}

Se adauga D

A

B(A,1)

D(B,2)

C(B,5)

E(-,∞)

1 1

3

6

3

1

2 4

Pas 1: N={A,B}

Se adauga B

= dist. recalculate

V(B) ∩ C (N)

C (N)= complement al

lui N

A

B(A,1)

D(B,2)

C(D,4)

E(D,5)

1 1

3

6

3

1

2 4

Pas (3): N= {A,B,D,C}

Se adauga C

A

B(A,1)

D(B,2)

C(D,4)

E(D,5)

1 1

3

6

3

1

2 4

Pas (4): N= {A,B,D,C, E}

Se adauga E

Arbore de drumuri minime

de la A la B,C,D,E

costuri

Figura 3-6 Exemplu de calcul pentru algoritmul Dijkstra

Arborele de rutare pentru nodul A va fi cel din tabelul de mai jos :

Destinatia Nodul urmator

B B

C B

D B

E B

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.

v

w

t

u

A

duA

dtA

dwA

lau

lat

law

Comparatie:

(lau + duA) < > (lat + dtA) < > (law + dwA)

Vv

Figure 3-1 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.

RS-Sem II – RST


B

A

C

D F

G

E

H1

`

H3

`

H6

`

H7

`

H2

H4

1 2

1

2 2 3

4

4

8

3

7

H4

V( B)

Figure 3-2 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 0 1 1

C 1

D 2

(A, 1)

Lista etichetelor dupa pasul 1.1

B C D E F G

(A,1) (-, ) (-, ) (-, ) (-, ) (-, )

Pasul 1.2 : v = C


ptr. nodul C

A 0 2 2 (A, 2)

RS-Sem II – RST


B 1 1 2

D 3 *

F 3 *

G 2 *

* = se poate inlocui cu x ( nu conteaza)


B C D E F G

(A,1) (A,2) (-, ) (-, ) (-, ) (-, )

Pasul 1.3 : v = D


ptr. nodul D

B 1 2 3

C 2 3 5

G x

(B,3)


B C D E F G

(A,1) (A,2) (B,3) (-, ) (-, ) (-, )

Pasul 1.4 : v = E


ptr. nodul E

A 0 7 7

G x

(A,7)

RS-Sem II – RST



B C D E F G

(A,1) (A,2) (B,3) (A,7) (-, ) (-, )

Pasul 1.5 : v = F


ptr. nodul F

C 2 3 5

G x

(C,5)


B C D E F G

(A,1) (A,2) (B,3) (A,7) (C,5 ) (-, )

Pasul 1.6 : v = G


ptr. nodul G

C 2 2 4

D 3 8 11

E 7 4 11

F 5 4 9

(C,4)


B C D E F G

(A,1) (A,2) (B,3) (A,7) (C,5) (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).

RS-Sem II – RST


B

A

C

D F

G

E

H1

H3

H6

H7

`

H2

H4

12

1

22 3

4

4

8

3

7

H4

Figure 3-3 Arborele drumurilor minime pana la nodul A

Tabelul de rutare pentru nodul A este :

Destinatia Ruta ( via) Cost

H2 B 1

H3 C 2

H4 B 3

H5 E 7

H6 C 5

H7 C 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

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

- don’t 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, “don’t fragment” – bit) – used in segmentation

- fragment offset ( measured in 64 bit units) – used in segmentation

- time to live (TTL) – measured in router hops

RS-Sem II – RST


0 4 8 16 31

Version 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

20

oct.

Figure 3-4 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:

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

UDP TCP netstat

command route

command

Routing

protocol

demon

packet for

this dest?

ICMP

IP process

options

forwarding

(compute

the next

hop)

Routing

table

Source routing

yes

Retransmission

(if valid)

no

update

redirection

Network interface IP layer

Figure 3-5 IP actions on the received datagrams

3.3.3 Network hierarchies

RS-Sem II – RST


Figure 3-6 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.

RS-Sem II – RST


Figure 3-7 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.

RS-Sem II – RST


Single-homed

stub AS

Multi-homed

stub AS

Transit AS

Tier-1, Tier-2 Tier-3

Figure 3-8 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

Today’s 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

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

RS-Sem II – RST


Backbone net

EG

EG

EG

EG SN1

IG

IG IG

N2

SN1

N1 N3

AS1

EGP

IGP IGP

second level IG router

AS2

AS3

EGP

host

iEGP

Figure 3-9 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

Interior Gateway Protocol (IGP) Exterior Gateway Protocol EGP Daemon

HELLO RIP OSPF EGP BGP

routed V1

gated V.2 V1 V1

gated V.3 V1, V2 V2 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

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

IP_addr

(32 bits)

NPA_addr

(e.g. M AC_addr 48 bits)

ARP

RARP

Figure 3-10 ARP and RARP actions

•••• ARP

driver

Ethernet

ARP

driver Ethernet

ARP

TCP

IP

driver

Ethernet

ARP

TCP

IP

FTPDNS

machine name

(1)

machine name

IP address (IP_a)

(0)

(2) setup connection

with IP addr = IP_a

(3) send

IP dg(IP_a) (conn-req)(4)

(5)

(6) (7) (8) send

IP dg(IP-a, MAC_a)

(conn-req)

ARP_req(IP_a)

source

(client)

destination

(server)

Ethernet LAN

Figure 3-11 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

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 WLANS-

MANET

• 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

RS-Sem II – RST


Control Plane

Routing

Protocols

Switch ( bus, matrix,

etc.) Packets

.

.

I/F

I/F

Figure 3-12 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 zero for itself

o one for directly attached networks

o 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

RS-Sem II – RST


a

w

v

u

D

duD

dvD

dwD

lau

lav

law

Comparison:

(lau + duD) < > (lav + dvD) < > (law + dwD)

Message : Routing table of w:

…(D, dWD)…

Figure 3-13 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 Next hop Distance Timers Flags

NetB Router 2 3 (in hop count) t1, t2, t3 x,y

NetA Router1 5 t1, t2, t3 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

RS-Sem II – RST


Figure 3-14 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

R1 Net A

directions to which R2 may forward

and advertise

its route to NetA via R1

R2

(Net A, cost)

Figure 3-15 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 )

RS-Sem II – RST


•

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

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

• AODV uses symmetric links between neighboring nodes. It does not attempt to follow paths

between nodes when one of the nodes cannot hear the other one; o however one may include the use of such links in some enhancements.

• Advantage 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 more time to establish a connection, and the initial communication

to establish a route is heavier than some other approaches.

• AODV is capable of both unicast and multicast routing.

AODV functional details

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, and 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

RS-Sem II – RST


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

A RREQ message carries

- the source identifier (SrcID),

- the destination identifier (DestID),

- the source/originator sequence number (SrcSeqNum),

- the destination sequence number (DestSeqNum),

- the broadcast identifier (BcastID),

- time to live (TTL) field.

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 sequence number at

the intermediate node with the destination sequence number in the RouteRequest packet.

Maintaining Sequence Numbers

Every route table entry at every node MUST include the latest information available about the

sequence number 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".

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

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 sequence number and the destination

sequence number in the RREQ packet.

Generating RREQ

A node disseminates a RREQ when it determines that it needs a route to a destination and does not

have one available.

This can happen

- if the destination is previously unknown to the node,

- or if a previously valid route to the destination expires or is marked as invalid.

The Destination Sequence Number field in the RREQ message is the last known destination

sequence number 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.

RS-Sem II – RST


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

Figure 3-16 AODV route finding (1): RREQ

Figure 3-17 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

RS-Sem II – RST


reachable by way of the broken link.

- 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 short-

lived 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 in Section 6.2)

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

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 variable-

length 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 different destinations/networks) to its

neighbours and not topological info!!

Each R sends link state information to all other routers ( flooding the area)

Info sent = estimate of cost to each

destinations/networks

Info sent by a R is the exact cost of its

links/segments to other networks

Info sent (usually) periodically or at events Info sent when changes appear

Metric = no of hops Different metrics are possible

R determines next hop info by using Bellman

Ford algorithm on the received estimated path

costs

R gets a graph of the network, computes SPF

and builds RT

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

backbone (contiguous set of nets not contained in any area, their attached routers and routers

RS-Sem II – RST


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.

RS-Sem II – RST


Figure 3-18 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

RS-Sem II – RST


o

SN 1

S N 2

SN 3

R 4

3

S N 4

R 2

S N 6

S N 8

S N 7

R 5

R 6R 3

SN 5

R 1

3

2

2

1

8

46

8

8

4

1

1

7

1

1

Figure 3-19 A sample of autonomous system (AS)

SN2

SN3

R4

3

R2

R5

R6R3

R1

3

2

2

1

8

46

8

8

41

1

7

1

1

SN1

SN45

SN5

SN8

SN6

SN7

Figure 3-20 Directed graph of AS

SN – subnetwork R - Router

Destination SN1 SN2 SN3 SN4 SN5 SN6 SN7 SN8

Next hop R3 R3 R3 R3 R3 R5 R5 R6

Distance 11 11 8 7 9 15 15 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.

RS-Sem II – RST


Database description – describes the contents of the topological database, exchanged at

initialisation

Link state request – requests pieces of neighbour’s 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 Router links advertisement (RLA) – collected states of R links to a specific area

o 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

o Summary links Advertisements (SLA) - sent by area border routers, summarises routes to

destination outside the area but within AS

o 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

RS-Sem II – RST


- eBGP, iBGP

•••• BGP-4 messages

Open - open relationship with another router

Update – (1) – transmit info about a single router

(2) – lists multiple routes to be withdrawn

Keepalive (1) – Ack to open

(2) – periodically confirm the neighbour relationship

Notification 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 Marker Marker Marker Marker

2 Length Length Length Length

1 Type Type Type Type

1 Error code1 Version 2 Unfeasible

routes

length

Keepalive

message1 Error

subcode

2 My

Autonomous

System

var Withdrawn

routes

var Data

2 Hold time 2 Total path

attributes

length

Notification

message

4 BGP ID var Path

attributes

1 Opt param.

length

var

var Optional

parameters

Network

layer

reachability

info

Open

message

Update

message

Hold time – minimum time

between two successive

messages (Update or Keep alive)

Keep alive – prevents Hold Time

to expire

Figure 3-21 Border Gateway Protocol message format

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 3-22 General IPv6 datagram format

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)

IPv6 H (40)

(40)

Hop-by-hop Options H

(var)

Routing Header

(var)

Fragment Header

(8)

Authentication Header

(var)

Encapsulation security

Payload H

(var)

Destination Options H

(var)

TCP Header (20)- opt

var. part

Application Data (var)

Next header field

IPv6 Header:

Version (4 bits)

Priority (4) 4 octets

Flow label (24)

Payload length (16)

Next Header (8) 4 octets

Hop limit(8)

Source address ( 128) 32 octets

Destination address ( 128)

Figure 3-23 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)

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,

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

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

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

•IP-QoS Technologies goals

–Provide better predictability and control beyond the current IP “best-effort” service

–several levels of guarantees)

• Basic principle

– 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

RS-Sem II – RST


4.2.1 Application classes

•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.1.1 Elastic applications

•Elastic applications examples

–Request−response

•client server, NFS, RPC, distributed computing, ...

–Interactive, reliable

•short www transactions, telnet, database access, ftp−control, Xwindow,

–Batch

•ftp, remote backup, long http transactions, news transfers, ...

4.2.1.2 Streaming applications

Examples

–Conversational multimedia applications

• voice over IP (VoIP), or videconference over IP

– Interactive multimedia applications

• distributed simulations, network games

– Non−interactive multimedia applications (continuous flow of multimedia information)

• distance learning, audio/video broadcasts,

• news on demand, ...

4.2.2 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);

- Self-similar for Ethernet / Internet traffic;

- Bounded model: deterministic/statistical bound.

RS-Sem II – RST


• Granularity/Difficulties: it is difficult to model precisely the traffic

in multimedia networks due to its varieties and dynamics.

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

Different services (or applications), however, may have quite different needs.

RS-Sem II – RST


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 4-1 QoS functional building blocks (ITU-T)

QoS building block may be specific

- to a network node (e.g. buffer management)

- applicable to a network segment (e.g. QoS routing)

The latter, in particular, requires signaling between network nodes:

RS-Sem II – RST


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

IntServ

DiffServ

Best

Effort

Complexity

Degree of

service

differentiation

Scalability

Per flow: QoS

processing Per class QoS

processing

No QoS

processing

Figure 4-2 IP Services

• Differentiated Services (DiffServ) QoS Technology Characteristics:

Differential treatment of packets based on some marking of them

No distinction between flows inside the core netwwork

RS-Sem II – RST


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 provider’s 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

Reservation based

Fine granularity distinction between flows inside the core netwwork

RS-Sem II – RST


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

4.3.2.1 Traffic Classification (TCl)

RS-Sem II – RST


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

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 queue’s 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.

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

4.3.3.1 Admission Control (AC)

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.

RS-Sem II – RST


4.3.3.2 QoS Signalling

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

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

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 QoS Guarantees (I)

4.4.1.1 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)

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

Routing

Table IP

Routing

Protocol

IPRouting

Routing

protocol

messages

(logical view)

Routing

protocol

messages

(logical view)

Forwarding

Table

Packet processing Packets

.

.

I/F

I/F

Figure 4-3 Block diagram of a Classical IP Router

Placement of the function in a router:

- input

- output

RS-Sem II – RST


Figure 4-4 QoS capable router – generic diagram

In practice, the shaper could also be located on the output link, but we don’t

address this issue here to keep the picture simple and understandable.

4.4.3 IP Level services

4.4.3.1 Best−effort (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 user’s 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

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 non−zero 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 ( low−pass 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 packets begin to be

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

- suitable for routers with a single queue

min_th Max_th

Avg

1

Pd

Pmax

accept Probabilistic

drop Drop all

Min_th

Max_th

Buf_Size

Drop

RS-Sem II – RST


Figure 4-5 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 tail−drop)

• 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();}

Th

Buf_Size

H H+L

Figure 4-6 RED buffer with two level of priorities

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 N−1 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)

min_th(L) Max_th(L)

avg(L+H)

1

Pd

Pmax(L)

min_th(H) Max_th(H)

Avg(H)

1

Pd

Pmax(H)

The average buffer fill is computed

for all packets ( H and L)

The average buffer fill is computed

for packets H only

Figure 4-7 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

RS-Sem II – RST


- 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)

4.4.3.4 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

Classifier Meter

and

Marker

Output buffer

Identified flows Identified

guaranteed or

excess packets

Buffer

acceptance

algorithm

Dropped

packets

Input flows Policing

RS-Sem II – RST


Figure 4-8 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

- difficult to find mathematical models to prove its bounds

o 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

draft−fang−diffserv−tc−tswtcm−00.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.362−373

4.4.4 Packet Classification and Marking

Why need classification of packets?

- similar treatment of a subset of packets ⇒ classification of input packets into flows

RS-Sem II – RST


• Flow : sequence of packets with one common "characteristic" - based on any field of the

packets

• Layer−N flow - sequence of packets with one common layer−N 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 routers recognize the marking (no need of a new

classifying action for each packet)

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

RS-Sem II – RST


Examples:

Application Transport protocol Port number

DHCPBootp UDP 67, 68

DNS TCP/UDP 53

HTTP TCP 80

IMAP TCP/UDP 143, 220

LDAP TCP/UDP 389

MS−SQL TCP 1433

NFS TCP/UDP 2049

NNTP TCP/UDP 119

POP TCP/UDP 109/110

SMTP TCP 25

SNMP TCP/UDP 161, 162

SSH TCP 22

Syslog UDP 14

Telnet TCP 23

X Windows TCP 6000−6003

b. if applications do not use well−known port numbers

- then analyse the contents of control packets for these applications

Examples

FTP: server and client may negotiate other non−default 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 5004−5005 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

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

7

Precedence Type of Service

0 3 6 2

0

1000 minimize delay

0100 maximize throughput

0010 maximize reliability

0001 minimize monetary cost

0000 normal service

Relative

priority

Figure 4-9 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

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

Non-conforming

packets

TP

Conforming

packets

Figure 4-10 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

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*/}

- Traffic anvelope: A(t) = 2B + t/T*B - total amount of bytes accepted by the algorithm in a time interval [0, t)

Drawbacks

- 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

RS-Sem II – RST


Older packet arrivals

New arrival

t1 Time window W t1

Figure 4-11 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): how much data can be sent or

forwarded per unit time on average.

• 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

RS-Sem II – RST


arriving

packets

rate R

token generator

Non-conforming

packets

M

Bucket size

B

Conforming

packets (pass)

Current fill

(c= credit)

M= measuring

algorithm

Discard/mark

Figure 4-12 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

RS-Sem II – RST


Parameters:

Committed Information Rate (CIR)

Committed Burst Size (CBS)

Excess Burst Size (EBS)

arriving

packets

rate CIR token generator

Packets in excess burst (yellow)

Non conforming packets ( red)

CBS

Conforming

packets (green)

M= measuring and

marking algorithm

EBS

M

ce

c

Figure 4-13 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; }

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

arriving

packets rate PR

token

generator

K

conformant packets

peak rate ≤≤≤≤ PR

Non conformant

packets

Figure 4-14 Leaky Bucket principle

Implementation

( equivalent algorithm – no real buffer required)

Variable c is a counter

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

If want to measure/police a flow conforming the parameters

PR - Peak Pate, AR - Average Rate, BS - Burst Size

we can use a cascade of LB(PR) + TB( AR, BS)

arriving

packets

rate AR

token generator

Non-conformant

(AR or BS) packets

Bucket size

BS

Conformant packets

(AR and BS)

rate PR

token

generator

K

conformant

packets

AR, BS, PR

Non conformant

packets (PR)

Figure 4-15 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

RS-Sem II – RST


arriving

packets

rate R

token

generator

capacity K

Control

B

departing

packets

( conformant

flow)

c

Figure 4-16 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

Classifier

Meter

and

Marker

Output buffer

Buffer

acceptance

algorithm

Dropped

packets

Input flows

Policing

Shaping

Figure 4-17 Functional diagram of a simple router

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

RS-Sem II – RST


Classifier

Meter

and

Marker

Output buffers

(queues)

Buffer

acceptance

algorithm

Dropped packets

Input

flows

Policing

Shaping

Scheduler

Figure 4-18 Functional components of a Router system

4.4.7.1 Basic Functions of a Scheduler

• Definitions

Two types of schedulers:

work-conserving scheduler is idle only when there is no packet awaiting service

non-work-conserving scheduler may be idle even if it has packets to serve

- makes the traffic arriving at downstream switches more predictable

- reduces buffer size necessary at output queues and the delay jitter experienced by a

connection

- allows the switch/router to send a packet only when the packet is eligible

for example, if the (k+1)th packet on connection becomes eligible for service only i seconds

after the service of the kth packet, the downstream swicth receives packets on its link no faster than

one every i secs.

- can provide guarantees on delay jitter - but not simple to implement

Functions

- select the packet sent on the output link by selecting a certain queue among all the logical

queues containing containing ≥ one packet, at least

Requirements for scheduler

- be easy to implement in hardware

- support BE and guaranteed services

- provide fairness for BE traffic (max-min fairness is the desired goal)

- provide protection between flows (one flow should not be able to consume bandwidth from

other existing flows)

- provide statistical or deterministic guarantees (bandwidth, delay, jitter)

4.4.7.2 Scheduling Best Effort Flows

BE schedulers should:

- be implementable at high speeds

- provide a fair distribution of bandwidth between active flows to support max−min fairness at

RS-Sem II – RST


network level, independently of congestion control mechanisms inside endsystems

- provide protection between flows ( a misbehaving flow should not be allowed to consume

most of the available bandwidth

- scheduler ensures distribution of output link bandwidth

- the packet discard mechanism should avoid that one flow consume all the available buffer

space

What can be done in case of congestion of one router?

- Frames should be fairly discarded when congestion appears

- To identify this congesting flow one consider the queue length of all flows

- Flow with longest queue is responsible for congestion (the rate of emtying the queue is lower

than the rate of entrance of new packets)

Solution: discard packet(s) from longest queue:

- at tail of the queue, at head of the queue or complete queue

4.4.7.2.1 Round Robin (RR)

Principle:

- suppose we have N queues Q1, Q2, …QN for N flows F1, F2, …FN

- serve the active queues one after the other :

Q1 → Q2 → Q3 → … QN → Q1

Advantages

- easily implemented in hardware

- offer protection for best−effort traffic

- fair distribution of bandwidth with fixed−size packets

- but fairness is only provided at timescales larger than schedule

Disadvantages: - one long packet can monopolize the output therefore RR exhibits unfairness with

variable length packets

Example

F1, F2, F3 – flows of packets

L = relative length for sending packets on the output link

T = conventional time interval required to transmit a packet of length L, on the output link

- to keep the figure simple it is supposed that the packet arrivals in the three queues associated to the

flows are: T, 2T, 3T, …

RS-Sem II – RST


F1

F2

F3

P0 P1 P3

P0

P2

P1

P0

time

L=1

L=2

L=1

P0

F1

P0

F2

P0

F3

P1

F1

P1

F2

P2

F1

P3

F1

Unfairness - a longer packet

can monopolize the output link-

Figure 4-19 Round Robin scheduling example

4.4.7.2.2 Deficit Round Robin (DRR)

Input

flows

Cyclic visit of

the queues

( bring credit)

F1

F2

F1

FN

F2

FN

credit

Can be sent

(enough credit)

Cannot be sent yet

(not enough credit)

Figure 4-20 Deficit Round Robin principle

Principle

Round-Robin scheduling plus a credit variable for each queue

- Credit accumulated in an associate counter Ci to each queue

- every time Qi is visited ⇒ Ci = Ci + ∆ ( quantum of credit)

- if length of the first packet of Qi is less then credit then the packet can be transmitted and

credit decreased with the length of the packet; otherwise the packet will wait accumulation of credit

Initialization:

For i=1 to N do { Ci = 0; }

Repeat forever

{ For i=1 to N do

RS-Sem II – RST


{Ci = Ci + ∆; /*increase credt each time when a queue is visited*/

while [(Ci > 0) and not_empty(Qi ) and length(first_pachet) < Ci)

do

{move_first_packet_in_output_link_queue( );

Ci = Ci- length(first_pachet);

}

if (empty(Qi)) then Ci =0; /* not used credit is cancelled if the queue is empty*/

}

}

Example of DRR algorithm

Let N= 4 flows; C1, ..C4 – deficit counters (credit conteiners)

Quantum of credit is ∆ = 1000 [octets]

In Figure 1-51 the queue contents are represented by the existent packet lengths

Round 1 of queues exploration:

- Q1 has three packets of lengths 200, 600, 1300: The first credit icrement brings 1000

units , therefore we can successively extract/send from Q1: 200, 600; the credit left is 200

hence the packet 1300 cannot be sent

- Q2 is empty – it gets no credit

- Q3 has two packets of lengths 600, 1100; one can send 600 and 1100 still waits for more

credit ( 400 is left after the first transmission)

- Q4 has a single packet (400( which can be sent in Round 1; for the moment Q4 is empty

so the credit left of 600 is cancelled

Round 2 of queues exploration:

- Q1 has one packets of lengths 1300; after credit incrementation the new credit is 1200 but

this is not enough to send a packet of length=1300, so this packet should still wait in the

queue, unt6il enough credit is accumulated

- meantime Q2 has received a new packet ( length = 500) , so this can be sent in Round 2;

Q2 becomes empty, so the credit left will be =0

- …….

RS-Sem II – RST


Q1

200

600

1300

F1

F2

F3

Round 1

1 3 4 2

C1

C2

C3

F4 C4

1 3 4 2 1

Q3

1100

Q4

800

Q1

1300

Q2

Q4

400

Q2

500

Q1

1300

Q3

600 1100

500 800

New packets

1000

200- left after 200, 600 are output

1200- not enough credit for 1300

length packet

2200

1000

1000

1000 1000

400 1400

Q2- empty – credit is zero

Q4- is empty – credit is cancelled

Cannot be sent yet

- not enough credit

Now the packet

is sent

Figure 4-21 Example of DRR scheduling

4.4.7.3 Schedulers for Guaranteed Flow Goals:

• Efficiently support flows with minimum and maximum guaranteed bandwidth

• provide bandwidth and delay guarantees

• Provide protection between flows: , a potentially misbehaving flow should not be able to

jeopardize the guarantees committed to other flows

• Implementable at high speeds

4.4.7.3.1 Priority-based scheduler

- simple approach :

- define N logical queues having different priorities –each priority is class C1, C2, C3, …

- each flow is classified to belong to one class (there can be several flows belonging to the

same class)

- the class queues are served conforming to their priority in a decreasing until the current

queue is empty

- each queue is served in FIFO order

Algorithm for Packet sending:

Repeat

{ For i=1 to N do

RS-Sem II – RST


{if (QCi not empty) then serve_QCi;

else i= i+1;}

} until all_queues_void( )

Advantages of priority scheduling

- easy to implement

- assure low delays for high priority class packets

Disadvantages

- no protection

- a high priority flow can always be served , preventing lower priorities flow for transmitting for

long time (this can be not acceptable in some cases)

4.4.7.3.2 Weighted Round Robin (WRR)

Modification of RR to assure more fairness and also control of allocated bandwidth

Suppose we have N flows

- one active flow Fk gets a weight Wk (percentage of bandwidth)

- with ∑Wi,= 1, i=1 ..N.

- the relative amount of number of visits of the scheduler for a flow Fk is proportional with

Wk

Example :

- the scheduling cycle is seen as a macro-cycle composed of a M cycles

- in each cycle no i some queues are visited, other are not

- the queues visited in this cycle are determined by a vector

vi= (wi1, wi2, …wiN), with

wik = 1 if the queue of Fk is visited and

wik = 0 if the queue of Fk is not visited

V = {v1, v2, ..vM}

Wk = (∑wi k , i =1, ..M) /(∑wi k , i =1, ..M, k = 1,..N)

Numerical example:

N=4, M=3, V = {(1,0,1,0), (1,1,1,0), (1,1,0,1)}

In this case ∑wi k = 8, for i =1, ..M, k = 1,..N

W1 = 3/8, W2= 2/8, W3 = 2/8, W4 = 1/8

WRR advantages: easy to implement with short schedule, different weights provide different

bandwidths, assures inter−flow protection

WRR disadvantages: to support many flows, each one having a small amount of bandwidth, a long

schedule ( high M value) is required – increased complexity

RS-Sem II – RST


4.4.7.3.3 Weighted Fair Queuing

Objective: Define an implementable approximation for GPS

The key idea: simulate GPS on a per-packet basis and serve the packets in (approximately) the same

order as GPS would do

Implementation: compute the time instants at which GPS would serve each packet (finish time) and

serve packets in order of finish times

• Virtual Clock (1)

- approximation of GPS

- assign one timestamp to each arriving packet

- scheduler selects among all the queued packets the packet with the smallest timestamp for

transmission (Earliest Deadline First –EDF scheduling policy )

Notations:

Bi - bandwidth associated with Qi

Vi : state variable associated with Qi

Arrival of a packet P of L bytes long in Qi

Vi = Vi + ( L / Bi)

- associate V[i] with the packet

- scheduler selects the packet with the smallest timestamp for transmission

L.Zhang. VirtualClock: A new traffic control algorithm for packet switching.

ACM Transactions on Computing Systems, 9(2):101−−124, May 1991.

F1

F2

F3

P0 P1 P2

P0

P1

P1

P0

time

L=1

B1=1

L=1

B2=1

Output

B=3

P0

F1

P0

F3

P1

F1

P1

F3

P1

F2

P2

F1 P2

F2

0+1/1 =1 1+1=2

0

L=1

B3=1

2+1=3

1 2 3 4 5 6 7 8

1+1 =2 0+1 =1

0+1 =1 1+1 =2

P0

F2

P2

2+1 =3

Figure 4-22 WFQ (1) scheduling example 1

Note:

RS-Sem II – RST


- if a flow is inactive its virtual clock will not advance, so we can say that this flow will

gets some precedence in the future w.r.t the pther flows ( credit not used by an inactive

flow will be accumulated in time) – see Example 2

- disadvantage: allow long bursts of a flow which has been inactive and suddenly becomes

active

F1

F2

F3

P0 P1 P2

P0

P1

P1

P0

time

L=1

B1=1

L=1

B2=1

Output

B=3

P0

F1

P0

F2

P1

F2

P0

F3

P1

F3

P2

F1

0+1/1 =1 1+1=2

0

L=1

B3=1

2+1=3

1 2 3 4 5 6 7 8

1+1 =2 0+1 =1

0+1 =1 1+1 =2

P1

F1

P2

2+1 =3

←←←← V1

2+1 =3

←←←← V2

←←←← V3

P3

3+1=4

V3 = 0

P2

F3

P3

F1

These packets have priority to be sent

because V3 < V1, V2


• Virtual Clock (2)

- The credit not used by an inactive flow will be lost

- arrival of a packet P having length L [bytes] at time t

Vi = max (t , Vi) + ( L / Bi)

- When an inactive flow become active at t=tk then its VC takes immediately the value of

current time, therefore the prvious credit of his flow is lost

RS-Sem II – RST


F1

F2

F3

P0 P1 P2

P0

P1

P1

P0

time

L=1

B1=1

L=1

B2=1

Output

B=3

P0

F1

P0

F2

P2

F1

P0

F3

P3

F1

P2

F2

0+1/1 =1 max (2,1)+1=3

0

L=1

B3=1

max(4,3)+1=5

1 2 3 4 5 6 7 8

max(3,2)+1 =4 max (1,0) +1 =2

max(5,0) +1=6 max(6,6) +1 =7

P1

F1

P2

max(6,4) +1 =7

←←←← V1

2+1 =3

←←←← V2

←←←← V3

P3

max(5,5) +1=6

P1

F3

P2

F3

max (t, Vi) ,1)+Li/Bi=3

V3=0

P2

max(7,7) +1 =8

P1

F2


This burst will increase strongly the VC of

F1, (slope greater than t)

F1

F2

F3

time

V3=0

Q3

Q2

Q1

V2=0

F2 and F3 will have precedence on F1

until the three VCs become comparable


5 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

RS-Sem II – RST


[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 Authentication, Authorisation and Accounting

AAL ATM Adaptation Layer

ABR Available Bit Rate

AC Admission Control

ADSL Asymmetric Digital Subscriber Line

AF Assured Forwarding

AN Access Network

ANG Access Network Gateway

AP Access Point

API Application Programming Interface

AQ&S Advanced Queuing and Scheduling

AQM Advanced (Queue) Management

AR Access Router

ARP Address Resolution Protocol

ARQ Automatic Repeat Request

AS Autonomous System

ATM Asynchronous Transfer Mode

BA Behaviour Aggregate

BB Bandwidth Broker

BE Best Effort

BGP Border Gateway Protocol

B-ICI Broadband Intercarrier Interface

BISDN Broadband Integrated Services Digital Network

BR Border Router

CA Congestion Avoidance

CAC Connection Admission Control

CAS Channel Associated Signalling

CBQ Class Based Queuing

CBR Constraint-based Routing

CBR Constant Bit Rate

RS-Sem II – RST


CC Content Consumer

CDMA Code Division Multiple Access

CDV Cell Delay Variation

CER Cell Error Rate

CES Circuit Emulation Service

CIM Common Information Model

CL Connectionless

CLI Command Line Interface

CLP Cell Loss Priority

CLR Cell Loss Rate

CMR Cell Misinsertion Rate

CO Connection Oriented

COPS Common Open Policy Service Protocol

CP Content Provider

CPCS Common Part Convergence Sublayer

CPE Customer Premises Equipment

CR Core Router

CS Convergence sublayer (adaptation)

cSLA Customer Service Level Agreement

cSLS SLS between customers and providers

cSLS Customer Service Level Specification

DB Database

DCCP Datagram Congestion Control Protocol

DI Digital Item

DiffServ Differentiated Services

DLCI Data Link Connection Identifier

DNS Domain Name Service

DS Differentiated Services (DiffServ), IETF Working Group

DSCP Differentiated Services Code Point

DSL Digital Subscriber Line

DSLAM Digital Subscriber Line Access Multiplexer

DVA Distance Vector Algorithm

DVB-S Digital Video Broadcast- Sattelite

DVB-T Digital Video Broadcast- Terrestrial

E2E End-to-End

ECN Explicit Congestion Notification

EF Expedited Forwarding

EFSM Extended Finite State Machines

EG Exterior(Border) Gateway

RS-Sem II – RST


ER Edge Router

ES/H End System/Host

FCFS First Come First Served

FDM Frequency Division Multiplexing

FDMA Frequency Division Multiple Access

FEC Forward Error Control

FEC Forwarding Equivalence Class

FIFO First-In First-Out (queue)

FR Frame Relay

GFC Generic Flow Control

GK Gate Keeper

GOP Group of Pictures

GPS Global Position System

GRED Generalized RED

GSM Global System for Mobile Communication

GW Gateway

HDSL High bit-rate Digital Subscriber Line

HEC Header Error Check

HTML Hypertext Mark-up Language

HTTP Hyper Text Transfer Protocol (IETF, W3C)

H-WRR Hierarchical WRR

IAB Internet Architecture Board

ICMP Internet Control Messages Protocol

IE Information Element

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IG Interior Gateway( Router)

IMA Inverse Multiplexing ATM

IMS Integrated Multimedia Subsystem

IntServ Integrated Services

IP Internet Protocol

IPC Inter Process Communication

IRTF Internet Research Task Force

IS Intermediate System

IS see IntServ

LAN Local Area Network

LANE LAN emulation

LAPD Link Access Procedure for D Channel

LB Leaky Bucket

RS-Sem II – RST


LDAP Large Directories Access Protocol

LDP Label Distribution Protocol

LLC Logical Link Control

LSP Label Switched Path

LSR Label Switched Route

LVC Label Virtual Circuit

MAC Medium Access Control

MAN Metropolitan Area Network

MCTD Mean Cell Transfer Delay

MDT Mean down-time

MF Multi Field

MGCP Media Gateway Control Protocol

MGW Media Gateway

MIB Management Information Base

MIB Management Information Base

MPEG Moving Picture Experts Group

MPLS Multiprotocol Label Switching

MPOA Multiprotocol over ATM

MSC Message Sequence Chart

MT Mobile Terminal

MTTR Mean time to repair/patch

NC Network Controller

NE Network Element

NGN Next Generation Network

NLRI Network Layer Reachability Information

NM Network Manager

NNI Network Network Interface

NP Network Provider

NPA Network Point of Attachment ( Physical Address)

NQoS Network QoS

nrt-VBR Non-real-time Variable Bit Rate

NSAP Network Service Access Point

NSIS Next Steps in Signalling

NTP Network Time Protocol

OA Ordered Aggregate

OAM Operation and Maintenance

OFDM Orthogonal Frequency Division Multiplexing

OSF Open Software Foundation

OSI - RM Open System Interconnection - Reference Model

RS-Sem II – RST


OSPF Open Shortest Path First

PBM Policy Based Management

PBNM Policy Based Network Management

PCM Pulse Code Modulation

PDB Per Domain Behaviour

PDH Plesiochronous Digital Hierarchy

PDP Policy Decision Point

PDU Protocol Data Unit

PDV Packet Delay Variation

PEP Policy Enforcement Point

PHB Per Hop Behaviour

PHP Penultimate Hop Popping

PID Program Identifier

PIM Protocol Independent Multicast

PMD Physical Medium Dependent

PMT Policy management tool

PNNI Private Network-Network Interface

POSIX Portable Operating System Interface

POTS Plain Old Telephone Service

PPP Point to Point Protocol

PQ Priority Queuing

PQoS Perceived QoS

PR Policy Repository

PRIO Priority

pSLA Provider Service Level Agreement

pSLS SLS between providers

pSLS Provider Service Level Specification

PSTN Public Switched Telephone Network

PT Payload Type

PTD Packet Transfer Delay

QC Quality of Service Class

QoS Quality of Services

RARP Reverse Address Resolution Protocol

RED Random Early Drop

RFC Request for Comments

RIP Routing Information Protocol

RM Resource Manager

RM Resource Manager

RSVP Resource reservation protocol

RS-Sem II – RST


rt -VBR Real-time Variable Bit Rate

RTCP Realtime Control Protocol

RTD Round Trip Delay

RTP Realtime Transport Protocol

RTT Round Trip Time

SAC Subscription Admission Control

SAP Service Access Point

SAR Segmentation/reassembling

SCTP Stream Control Transmission Protocol

SDH Synchronous Digital Hierarchy

SDR Service Discovery Repository

SDU Service Data Unit

SIP Session Initiation Protocol

SLA Service Level Agreement

SLS Service Level Specification

SM Service Manager

SMDS Switched Multimegabit Data Service

SMI Structure of Management Information

SMTP Simple Mail Transfer Protocol

SNDAP Subnetwork Dependent Network Access Protocol

SNDCP Subnetwork Dependent Convergence Protocol

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SONET Synchronous Optical Network

SP Service Provider

SQL Structured Query Language

SS7 Signalling System No.7

SSCOP Service Specific Connection Oriented Protocol

SSCS Service Specific Convergence Sublayer

STP Signaling Transfer Point

SVC Signalling Virtual Channels

TBF Token Bucket Flow

TC Traffic Control

TCP Transmission Control Protocol

TCS Traffic Conditioning Specification

TD Traffic Demand

TDM Time Division Multiplexing

TDM Terminal Device Manager

TE Traffic Engineering

RS-Sem II – RST


TLI Transport Layer Interface

TME Existing Subscriptions TM

TMN New Subscriptions TM

TP Traffic Policing

TS Traffic Shaping

TSAP Transport Service Access Point

TSPEC Traffic Specification

TT Traffic Trunk

UBR Unspecified Bit Rate

UDP User Datagram Protocol

UED User Environment Description

UNI User network Interface

UPC Usage Parameter Control

UTRAN Universal Terrestrial Radio Access Network

VBR Variable Bit Rate

VC Virtual Channel

VCC Virtual Channel Connection

VCI Virtual Channel Identifier

VoD Video on-demand

VoIP Voice over IP

VP Virtual Path

VPC Virtual Path Connection

VPI Virtual Path Identifier

VPN Virtual Private Network

WAN Wide Area Network

WDM Wavelength Division Multiplexing

WFQ Weighted Fair Queuing

WRR Weighted Round Robin

XML Extensible mark-up language

6 ANNEX 1

6.1 Ethernet Frame Formats:

RS-Sem II – RST


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 Min Size Max Size Min w/o Preamble Max w/o Preamble

Preamble 7 7

Start of frame delimiter 1 1

Dst 6 6 6 6

Src 6 6 6 6

Type/Length 2 2 2 2

Data 46 1500 46 1500

Checksum 4 4 4 4

Total 72 1526 64 1518

RS-Sem II – RST


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

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.

RS-Sem II – RST


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

0 1 2 3

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

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

| Type |J|R|G|D|U| Reserved | Hop Count |

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

| RREQ ID |

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

| Destination IP Address |

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

| Destination Sequence Number |

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

| Originator IP Address |

RS-Sem II – RST


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

| Originator Sequence Number |

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

The format of the Route Request message is illustrated above, and contains the following fields:

Type 1

J Join flag; reserved for multicast.

R Repair flag; reserved for multicast.

G Gratuitous RREP flag; indicates whether a gratuitous RREP should be unicast to the node

specified in the Destination IP Address field

D Destination only flag; indicates only the destination may respond to this RREQ

U Unknown sequence number; indicates the destination sequence number is unknown

Reserved Sent as 0; ignored on reception.

Hop Count The number of hops from the Originator IP Address to the node handling the request.

RREQ ID A sequence number uniquely identifying the particular RREQ when taken in conjunction

with the originating node's IP address.

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

The current sequence number to be used in the route entry pointing towards the originator

of the route request.

5.2. Route Reply (RREP) Message Format

0 1 2 3

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

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

| Type |R|A| Reserved |Prefix Sz| Hop Count |

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

| Destination IP address |

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

| Destination Sequence Number |

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

| Originator IP address |

RS-Sem II – RST


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

| Lifetime |

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

The format of the Route Reply message is illustrated above, and contains the following fields:

Type 2

R Repair flag; used for multicast.

A 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 for which the route is supplied.

Lifetime The time in milliseconds for which nodes receiving the RREP consider the route to be valid.

rs-2011-2012-v0.5-8mai 2012

Documents