CN1691636A - Method of flow state establishment - Google Patents

Abstract

The invention discloses a method for establishing a stream state, which includes: sending a message containing a data stream resource request to a receiving end through the step-by-step forwarding of an intermediate node at the sending end; The intermediate node that establishes the function judges whether the node satisfies the requirements of the resource request in the current message, and if so, performs resource reservation according to the resource request and forwards the current message to the next node, otherwise, feeds back the resource to the sender Request a rejection response, turn the resource request into a resource collection request, and forward the message containing the resource collection request to the next node; if the message received by the receiving end contains a resource request, perform resource reservation according to the resource request If the current packet received by the receiving end contains a resource collection request, it will feed back a resource collection response to the sending end. The method of the invention effectively solves the problem of delivering real-time services.

Description

The method of stream state establishment

technical field

The invention relates to a network message transmission technology, in particular to a method for establishing a flow state.

Background technique

A flow refers to a set of packet sequences between a specific source and a destination. These packets start from the same source and arrive at the same destination, and have the same flow identifier. The source requires the intermediate node to perform specific processing on these packets through signaling or other means.

Considering the needs of real-time services, Internet Protocol Version 6 (IPv6) has made further improvements in terms of support for flows and resource reservation, and defines a 20-bit flow label (FlowLabel) field in the IPv6 header, thus compared with Internet Protocol Version 4 (IPv4) has clear advantages.

In this way, when the host sends a message, if the message needs to be transmitted in a flow, it only needs to fill in the corresponding flow number in the flow label field. A packet with a flow label value of 0 does not belong to any flow and is treated as a general packet.

The IPv6 node identifies the flow according to the triplet composed of the source address, destination address and flow label in the header, and processes the message of the flow according to the established flow state. In the IPv6 network, due to the unfixed length and position of the IPv6 extension header, and the transmission control protocol/user datagram protocol (TCP/UDP) port number is located in the IPv6 load, because fragmentation or encryption is not easy to obtain, the triplet ratio is used. The five-tuple composed of source address, destination address, protocol type, TCP/UDP source port, and TCP/UDP destination port used in IPv4 can more effectively speed up packet classification, that is, the speed of flow identification. In addition, since the packet classifier only depends on the information of the Internet Protocol (IP) header, it is easy to introduce new upper-layer protocols on IPv6 in the future.

The IPv6 group of the Internet Task Force (IETF, Internet Engineering Task Force) defines the purpose of the flow label field in the draft (RFC) 3697, and specifies the minimum requirements for the source node to mark the flow, the forwarding node to forward the flow message, and the establishment of the flow state . Among them, regarding the method of establishing IPv6 flow state, RFC3697 only made two requirements:

1) In order to perform specific processing on the flow, it is necessary to establish the flow state in all or part of the IPv6 nodes on the source-to-destination path. The stream state establishment method and stream processing model are specified in separate RFCs.

2) In order to make various IPv6 flow state establishment methods co-exist, these methods must meet two basic requirements: first, a flow state clearing means must be provided, and the source node can specify a flow longer than the default 120 seconds through signaling. State life cycle; Second, the flow state establishment method must be able to recover from the situation that the required flow state cannot be supported.

Although RFC3697 stipulates two basic requirements of the convective state establishment method, it does not specify the specific method and processing model, and so far, there is no draft or personal proposal in this regard.

The Resource Reservation Protocol (RSVP) formulated by IETF in RFC2205 and the Quality of Service (QoS) Integrated Service Model (IntServ) formulated in RFC2210 can be used to establish and maintain application resources and priorities for IPv4/IPv6 flows on intermediate nodes Soft state, the intermediate node adopts a specific scheduling policy to process the flow packet according to the soft state of the flow. That is to say, a special channel is created for a flow message with a specific identifier in the network to ensure its rapid forwarding. Wherein, the specific identifier refers to a five-tuple of IPv4 or a triple of IPv6.

RSVP protocol packets are generally encapsulated in Raw IP packets, and can also be encapsulated in UDP packets for transmission. The RSVP protocol is a control protocol like the Internet Control Message Protocol (ICMP). It does not carry any application data and only transmits reserved signaling parameters, and supports unicast and multicast. As a new protocol type, RSVP introduces the IP router alarm option in the IP header according to RFC2113 in order to notify intermediate routers to intercept RSVP messages and perform further processing. Fragmentation and reassembly of RSVP packets are not allowed, and the default refresh period of the soft state is 30 seconds.

The original design intention of RSVP is an end-to-end QoS signaling protocol designed for Intserv to support the transmission of real-time application data on the Internet. At that time, it was considered that the multipoint multicast real-time application was a key application that RSVP must support, and the multicast receivers were distributed in different locations, and the network conditions between them might be far apart. Therefore, the basic design idea of RSVP is: Periodically send messages to refresh the protocol state on routers and hosts, that is, soft state, bidirectional signaling message exchange, the receiving end initiates resource reservation requests, and QoS signaling is independent of routing protocols.

The application first triggers the RSVP protocol to request resources that meet a certain QoS for the data flow to be established. The specific transmission process of the message in the resource request can be seen in Figure 1. The sending end Src forwards the path (PATH) message to the receiving end Dst through the step-by-step forwarding of the intermediate nodes R1~R3, and the receiving end Dst sends the feedback reservation The (RESV) message is sent to the sender Src step by step in reverse according to the original path. The specific processing process of each node includes the following steps:

In step 101, the sending end periodically sends PATH messages along the data flow path.

Step 102, after receiving the PATH message, the intermediate node obtains the reverse path information of the data flow by analyzing the parameters in the PATH message.

Step 103, after receiving the PATH message, the receiver sends a RESV message to request resource reservation.

Step 104, the intermediate node analyzes the RESV message to perform policy control and admission control. After the policy control and admission control are passed, it reserves resources and sets processing parameters for the data flow, and according to the reverse path information obtained from the PATH message, along the RSVP messages are forwarded along the path reverse to the data flow.

If the intermediate node does not receive periodic PATH and RESV refresh messages within a default period of time, the resources reserved for the data flow and the processing parameters set in the intermediate node will be cancelled. Moreover, the sending end and the receiving end may also actively cancel the resources reserved for the data flow and the processing parameters set in the intermediate router by sending a disassembly message.

Because RSVP has good scalability, reserved parameters and specific operations are transparently encapsulated in RSVP messages in the form of objects, and different processing models can expand the reserved parameters and specific operations they need.

After RFC2205, IETF made more than ten kinds of extensions to RSVP for various needs. According to the summary analysis of these extensions in draft-ietf-nsis-signalling-analysis-03.txt by the NSIS working group, including: RSVP traversal IP tunnel, support IPSec, support policy control framework, reduce soft state refresh overhead, RSVP aggregation, support traversal of 802 LAN, support traversal of ATM network, support traversal of differentiated service model (DiffServ), support null service type, support multi-protocol label switching ( MPLS) traffic engineering (TE), support for general multi-protocol label switching (GMPLS), support for RSVP proxy, localized RSVP (that is, reserved only in the access network), support for mobile IP, etc.

Among these extensions, only the RSVP-TE protocol is successful and has been widely deployed by a large number of operators to support the establishment of explicit routing Label Switched Paths (LSPs) in MPLS networks. Other extensions, as well as the RSVP and IntServ models themselves, have not been widely deployed.

RSVP-TE is used in MPLS networks to establish explicit routing LSPs for relatively stable aggregation traffic and reserve bandwidth. Due to the long life cycle of LSP, traffic and paths will not change frequently, and the number of LSPs in the network is geometrically smaller than the number of IP microflows. Therefore, the refresh message overhead of RSVP-TE and the reception designed to support multicast There is no scalability problem in the end-initiated request and request merging mechanism.

However, the original intention of RSVP is to reserve resources and special processing in the network for small IP application data streams, and to support resource reservation of IP multicast streams. Since the data flow targeted by RSVP is an application-level microflow with a short life cycle and frequent changes, if resources and special processing are reserved on the intermediate router for each microflow, the overhead of RSVP refresh messages and the complexity of receiving end-initiated requests and The complexity and expansibility of the request merging mechanism are very prominent, and the support for mobile IP is even more difficult to solve. Therefore, IntServ or RSVP is only suitable for small networks at present.

In large and medium-sized networks, coarse-grained DiffServ, which does not rely on signaling and has good scalability, currently occupies a dominant position. However, DiffServ can only provide relative QoS and cannot guarantee predictable end-to-end QoS, so it still cannot fully satisfy real-time business requirements.

To sum up, the IPv6 protocol has made improvements to the outstanding mobility, security and QoS issues in the IPv4 network. etc. The problems of mobile IP and IPsec are simplified and solved to a great extent. However, in terms of QoS, RFC3697 only stipulates two basic requirements for 3-tuples to be used for flow classification and convection state establishment methods, without specifying specific flow state establishment methods and processing models. In addition, the scalability issues of IntServ/RSVP, the end-to-end predictable QoS guarantee issues of DiffServ, and the combination issues of IntServ and DiffServ remain the same in the current IPv6 and have not been fundamentally resolved. Years of practice have proved that the complex RSVP protocol is successful in RSVP-TE extension, but it fails in the establishment of application-level data flow state. Therefore, there is currently no satisfactory flow state establishment scheme that can meet real-time Business requirements, to solve real-time business delivery problems such as QoS requirements of application-level real-time data streams.

Contents of the invention

In view of this, the main purpose of the present invention is to provide a method for establishing a flow state to solve the problem of delivering real-time services.

According to the above purpose, the present invention provides a method for establishing a flow state, including:

a) The sending end sends a message including a data flow resource request to the receiving end through the step-by-step forwarding of the intermediate node;

b) On the path that the message passes through, after receiving the current message, the intermediate node that has started the flow state establishment function judges whether the node satisfies the demand condition of the resource request in the current message, and if so, according to the resource Request resource reservation, forward the current message to the next node along the message transmission path, otherwise, feed back the resource request rejection response to the sender, convert the resource request in the current message into a resource collection request, and forward the message along the message transmission path Forward the message containing the resource collection request to the next node;

c) If the current message received by the receiving end contains a resource request, perform resource reservation according to the resource request, and feed back a resource request confirmation response to the sending end, if the current message received by the receiving end contains resource collection request, the resource collection response is fed back to the sender.

The process of sending the message in step a) of the method further includes: the sending end periodically sends a message including the resource request of the data flow to the receiving end within the effective lifetime of the data flow.

The step a) of the method further includes: the sending end and the receiving end obtain each other's network conditions through an upper-layer application protocol, and assign a flow label to the data flow.

In this method, the number of the receiving end is more than one, and the network conditions are the same, then the receiving end receives the message sent by the sending end through a multicast group.

The number of receivers described in this method is more than two, and at least one of the receivers is in a network condition different from other receivers, then the receivers whose network conditions are different from other receivers receive the report sent by the sender through unicast In a multicast group, more than one receiving end with the same network conditions receives the message sent by the sending end through a multicast group.

The data flow described in the method is identified by source address, destination address and flow label value; or by source address and flow label value; or by destination address and flow label value.

In this method, if the sending end and the receiving end are fixed IP terminals, the data flow is identified by a source address, a destination address and a flow label value;

If the sending end or the receiving end is a mobile IP terminal, the data flow is identified by a source address and a flow label value, or by a destination address and a flow label value.

The resource request described in this method includes: flow average rate, peak rate, minimum packet length, maximum packet length, bandwidth requirement, delay requirement, QoS guarantee availability, path MTU, available bandwidth and minimum delay, wherein, QoS guarantee availability is available;

The resource collection request includes: flow average rate, peak rate, minimum packet length, maximum packet length, bandwidth requirement, delay requirement, QoS guaranteed availability, path MTU, available bandwidth and minimum delay, wherein, QoS guaranteed availability is unavailable.

The method does not require the intermediate node to listen or intercept during the feedback process of the resource request confirmation response;

The intermediate node is not required to listen or intercept during the feedback process of the resource request rejection response;

During the feedback process of the resource collection response, no intermediate node is required to intercept or intercept.

The feedback path of the resource request confirmation response described in the method is different from the reverse path of the resource request;

The feedback path of the resource request rejection response is different from the reverse path of the resource request;

The feedback path of the resource collection response is different from the reverse path of the resource request.

In this method, the resource request is set in the message extension header; the resource collection request is set in the message extension header.

In this method, the resource request is set in the option of the message extension header; the resource collection request is set in the option of the message extension header.

The method further includes: setting a new extension header for the message, the resource request is set in the options of the newly set extension header, and the resource collection request is set in the options of the newly set extension header;

Or a new option is set in the existing hop-by-hop option header of the message, the resource request is set in the newly set option, and the resource collection request is set in the newly set option.

The resource request confirmation response described in the method is an ICMP message or an upper layer protocol message carrying resource request confirmation information;

The resource request rejection response is an ICMP message or an upper layer protocol message carrying resource request rejection information;

The resource collection response is an ICMP message or an upper layer protocol message carrying resource collection information.

In the method, the upper layer protocol message is a SIP message or an H.323 message.

The message described in the method is a dedicated protocol message;

The resource request is sent in a dedicated protocol message;

The resource collection request is sent in a dedicated protocol message;

The resource request confirmation response is a dedicated protocol message carrying resource request confirmation information;

The resource request rejection response is a dedicated protocol message carrying resource request rejection information;

The resource collection response is a dedicated protocol message carrying resource collection information.

The special protocol message described in the method is an RSVP special protocol message.

The resource collection information in this method includes the collected path attributes.

The path attributes described in the method are path MTU, available bandwidth estimation and minimum delay.

The message described in the method is an ICMPv6 special protocol message;

The resource request is carried in the ICMPv6 dedicated protocol message for sending;

The resource collection request is carried in the ICMPv6 dedicated protocol message for sending.

The packet described in the method is an IPv6 packet.

The packet described in the method is an IPv4 packet.

In the step b) of the method, if the intermediate node satisfies the demand condition of the resource request in the current message, it further includes: performing specific processing unique to the data flow;

In the step c), if the current message received by the receiving end contains a resource request, it further includes: performing specific processing specific to the data flow.

The requirement condition of the resource request in the current message in step b) of the method is the QoS requirement parameter obtained from the resource request.

It can be seen from the above that the method for establishing a flow state provided by the present invention simplifies the original two-way message exchange to one-way by initiating a resource reservation request by the sender and collecting path attributes as required. The resource request simplifies the resource reservation mechanism for real-time business application-level micro-flows, and can flexibly support multiple QoS guarantee models, so that each network domain that the flow passes through can independently select its own QoS guarantee model, while ensuring end-to-end end QoS. And further by compressing the parameters in the resource request, using the extension header of the IPv6 message to carry the resource request and other measures, the network overhead of resource reservation is greatly reduced, and the resource reservation support of mobile IP is supported; by cooperating with the negotiation function of the upper layer application protocol , which increases the difficulty of counterfeiting flow labels, reduces the probability of reservation failure and feedback storms, and simplifies the resource reservation of multicast flows; and can effectively collect path attributes according to QoS requirements, avoiding the blindness of isolated collection path attributes and causing waste of resources.

Description of drawings

FIG. 1 is a schematic diagram of a message transmission process of resource request by RSVP protocol in the prior art;

FIG. 2 is a schematic diagram of a process in which a sending end sends a resource request to a receiving end according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a message delivery process in the first case of resource request feedback according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of a message delivery process in a second case of resource request feedback according to an embodiment of the present invention.

Detailed ways

The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

For a large number of short-lived or even mobile real-time application data streams, the RSVP bidirectional signaling message exchange process is too complicated and the overhead is too large. Therefore, a simpler mechanism with less overhead is needed. Carefully analyze the originally designed RSVP protocol and the IntServ model. If only to realize the QoS guarantee of the application data flow, only the following three objects are needed in the PATH and RESV messages of RSVP:

(1) RSVP SENDER_TSPEC: Contains traffic specification information of the sender, such as token bucket rate and size, peak rate, minimum packet length, and maximum packet length.

(2) RSVP FLOWSPEC: Contains the reservation request information of the receiver, such as token bucket rate and size, peak rate, minimum packet length, maximum packet length, bandwidth requirements, and delay requirements.

(3) RSVP ADSPEC: contains information generated by the source or intermediate nodes, collects the QoS guaranteed availability of the path, estimated bandwidth, minimum delay, MTU and other path attributes, and the transmission direction is source to destination.

And, considering that in fact several early or contemporaneous resource reservation protocols, such as ST-II, YESSIR, Boomrang, and the next-generation signaling (NSIS) under study are all resource reservation requests issued by the sender, And even for RSVP, the receiver sends the RESV request after receiving the PATH message from the sender.

Therefore, without considering the multipoint-to-multipoint resource reservation requirements for multicast streams with different network conditions at the receiving end, it is entirely possible for the sending end to initiate a resource reservation request with a small number of parameters, and according to It is necessary to carry path attributes to collect objects, so that the two-way message exchange is simplified to one-way, and the content of the message is also compressed.

Referring to Fig. 2 to shown in Fig. 4, the IPv6 flow state establishment method provided by the present invention is mainly divided into two major steps:

Step 1: The sender initiates a resource request for the real-time application data stream.

As shown in Figure 2, the sending end Src carries the resource request Resource Req in the IPv6 packet extension header of the data flow, and periodically sends it to the receiving end Dst through the intermediate nodes R1-R3 during the effective lifetime of the data flow.

Among them, the periodicity mentioned here does not necessarily refer to a fixed time interval. The time interval for sending each message can be different, but it must be guaranteed that a message is sent at least once within the effective lifetime of the data stream, or called Perform a packet refresh.

In order to carry resource requests, it is necessary to define a new IPv6 extension header—FlowQoS Requirements Header (FlowQoS Requirements Header), and put the resource requests of real-time application data streams in the option (Option) of Flow QoSRequirements Header; or in the defined A new Option is defined in the Hop-by-hop Options Header, which contains resource requests for real-time application data streams.

In this way, the sender carries the resource request in the Option of the IPv6 message extension header or the newly defined Option, without using a dedicated protocol message to transmit, thereby reducing the message overhead, because the message does not need to transmit the description of the filter , instead the function of the filter is implied in the triplet of the IPv6 header.

The resource request only needs to include the following parameters: average flow rate, peak rate, minimum packet length, maximum packet length, bandwidth requirements, delay requirements, QoS guaranteed availability, path maximum transmission unit (MTU), available bandwidth, minimum time delay parameters. Among them, QoS guaranteed availability, path MTU, available bandwidth and minimum delay are used to collect path attributes, intermediate nodes can change their values when forwarding, and other parameters remain unchanged and passed to the receiving end. And when the QoS guarantee availability indicates that the path cannot meet the QoS requirement, the path MTU field, the available bandwidth field and the minimum delay field are valid, indicating the collected path attributes. Although RFC1981 defines a path MTU discovery mechanism, this method is more effective, because the path MTU needs to be collected only when the path cannot meet the QoS requirements of the flow. By default, the IPv6 link specified by IPv6-SPEC is used. MTU.

In addition, before this step, the sending end and the receiving end usually need to obtain the network conditions of the sending end and the receiving end through upper-layer application protocol negotiation. By cooperating with the negotiation function of the upper-layer application protocol, the flow label is assigned and the network conditions at both ends are known, thereby increasing the difficulty of counterfeiting the flow label and reducing the probability of reservation failure. In the case of multicast, it can also prevent feedback storm and simplify multicast The resource reservation status of the flow.

Wherein, if the intermediate node does not receive a periodic resource request refresh message within the default effective lifetime of the flow label, the resource reserved and the processing parameters set for the data flow in the intermediate node will be automatically cancelled. Moreover, the sending end and the receiving end may also actively cancel the resources reserved for the data flow and the processing parameters set in the intermediate router by sending a disassembly message.

Step 2, feedback on the resource request of the real-time application data flow.

On the path from the sending end to the receiving end of the IPv6 message, the intermediate node that cannot recognize the resource reservation request or has not started the flow state establishment function will forward the received message along the path direction as it is. For the intermediate node that has started the flow state establishment function, after receiving the IPv6 message, it will analyze the content in the IPv6 extension header, obtain the QoS requirement parameters of the flow, and judge whether the current local can meet the resource reservation required by the QoS requirement. If the reservation request is satisfied, perform resource reservation and other special processing such as encryption and other specific processing unique to the data flow according to the QoS guarantee model of the network, and forward the message to the next node; otherwise, reject the resource Request, feed back a resource request rejection response to the sender, and set the QoS guarantee availability field in the resource request to be unavailable, so that the path MTU field, available bandwidth field and minimum delay field become effective, and the resource request is transformed into a resource collection request, and continue to send the resource collection request to the next node. In this way, the intermediate node and subsequent nodes can collect path attributes such as path MTU, available bandwidth estimation, and minimum delay through the path MTU field, available bandwidth field, and minimum delay field reserved in the resource collection request.

After receiving the message, the receiving end judges whether the message contains a resource request or a resource collection request by analyzing the QoS guarantee availability field. If the message contains a resource request, then obtain the QoS of the flow according to the resource request Requirement parameters, perform resource reservation and specific processing for the flow according to the network QoS guarantee model, and feed back a resource request confirmation response to the sender; if the message contains a resource collection request, feed back a resource collection response to the sender.

