WO2003075518A1

WO2003075518A1 - Method for signalling service requests in heterogeneous networks

Info

Publication number: WO2003075518A1
Application number: PCT/DE2003/000609
Authority: WO
Inventors: Christian Winkler; Karl Schrodi
Original assignee: Siemens Aktiengesellschaft
Priority date: 2002-03-01
Filing date: 2003-02-26
Publication date: 2003-09-12
Also published as: DE10209048A1; EP1481516A1

Abstract

The invention relates to a method for a packet-oriented, connectionless, heterogeneous network, wherein a request message is sent from the source-side to the drain-side and a return message is sent from the drain-side to the source-side in order to request and make available the required network resources to ensure application-specific requests to the network service such as quality of service, for example. The request message, wherein the contributions of the individual networks can be added up, enables the network resources to be assigned.

Description

description

Procedure for signaling service requests in heterogeneous networks

The subject matter of the application relates to a method for setting up a connectionless, packet-oriented connection across different networks.

In future 'converged' communication networks ('Next Generation Networks', NGNs), which include both classic and new telecommunications applications (starting with telephony and video (conference) communication to real multimedia applications) as well as 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.

The following essential boundary conditions must be taken into account (along with a few others):

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.

The architecture of the networks clearly differentiates between the control of services and applications ('Service Control') and the transport of information ('Network Control'). At the level of service control, the (end-to-end) relationships between users and the agreements on Processed the type, scope and characteristics etc. of the service or services to be used. 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.

In the context of increasing globalization with simultaneous massive deregulation of the national and regional markets, an increased heterogeneity of the networks can be expected. In addition to the just mentioned division of the vertically superimposed tasks of network, service and application control, competition will also take place in the horizontal area and, as a result, a differentiation between different network operators will take place. An easy

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)

Share in different budgets (e.g. packet loss or delay) may be helpful or even necessary.

I. In the classic telephone networks there is usually only one uniform (basic) network service which, for example in ISDN, relies on the provision of a so-called B channel (64 kbit / s transmission capacity). The properties of variants based on this (e.g. through channel bundling) are also standardized throughout the network. Such standardized 'well known network services' can be signaled uniformly across different subnets and can be requested and used directly. A further simplification in the use of such services results from the unit of network and service control, which are provided and used in an integrated manner in each network node. A service request is then passed from node to node, with each node providing the necessary network resources.

II. Also in the field of ATM technology (Asynchronous

Transfer Mode), the development of which was pursued with the aim of expanding the ISDN to a broadband and multimedia-capable B-ISDN, the integrated provision of network and service control applies. 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.)

III. For 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. The most far-reaching approach (and thus probably the closest prior art for this invention report) is the concept of 'Integrated Services' (IntServ). The associated

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

Enter properties and capabilities that could be of importance for the handling of the expected data stream. After the path message arrives at the data sink (receiver), the receiver uses it to create

Information an RSVP FlowSpec, which is now sent in a 'Reservation Message' along the explored path through the network back to the sender, reserving appropriate resources and setting the path for use.

This procedure is very universal, but also immensely complex, since it tries to take into account every conceivable eventuality in the network and to derive a corresponding reservation strategy from an overall picture. The height

Complexity leads to very limited scalability and thus only limited usability. b) The 'Differentiated Services' approach (DiffServ, eg RFCs 2474 and 2475) is limited to simply marking the data packets according to their belonging to a traffic class. Class membership can thus be signaled across the boundaries of network domains (ie between different subnets) and different ('differentiated') treatment of data packets from different traffic classes in the individual network nodes (represented by so-called 'per hop behaviors', e.g. RFCs 2597, 2598). However, statements about desired or actually achievable end-to-end properties in complex networks are generally not possible with this procedure.

c) MPLS (see e.g. RFC3031) is often cited in connection with QoS and network reliability. It uses fixed paths that are notified via a so-called 'Label Distribution Protocol' (LDP). Such a protocol can of course also be used to signal further requirements (e.g. in relation to QoS etc.). In this context, very often

Extension of RSVP with inclusion of label distribution proposed (see also RFCs 3209, 3210). In addition to losing the advantages of free routing (restriction to fixed paths), an MPLS user also inherits the complexity and scalability problems of the IntServ concept. All of the approaches mentioned address more or less only a sub-problem of the complex NGN signaling task and therefore only show solutions for the respective sub-areas. The only comprehensive approach, RSVP, disqualifies itself due to its high level of complexity and the associated problems in practical use. A usable solution that does justice to the overall problem (also beyond the pure topic of QoS) and under the various possible boundary conditions of an NGN - Implementation is sensible and economically usable, is currently not known.

A simple solution would of course be assuming the exclusive use of globally standardized and available 'well known network services' (see above 'ATM'). With increasing competition between operators (deregulation) and various standardization committees, a corresponding agreement must be seen as rather unlikely.

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.

The problem is solved by the features of the characterizing part of claim 1.

Advantages associated with the registration status:

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

