CN1691636A - Method of flow state establishment - Google Patents
Method of flow state establishment Download PDFInfo
- Publication number
- CN1691636A CN1691636A CNA200410034709XA CN200410034709A CN1691636A CN 1691636 A CN1691636 A CN 1691636A CN A200410034709X A CNA200410034709X A CN A200410034709XA CN 200410034709 A CN200410034709 A CN 200410034709A CN 1691636 A CN1691636 A CN 1691636A
- Authority
- CN
- China
- Prior art keywords
- message
- resource request
- resource
- request
- response
- 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.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The invention discloses method to build steam mode, and comprises: sending end sends message contained data current resource request by intermediate node step transmission; on the path of message, startup the intermediate built by stream mode, and decides whether the node meets requirement term of message currently, if yes, executes resource pre-reservation according to requirement and transmits message to next node, or else feedbacks exclusion response to the resource requirement form sending end and changes it to resource collection requirement and sent the message; if message contains resource requirement on receiving end, then executes resource pre-reservation according to requirement and feedbacks resource requirement to sending end for confirm response; if message contains resource collection requirement, then feedbacks resource collection response to sending end. The method in this invention solves efficiently transmission problem of real time affair.
Description
Technical field
The present invention relates to the message transmissions technology of network, be meant the method that a kind of stream mode is set up especially.
Background technology
Stream is meant one group of sequence of message between the specific source and destination, and these messages arrive identical destination from identical source, and have identical traffic identifier.The source requires intermediate node that these messages are done particular procedure by signaling or alternate manner.
Consider the needs of real time business, Internet protocol the 6th edition (IPv6) is being done further improvement aspect the support of convection current and the resource reservation, in ipv6 header, defined stream label (FlowLabel) territory of a 20bit, thereby remarkable advantages has been arranged than Internet protocol the 4th edition (IPv4).
Like this, when main frame sends message, message is placed in the stream transmits if desired, only need in the stream label territory, to insert corresponding stream numbering.The stream label thresholding is that 0 message does not belong to any stream, is regarded as general message and handles.
The IPv6 node flows according to the tlv triple identification that the source address in the header, destination address and stream label are formed, and handles the message of this stream according to the stream mode of having set up.In the IPv6 network, because IPv6 extension header length and position is unfixing, and transmission control protocol/User Datagram Protoco (UDP) (TCP/UDP) port numbers is arranged in the IPv6 load because burst or encryption are difficult to obtain, therefore use tlv triple and can more effectively accelerate message classification, be i.e. the speed discerned of stream than the five-tuple of forming by source address, destination address, protocol type, TCP/UDP source port, TCP/UDP destination interface that uses among the IPv4.In addition, because the message classification device only depends on the information of Internet protocol (IP) head, on IPv6, be easy to introduce new upper-layer protocol after making.
(the IETF of internet task working group, Internet Engineering Task Force) IPv6 group has defined the purposes in stream label territory in draft (RFC) 3697, stipulated the minimum requirement that source node marked flows, forward node forwarding flow message and stream mode are set up.Wherein, about the method that the IPv6 stream mode is set up, RFC3697 has only done 2 requirements:
1), need in all or part of IPv6 node of source to the destination path, set up stream mode for can convection current carrying out particular procedure.Stream mode method for building up and stream transaction module are stipulated in independent RFC.
2) for various IPv6 stream mode method for building up can and be deposited, these methods must satisfy two basic demands: the first, and must provide stream mode to remove means, source node can be specified than default 120 seconds longer stream mode life cycles by signaling; The second, the stream mode method for building up must recover from the situation that the requirement stream mode can not be supported.
Though stipulated 2 basic demands among the RFC3697, do not stipulate concrete method and transaction module, and up to the present, also do not have the draft of this respect or individual motion to occur the stream mode method for building up.
The service quality of working out among resource reservation protocol (rsvp) that IETF works out in RFC2205 and the RFC2210 (QoS) integrated service model (IntServ) can be used to application resource and the priority of IPv4/IPv6 stream on intermediate node to set up and safeguard soft state, and intermediate node adopts specific scheduling strategy to carry out particular procedure according to the soft state of stream to stream packet.That is to say, be that the stream packet of specific identifier produces a special passage in network, guarantees that it promptly transmits.Wherein, described specific identifier is meant the tlv triple of five-tuple or the IPv6 of IPv4.
The RSVP message generally is encapsulated in the Raw IP message, also can be encapsulated in the UDP message to send.RSVP is the same with internet control messages agreement agreements such as (ICMP) to be a control protocol, and it does not deliver any application data and only transmits the reservation signaling parameter, supports clean culture and multicast.RSVP intercepts the RSVP message in order to notify intermediate router, and does further processing as a new protocol type, has introduced the ip router alert options according to RFC2113 in the IP head.The RSVP message does not allow burst and reorganization, and the default refresh cycle of soft state is 30 seconds.
The design original intention of RSVP is the end-to-end QoS signaling protocol that designs for Intserv, goes up the real-time application data of transmission to be supported in Intemet.Because thought at that time that the multicast application in real time of multiple spot was that the key that RSVP must support is used, and the multicast receiving terminal is distributed in different places, network condition each other may fall far short.So the basic design philosophy of RSVP is: periodically send message and refresh protocol status on router and the main frame, i.e. soft state, the exchange of two-way ground signaling message, receiving terminal is initiated resource reservation request, and qos signaling is independent of Routing Protocol.
Application program at first triggers RSVP, satisfies the resource of certain QoS for data flow request to be set up.The transmission course of message can be referring to shown in Figure 1 in the concrete resource request, transmitting terminal Src is by the forwarding step by step of intermediate node R1～R3, to receiving terminal Dst transmit path (PATH) message, the reservation that receiving terminal Dst will feed back (RESV) message oppositely is sent to transmitting terminal Src step by step by original route.The concrete processing procedure of each node may further comprise the steps:
Step 101, transmitting terminal periodically sends PATH message along data flow path.
Step 102, receive PATH message after, intermediate node is by analyzing the reverse path information that parameter in the PATH message obtains data flow.
After step 103, receiving terminal are received PATH message, send RESV message request resource reservation.
Step 104, intermediate node is analyzed RESV message and is carried out policy control and admit control, after policy control and admittance control are all passed through, be data flow reserved resource and setting processing parameter, and according to the reverse path information that from PATH message, obtains, along the path forwarding RSVP message reverse with data flow.
If intermediate node is not received periodic PATH and RESV update in default a period of time, then the processing parameter for data flow reserved resource and setting will be cancelled in the intermediate node.And described transmitting terminal and receiving terminal also can be by sending dismounting message, and initiatively cancelling in the intermediate router is the processing parameter of data flow reserved resource and setting.
Because RSVP has favorable expansibility, therefore reserve parameter and specific operation with object mode transparent enclosure in RSVP message, and different transaction modules can be expanded the reservation parameter and the specific operation of own needs.
After RFC2205, IETF for various need do ten to RSVP surplus kind expansion, analysis and summary according to NSIS working group does these expansions in draft-ietf-nsis-signalling-analysis-03.txt comprise: RSVP passes through IP tunnel, support IPSec, the support policy control framework, reduce the soft-state refreshes expense, the RSVP polymerization, 802 local area network (LAN)s are passed through in support, the ATM net is passed through in support, differentiated service (DiffServ) is passed through in support, support empty COS, support the multiprotocol label switching (mpls) traffic engineering (te), support general multiple protocols label exchange (GMPLS), support the RSVP agency, localization RSVP (promptly only reserving) at Access Network, support mobile IP etc.
In these expansions, it is successful having only the RSVP-TE agreement, and is set up explicit route label switched path (LSP) by a large amount of operator's widespread deployments in the MPLS network to be supported in.And other expansion and RSVP and intserv model itself do not obtain widespread deployment.
RSVP-TE is used for the MPLS network, for metastable polymerization traffic is set up explicit route LSP, and bandwidth reserved.Because the life cycle of LSP is long, flow and path can not change continually, the quantity of LSP in network becomes the quantity of how much grades of ground less than the IP miniflow, so the refresh message expense of RSVP-TE, and be to support the receiving terminal initiation of multicast design to ask and ask merging mechanism not have scaling concern.
Yet the design original intention of RSVP is used to tiny IP application data stream reserved resource and special processing in network, and supports the resource reservation of IP multicast data flow.Since RSVP at data flow be the miniflow of application layer, life cycle is short, variation is frequent, if be each miniflow reserved resource and special processing on intermediate router, then RSVP refresh message expense and complicated receiving terminal are initiated request and request merging mechanism, problem aspect complexity and autgmentability is just very outstanding, support to mobile IP then more is difficult to resolve certainly, and therefore, IntServ or RSVP only are applicable in the mininet at present.
In big-and-middle-sized network, the DiffServ that does not rely at present signaling, coarseness that extensibility is good is in occupation of dominant position, and still, DiffServ can only provide relative QoS, predictable QoS end to end can not be guaranteed, therefore still the real time business requirement can not be satisfied fully.
In sum, the IPv6 agreement at outstandingly in the IPv4 network move, safety and QoS problem improve, by adopting fixed header, 8 bit traffic grades (TC, Traffic Class) territory, 20 bit Flow Label, variable length extension header etc. to make mobile IP and IPsec problem be simplified largely and solve.But aspect QoS, only stipulated that in RFC3697 3 tuples are used for traffic classification and to 2 basic demands of stream mode method for building up, do not stipulate concrete stream mode method for building up and transaction module.In addition, the end-to-end measurable QoS of the scalability problem of IntServ/RSVP, DiffServ guarantees also keeping intact in conjunction with problem of problem, IntServ and DiffServ in present IPv6, do not solved at all.Facts have proved for many years, complicated RSVP is successful in the RSVP-TE expansion, but fail aspect setting up in the application layer data flow state, therefore, there is not a gratifying stream mode to set up scheme at present as yet, can satisfy the requirement of real time business, solve as the real time business problem of transmission the QoS demand of application layer real time data stream.
Summary of the invention
In view of this, main purpose of the present invention is to provide a kind of method of stream mode foundation, solves the problem of transmission of real time business.
Method according to above-mentioned purpose a kind of stream mode provided by the invention is set up comprises:
A) transmitting terminal sends the message that includes the data flow resource request by the forwarding step by step of intermediate node to receiving terminal;
B) on the path of described message process, after having started stream mode and setting up the intermediate node of function and receive current message, judge whether this node satisfies the demand condition of resource request in the current message, if, then carry out resource reservation according to this resource request, transmit current message along the message transmissions path to next node, otherwise, to the response of transmitting terminal feedback resources request refusal, change the resource request in the current message into the resource acquisition request, transmit the message that this includes the resource acquisition request to next node along the message transmissions path;
C) if include resource request in the current message that receiving terminal is received, then carry out resource reservation according to this resource request, confirm response to the request of transmitting terminal feedback resources,, then collect response to the transmitting terminal feedback resources if include the resource acquisition request in the current message that receiving terminal is received.
This method step a) process of transmitting of described message further comprises: transmitting terminal periodically sends the message that includes this data flow resource request to receiving terminal in effective life cycle of described data flow.
The described step a) of this method takes a step forward and comprises: described transmitting terminal and receiving terminal obtain the other side's network condition by upper layer application protocol, and are described distribution of flows stream label.
The number of the described receiving terminal of this method is more than one, and network condition of living in is identical, the message that then described receiving terminal sends by a multicast group receiving end/sending end.
The number of the described receiving terminal of this method is more than two, and there is the residing network condition of at least one receiving terminal different with other receiving terminal, then different receiving terminals with other receiving terminal network condition, by the message that the clean culture receiving end/sending end sends, the message that above receiving terminal sends by a multicast group receiving end/sending end that network condition is identical.
The described data flow of this method adopts source address, destination address and flow label values sign; Or adopt source address and flow label values to identify; Or adopt destination address and flow label values to identify.
If described transmitting terminal of this method and receiving terminal are fixing IP terminal, then described data flow adopts source address, destination address and flow label values to identify;
If described transmitting terminal or receiving terminal are mobile IP terminal, then described data flow adopts source address and flow label values, or adopts destination address and flow label values sign.
The described resource request of this method comprises: the equal speed of levelling, peak rate, minimum message length, maximum message segment length, bandwidth requirement, delay requirement, QoS guarantee availability, path mtu, available bandwidth and minimal time delay, wherein, QoS guarantees that availability is available;
Described resource acquisition request comprises: the equal speed of levelling, peak rate, minimum message length, maximum message segment length, bandwidth requirement, delay requirement, QoS guarantee availability, path mtu, available bandwidth and minimal time delay, wherein, QoS guarantees that availability is unavailable.
The described resource request of this method confirms not require in the feedback procedure of response that intermediate node intercepts or tackle;
Do not require in the feedback procedure of described resource request refusal response that intermediate node intercepts or tackle;
Do not require in the feedback procedure of described resource acquisition response that intermediate node intercepts or tackle.
The described resource request of this method confirms that the feedback path of response is different with the reverse path of resource request;
The feedback path of described resource request refusal response is different with the reverse path of resource request;
The feedback path of described resource acquisition response is different with the reverse path of resource request.
The described resource request of this method is arranged in the described message extension header; Described resource acquisition request is arranged in the described message extension header.
The described resource request of this method is arranged in the prolate-headed option of described message; Described resource acquisition request is arranged in the prolate-headed option of described message.
This method further comprises: for message newly is provided with an extension header, described resource request is arranged in this newly-installed prolate-headed option, and described resource acquisition request is arranged in this newly-installed prolate-headed option;
An option perhaps newly is set in the existing hop-by-hop options header of message, and described resource request is arranged in this newly-installed option, and described resource acquisition request is arranged in this newly-installed option.
The described resource request of this method confirms that response is for carrying the icmp packet or the upper-layer protocol message of resource request confirmation;
The response of described resource request refusal is for carrying the icmp packet or the upper-layer protocol message of resource request refusal information;
Described resource acquisition response is for carrying the icmp packet or the upper-layer protocol message of resource acquisition information.
The described upper-layer protocol message of this method is SIP message or message H.323.
The described message of this method is the specialized protocol message;
Described resource request is carried in the specialized protocol message and sends;
Described resource acquisition request is carried in the specialized protocol message and sends;
Described resource request confirms that response is for carrying the specialized protocol message of resource request confirmation;
The response of described resource request refusal is for carrying the specialized protocol message of resource request refusal information;
Described resource acquisition response is for carrying the specialized protocol message of resource acquisition information.
The described specialized protocol message of this method is a RSVP specialized protocol message.
Comprise collected path attribute in the described resource acquisition information of this method.
The described path attribute of this method is MTU, estimation of available bandwidth and the minimal time delay in path.
The described message of this method is an ICMPv6 specialized protocol message;
Described resource request is carried in this ICMPv6 specialized protocol message and sends;
Described resource acquisition request is carried in this ICMPv6 specialized protocol message and sends.
The described message of this method is the IPv6 message.
The described message of this method is the IPv4 message.
If intermediate node satisfies the demand condition of resource request in the current message in the described step b) of this method, then further comprise: carry out the peculiar particular procedure of described data flow;
If include resource request in the current message that receiving terminal is received in the described step c), then further comprise: carry out the peculiar particular procedure of described data flow.
This method step b) the QoS demand parameter of the demand condition of resource request for from resource request, obtaining in the current message described in.
From above as can be seen, the method that a kind of stream mode provided by the present invention is set up, by initiating resource reservation request by transmitting terminal, and carry out path attribute as required and collect, make original two-way news exchange be reduced to unidirectional resource request, simplified resource reservation mechanism, can support multiple QoS to guarantee model flexibly at real time business application layer miniflow, make stream each network domains of process can independently select to be fit to own QoS assurance model, guarantee QoS end to end simultaneously.And, utilize the extension header of IPv6 message to carry measures such as resource request further by the parameter in the compressed resource request, significantly reduced the resource reservation network overhead, and the resource reservation support of mobile IP; By cooperating with the negotiation functionality of upper layer application protocol, increased the pseudo-difficulty of emitting stream label, reduce and reserve failure probability and feedback implosion, simplify the resource reservation situation of multicast data flow; And can collect path attribute effectively according to the QoS demand, avoid isolated the collect blindness of path attribute and the wasting of resources that causes.
Description of drawings
Fig. 1 carries out the message transmission procedure schematic diagram of resource request for the prior art RSVP;
Fig. 2 is the transmitting terminal of the embodiment of the invention sends a process schematic diagram from resource request to receiving terminal;
Fig. 3 is the message transmittance process schematic diagram under first kind of situation of embodiment of the invention resource request feedback;
Fig. 4 is the message transmittance process schematic diagram under second kind of situation of embodiment of the invention resource request feedback.
Embodiment
The present invention is further described in more detail below in conjunction with drawings and the specific embodiments.
Because for the of short duration or even real-time application data streams that move of a large amount of tiny life, the two-way signaling message exchange process of RSVP is too complicated, and expense is excessive, therefore, need a kind of more simple and mechanism that expense is little.Anatomize the RSVP and the intserv model of initial design, if, only need use following three objects in the PATH of RSVP and the RESV message only for the QoS that realizes application data stream guarantees:
(1) RSVP SENDER_TSPEC: comprise the flow specification information of transmitting terminal, as token bucket rate and size, peak rate, minimum message length, maximum message segment length.
(2) RSVP FLOWSPEC: comprise the reservation request information of receiving terminal, as token bucket rate and size, peak rate, minimum message length, maximum message segment length, bandwidth requirement, delay requirement.
(3) RSVP ADSPEC: comprise the information that source or intermediate node produce, the QoS that collects the path guarantees availability, estimated bandwidth, minimal time delay, MTU and other path attribute, and direction of transfer is that purpose is arrived in the source.
And, consider the RSVP of in fact several early stage or same periods, all send resource reservation request as ST-II, YESSIR, Boomrang and the signaling of future generation (NSIS) now studied by transmitting terminal, even and if RSVP also be that the recipient receives that just sending RESV after the PATH message that transmit leg sends asks.
Therefore, do not considering that multiple spot is to multiple spot, and under the situation that the resource reservation of the multicast data flow that the receiving terminal network condition has nothing in common with each other requires, can initiate to carry the resource reservation request of few parameters fully by transmitting terminal, and carry the path attribute intelligence-collecting object as required, thereby two-way message is reduced to unidirectional the time, and the content of message also obtains compression.
To shown in Figure 4, IPv6 stream mode method for building up provided by the invention mainly is divided into two big steps referring to Fig. 2:
Step 1, transmitting terminal are initiated the resource request of real-time application data stream.
Referring to shown in Figure 2, transmitting terminal Src was carried at resource request Resource Req in the IPv6 message extension header of data flow in effective life cycle of data flow, periodically sent to receiving terminal Dst by intermediate node R1～R3.
Wherein, periodicity described here might not be meant regular time at interval, and the time interval that each message sends can be different, but must guarantee to send one time message at least in effective life cycle of data flow, or is called and carries out a message and refresh.
For carrying resource request, needing a kind of IPv6 extension header of redetermination---stream QoS request header (FlowQoS Requirements Header) is placed on the resource request of real-time application data stream in the option (Option) of Flow QoSRequirements Header; Perhaps a kind of Option of redetermination in defined hop-by-hop options header (Hop-by-hop Options Header) comprises the resource request of real-time application data stream among the Option.
So, transmit leg is carried at resource request among the Option of prolate-headed Option of IPv6 message or redetermination, and needn't transmit with the specialized protocol message, thereby can reduce message overhead, this is because of the description that need not transmit filter in the message, but the function of filter is lain in the tlv triple of ipv6 header.
Only need comprise following parameter in the resource request: the equal speed of levelling, peak rate, minimum message length, maximum message segment length, bandwidth requirement, delay requirement, QoS guarantee parameters such as availability, PMTU (MTU), available bandwidth, minimal time delay.Wherein, QoS guarantees that availability, path mtu, available bandwidth and minimal time delay are used to collect path attribute, and intermediate node can change their value when transmitting, and other parameter passes to receiving terminal with then remaining unchanged.And when QoS guaranteed that availability represents that the QoS demand can not be satisfied in the path, path mtu territory, available bandwidth territory and minimal time delay territory were just effective, the path attribute that expression is collected.Although defined a kind of path mtu discovery mechanism among the RFC1981, this method is more effective, because have only when having determined that the QoS demand of stream can not be satisfied in the path just needs to collect path mtu, the default minimum MTU of IPv6 link that then uses the IPv6-SPEC regulation.
In addition, before this step, transmitting terminal and receiving terminal need consult to have obtained the network condition of transmission and receiving terminal usually by upper layer application protocol.By cooperating, distribute stream label and understand the one-port condition, thereby increase the pseudo-difficulty of emitting stream label with the negotiation functionality of upper layer application protocol, reduce and reserve the failure probability, if multicast scenarios can also prevent feedback implosion, simplify the resource reservation situation of multicast data flow.
Wherein, if default stream label in effective life cycle intermediate node do not receive periodic resource request update, then the processing parameter for this data flow reserved resource and setting will be cancelled automatically in the intermediate node.And described transmitting terminal and receiving terminal also can be by sending dismounting message, and initiatively cancelling in the intermediate router is the processing parameter of data flow reserved resource and setting.
Step 2 is to the feedback of the resource request of real-time application data stream.
On the path of IPv6 message from the transmitting terminal to the receiving terminal, can not the recognition resource reservation request or do not start the intermediate node that stream mode is set up function, the message of receiving in statu quo can be transmitted along path direction.And set up the intermediate node of function for having started stream mode, after receiving the IPv6 message, with the content in the analyzing IP v6 extension header, therefrom obtain the QoS demand parameter of stream, judge whether current this locality can satisfy the desired resource reservation request of this QoS demand, if satisfy, then this stream is guaranteed according to the QoS of network that model is carried out resource reservation and other this data flow is peculiar as: particular procedure such as encryption, and message transmitted to next node; Otherwise, refuse this resource request, to the response of a resource request refusal of transmitting terminal feedback, and be changed to the assurance of the QoS in this resource request availability territory unavailable, path mtu territory, available bandwidth territory and minimal time delay territory begin effectively like this, resource request changes the resource acquisition request into, and this resource acquisition request is continued to send to next node.This intermediate node and later node thereof can be collected the path attributes such as MTU, estimation of available bandwidth and minimal time delay in path by path mtu territory, available bandwidth territory and the minimal time delay territory of reserving in this resource acquisition request like this.
After receiving terminal receives described message, by what analyze that QoS guarantees that the availability territory judges that this message comprises is resource request or resource acquisition request, if include resource request in this message, then obtain the QoS demand parameter of stream according to this resource request, this stream is carried out resource reservation and particular procedure according to the QoS assurance model of network, confirm response to the request of transmitting terminal feedback resources; If include the resource acquisition request in this message, then collect response to the transmitting terminal feedback resources.
Like this, in fact comprise two kinds of situations in this step, respectively referring to Fig. 3 and shown in Figure 4.
As shown in Figure 3, if the resource request Resource Req from transmitting terminal Src to receiving terminal Dst is satisfied by the intermediate node R1～R3 one road along the road, when then resource request Resource Req arrives receiving terminal Dst, return resource request of feedback by receiving terminal Dst to transmitting terminal Src and confirm response ResourceConfirm, intermediate node does not then feed back without exception.
As shown in Figure 4, if the resource request Resource Req from the transmitting terminal to the receiving terminal has run into refusal on the path, then first intermediate node R2 that refuses this resource request Resource Req can be to a resource request refusal of transmitting terminal Src feedback response Resource Reject, and, from this intermediate node R2, QoS among the resource request Resource Req guarantees that the availability territory is changed to unavailable, resource request changes resource acquisition request Resource Col Req into, continues to the receiving terminal transmission.When arriving receiving terminal Dst, to a resource acquisition response of transmitting terminal Src feedback ResourceCol Response, remaining intermediate node does not then feed back without exception by receiving terminal Dst.
Above-mentioned resource request response (comprising that resource request is confirmed to respond and the resource request refusal responds) and resource acquisition response are when feedback, do not require that intermediate node intercepts or tackle, and feedback path not necessarily pass through resource request or resource acquisition request the intermediate node of process, the feedback path of resource request response/resource acquisition response can be different with the reverse path of resource request/resource acquisition request.
The resource request here confirms that response and the response of resource request refusal are to include Internet Control Message Protocol (ICMP) message or the upper-layer protocol that resource request is confirmed response or resource request refusal response message, as Session Initiation Protocol or message H.323, can pass through ICMP by receiving terminal or intermediate node, or pass through upper-layer protocol by receiving terminal, as SIP or H.323, give transmitting terminal with the resource request responsive feedback.Equally, resource acquisition response is for including the icmp packet or the upper-layer protocol of resource acquisition information, as SIP or message H.323.Can be by receiving terminal by ICMP or by upper-layer protocol, as SIP or H.323, path attributes such as the collected MTU that comprises in the resource acquisition information, available bandwidth, minimal time delay are fed back to transmitting terminal.Thereby so that transmitting terminal is revised reservation request and is adjusted transmitted traffic.
For the situation of multicast, consider because the IP multicasting technology does not have extensive widespread usage as desired all the time through years of development, still be in up to now in experiment and the exploration.And the multicast brainstrust of IETF has also been abandoned early stage any source multi-to-multi multicast pattern gradually, multicast pattern is simplified and be locked on the particular source one-to-many multicast pattern, use because most of multicast application all are one-to-manies, other then available one-to-many multicast and clean culture are in conjunction with solution.And, situation about having nothing in common with each other for receiving terminal network condition of living in, fully can be by application layer Session Initiation Protocol or H.245 protocol capability negotiation acquisition, the receiving terminal that network condition is identical receives by a multicast group, and the different receiving terminal of network condition receives by clean culture.Even can expand SIP or the H245 agreement value with the flowlabel in the ipv6 header of negotiation data stream, thereby both sides understand the binary group information that the triplet information of sign stream or source/destination address, flow label values constitute before sending data.Generally, default employing tlv triple is not because need the method for special instruction intermediate node identification stream.
Therefore, the present invention program's being treated to for multicast traffic stream:
When transmitting terminal is initiated the resource request of real-time application data stream, suppose that transmitting terminal and receiving terminal have obtained the network condition of transmission and receiving terminal by the upper layer application protocol negotiation, the receiving terminal that then network condition is identical adopts the inventive method to receive by a multicast, and the different receiving terminal of network condition adopts the inventive method to receive by clean culture.
When the resource request of real-time application data stream is fed back, owing to by upper-layer protocol the network condition of receiving terminal is had gained some understanding before reserving, and to the feedback method of resource request, each transmitting terminal will only can be received 1 to 2 feedback, therefore can avoid feedback implosion according to the present invention.In addition, if the path of some receiving terminals can not meet the demands, then after receiving the response of resource request refusal and resource acquisition response that this receiving terminal or intermediate node are sent, transmitting terminal can be used mode of unicast instead and send data traffic with the path bandwidth speed of collecting to it.
The transmitting terminal of present embodiment is carried at resource request in the IPv6 message extension header of data flow, also simplified support issue greatly to mobile IP, because mobile IPv 6 node is after moving to foreign link, can be to reserve QoS simultaneously in the Binding Update process at the new route in other places, after returning home link, the original route that can be the local in the notifying communication partner is reserved QoS, and the QoS in the other places reserves owing to do not re-use, by soft-state refreshes is overtime can be automatically with its dismounting.For mobile IP, because transmit leg or recipient's IP address can change at the stream life span, so the present invention advises adopting binary group id stream.
Above the resource request pass through mechanism of described step 1 not only can be used for intserv model, can also be used for other QoS and guarantee model, comprise policy control model, DiffServ model, MPLS TE model, reach other comprehensive QoS assurance model, make end-to-end path each network domains of process can select to be fit to own QoS independently and guarantee model, realize QoS guarantee end to end simultaneously.For example: the end-to-end measurable QoS that solves the DiffServ model guarantees problem.When entrained stream QoS demand parameter whenever entered edge, a DiffServ territory in the extension header, this DiffServ realm entry edge router can be according to the TC thresholding in the stream IPv6 message of these parameter settings, to meet the differentiated grades of service management strategy in this territory.The ingress edge router can also give policy control functions (Policy Control Function) with the qos parameter of stream and accommodating control function (Admission ControlFunction) is handled.The ingress edge router can also carry out polymerization accurately according to the qos parameter of stream, selects MPLS or other towards interconnection technique or special line technical transmission stream, the QoS of strict guarantee stream.
Scheme from above as can be seen, this preferred embodiment of the present invention, utilize ipv6 header and prolate-headed advantage, in the IPv6 extension header, carry simple stream mode and set up request, make it be used to transmit the QoS demand of real-time application data stream, the QoS that determines the path guarantees availability and MTU, in icmp packet, carry the stream mode that includes wrong and confirmation and set up response, thereby reduce RSVP message expense, simplify complexity and the scaling concern of IntServ/RSVP, and simplified the QoS assurance problem of mobile IP.On this basis, combine, can in the IPv6 network, provide predictable services quality assurance end to end for real-time application data stream with core net QoS technology MPLS and DiffServ.
In addition, method of the present invention also can realize by directly the specialized protocols such as agreement of RSVPv1 being simplified and revised, carry resource request, resource acquisition request, resource request response and resource acquisition response with RSVP specialized protocol message, rather than be carried in IPv6 message extension header or the icmp packet.RSVP can be revised and be like this: initiate resource request by transmit leg, recipient or intermediate node feedback resources request response, the request response of recipient's feedback resources or resource acquisition request response.The benefit of doing like this is by with five-tuple sign stream, also can realize in IPv4, and shortcoming is that message overhead is big and complicated to the support meeting of mobile IP.
And method of the present invention can also adopt internet control messages agreement (ICMPv6) the specialized protocol message of Internet protocol the 6th edition to carry resource request, rather than is carried in IPv6 extension header or the RSVP message.In fact, in IPv6, internet group management protocol (MLDv2) is exactly to use the ICMPv6 protocol type, rather than continues to use the IGMP protocol type among the IPv4.
The RSVP-TE Extended Protocol can continue to use among the present invention, is exclusively used in to stable polymerization traffic and sets up tunnel and bandwidth reserved reliably.
Those skilled in the art can not find out, the present invention program is by the relevant parameter adjustment, except that QoS also applicable to other application layer real time data stream.
The above only is preferred embodiment of the present invention, and is in order to restriction the present invention, within the spirit and principles in the present invention not all, any modification of being done, is equal to replacement, improvement etc., all should be included within protection scope of the present invention.
Claims (24)
1, a kind of method of stream mode foundation is characterized in that, comprising:
A) transmitting terminal sends the message that includes the data flow resource request by the forwarding step by step of intermediate node to receiving terminal;
B) on the path of described message process, after having started stream mode and setting up the intermediate node of function and receive current message, judge whether this node satisfies the demand condition of resource request in the current message, if, then carry out resource reservation according to this resource request, transmit current message along the message transmissions path to next node, otherwise, to the response of transmitting terminal feedback resources request refusal, change the resource request in the current message into the resource acquisition request, transmit the message that this includes the resource acquisition request to next node along the message transmissions path;
C) if include resource request in the current message that receiving terminal is received, then carry out resource reservation according to this resource request, confirm response to the request of transmitting terminal feedback resources,, then collect response to the transmitting terminal feedback resources if include the resource acquisition request in the current message that receiving terminal is received.
2, method according to claim 1 is characterized in that, the process of transmitting of the described message of step a) further comprises: transmitting terminal periodically sends the message that includes this data flow resource request to receiving terminal in effective life cycle of described data flow.
3, method according to claim 1 is characterized in that, described step a) takes a step forward and comprises: described transmitting terminal and receiving terminal obtain the other side's network condition by upper layer application protocol, and are described distribution of flows stream label.
4, method according to claim 3 is characterized in that, the number of described receiving terminal is more than one, and network condition of living in is identical, the message that then described receiving terminal sends by a multicast group receiving end/sending end.
5, method according to claim 3, it is characterized in that, the number of described receiving terminal is more than two, and there is the residing network condition of at least one receiving terminal different with other receiving terminal, then different receiving terminals with other receiving terminal network condition, by the message that the clean culture receiving end/sending end sends, the message that above receiving terminal sends by a multicast group receiving end/sending end that network condition is identical.
6, method according to claim 1 is characterized in that, described data flow adopts source address, destination address and flow label values sign; Or adopt source address and flow label values to identify; Or adopt destination address and flow label values to identify.
7, method according to claim 6 is characterized in that, if described transmitting terminal and receiving terminal are fixing IP terminal, then described data flow adopts source address, destination address and flow label values to identify;
If described transmitting terminal or receiving terminal are mobile IP terminal, then described data flow adopts source address and flow label values, or adopts destination address and flow label values sign.
8, method according to claim 1, it is characterized in that, described resource request comprises: the equal speed of levelling, peak rate, minimum message length, maximum message segment length, bandwidth requirement, delay requirement, QoS guarantee availability, path mtu, available bandwidth and minimal time delay, wherein, QoS guarantees that availability is available;
Described resource acquisition request comprises: the equal speed of levelling, peak rate, minimum message length, maximum message segment length, bandwidth requirement, delay requirement, QoS guarantee availability, path mtu, available bandwidth and minimal time delay, wherein, QoS guarantees that availability is unavailable.
9, method according to claim 1 is characterized in that, described resource request confirms not require in the feedback procedure of response that intermediate node intercepts or tackle;
Do not require in the feedback procedure of described resource request refusal response that intermediate node intercepts or tackle;
Do not require in the feedback procedure of described resource acquisition response that intermediate node intercepts or tackle.
10, method according to claim 1 is characterized in that, described resource request confirms that the feedback path of response is different with the reverse path of resource request;
The feedback path of described resource request refusal response is different with the reverse path of resource request;
The feedback path of described resource acquisition response is different with the reverse path of resource request.
11, method according to claim 1 is characterized in that, described resource request is arranged in the described message extension header; Described resource acquisition request is arranged in the described message extension header.
12, method according to claim 11 is characterized in that, described resource request is arranged in the prolate-headed option of described message; Described resource acquisition request is arranged in the prolate-headed option of described message.
13, method according to claim 12, it is characterized in that, further comprise: for message newly is provided with an extension header, described resource request is arranged in this newly-installed prolate-headed option, and described resource acquisition request is arranged in this newly-installed prolate-headed option;
An option perhaps newly is set in the existing hop-by-hop options header of message, and described resource request is arranged in this newly-installed option, and described resource acquisition request is arranged in this newly-installed option.
14, method according to claim 1 is characterized in that, described resource request confirms that response is for carrying the icmp packet or the upper-layer protocol message of resource request confirmation;
The response of described resource request refusal is for carrying the icmp packet or the upper-layer protocol message of resource request refusal information;
Described resource acquisition response is for carrying the icmp packet or the upper-layer protocol message of resource acquisition information.
15, method according to claim 14 is characterized in that, described upper-layer protocol message is SIP message or message H.323.
16, method according to claim 1 is characterized in that, described message is the specialized protocol message;
Described resource request is carried in the specialized protocol message and sends;
Described resource acquisition request is carried in the specialized protocol message and sends;
Described resource request confirms that response is for carrying the specialized protocol message of resource request confirmation;
The response of described resource request refusal is for carrying the specialized protocol message of resource request refusal information;
Described resource acquisition response is for carrying the specialized protocol message of resource acquisition information.
17, method according to claim 16 is characterized in that, described specialized protocol message is a RSVP specialized protocol message.
18, according to claim 14 or 16 described methods, it is characterized in that, comprise collected path attribute in the described resource acquisition information.
19, method according to claim 18 is characterized in that, described path attribute is MTU, estimation of available bandwidth and the minimal time delay in path.
20, method according to claim 1 is characterized in that, described message is an ICMPv6 specialized protocol message;
Described resource request is carried in this ICMPv6 specialized protocol message and sends;
Described resource acquisition request is carried in this ICMPv6 specialized protocol message and sends.
21, according to claim 1 or 10 or 16 or 20 described methods, it is characterized in that described message is the IPv6 message.
22, method according to claim 16 is characterized in that, described message is the IPv4 message.
23, method according to claim 1 is characterized in that, if intermediate node satisfies the demand condition of resource request in the current message in the described step b), then further comprises: carry out the peculiar particular procedure of described data flow;
If include resource request in the current message that receiving terminal is received in the described step c), then further comprise: carry out the peculiar particular procedure of described data flow.
24, method according to claim 1 is characterized in that, the QoS demand parameter of the demand condition of resource request for obtaining from resource request in the current message described in the step b).
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200410034709XA CN100387023C (en) | 2004-04-26 | 2004-04-26 | Method of flow state establishment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200410034709XA CN100387023C (en) | 2004-04-26 | 2004-04-26 | Method of flow state establishment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1691636A true CN1691636A (en) | 2005-11-02 |
| CN100387023C CN100387023C (en) | 2008-05-07 |
Family
ID=35346771
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB200410034709XA Expired - Fee Related CN100387023C (en) | 2004-04-26 | 2004-04-26 | Method of flow state establishment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100387023C (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007045163A1 (en) * | 2005-10-17 | 2007-04-26 | Huawei Technologies Co., Ltd. | Method for realizing end-to-end stream transmission and the node equipment |
| CN100420237C (en) * | 2005-11-18 | 2008-09-17 | 华为技术有限公司 | Method for controlling real time service on router |
| WO2009079844A1 (en) * | 2007-12-20 | 2009-07-02 | Zte Corporation | Processing method for resource request in ngn |
| CN101047614B (en) * | 2006-05-01 | 2010-08-25 | 华为技术有限公司 | Flow transmission route set-up method and data transmission system in IPv6 network environment |
| CN101043440B (en) * | 2006-03-25 | 2011-02-16 | 华为技术有限公司 | Method for supporting multi-service flow operation in WiMAX network |
| CN102638388A (en) * | 2011-02-09 | 2012-08-15 | 华为技术有限公司 | Flow label negotiating method, relevant device and system |
| CN103051562A (en) * | 2008-12-01 | 2013-04-17 | 华为技术有限公司 | Method and equipment for realizing maximum transmission unit of resource reservation protocol link |
| CN105099915A (en) * | 2014-04-28 | 2015-11-25 | 华为技术有限公司 | Business path establishing method and device |
| CN102123440B (en) * | 2010-01-08 | 2016-05-11 | 中兴通讯股份有限公司 | The confirmation method of control head and system |
| EP1965530A4 (en) * | 2005-12-23 | 2016-10-19 | Zte Corp | A method for soft rerouting in optical network |
| WO2016165492A1 (en) * | 2015-07-02 | 2016-10-20 | 中兴通讯股份有限公司 | Method and apparatus for implementing service function chain |
| CN106060023A (en) * | 2016-05-20 | 2016-10-26 | 汉柏科技有限公司 | Malicious data interception processing method and device |
| CN112787902A (en) * | 2019-11-08 | 2021-05-11 | 中兴通讯股份有限公司 | Message encapsulation method and device and message de-encapsulation method and device |
| CN113055293A (en) * | 2019-12-27 | 2021-06-29 | 华为技术有限公司 | Routing method and device in software defined wide area network and communication system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001352347A (en) * | 2000-04-12 | 2001-12-21 | Alcatel Internetworking Inc | Rsvp proxy service for communication network |
| US7209439B2 (en) * | 2001-03-20 | 2007-04-24 | Mci, Llc | Pool-based resource management in a data network |
-
2004
- 2004-04-26 CN CNB200410034709XA patent/CN100387023C/en not_active Expired - Fee Related
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007045163A1 (en) * | 2005-10-17 | 2007-04-26 | Huawei Technologies Co., Ltd. | Method for realizing end-to-end stream transmission and the node equipment |
| CN100420237C (en) * | 2005-11-18 | 2008-09-17 | 华为技术有限公司 | Method for controlling real time service on router |
| EP1965530A4 (en) * | 2005-12-23 | 2016-10-19 | Zte Corp | A method for soft rerouting in optical network |
| CN101043440B (en) * | 2006-03-25 | 2011-02-16 | 华为技术有限公司 | Method for supporting multi-service flow operation in WiMAX network |
| CN101047614B (en) * | 2006-05-01 | 2010-08-25 | 华为技术有限公司 | Flow transmission route set-up method and data transmission system in IPv6 network environment |
| WO2009079844A1 (en) * | 2007-12-20 | 2009-07-02 | Zte Corporation | Processing method for resource request in ngn |
| US8526304B2 (en) | 2007-12-20 | 2013-09-03 | Zte Corporation | Processing method for resource request in NGN |
| CN103051562A (en) * | 2008-12-01 | 2013-04-17 | 华为技术有限公司 | Method and equipment for realizing maximum transmission unit of resource reservation protocol link |
| CN103051562B (en) * | 2008-12-01 | 2015-09-09 | 华为技术有限公司 | A kind of MTU implementation method of resource reservation protocol link and equipment |
| CN102123440B (en) * | 2010-01-08 | 2016-05-11 | 中兴通讯股份有限公司 | The confirmation method of control head and system |
| US9185040B2 (en) | 2011-02-09 | 2015-11-10 | Huawei Technologies Co., Ltd. | Flow label negotiation method, related device, and system |
| CN102638388B (en) * | 2011-02-09 | 2014-03-12 | 华为技术有限公司 | Flow label negotiating method, relevant device and system |
| CN102638388A (en) * | 2011-02-09 | 2012-08-15 | 华为技术有限公司 | Flow label negotiating method, relevant device and system |
| CN105099915A (en) * | 2014-04-28 | 2015-11-25 | 华为技术有限公司 | Business path establishing method and device |
| CN105099915B (en) * | 2014-04-28 | 2018-11-30 | 华为技术有限公司 | A kind of method and apparatus for establishing service path |
| WO2016165492A1 (en) * | 2015-07-02 | 2016-10-20 | 中兴通讯股份有限公司 | Method and apparatus for implementing service function chain |
| CN106060023A (en) * | 2016-05-20 | 2016-10-26 | 汉柏科技有限公司 | Malicious data interception processing method and device |
| CN112787902A (en) * | 2019-11-08 | 2021-05-11 | 中兴通讯股份有限公司 | Message encapsulation method and device and message de-encapsulation method and device |
| CN112787902B (en) * | 2019-11-08 | 2023-11-21 | 中兴通讯股份有限公司 | Message encapsulation method and device and message decapsulation method and device |
| CN113055293A (en) * | 2019-12-27 | 2021-06-29 | 华为技术有限公司 | Routing method and device in software defined wide area network and communication system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100387023C (en) | 2008-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4520705B2 (en) | Communication system and communication method | |
| CN1283079C (en) | IP network service quality assurance method and system | |
| CN1488217A (en) | Method and system for resource reservations in a multicasting network | |
| CN1701319A (en) | Edge-based per-flow QoS admission control in a data network | |
| CN1511279A (en) | Strategy based synchronization for each resource between routers in data networks | |
| CN1691636A (en) | Method of flow state establishment | |
| CN1747400A (en) | System and realization for dynamic cooperating service quality in next generation network | |
| CN1449162A (en) | Telecommunications system employing virtual service network architecture | |
| JP2007507931A (en) | Bidirectional QoS reservation in in-band signaling mechanism | |
| CN1832449A (en) | Method for implementing resource preretention of agency requir mode in next network | |
| CN1863144A (en) | Method for providing differential service | |
| WO2009114976A1 (en) | Method and system for resource and admission control | |
| CN101047614A (en) | Flow transmission route set-up method and data transmission system in IPv6 network environment | |
| CN1581791A (en) | Method for providing reliable transmission service quality in communication network | |
| CN101064637A (en) | Method for guaranteeing quality of service of operation maintenance data stream | |
| CN101599843A (en) | Quality control method for multicast service based on IPv6 | |
| CN101309229B (en) | Resource admission control method for network of multiple protocol label switch structure | |
| CN1863149A (en) | Method of implementing a set of specific stream QoS control | |
| CN1643858A (en) | Quality of service request correlation | |
| CN1622529A (en) | A method for implementing VPN having service quality guarantee | |
| CN101047706A (en) | Session control system and method for access network | |
| CN1617508A (en) | Service quality strategy conversion device and method | |
| JP2009105949A (en) | TERMINAL CAPABLE OF EXECUTING QoS CONTROL | |
| CN1859363A (en) | Method and its system for interdomain consultation of end-to-end service quality | |
| CN1917440A (en) | Method of realizing Pipe model based on distinction service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080507 Termination date: 20180426 |