CN100488197C - Exchange protecting method in multi protocol label exchange - Google Patents
Exchange protecting method in multi protocol label exchange Download PDFInfo
- Publication number
- CN100488197C CN100488197C CNB200510033415XA CN200510033415A CN100488197C CN 100488197 C CN100488197 C CN 100488197C CN B200510033415X A CNB200510033415X A CN B200510033415XA CN 200510033415 A CN200510033415 A CN 200510033415A CN 100488197 C CN100488197 C CN 100488197C
- Authority
- CN
- China
- Prior art keywords
- message
- node
- protected mode
- exchanges
- guard method
- 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.)
- Expired - Fee Related
Links
Images
Abstract
The present invention relates to a multiple protocol label exchange protection method. It contains 1, first node transmitting first message including first node supported protection mode to second node, 2, second node matched receiving protection mode in first message, if matching successfully then feeding back matched protection mode second message to first node. The present invention can make label exchange route select optimize protection mode through protective capability announce and negotiation between source node and host node, thereby raising label exchange route establishing efficiency.
Description
Technical field
The present invention relates to the communications field, the guard method of the exchange in particularly a kind of multiprotocol label switching.
Background technology
(Multiprotocol Label Switching MPLS) obtains more application as data transferring technique in multiprotocol label switching at present.The protection of multiprotocol label switching roughly has modes such as quick heavy-route, load sharing, 1:1,1+1, and different protected modes to Point of Local Repair (Point of LocalRepair, PLR) and merge point (Merge Point, requirement difference MP).Wherein, heavy-route, load sharing, 1:1 require two ends to support same agreement fast; The Point of Local Repair of load sharing, 1:1 requires the distribution of support point to merge point (P2MP); The merge point of 1:1,1+1 requires to support to receive from the choosing of protection passage.Label switched path is generally created automatically by agreement, and common protocol has RSVP (RSVP/RSVP-TE) and tag distribution protocol (LDP/CR-LDP).
Heavy-route is present the most frequently used a kind of multiprotocol label switching protected mode fast, and this mode requires that same protective capability is all arranged between Point of Local Repair and the merge point (supporting same protection agreement).Yet at one arbitrarily in the network, the protected mode that each node provides may be not just the same.Because heavy-route is not consulted the protected mode at the node two ends of participation protective fast, may be because the resource that the fixed protected mode of the discontented toe of an end needs causes protection to switch failure.
Summary of the invention
The objective of the invention is to, the guard method that exchanges in a kind of multiprotocol label switching is provided, do not cause setting up the lower problem of label switched path efficient owing to consulting protected mode between end points in the existing multiprotocol label switching of solution.
Technical scheme of the present invention is, the guard method that exchanges in a kind of multiprotocol label switching is provided, and may further comprise the steps:
First node sends first message of the protected mode that comprises that first node is supported to Section Point;
Section Point mates the protected mode in first message that receives, and then returns second message of the protected mode that comprises coupling to first node as if the match is successful.
First node is set up label switched path according to the coupling protected mode in second message that receives.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, also comprise and when Section Point can not mate protected mode in first message, return the step that the 3rd message of failure is consulted in expression to first node.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, comprise that also first node stops the step of the foundation of label switched path according to the 3rd message that receives.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, described first message is extensions path message, comprise the stream object of protection that is used to write down the first node protected mode in the described extensions path message, described second message is RESV, comprises the stream object of protection of the protected mode of record first node and Section Point coupling in the described RESV; Perhaps described first message is label request message, comprises the protective valve limiting value field of the protected mode that the record first node is supported in the described label request message; Described second message is label mapping message, comprises the protective valve limiting value field of the protected mode of record coupling in the described label mapping message.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, the protected mode of the first node support in the stream object of protection of described first node is arranged according to priority orders.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, described first node is source node or Point of Local Repair, and described Section Point is destination node or merge point.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, described first node sends first message by intermediate node to Section Point; Described Section Point returns second message by intermediate node to first node.
In the guard method that exchanges in the above-mentioned multiprotocol label switching, the protected mode in first message that described Section Point coupling receives, if second message that the match is successful then returns the protected mode that comprises coupling to first node may further comprise the steps:
The protected mode that Section Point has according to local terminal is mated the protected mode in first message successively;
If Section Point matches the protected mode that this node possesses, then in second message, generate the protected mode object and second message is returned first node, stop to mate other protected modes simultaneously.
The guard method that exchanges in the multiprotocol label switching of the present invention by announcement of the protective capability between source node and destination node and negotiation, makes label switched path can select the most appropriate protected mode, thereby has improved the efficient that label switched path is set up.
Description of drawings
Fig. 1 is a schematic diagram of setting up label switched path;
Fig. 2 is the PATH message of the guard method that exchanges in the multiprotocol label switching of the present invention and the form schematic diagram of the FLOWPROT object in the RESV message;
Fig. 3 is the source node workflow diagram of the guard method that exchanges in the multiprotocol label switching of the present invention;
Fig. 4 is the destination node workflow diagram of the guard method that exchanges in the multiprotocol label switching of the present invention;
Fig. 5 is the form schematic diagram of label request message among another embodiment of the guard method that exchanges in the multiprotocol label switching of the present invention;
Fig. 6 is the form schematic diagram of label mapping message among another embodiment of the guard method that exchanges in the multiprotocol label switching of the present invention.
Embodiment
As shown in Figure 1, for setting up label switched path (Label Switching Path, schematic diagram LSP).Under RSVP (Resource ReSerVation Protocol, RSVP) agreement, at first, source node 11 transmit paths (PATH) message is to intermediate node 12.Intermediate node 12 receives PATH message, sets up path status, and (being next intermediate node 12) transmits PATH message downstream.Downstream node transmits PATH message in the same manner, up to destination node 13.Certainly, source node 11 also can be Point of Local Repair (Point of Local Repair, PLR), and destination node 13 can for merge point (Merge Point, MP).
After destination node 13 is received PATH message, upstream (being intermediate node 12) sends RESV (RESV), this message has flow descriptors (Flow Descriptor), specifically comprises traffic specification explanation (TSpec), resource reservation specification (RSpec) and filter specification explanation (Filter Spec).RESV message is to return along the former road of the transmit path of PATH message, after intermediate node 12 is on the way received RESV message, judge the legitimacy of resource reservation request and whether distributable label is arranged, if then be traffic flow assignment bandwidth and spatial cache on request, and write down this flow state information, then RESV message is continued upstream (promptly to go up an intermediate node 12) and transmit; If refusal then sends a path error messages (PathErr message) to source node, to stop the foundation of label switched path.When last source node 11 was received RESV message and accepted this request, it beamed back an acknowledge message to destination node, finishes the foundation of label switched path.
Protective capability and mode are consulted, and can expand an object (object) or TLV (type, length and value) attribute and realize.In the present embodiment, the LABEL_REQUEST object in the PATH message comprises sender's flowspec symbol (FLOWPROT) object, and this sender's flowspec symbol object comprises the protection type field; In this field with several bit identification of fixed length a kind of can support the protection type (such as the field of 4 bits, identify maximum 16 kinds the protection types).Can comprise several protection types in the protected field; Upstream node is told downstream node by this field, the protection type that oneself can support.Also can pass through the front and back order, the protection type of the preferential foundation that the sign upstream node is wished; Protection type is in front preferentially recommended to use by upstream node, and the like.Certainly, priority also can adopt other modes to identify.In the present embodiment, protected mode is represented with a field.
PATH message after the expansion (＜Path Message 〉) be:
<Path?Message>::＝<Common?Header>[<INTEGRITY>]
<SES?SION><RSVP_HOP><TIME_VALUES>
[<POLICY_DATA>...]
[<sender?descriptor>]
<sender?descriptor>::＝<SENDER_TEMPLATE><FLOWPROT>[……]
Wherein,＜and Path Message〉be PATH; And＜Common Header〉be common header, it comprises information such as protocol version, sign, type of message, RSVP check code.＜SESSION〉be session object, by destination address, IP protocol identifier and destination slogan are determined;＜RSVP_HOP〉object provides the previous dive IP addresses of nodes, provides logical interface handles program (LIH) simultaneously;＜TIME_VALUES〉be time value.＜POLICY_DATA〉be policy data, its information of carrying allows local policy controller to be used to determine whether to allow the reservation request of being correlated with.＜sender descriptor〉be sender's descriptor, it comprises sender's model object, the sender flows object of protection (＜FLOWPROT 〉) etc.
<Resv?Message>::＝<Common?Header>[<INTEGRITY>]
<SESSION><RSVP_HOP><TIME_VALUES>
<RESV_CONFIRM>][<SCOPE>]
<POLICY_DATA>...]
<STYLE><flow?descriptor?list>
<flow?descriptor?list>::＝<empty>|
<flow?descriptor?list><flow?descriptor><FLOWPROT>
The same with the PATH message of expansion, the RESV message of expansion comprises common header, session, time value etc., is the IP address of next-hop node and the RSVP_HOP object comprises, and this IP address is the IP address of output reserving message interface.Identical with the Path message after the expansion, the RESV message after the expansion is also carried stream protection (FLOWPROT) object, is used for the negotiation of protected mode between source, destination node.＜flowdescriptor list〉be that flow descriptors is tabulated.
Path error messages form does not change, and has just increased in error characteristic (ERROR_SPEC) object wherein to consult the failure error code.
About other parameters of above-mentioned extended message, can be with reference to internet engineering task group (InternetEngineering Task Force, rfc2205 IETF) and rfc2210 consensus standard.
As shown in Figure 2, be the form schematic diagram of FLOWPROT object 20.In the present embodiment, the FLOWPROT object comprises length field, class number field, type field, gap marker field, LSP identification number field, LSP type field and protected mode field.Wherein, gap marker field and＜SESSION〉gap marker number value in the object is identical, LSP identification number and＜SENDER_TEMPLATE in the LSP identification number identical.The LSP type is represented the type of LSP, and in the present embodiment, it represents that with 0x0 working LSP, 0x1 represent to protect LSP, 0x2 to represent the LSP that returns in the 1:1 protected mode.P1-P15 represents 15 kinds of protected modes of arranging backward according to priority orders, and P1-P15 is corresponding a kind of respectively.0 does not represent protected mode, is used for polishing.P1-P15 represents the protected mode that local terminal has in PATH message; In RESV message, have only P1 effective, the protected mode that expression is selected.
As shown in Figure 3, handle the flow chart of RESV message for source node 11.At first source node 11 judges whether to receive RESV message after receiving message, judges promptly whether the message that receives is RESV message (step S31).If do not receive RESV message, then further judge whether to receive PathErr message, judge promptly whether the message that receives is PathErr message (step S32).If receive PathErr message, then finish the foundation of LSP; If do not receive PathErr message, then handle the message of receiving (step S37) according to other types Message Processing standard.
If source node receives RESV message, then source node 11 further judges whether comprise PLOWPROT object (step S33) in the RESV message.If comprise the PLOWPROT object in the RESV message, then write down the protected mode of the protected field (P1) in the PLOWPROT object, set up LSP then.If do not comprise the PLOWPROT object in the RESV message, then set up process and handle (step S36) by normal LSP.
In addition, source node 11 is also tactful for the protection of PATH message arrangement when setting up PATH message, promptly fills each attribute in the PLOWPROT object, according to the protected mode that local terminal has, fills the P1-P15 field of PLOWPROT object according to priority orders.
As shown in Figure 4, be destination node 13 workflow diagrams.At first destination node 13 judges whether to receive PATH message (step S41).If receive PATH message, then destination node 13 further judges whether comprise FLOWPROT object (step S42) in the PATH message; If destination node does not receive PATH message, then by normal flow processing messages (step S45).If comprise the FLOWPROT object in the PATH message, then destination node 13 mates the protected mode in the P1-P15 field successively, if the protected mode that finds this node to possess, then destination node 13 returns with the FLOWPROT object in RESV message, and stops to mate other protected modes; If destination node 13 does not match the protected mode that it possesses, then return PathErr message.If do not comprise the FLOWPROT object in the PATH message, then destination node 13 is set up process by normal LSP and is handled the data that receive.
In the LSP that sets up with LDP (tag distribution protocol) or CR-LDP agreement (please refer to the rfc3036 of IETF), can do protective valve limiting value (PROT TLV) expansion.Behind the expansion PROTTLV, form such as Fig. 5, shown in Figure 6 of label request message (Label request message) and label mapping message (Labelmappinp message).Be that with existing label request message and label mapping message difference label request message 50 and label mapping message 60 in the present embodiment after the expansion all comprise PROT TLV.The form of the form of PROT TLV and FLOWPROT object shown in Figure 2 is similar, comprises the protected mode of arranging backward according to priority orders.
Upstream node can use the label request message of expansion to carry the protective capability of oneself and the priority of recommendation by PROT TLV, the notice downstream node.Downstream node can carry the protective capability of considering downstream node by the label mapping message of expansion; select the protected mode of the high priority of upstream node recommendation for use, the protected mode after will selecting then is by label mapping message (comprising PROT TLV) the notification source node of expansion as far as possible.
When the downstream node can't mate the protected mode of upstream node recommendation; downstream node returns the particular error sign indicating number by the fields such as conditional code among the state TLV (status TLV) that carries expansion in notification message (Notification message) (not shown); the notice upstream node, failure is consulted in the state encoding sign protection of carrying of the Status TLV of expansion.
In the LSP that sets up with LDP (tag distribution protocol) or CR-LDP agreement, the workflow and the flow process among Fig. 3 of source node 11 are similar, the workflow and the flow process among Fig. 4 of destination node 13 are similar, and difference is that the process object of source node 11 and destination node 13 is PROTTLV.
The above; only for the preferable embodiment of the present invention, but protection scope of the present invention is not limited thereto, and anyly is familiar with those skilled in the art in the technical scope that the present invention discloses; the variation that can expect easily or replacement all should be encompassed within protection scope of the present invention.Therefore, protection scope of the present invention should be as the criterion with the protection range of claim.
Claims (9)
1, the guard method that exchanges in a kind of multiprotocol label switching is characterized in that, may further comprise the steps:
First node sends first message of the protected mode that comprises that first node is supported to Section Point;
Section Point mates the protected mode in first message that receives, and then returns second message of the protected mode that comprises coupling to first node as if the match is successful;
First node is set up label switched path according to the coupling protected mode in second message that receives.
2, the guard method that exchanges in the multiprotocol label switching according to claim 1 is characterized in that, also comprises returning the step that the 3rd message of failure is consulted in expression to first node when Section Point can not mate protected mode in first message.
3, the guard method that exchanges in the multiprotocol label switching according to claim 2 is characterized in that, comprises that also first node stops the step of the foundation of label switched path according to the 3rd message that receives.
4, the guard method that exchanges in the multiprotocol label switching according to claim 1 is characterized in that, described first message is extensions path message, comprises the stream object of protection that is used to write down the first node protected mode in the described extensions path message; Described second message is RESV, comprises the stream object of protection of the protected mode of record first node and Section Point coupling in the described RESV.
5, the guard method that exchanges in the multiprotocol label switching according to claim 4 is characterized in that, the protected mode of the first node support in the stream object of protection of described first node is arranged according to priority orders.
6, the guard method that exchanges in the multiprotocol label switching according to claim 1 is characterized in that, described first message is label request message, comprises the protective valve limiting value field of the protected mode that the record first node is supported in the described label request message; Described second message is label mapping message, comprises the protective valve limiting value field of the protected mode of record coupling in the described label mapping message.
7, the guard method that exchanges in the multiprotocol label switching according to claim 1 is characterized in that, described first node is source node or Point of Local Repair, and described Section Point is destination node or merge point.
8, the guard method that exchanges in the multiprotocol label switching according to claim 1 is characterized in that, described first node sends first message by intermediate node to Section Point; Described Section Point returns second message by intermediate node to first node.
9, the guard method that exchanges in the multiprotocol label switching according to claim 1; it is characterized in that; protected mode in first message that described Section Point coupling receives, if second message that the match is successful then returns the protected mode that comprises coupling to first node may further comprise the steps:
The protected mode that Section Point has according to local terminal is mated the protected mode in first message successively;
If Section Point matches the protected mode that this node possesses, then in second message, generate the protected mode object and second message is returned first node, stop to mate other protected modes simultaneously.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200510033415XA CN100488197C (en) | 2005-03-04 | 2005-03-04 | Exchange protecting method in multi protocol label exchange |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200510033415XA CN100488197C (en) | 2005-03-04 | 2005-03-04 | Exchange protecting method in multi protocol label exchange |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1829216A CN1829216A (en) | 2006-09-06 |
| CN100488197C true CN100488197C (en) | 2009-05-13 |
Family
ID=36947344
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB200510033415XA Expired - Fee Related CN100488197C (en) | 2005-03-04 | 2005-03-04 | Exchange protecting method in multi protocol label exchange |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100488197C (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7782762B2 (en) * | 2007-09-21 | 2010-08-24 | Alcatel Lucent | RSVP-TE enhancement for MPLS-FRR bandwidth optimization |
| CN101453411B (en) * | 2007-11-28 | 2011-04-20 | 华为技术有限公司 | Method, system and equipment for label switch path establishment |
| US20120008632A1 (en) * | 2010-07-12 | 2012-01-12 | Telefonaktiebolaget L M Ericsson | Sharing Resource Reservations Among Different Sessions In RSVP-TE |
-
2005
- 2005-03-04 CN CNB200510033415XA patent/CN100488197C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN1829216A (en) | 2006-09-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1992676B (en) | Method and device for forwarding state sharing between multiple traffic paths in a communication network | |
| US7535829B2 (en) | Tunnel reroute | |
| CN103155499B (en) | For calculating the system and method for the backup outlet of point-to-multipoint label switch paths | |
| CN100372276C (en) | RSVP proxy service for communication network | |
| CN101631072B (en) | Method, device and system for establishing pseudowire | |
| US7065084B2 (en) | Data structure for implementation of traffic engineering function in multiprotocol label switching system and storage medium for storing the same | |
| CN101588296B (en) | Method, head node and tail node of forwarding multicasting message | |
| US7852840B2 (en) | Method and device for creating a tunnel in a label-switched telecommunication network | |
| CN100372337C (en) | Route selection method for implementing cross-domain constraint-based routing | |
| US20020110087A1 (en) | Efficient setup of label-switched connections | |
| CN100563202C (en) | The method of differential service is provided | |
| CN101406023B (en) | Method and system for implementing multi-protocol label switching network differential service flux engineering | |
| CN101047614B (en) | Flow transmission route set-up method and data transmission system in IPv6 network environment | |
| KR20150036206A (en) | System and method for switching traffic from sub-optimal primary p2mp to standby p2mp | |
| CN101485163A (en) | A method and system for optimizing resources for establishing pseudo-wires in a multiprotocol label switching network | |
| CN101369958A (en) | Fast rerouting method and label exchange router | |
| CN107888497A (en) | Communication means, the network equipment and computer-readable recording medium | |
| WO2006102851A1 (en) | A method for informing and negotiating the monitor ability of the label switching capability | |
| US20070140233A1 (en) | Resource sharing among network | |
| CN100488197C (en) | Exchange protecting method in multi protocol label exchange | |
| CN100502528C (en) | Method for realizing association between optical interconnection in automatic exchanging optical network | |
| US20100098088A1 (en) | Pseudo Wire Establishing Method and Device | |
| US7729261B2 (en) | Forwarding of network traffic in respect of differentiated restricted transit network nodes | |
| CN100508521C (en) | Binding work-label exchanging route and method for protecting label exchange route | |
| CN103051562B (en) | A kind of MTU implementation method of resource reservation protocol link and equipment |
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 |
Granted publication date: 20090513 Termination date: 20160304 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |