EP1792444A1 - Etablissement de la qualite de services a travers une succession de reseaux - Google Patents

Etablissement de la qualite de services a travers une succession de reseaux

Info

Publication number
EP1792444A1
EP1792444A1 EP05784569A EP05784569A EP1792444A1 EP 1792444 A1 EP1792444 A1 EP 1792444A1 EP 05784569 A EP05784569 A EP 05784569A EP 05784569 A EP05784569 A EP 05784569A EP 1792444 A1 EP1792444 A1 EP 1792444A1
Authority
EP
European Patent Office
Prior art keywords
qos
network
service
traffic
mapping
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05784569A
Other languages
German (de)
English (en)
Inventor
Thomas Engel
John W. Floroiu
Götz Lichtwald
Karl Schrodi
Thomas Schwabe
Dorgham Sislaem
Birger Toedtmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV, Siemens AG, Nokia Siemens Networks GmbH and Co KG filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority to EP05784569A priority Critical patent/EP1792444A1/fr
Publication of EP1792444A1 publication Critical patent/EP1792444A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2491—Mapping quality of service [QoS] requirements between different networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS

Definitions

  • the invention relates to a method for coordinating QoS provisioning by a first and a second communication network and an apparatus having means adapted for carrying out such a method.
  • IP Internet
  • Future enhanced packet networks are intended to support applications that include transmissions of voice, video and data streams. Such services require timely delivery of data packets. Low latency, small delay jitter as well as very low packet loss rates are required.
  • Next Generation Networks Next Generation Networks (NGNs) below, will implement a number of advanced service classes in addition to the traditional best effort service. These advanced service classes will guarantee that data packets are delivered to their destinations without exceeding certain delay, jitter and loss limits to a very high probability. Guarantees or limits will be specific to individual kinds of traffic or classes of service.
  • the implementation of the above service classes is likely to be based on the DiffServ model defined by the IETF (Internet Engineering Task Force) in [RFC2474] and [RFC2475] .
  • the basic DiffServ model defined in [RFC2474] and [RFC2475] is complemented by literature about bandwidth brokers, inter- domain control plane architectures and signalling protocols like BGRP (Border Gateway Reservation Protocol) , SICAP (Shared-Segment Inter-domain Control Aggregation Protocol) , SIBBS (Simple Inter-Domain Bandwidth Broker Specification) , and protocols which emerge from NSIS (New Steps in Signalling), an IETF working group.
  • BGRP Bit Gateway Reservation Protocol
  • SICAP Shared-Segment Inter-domain Control Aggregation Protocol
  • SIBBS Simple Inter-Domain Bandwidth Broker Specification
  • a user or application has to successfully pass admission control for each flow.
  • a resource reservation request is issued by the end system (hosting the user and his applications) . It specifies the characteristics of the traffic that is to be transmitted and the required end-to-end QoS.
  • this request is transmitted by means of a signalling protocol across multiple NGNs (i.e. along a route) to a destination. Each NGN along the route has to decide whether it can support the requested QoS. Resources for the requested transmission service are then reserved. A flow is only admitted if all NGNs involved comply with the request.
  • the ingress border router of each NGN will open a gate for the flow, i.e. set up a classifier, a marker, and a policer accordingly.
  • the end system Upon admission the end system transmits the flow with the requested QoS on the condition that the announced traffic profile is not exceeded.
  • two-side or bilateral mappings of QoS (Quality of Service) indicators between neighbouring networks are performed to allow for combining individual service classes to end-to-end services.
  • QoS Quality of Service
  • a person skilled in the art will appreciate that the inventive concept may be extended to many-side or multilateral mappings without the need for globally accepted or standardised QoS indicators or service classes.
  • the invention employs QoS indicators or identifiers to specify the required treatment of QoS traffic by a network.
  • the QoS provisioning is coordinated or linked my means of mapping of QoS indicators. This mapping may be performed via a service class table.
  • a set of QoS indicators is negotiated. This set of QoS indicators is locally defined in that sense that it is used or recognized by two or more adjacent networks, but as a rule not by all networks along an end-to-end route. These QoS indicators are associated with specific QoS requirements or service classes.
  • the negotiation process may be carried out in the form of SLAs (service level agreements) . Below the invention is set out with respect two adjacent or neighbouring networks, which are referred to as the first and the second network.
  • First QoS indicators are fixed for QoS traffic to be transmitted from the first to the second network. Such QoS traffic is provided with a first QoS indicator. Upon transmission to the second network the first QoS indicator is mapped to a second QoS indicator and the QoS traffic is provided with the second QoS indicator, e.g. by replacing the first QoS indicators.
  • the second QoS indicator ensures that QoS traffic is processed as such in the second network.
  • a QoS indicator may be given by a DSCP (differentiated service code point) value defined in the DiffServ concept. DSCP values are commonly inserted in a data packet header and thus can be extracted for interpretation and assignation of a service class. Usually, QoS indicators will correspond to service classes.
  • the QoS indicator may also be used to identify the requisite traffic policing or traffic conditioning measures.
  • the present invention does not require standardised or globally defined services as a prerequisite for transmitting QoS traffic across multiple networks.
  • Modern networks such as NGNs, may start with a set of service classes, add and delete service classes, as well as adopt the service classes supported by other networks, i.e. the invention is conductive to a gradual development of de facto standards by evolution and propagation of initial service classes.
  • the flexibility is compounded by the fact that the individual networks may use additional service classes that are only defined within the network. Such service classes may be used for offering services to one's own customers only, i.e. for traffic that stays within the network.
  • first QoS indicators may be mapped to different second QoS indicators. That way the mapping is injective and the ordering of traffic classes may be kept transitive across an end-to-end route.
  • an injective mapping of QoS indicators the number of inter-domain service classes need not to be the same for each network, but different service classes are never mapped to the same service class. Traffic of different service classes is then not to be marked with the same QoS indicator. This way of mapping also insures that no service class will vanish.
  • Service classes will be transitive along end-to-end routes: packets or traffic of different service classes will carry distinguishable QoS indicators everywhere, even in networks that implement a lower number of service classes.
  • QoS traffic with a first QoS indicator that cannot be mapped to a second QoS indicator may be subjected to a standard treatment for non-QoS traffic or discarded.
  • transmission of QoS traffic from the first to the second network is preceded by requesting a resource reservation for transmission of QoS traffic.
  • For a resource request according to a first service class the request is rejected by the second network if it is not able to support or recognize said first service class.
  • the mapping may be performed at an ingress point of the second network.
  • This ingress point may be given by a router, a gateway or any other network element equipped with requisite mapping means, such as a service class table and software for changing QoS indicators of QoS traffic.
  • mapping may be performed at an egress point of the first network.
  • Fig. 1 a number of networks adapted for the inventive concept
  • Fig. 2 a flow chart illustrating an embodiment of the method according to the invention
  • Fig. 3 a flow chart for control measures within an employment scenario of the invention
  • networks are given by IP (Internet Protocol) based NGNs (new generation networks), i.e. packet networks enhanced for real time services.
  • IP Internet Protocol
  • NGNs new generation networks
  • Each network is assumed to support a small, fixed number of service classes at its network boundary for end-to-end QoS (Quality of service) provisioning across networks.
  • these service classes are called inter-domain service classes (IDSCs) .
  • a network may use additional service classes to offer further services to their own customers only, i.e. for traffic that does not cross further NGNs.
  • Neighbouring NGNs are assumed to use bilateral agreements, also called service level agreements (SLAs), to determine rules for mapping their IDSCs. These agreements are accompanied by bilaterally agreed DSCP (differentiated service code point) values which are used to mark or indicate the IP packets belonging to IDSCs.
  • SLAs service level agreements
  • IP packets of an IDSC that are transmitted from a neighbouring NGN to an ingress border router of a subsequent network have to be marked with agreed DSCP values.
  • Packets of different service classes are marked with different DSCP values, and packets not belonging to IDSCs must not use one of the DSCP values agreed for IDSCs.
  • Packets of an IDSC that are forwarded via an egress border router to a next hop NGN are marked with agreed DSCP values in the same way.
  • a network will use the same DSCP marking for all packets of an IDSC within its boundaries and will even not change these DSCP values at egress border routers. So, agreed DSCP values allow straightforward classification of incoming IP packets and are changed at ingress border routers only.
  • Figure 1 shows an example where five NGNs are interconnected by bilateral exchange points Rl ⁇ -»R41 and R45 ⁇ -»R5 and a multilateral exchange point XP, respectively.
  • the tables T41, T42 and T5 show examples of SCTs (service class tables) .
  • the last column of the table provides the maximum bandwidth in Mbps for the respective traffic envelopes .
  • the layer 2 source address is used to identify the source NGN as indicated in table T42. This way to proceed allows for independent usage of DSCP values. Packets that arrive via router Rl at border router R41 and that are marked with value 8 in the DSCP field are identified to belong to an IDSC.
  • each ingress border router uses a service class table (SCT) .
  • SCT service class table
  • a SCT translates DSCP values of incoming packets into internally used DSCP values and includes agreed traffic envelopes (see figure 2) .
  • the border router checks whether it belongs to an IDSC in step (2), i.e. whether it carries a DSCP value listed in its SCT. If it does carry a listed DSCP value, the DSCP value of the packet is changed according to the SCT in step (3) . Otherwise, standard packet processing is applied in step (9) .
  • a policer uses the traffic limits of the SCT to check whether the packet exceeds any traffic limit (e.g. maximum data rate or sustainable and peak rate provided by token buckets) . Packets within the traffic limits are forwarded in step (5) . Packets exceeding any limit are treated as agreed in step (7) or (8) by dropping or downgrading to best effort.
  • any traffic limit e.g. maximum data rate or sustainable and peak rate provided by token buckets
  • DSCP mapping and policing described by the SCT are configured statically. Only the traffic envelope used by the policer is adapted dynamically to the actual traffic volume changing with arrival and termination of flows as shown in figure 3.
  • a network need not to implement a different per hop behaviour (PHB) for each of its IDSC offered at the network boundary.
  • PHB per hop behaviour
  • a network may feed the packets of two or more IDSCs into the same queue at each router and let them experience the same PHB within this network. But it is important to preserve the mapping of IP packets to IDSCs per neighbour. IP packets received from the same neighbouring NGN that belong to different IDSCs have to be mapped to distinguishable IDSCs again.
  • IP packets of different service classes must not be marked with the same DSCP value. This insures that no service class will vanish.
  • Service classes are transitive: packets of different service classes will carry distinguishable DSCP values everywhere, even in NGNs that implement a lower number of service classes.
  • a network If a network is not able to support a certain IDSC of its neighbour by mapping to one of its own IDSCs, it must reject corresponding resource requests in the control plane as shown in figure 3.
  • a service request is received (1), it is checked whether the requested service class is supported (2) .
  • To be processed a request also needs to pass an admission control (3) so that sufficiency of resources is ensured.
  • the service class is supported (1) and the admission control is passed (2) the maximum rate of the traffic envelope in the SCT and the policer are accordingly adjusted (4) . Otherwise, the request is rejected (5) .
  • packets of a certain service class of a neighbouring NGN are either forwarded with a distinguishable DSCP value or the admission control (or policy control) will reject all corresponding service requests. This allows new service classes to be introduced partially and to be adopted by more NGNs in time or to die out again.
  • Traffic transmitted from access networks will be classified by the source address, source port, destination address, destination port, and protocol id fields as usually, i.e. need not to be pre-marked with DSCP values.
  • the SCT of an ingress router may be configured by network management or may be retrieved from an SLA database using the identifiers of the respective interface and the connected neighbouring router or network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention porte sur un procédé et un appareil de coordination de l'établissement de la qualité de service (QoS) à travers une succession de réseaux. Selon l'invention, les QoS d'un premier et d'un deuxième réseau sont coordonnés via une mise en correspondance bilatérale des paramètres de QoS. Pour pouvoir effectuer cette mise en correspondance, on se met d'abord d'accord sur un ensemble d'indicateurs de QoS fixant des classes mutuellement reconnues de QoS. La mise en correspondance s'effectue en conséquence et le trafic transmis du premier réseau au deuxième reçoit le même QoS dans chacun des réseaux. En coordonnant ainsi les QoS des différents réseaux d'un cheminement, on peut établir son QoS d'un bout à l'autre.
EP05784569A 2004-09-21 2005-09-06 Etablissement de la qualite de services a travers une succession de reseaux Withdrawn EP1792444A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05784569A EP1792444A1 (fr) 2004-09-21 2005-09-06 Etablissement de la qualite de services a travers une succession de reseaux

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP04022438A EP1638262A1 (fr) 2004-09-21 2004-09-21 Provisionnement de qualité de service à travers plusieurs réseaux
EP05784569A EP1792444A1 (fr) 2004-09-21 2005-09-06 Etablissement de la qualite de services a travers une succession de reseaux
PCT/EP2005/054389 WO2006032609A1 (fr) 2004-09-21 2005-09-06 Etablissement de la qualite de services a travers une succession de reseaux

Publications (1)

Publication Number Publication Date
EP1792444A1 true EP1792444A1 (fr) 2007-06-06

Family

ID=34926646

Family Applications (2)

Application Number Title Priority Date Filing Date
EP04022438A Withdrawn EP1638262A1 (fr) 2004-09-21 2004-09-21 Provisionnement de qualité de service à travers plusieurs réseaux
EP05784569A Withdrawn EP1792444A1 (fr) 2004-09-21 2005-09-06 Etablissement de la qualite de services a travers une succession de reseaux

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP04022438A Withdrawn EP1638262A1 (fr) 2004-09-21 2004-09-21 Provisionnement de qualité de service à travers plusieurs réseaux

