EP1481516A1 - Procede de signalisation de demandes de services dans des reseaux heterogenes - Google Patents

Procede de signalisation de demandes de services dans des reseaux heterogenes

Info

Publication number
EP1481516A1
EP1481516A1 EP03714659A EP03714659A EP1481516A1 EP 1481516 A1 EP1481516 A1 EP 1481516A1 EP 03714659 A EP03714659 A EP 03714659A EP 03714659 A EP03714659 A EP 03714659A EP 1481516 A1 EP1481516 A1 EP 1481516A1
Authority
EP
European Patent Office
Prior art keywords
network
block
information
request message
service
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
EP03714659A
Other languages
German (de)
English (en)
Inventor
Christian Winkler
Karl Schrodi
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
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 Siemens AG, Nokia Siemens Networks GmbH and Co KG filed Critical Siemens AG
Publication of EP1481516A1 publication Critical patent/EP1481516A1/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/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • 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/15—Flow control; Congestion control in relation to multipoint traffic
    • 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/18—End to end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware

Definitions

  • the subject matter of the application relates to a method for setting up a connectionless, packet-oriented connection across different networks.
  • NGNs Next Generation Networks', NGNs
  • telecommunications applications starting with telephony and video (conference) communication to real multimedia applications
  • traditional and future data services from file transfer via email, web surfing, e-co-merce to 'electronic infotainment'
  • suitable signaling methods must be used to register and provide the necessary network resources to ensure the application-specific requirements for network services, e.g. bez. a quality of service (QoS) or a corresponding reliability and availability of the services from the perspective of the user.
  • QoS quality of service
  • NGNs will be based on Internet Protocol (IP) technology, i.e. the information is transported in packet form and a priori without a connection, advantageously using the statistical traffic behavior of the packet-oriented information transmission.
  • IP Internet Protocol
  • the architecture of the networks clearly differentiates between the control of services and applications ('Service Control') and the transport of information ('Network Control').
  • Service Control' the control of services and applications
  • 'Network Control' the transport of information
  • the actual transport of the (useful) information to be exchanged within the framework of the service takes place at the network level.
  • the necessary (control) information for determining the necessary resources and settings of the network are exchanged via signaling. Since the service control, which is independent of the network, does not know the network structure and the possible routes through the network, a 'horizontal' signaling between network nodes and possibly neighboring subnetworks is also required.
  • Figure 1 shows an example of the resulting architecture. If two network operators offer diverging network services (see definition at the end of the text), then either a suitable mapping between the respective different network services must be agreed for a transition or the original requirement definition must be provided to individually select a suitable network service. Possibly. can also provide additional information about the sub-networks that have already been run through (and thus used up)
  • a set of 'well known network services' (essentially the CBR, VBR, ABR, UBR and GFR) with properties defined by the standardization are available for selection and can be requested directly via the signaling. Since properties such as e.g. the QoS, which have already been determined, only have to be given a (also standardized) description of the delivered traffic (e.g. by parameters such as peak rate and sustainable rate in the case of VBR). (Of course, the requirements regarding the QoS only apply if certain boundary conditions, e.g. regarding the maximum number of nodes passed, etc., are met.)
  • IP-based networks there are a number of approaches from the activities of the Internet Engineering Task Force (ETF) that aim at a possible provision of QoS.
  • ETF Internet Engineering Task Force
  • the most far-reaching approach (and thus probably the closest prior art for this invention report) is the concept of 'Integrated Services' (IntServ).
  • IntServ 'Integrated Services'
  • Signaling procedure is based on the 'Resource Reservation Protocol' (RSVP, RFC 2205 and RFC 2210 ff.)) And works according to the following basic principle: At the starting point of a communication relationship (sender) a 'Path Message' is sent, which is basically the way through the network to explore. It contains a description of the traffic to be generated by the transmitter (transmitter TSpec) and an area (RSVP ADSpec) in which the subnetworks and network nodes passed provide information about their
  • the receiver uses it to create
  • MPLS see e.g. RFC3031
  • LDP 'Label Distribution Protocol
  • Such a protocol can of course also be used to signal further requirements (e.g. in relation to QoS etc.).
  • LDP 'Label Distribution Protocol
  • the object of the registration is based on the problem, for a packet-oriented, connectionless communication network, a method for registering and providing the necessary network resources to ensure the user-specific
  • Requirements for the desired network services e.g. B. with regard to a Quality of Service (QoS) or a reliability and availability of the services.
  • QoS Quality of Service
  • the signaling does not include only one
  • Traffic description but explicitly and specifically the Requirements of the traffic source, for example in relation to QoS and / or reliability of the requested service.
  • the signaling also optionally contains a network service specification / request with either global (network-wide) or local (only at the current peering point) meaning.
  • RSVP For a successful reservation, only one complex process is necessary in each network instance concerned (with RSVP there are two: exploring in the forward pass and reserving in the reverse pass).
  • a successful route setup can be processed quickly (one pass, one direct receipt). In the event of failure, the additional delay due to the dismantling can be used as a kind of implicit overload protection to delay a renewed request. (Low efficiency losses in terms of capacity utilization due to 'reservation before approval' must be accepted in all reservation processes.) • The coincidence of requests and reservations guarantees the availability of the 'explored' route properties.
  • the proposed approach can be used not only for signaling QoS requirements but also for or in
  • Step a request message is sent from the source side to the sink side.
  • either a confirmation or a rejection is sent back to the source page.
  • the method supports unidirectional data flows, since it must be assumed in IP networks that traffic going in and out of a bidirectional communication relationship does not necessarily take the same route. For bidirectional communication relationships, the procedure is to be applied separately for each direction.
  • the request message originates either from the source itself or from an agent or proxy working for it. In any case, it passes through the access network to which the source is connected and then marches through one or more of the various subnetworks of the overall network to the access network of the sink and finally ends either in the sink itself or an agent or proxy working for it.
  • the request message contains in a first information block (block 1) a description of the traffic intended to be sent by the source (e.g.
  • Bandwidth information, variability / burstiness, etc. see e.g. RSVP TSpec)
  • block 2 a second information block
  • Flow of information is interrupted (for a longer period) or terminates and / or a limit value for a maximum permissible interruption time of the information flow, • the permissibility or non-permissibility of a sequence reversal of the data packets (packet reordering) and / or limit values for the permissible scope of reordering,
  • block 1 there is only a bandwidth value (e.g. an average or peak value) and in block 2 there is only a maximum permitted packet delay.
  • block 2 can also remain empty if no further requirements are made or these are covered by the third information block (see below).
  • a specific, network-wide specified network service ('well known network service') can be requested from the source or its agent or proxy if one exists and is desired. If this is not the case, this block remains (initially) empty. In this case (i.e. whenever this block is empty), block 3 can be used at the transitions between different network domains (subnetworks, also access networks are subnetworks! To request network services (locally) agreed between these subnetworks.
  • the procedure then proceeds in such a way that the first subnet in the flow direction of the request message selects a network service that is agreed with the second subnet and matches the requirements in blocks 1 and 2 (which only has to be valid between these two) and enters it in the request message and passes this on to the second subnet.
  • the second subnet evaluates the information, makes the necessary reservations and settings, deletes block 3 of the request message and proceeds again at the transition to the third subnet in accordance with the rule described.
  • the received network service request can also be directly mapped to a network service agreed with the subsequent subnet. In the case of non-identical network service specifications, however, there is a risk of 'rocking up', ie an upgrade to increasingly high-quality services, since the service in the next subnet should not have any worse properties than the one used locally.
  • the block 2 information (if available) can be evaluated in each subnetwork regardless of the existence of useful block 3 information. If this is meaningful enough, the (locally or globally specified) network service to be used in this subnet can be selected on this basis. In special cases (option) it is also possible to deviate from the network service that may be notified in block 3 ('overrun').
  • the evaluation of the block 2 information is mandatory if no valid or usable block 3 information is available. The basic assumption is that block 1 information is always evaluated.
  • a fourth information block (block 4) is used to collect information about the 'consumption' of the 'requirement budgets' specified in block 2.
  • the expected (maximum) delays in the subnets passed through can be added up and checked against the limit value specified in block 2.
  • the individual values of each subnet could simply be entered and stored in another (central) location Review against the requirements are evaluated.
  • the order of the blocks or the general arrangement of the information elements in the request message can of course be determined as desired. If the blocks can be individually and uniquely identified by appropriate labeling, only the individual blocks need to be standardized and the request message can be constructed or assembled practically freely and in a modular manner ('option principle'). Only the blocks that are really necessary in individual cases need to be installed. Alternatively, the overall structure of the notification could of course be firmly agreed (standardized).
  • a confirmation message is sent back to the requesting instance on the source side, after which the Information flow can be released.
  • the confirmation message may also contain the route information collected in block 4 of the request message.
  • the confirmation message can take any route to its destination. If the collected consumption values exceed the permissible range, a rejection message is sent back.
  • the rejection message may contain parts or all of the information collected in block 4 of the request message
  • rejection notification is sent back in any way.
  • the requesting entity can then either a) accept the offer on the worse conditions than the request and the
  • the determining body can (optionally) immediately send back an 'early rejection' along the previously reserved path. With the 'early rejection' all reserved resources are released again.
  • a rejection or
  • the request message will contain a message header that clearly identifies it and from others
  • Block 1 is 'mandatory', the rest are optional.
  • the contents and representations of blocks 1, 2 and 4 require standardization.
  • block 3 contains only one number (e.g. encoded in 7 or 8 bits).
  • the number 5 would then specify the network service agreed with the identification number 5.
  • An additional information carrier (bit or byte) could indicate whether it is a global or only a locally agreed network service if this information was not already implicitly contained in the identification number.
  • a network service specifies certain properties for the transport of packets through a network. These properties are determined by the network (statistically, with a certain
  • the parameters describing the properties of a network service can also include the specification of the reliability or the availability (blocking probability) of the network service.
  • the network services offered by a network can in principle be freely specified within the limits of the technical possibilities of the network. Possible influencing parameters in a Appropriate definitions range from the requirements of the application classes to be transferred to the business and tariff considerations of the operator.
  • IRT Interactive Real-Time
  • Real-time communication e.g. video access
  • TAS Transactional and signaling
  • BE Best effort
  • WWW WWW

Landscapes

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

Abstract

Procédé pour un réseau hétérogène en mode sans connexion orienté paquets. Selon ledit procédé, en vue de la demande et de la mise à disposition des ressources de réseau nécessaires à la préservation des exigences spécifiques en matière d'utilisation, concernant les services du réseau, telles que la qualité de service, un message de demande est envoyé du côté source au récepteur et un message de retour est envoyé du récepteur au côté source. Le message de demande, dans lequel les contributions des différents services peuvent être réunies, permet la réservation des ressources de réseau.
EP03714659A 2002-03-01 2003-02-26 Procede de signalisation de demandes de services dans des reseaux heterogenes Withdrawn EP1481516A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10209048 2002-03-01
DE10209048A DE10209048A1 (de) 2002-03-01 2002-03-01 Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen
PCT/DE2003/000609 WO2003075518A1 (fr) 2002-03-01 2003-02-26 Procede de signalisation de demandes de services dans des reseaux heterogenes

Publications (1)

Publication Number Publication Date
EP1481516A1 true EP1481516A1 (fr) 2004-12-01

Family

ID=27762573

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03714659A Withdrawn EP1481516A1 (fr) 2002-03-01 2003-02-26 Procede de signalisation de demandes de services dans des reseaux heterogenes

Country Status (3)

Country Link
EP (1) EP1481516A1 (fr)
DE (1) DE10209048A1 (fr)
WO (1) WO2003075518A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100703770B1 (ko) 2005-03-25 2007-04-06 삼성전자주식회사 가중 예측을 이용한 비디오 코딩 및 디코딩 방법, 이를위한 장치
DE102016119080B4 (de) 2016-10-07 2020-11-12 Condias Gmbh Vorrichtung zum elektrochemischen Behandeln von Abwasser

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69829203T2 (de) * 1997-11-03 2006-02-16 British Telecommunications P.L.C. Paketnetzwerk
DE10038878C1 (de) * 2000-08-09 2002-01-10 Siemens Ag Verfahren zum Aufbau einer Verbindung mit vorgegebener Dienstgüte zwischen Kommunikationsnetzen mit Resourcenmanagern

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2003075518A1 (fr) 2003-09-12
DE10209048A1 (de) 2003-09-18

Similar Documents

Publication Publication Date Title
DE60109809T2 (de) Verfahren und system für betriebsmittelreservierungen in einem multicast-netzwerk
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
DE60102367T2 (de) Netzoptimierungsmethode
DE69919569T2 (de) Verwaltung von verbindungsorientierten diensten über das internet-protokoll
DE60017622T2 (de) Auf RSVP-basiertes Tunnelprotokoll zum Bereitstellen von integrierten Diensten
DE60032669T2 (de) Vorrichtung und Verfahren zur Bandbreitenüberwachung
DE60117476T2 (de) Bidirektionales Reservierungsprotokoll
DE60204645T2 (de) Ressourcenverwaltung in heterogenen dienstqualitätsbasierten Paketnetzwerken
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE60221261T2 (de) Verfahren und anordnung in einem ip-netzwerk
DE60103338T2 (de) Etikettvermitteltes Kommunikationsnetzwerk
EP1451980B1 (fr) Procede de transmission de donnees d'application avec une qualite differente
DE102006022046B4 (de) Verfahren zum Ermöglichen einer Steuerung der Dienstqualität und/oder der Dienstvergebührung bei Telekommunikationsdiensten
EP1428361B1 (fr) Limitation de trafic pour reseau avec transmission a bon niveau de qualite de service
DE102004008376A1 (de) Verfahren und System zum Schaffen einer garantierten Qualität des Dienstes in einem IP-Netz
DE60012736T2 (de) Verfahren zur leitwegerzeugung für mehrfachdatenverkehr
EP1398907B1 (fr) Méthode de contrôle de ressource de transmission dans un réseau de paquets de données lors des changements de topologie
EP1908234A1 (fr) Procede de controle de ressources dans des elements d'un reseau de telecommunication
EP1249154B1 (fr) Procede et dispositif de commande d'acces a un reseau de communication
DE10100609A1 (de) Verfahren zum Vergebühren bei der Datenübertragung, zugehörige Einheiten, Zugehöriges Programm und elektronischer Gutschein
EP1665676B1 (fr) Procede de regulation de charge dans un reseau de donnees par paquets
EP1481516A1 (fr) Procede de signalisation de demandes de services dans des reseaux heterogenes
EP1266496B1 (fr) Procede et dispositif de controle d'admissibilite d'une utilisation de service
EP1374627B1 (fr) Procede et systeme permettant une gestion efficace des ressources dans des reseaux mpls

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: 20040902

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

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

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

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

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

17Q First examination report despatched

Effective date: 20071112

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

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

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: 20080326