In this way, this step actually includes two situations, as shown in FIG. 3 and FIG. 4 respectively.

As shown in Figure 3, if the resource request Resource Req from the sending end Src to the receiving end Dst is satisfied by the intermediate nodes R1~R3 along the road, when the resource request Resource Req reaches the receiving end Dst, the receiving end Dst sends the request to the sending end Src Feed back a resource request confirmation response ResourceConfirm, and the intermediate nodes will not feedback at all.

As shown in Figure 4, if the resource request Resource Req from the sender to the receiver is rejected on the path, the first intermediate node R2 that rejects the resource request Resource Req will feed back a resource request rejection response Resource to the sender Src Reject, and, starting from this intermediate node R2, the QoS guaranteed availability domain in the resource request Resource Req is set to be unavailable, and the resource request is transformed into a resource collection request Resource Col Req, which continues to be transmitted to the receiving end. When reaching the receiving end Dst, the receiving end Dst feeds back a resource collection response ResourceCol Response to the sending end Src, and the rest of the intermediate nodes do not feed back at all.

The above resource request responses (including resource request confirmation responses and resource request rejection responses) and resource collection responses do not require intermediate nodes to listen or intercept when feeding back, and the feedback path does not necessarily pass through the intermediate nodes that resource requests or resource collection requests pass through , the feedback path of resource request response/resource collection response can be different from the reverse path of resource request/resource collection request.

The resource request confirmation response and resource request rejection response here are Internet Control Message Protocol (ICMP) messages or upper-layer protocols, such as Session Initiation Protocol (SIP) or H. The resource request response can be fed back to the sender by the receiver or an intermediate node through ICMP, or by the receiver through an upper-layer protocol, such as SIP or H.323. Similarly, the resource collection response is an ICMP packet or an upper-layer protocol, such as a SIP or H.323 packet, containing resource collection information. The receiving end can feed back path attributes such as the collected MTU, available bandwidth, and minimum delay included in the resource collection information to the sending end through ICMP or an upper-layer protocol, such as SIP or H.323. So that the sender can modify the reservation request and adjust the sending traffic.

For the case of multicast, considering that the IP multicast technology has not been widely used in a large scale as people expected after years of development, it is still in the experiment and exploration until now. The multicast experts of IETF also gradually abandoned the early arbitrary-source many-to-many multicast mode, and simplified and locked the multicast mode on a specific source-to-many multicast mode, because most multicast applications are one-to-many Many applications, others can be solved by combining one-to-many multicast and unicast. In addition, for the situation where the network conditions of the receiving end are different, it can be obtained through the application layer SIP protocol or H.245 protocol capability negotiation. The receiving end with the same network condition receives through a multicast group, and the receiving end with different network conditions Received via unicast. It is even possible to extend the SIP or H245 protocol to negotiate the value of flowlabel in the IPv6 header of the data flow, so that both parties know the triplet information identifying the flow or the two-tuple information consisting of source/destination address and flow label value before sending data. Generally, triplets are used by default, because intermediate nodes do not need to be specifically informed of the method of identifying flows.

Therefore, the solution of the present invention for the processing of the multicast data flow is:

When the sending end initiates a resource request for a real-time application data flow, it is assumed that the sending end and the receiving end have obtained the network conditions of the sending end and the receiving end through upper-layer application protocol negotiation, then the receiving end with the same network condition adopts the method of the present invention to receive , receiving terminals with different network conditions adopt the method of the present invention to receive through unicast.

When feeding back resource requests for real-time application data streams, because the network conditions of the receiving end have been known through the upper layer protocol before reservation, and according to the resource request feedback method of the present invention, each sending end will only receive 1 to 2 feedbacks, so feedback storms can be avoided. In addition, if the path of some receiving end cannot meet the requirements, after receiving the resource request rejection response and resource collection response from the receiving end or the intermediate node, the sending end can use the unicast method to send the collected path bandwidth rate to It sends data traffic.

The sender of this embodiment carries the resource request in the IPv6 message extension header of the data stream, which also greatly simplifies the problem of supporting mobile IP, because after the mobile IPv6 node moves to a foreign link, it can At the same time, QoS is reserved for the new path in other places. After returning to the home link, the communication partner can be notified and QoS reserved for the original path of the home. A timeout can automatically remove it. For Mobile IP, since the IP address of the sender or receiver will change during the lifetime of the flow, the present invention proposes to use a two-tuple to identify the flow.