Optional evaluation of the specific requirements even if there is a network service specification for requesting a specifically defined network service (possibility of an 'overrun').

Reserve resources at the same time and check compliance with the various network budgets (e.g. packet loss, delay or delay variation) in a single network run. - Optional modular structure of the request message allows free selection and compilation of the content.

- Simple basic structure and modular structure allow a variety of variants the overall process of a reservation or rejection.

Additional advantages:

• The procedure reduces the effort for signaling requests and the reservation of suitable network resources to a minimum and allows a reliable check of the compliance with the

Conditions.

• The method can be used regardless of the specific properties of individual subnetworks and without any special requirements in any heterogeneous NGNs.

• Due to the explicit signaling of the requirements, the optimal (both in terms of Fulfillment of the pure requirements as well as

Economy) network service can be selected.

• The option to choose an "agreed" network service (global or local) facilitates both standardization and peering between subnets.

• 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 'picking up' of the path properties gives the greatest possible freedom regarding of the mechanisms and technologies used in the subnetworks and nevertheless enables a very good assessment of the achievement or non-achievement of the requirements.

The proposed approach can be used not only for signaling QoS requirements but also for or in

Combination with requirements of any other kind, eg regarding Reliability and availability of the requested network service. The subject of registration is hereinafter referred to as

Embodiment in a necessary for understanding

Extent explained in more detail using a figure. The signaling process has two steps. In the first

Step a request message is sent from the source side to the sink side. In the second step, 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)) and, in a second information block (block 2), a precise description of various specific requirements / boundary conditions that must be met / observed on the way through the network. For this, e.g. belong:

Limit values for QoS parameters such as packet loss, packet delay or packet delay variation, • Limits for the probability that the

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,

• ... In a very simple example, e.g. in 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. Of course, block 2 can also remain empty if no further requirements are made or these are covered by the third information block (see below).

In a third information block (block 3), 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. Optionally, however, 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.

As a further option, 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. As a simple example, the expected (maximum) delays in the subnets passed through can be added up and checked against the limit value specified in block 2. (Alternatively, the individual values of each subnet could simply be entered and stored in another (central) location Review against the requirements are evaluated.)

This 'conformity check' is necessary because the individual subnetworks can work independently of one another and with completely different mechanisms and also differently specified network services. Only with the continuous availability and use of a 'well known network service' this should be dispensed with if it is appropriately comprehensive and sufficiently precisely specified. In addition, information about the selected route can also be entered in this block if this is not clearly predetermined.

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

If the request message reaches the responsible instance on the sink side (sink or its agent / proxy) and the collected 'consumption values' in block 4 are within the permissible range according to block 2, 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

Information. This results in the following main variants: I. The rejection message is' along the

Request paths' sent back. The reserved resources are released step by step.

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

Release the flow of information or b) accept the rejection for this attempt. In this case, the requesting entity must immediately send a release request along the still reserved path in order to release the blocked resources again.

Even during the passage of the request message through the network, a lack of resources, the unavailability of a suitable network service or the exceeding of the request specification can be determined. In such a case, 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. Of course, in the event of a rejection (or

Acceptance of a rejection according to II.b), see above) the requesting entity is free to start another attempt with the same or modified requirements.

Basically, the request message will contain a message header that clearly identifies it and from others

Messages differs. Basic information can also be transmitted in this header. The following 'blocks' are also marked exactly for differentiation and delimitation. Block 1 is 'mandatory', the rest are optional. The contents and representations of blocks 1, 2 and 4 require standardization. In the simplest case, 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

Probability) guaranteed. In addition to the usual QoS parameters such as delay or loss, 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.

Example of a set of network services that covers common applications:

1.Emergency Network Control (ENC) - network-internal control traffic (e.g. signaling)

2. Interactive Real-Time (IRT) - Interactive real-time communication (e.g. video conferences)

3. Non-Interactive Real-Time (NIRT) - non-interactive

Real-time communication (e.g. video access) 4.Transactional and signaling (TAS) - transaction-oriented applications (e.g. e-commerce) 5.Best effort (BE) - classic data traffic without special requirements (e.g. WWW)

Claims

claims

1. Method for setting up a connectionless, packet-oriented connection across different networks, wherein a request message in which several blocks can be accommodated is sent from the source side to the sink side, in the first block of the request message a description of the traffic intended to be sent by the source is recordable and feedback is sent from the sink side to the source side.

2. The method according to claim 1, characterized in that a second block of the request message has a description of the requirements to be met on the way.

3. The method according to claim 2, characterized in that a specific network service can be requested in a third block.

4. The method according to claim 2 or 3, characterized in that the requirements specified in the second block can be accumulated in a fourth block.

5. The method according to any one of claims 2 to 4, characterized in that information about the selected route can be stored in a fifth block.

6. The method according to any one of the preceding claims, characterized in that the charging / charging information of the individual networks can be accumulated in one block.

7. The method according to any one of the preceding claims, characterized in that the request message to the before reaching the sink side

Source page is returned if one in the

Requirement message specified requirement is not met.