Country Status (2)

Country Link
EP (2) EP1638262A1 (fr)
WO (1) WO2006032609A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8989029B2 (en) * 2011-06-10 2015-03-24 Comcast Cable Communications, Llc Quality of service in packet networks
US9338101B2 (en) * 2012-12-06 2016-05-10 At&T Intellectual Property I, L.P. Advertising network layer reachability information specifying a quality of service for an identified network flow
CN104301251B (zh) * 2014-09-22 2018-04-27 新华三技术有限公司 一种QoS处理方法、系统及设备
JP7347507B2 (ja) * 2018-11-16 2023-09-20 ソニーグループ株式会社 非公開ネットワーク通信の有効化
EP4320817B1 (fr) * 2021-04-06 2024-11-06 Telefonaktiebolaget LM Ericsson (publ) Qualité de service initiée par un dispositif de communication avec un accord de niveau de service pour prendre en charge une qualité de modification de service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006032609A1 *

Also Published As

Publication number Publication date
WO2006032609A1 (fr) 2006-03-30
EP1638262A1 (fr) 2006-03-22

Similar Documents

Publication Publication Date Title
Vegesna IP quality of service
Gozdecki et al. Quality of service terminology in IP networks
KR20050061237A (ko) 서비스 품질 보장을 위한 시스템 및 방법
AU2002339309C1 (en) Traffic restriction by means of reliability check for a packet-oriented connectionless network with QoS transmission
US6839327B1 (en) Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions
EP1792444A1 (fr) Etablissement de la qualite de services a travers une succession de reseaux
Rahimi et al. Implementation of quality of service (QoS) in multi protocol label switching (MPLS) networks
Bechler et al. Traffic shaping in end systems attached to QoS-supporting networks
Zhang et al. End-to-end QoS guarantees over diffserv networks
Vasiliou Reading Course Paper Overview of Internet QoS and Web Server QoS
Domżał et al. Guide to Flow-Aware Networking: Quality-of-Service Architectures and Techniques for Traffic Management
Cisco Implementing DiffServ for End-to-End Quality of Service Overview
Cisco QC: Quality of Service Overview
Cisco Cosco IOS Quality of Service Solutions Configuration Guide Release 12.2
Cisco Quality of Service for Voice over IP
Agharebparast et al. QoS support in the UMTS/GPRS backbone network using DiffServ
Shaikh et al. End-to-end testing of IP QoS mechanisms
Metz Differentiated services
Serenato et al. MPLS backbones and QoS enabled networks interoperation
Luoma Simulation studies of differentiated services networks
Odinma et al. Quality of service mechanisms and challenges for IP networks
Rexhepi et al. Interoperability of Integrated Services and Differentiated Services Architectures
KR100794367B1 (ko) 차등서비스를 지원하는 엠피엘에스 트래픽 엔지니어링을 이용한 가상 네트워킹 방법
F AL-Allaf et al. Simevents/Stateflow base Reconfigurable Scheduler in IP Internet Router
KR100510820B1 (ko) 차등화 서비스 망에서 패스 및 링크 레벨 정보데이터베이스를이용한 수락제어 방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061212

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20070706

RIN1 Information on inventor provided before grant (corrected)

Inventor name: SISLAEM, DORGHAM

Inventor name: ENGEL, THOMAS

Inventor name: TOEDTMANN, BIRGER

Inventor name: LICHTWALD, GOETZ

Inventor name: FLOROIU, JOHN, W.

Inventor name: SCHRODI, KARL

Inventor name: SCHWABE, THOMAS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWAN

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWAN

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWAN

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20071117