The resource request transfer mechanism in step 1 above can be used not only for the IntServ model, but also for other QoS guarantee models, including policy control model, DiffServ model, MPLS TE model, and other comprehensive QoS guarantee models, so that end-to-end Each network domain that the end path passes through can independently select its own QoS guarantee model, and at the same time realize end-to-end QoS guarantee. For example: solve the end-to-end predictable QoS guarantee problem of DiffServ model. When the flow QoS requirement parameters carried in the extension header enter a DiffServ domain edge, the DiffServ domain ingress edge router can set the TC field value in the flow IPv6 message according to these parameters to comply with the differentiated service level management in this domain Strategy. The ingress edge router can also send the flow QoS parameters to the policy control function (Policy Control Function) and admission control function (Admission Control Function) for processing. The ingress edge router can also perform accurate aggregation according to the QoS parameters of the flow, select MPLS or other connection-oriented technology or private line technology to transmit the flow, and strictly guarantee the QoS of the flow.

As can be seen from the scheme described above, this preferred embodiment of the present invention utilizes the advantages of the IPv6 header and the extension header to carry a simple flow state establishment request in the IPv6 extension header, so that it is only used to transmit real-time Apply the QoS requirements of the data flow, determine the QoS guarantee availability and MTU of the path, and carry the flow status including error and confirmation information in the ICMP message to establish a response, thereby reducing the RSVP message overhead and simplifying the complexity and expansion of IntServ/RSVP Sexual issues, and simplify the QoS guarantee problem of mobile IP. On this basis, combined with core network QoS technology MPLS and DiffServ, it can provide end-to-end predictable service quality guarantee for real-time application data flow in IPv6 network.

In addition, the method of the present invention can also be realized by directly simplifying and revising special protocols such as the RSVPv1 protocol, and using RSVP special protocol messages to carry resource requests, resource collection requests, resource request responses, and resource collection responses instead of Carried in the extension header of IPv6 packets or ICMP packets. In this way, the RSVP protocol can be revised as follows: the sender initiates a resource request, the receiver or an intermediate node feeds back a resource request response, and the receiver feeds back a resource request response or a resource collection request response. The advantage of this method is that it can also be implemented in IPv4 by using five-tuple to identify the flow. The disadvantage is that the message overhead is large and the support for mobile IP will be more complicated.

Moreover, the method of the present invention can also use the Internet Protocol version 6 Internet Control Message Protocol (ICMPv6) special protocol message to carry the resource request instead of carrying it in the IPv6 extension header or RSVP message. In fact, in IPv6, the multicast group management protocol (MLDv2) uses the ICMPv6 protocol type instead of the IGMP protocol type in IPv4.

The RSVP-TE extension protocol in the present invention can continue to be used, and is specially used for reliably establishing tunnels and reserving bandwidth for stable aggregation traffic.

Those skilled in the art cannot see that the solution of the present invention can also be applied to other application-level real-time data streams except QoS through corresponding parameter adjustment.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of the present invention. within the scope of protection.

Claims (24)

1. A method for establishing a flow state, comprising: a) The sending end sends a message including a data flow resource request to the receiving end through the step-by-step forwarding of the intermediate node; b) On the path that the message passes through, after receiving the current message, the intermediate node that has started the flow state establishment function judges whether the node satisfies the demand condition of the resource request in the current message, and if so, according to the resource Request resource reservation, forward the current message to the next node along the message transmission path, otherwise, feed back the resource request rejection response to the sender, convert the resource request in the current message into a resource collection request, and forward the message along the message transmission path Forward the message containing the resource collection request to the next node; c) If the current message received by the receiving end contains a resource request, perform resource reservation according to the resource request, and feed back a resource request confirmation response to the sending end, if the current message received by the receiving end contains resource collection request, the resource collection response is fed back to the sender. 2. The method according to claim 1, characterized in that the sending process of the message in step a) further comprises: the sending end periodically sends to the receiving end within the effective lifetime of the data flow The packet requested by the data flow resource. 3. The method according to claim 1, wherein said step a) further comprises: the sending end and the receiving end obtain each other's network conditions through an upper-layer application protocol, and assign a flow label to the data flow . 4. The method according to claim 3, wherein the number of the receiving end is more than one, and the network conditions are the same, then the receiving end receives the message sent by the sending end through a multicast group. 5. The method according to claim 3, characterized in that, the number of the receiving ends is more than two, and at least one receiving end is in a network condition different from other receiving ends, then the network conditions of the other receiving ends are different The receiving end receives the message sent by the sending end through unicast, and more than one receiving end with the same network conditions receives the message sent by the sending end through a multicast group. 6. The method according to claim 1, wherein the data flow is identified by source address, destination address and flow label value; or by source address and flow label value; or by destination address and flow label value . 7. The method according to claim 6, wherein if the sending end and the receiving end are fixed IP terminals, the data flow is identified by a source address, a destination address and a flow label value; If the sending end or the receiving end is a mobile IP terminal, the data flow is identified by a source address and a flow label value, or by a destination address and a flow label value. 8. The method according to claim 1, wherein the resource request includes: flow average rate, peak rate, minimum packet length, maximum packet length, bandwidth requirement, delay requirement, QoS guaranteed availability, path MTU, available bandwidth and minimum delay, where QoS guaranteed availability is available; The resource collection request includes: flow average rate, peak rate, minimum packet length, maximum packet length, bandwidth requirement, delay requirement, QoS guaranteed availability, path MTU, available bandwidth and minimum delay, wherein, QoS guaranteed availability is unavailable. 9. The method according to claim 1, wherein the feedback process of the resource request confirmation response does not require intermediate nodes to intercept or intercept; The intermediate node is not required to listen or intercept during the feedback process of the resource request rejection response; During the feedback process of the resource collection response, no intermediate node is required to intercept or intercept. 10. The method according to claim 1, wherein the feedback path of the resource request confirmation response is different from the reverse path of the resource request; The feedback path of the resource request rejection response is different from the reverse path of the resource request; The feedback path of the resource collection response is different from the reverse path of the resource request. 11. The method according to claim 1, wherein the resource request is set in the packet extension header; the resource collection request is set in the packet extension header. 12. The method according to claim 11, wherein the resource request is set in the option of the message extension header; the resource collection request is set in the option of the message extension header. 13. The method according to claim 12, further comprising: setting a new extension header for the message, the resource request is set in the options of the newly set extension header, and the resource collection request is set in In the options of the extension header for this new setting; Or a new option is set in the existing hop-by-hop option header of the message, the resource request is set in the newly set option, and the resource collection request is set in the newly set option. 14. The method according to claim 1, wherein the resource request confirmation response is an ICMP message or an upper layer protocol message carrying resource request confirmation information; The resource request rejection response is an ICMP message or an upper layer protocol message carrying resource request rejection information; The resource collection response is an ICMP message or an upper layer protocol message carrying resource collection information. 15. The method according to claim 14, wherein the upper layer protocol message is a SIP message or an H.323 message. 16. The method according to claim 1, wherein the message is a dedicated protocol message; The resource request is sent in a dedicated protocol message; The resource collection request is sent in a dedicated protocol message; The resource request confirmation response is a dedicated protocol message carrying resource request confirmation information; The resource request rejection response is a dedicated protocol message carrying resource request rejection information; The resource collection response is a dedicated protocol message carrying resource collection information. 17. The method according to claim 16, wherein the dedicated protocol message is an RSVP dedicated protocol message. 18. The method according to claim 14 or 16, wherein the resource collection information includes the collected path attributes. 19. The method according to claim 18, wherein the path attributes are MTU of the path, available bandwidth estimation and minimum delay. 20. The method according to claim 1, wherein the message is an ICMPv6 dedicated protocol message; The resource request is carried in the ICMPv6 dedicated protocol message for sending; The resource collection request is carried in the ICMPv6 dedicated protocol message for sending. 21. The method according to claim 1 or 10 or 16 or 20, wherein the packet is an IPv6 packet. 22. The method according to claim 16, wherein the packet is an IPv4 packet. 23. The method according to claim 1, characterized in that, in the step b), if the intermediate node satisfies the demand condition of the resource request in the current message, further comprising: performing specific processing unique to the data flow; In the step c), if the current message received by the receiving end contains a resource request, it further includes: performing specific processing specific to the data flow. 24. The method according to claim 1, wherein in step b), the requirement condition of the resource request in the current message is the QoS requirement parameter obtained from the resource request.

Images