WO2007030988A1 - Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant - Google Patents

Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant Download PDF

Info

Publication number
WO2007030988A1
WO2007030988A1 PCT/CN2006/000962 CN2006000962W WO2007030988A1 WO 2007030988 A1 WO2007030988 A1 WO 2007030988A1 CN 2006000962 W CN2006000962 W CN 2006000962W WO 2007030988 A1 WO2007030988 A1 WO 2007030988A1
Authority
WO
WIPO (PCT)
Prior art keywords
tunnel
router
binding
peer
binding object
Prior art date
Application number
PCT/CN2006/000962
Other languages
English (en)
Chinese (zh)
Inventor
Hejun Li
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2007030988A1 publication Critical patent/WO2007030988A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]

Definitions

  • the present invention relates to the field of communications, and in particular, to a method, system, and router for implementing a bidirectional traffic engineering tunnel.
  • RSVP-TE Resource Reservation Protocol-Traffic Engineering
  • MPLS/IP Multi-Protocol Label Switch/Internet Protocol
  • RSVP-TE can establish a tunnel based on constraint routing and reserve bandwidth for the tunnel.
  • RSVP-TE FRR Frast Renewedly Route
  • LSP Label Switching Path, Label Switching Path
  • RSVP-TE Long Term Evolution
  • MPLS / BGP VPN Multiprotoco Label Switching/ Border Gateway
  • VPN Multi-Protocol Label Switching/Border Gateway Protocol
  • the main purpose of the present invention is to provide a method for implementing a bidirectional traffic engineering tunnel, which overcomes the shortcomings of the prior art that only one-way tunnel can be established through RSVP-TE, so that the VPN service with bandwidth guarantee is complicated to implement. Effectively provide L3 VPN services with bandwidth guarantees.
  • Another object of the present invention is to provide a router for implementing a bidirectional traffic engineering tunnel, To support the establishment of a bidirectional TE tunnel with other routers to provide service quality assurance for L3 VPN services.
  • a method for implementing a bidirectional traffic engineering tunnel includes:
  • Each party sends the configured binding object information to the other party;
  • the router binds the TE unidirectional tunnel whose destination is established to each other to the bidirectional tunnel according to the received binding object information.
  • the step B specifically includes:
  • the local router sends the configured binding object information to the peer router through the path message of the RS VP-TE protocol.
  • the step C includes:
  • the peer router binds the tunnel established by the local router to the tunnel established by the local router according to the binding object information in the received path message;
  • the Resv message is sent to the local router, and the binding object information constructed by the Resv message is carried in the Resv message;
  • the local router binds the tunnel established by the peer router to the tunnel established by the peer router according to the binding object information in the received Resv message.
  • the step C1 includes:
  • the peer router After receiving the path message, the peer router checks whether the binding object information in the path message meets the condition;
  • the tunnel established by the local router is bound to the tunnel of the local router as a Han tunnel, and the binding is considered successful.
  • the step C further includes: If the peer router fails to bind the tunnel, the Resv message is sent to the local router, and the binding object information is not carried in the Resv message.
  • the binding object information includes: a name of the peer TE tunnel to be bound, a destination address of the session object, and a source address.
  • the step of checking whether the binding object information in the path message satisfies a condition includes:
  • the peer router checks whether the name of the peer TE tunnel to be bound in the binding object is consistent with the name of the locally established TE tunnel, if it is consistent; whether the destination address of the session object is a locally established TE tunnel Source address of the session object; whether the source address of the session object is the destination address of the locally established TE tunnel;
  • the destination address of the session object is the source address of the locally established TE tunnel, and the source address of the session object is local.
  • the destination address of the established TE tunnel determines that the binding object information satisfies the condition.
  • the binding element further includes: a binding flag.
  • the binding flag in the binding object information in the Resv message is set as a confirmation flag, and the distribution label is set to Ordinary label.
  • the step C3 includes:
  • the local router After receiving the Resv message, the local router checks whether the binding object information in the Resv message satisfies the condition;
  • the tunnel established by the peer router is bound to the tunnel of the peer router as a bidirectional tunnel, and the bidirectional tunnel is successfully bound; if the condition is not met, the connection is considered to be tied. Hence failed.
  • the step of the local router checking whether the binding object information in the Resv message satisfies the condition includes:
  • the local router checks whether the name of the peer TE tunnel to be bound in the binding object is the name of the tunnel established by the peer; and checks whether the binding flag in the binding object is an acknowledged flag.
  • the step C includes:
  • the peer router binds the tunnel established by the local router to the tunnel established by the local router according to the binding object information in the received path message;
  • the Resv message is sent to the local router; otherwise, the local router responds with an error alarm message.
  • a system for implementing a two-way traffic engineering tunnel includes: a carrier edge router and a core router connected through an IP network, and routing and forwarding by a core router, and a TE one-way tunnel is established between edge routers of different operators according to the RVSP-TE protocol, where
  • the carrier edge router includes:
  • a TE tunnel establishing module configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol
  • a binding object configuration module connected to the TE tunnel establishing module, configured to establish, according to the TE tunnel, a TE unidirectional tunnel information Configure the local carrier edge router bidirectional tunnel binding object.
  • the tunnel binding module is connected to the TE tunnel establishment module, and is configured to: according to the binding object information of the peer carrier edge router received by the local carrier edge router, the local carrier edge router and the peer carrier edge
  • the unidirectional tunnels established by the routers to each other are bound to be two-way tunnels.
  • the carrier edge router further includes:
  • the binding object checking module is respectively connected to the TE tunnel establishing module and the tunnel binding module, and is configured to check, according to the information of the TE unidirectional tunnel established by the TE tunnel establishing module, the pair received by the operator edge router. Whether the binding object information of the edge carrier edge router satisfies the condition, and sends the check result to the tunnel binding module.
  • the local carrier edge router sends the configured local carrier edge router bidirectional tunnel binding object information to the peer carrier edge router through the path message in the extended RVSP-TE protocol.
  • All core routers between the local carrier edge router and the peer carrier edge router transmit the binding object information transmitted between the local carrier edge router and the peer carrier edge router as they are. After the two-way tunnel is successfully bound, the local carrier edge router sends the binding success information to the peer carrier edge router through the Resv message in the extended RVSP-TE protocol.
  • a TE tunnel establishing module configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol
  • a binding object configuration module connected to the TE tunnel establishing module, configured to establish, according to the TE tunnel, a TE unidirectional tunnel information Configure a bidirectional tunnel binding object.
  • the tunnel binding module is connected to the TE tunnel establishment module, and is configured to bind the unidirectional tunnel that is established by the local router and the peer router to each other according to the binding object information of the peer router received by the router. Set as a two-way tunnel.
  • the router further includes:
  • the RSVP-TE extension is bound.
  • the object is bound, and the unidirectional tunnel whose destination is established by the two parties is bound.
  • the bidirectional tunnel established in the present invention can not only support all the original service applications of RSVP-TE, but also provide L3 VPN services with bandwidth guarantee through virtual router technology or policy routing technology.
  • FIG. 1 is a flowchart of an implementation of a method for implementing a bidirectional traffic engineering tunnel according to the present invention
  • FIG. 2 is a flowchart of implementing tunnel binding by a router according to binding object information in the method of the present invention
  • FIG. 3 is a schematic diagram of a virtual router implemented by a RSVP-TE bidirectional tunnel
  • FIG. 4 is a schematic block diagram of a first embodiment of a router according to the present invention
  • FIG. 5 is a schematic block diagram of a second embodiment of a router according to the present invention.
  • FIG. 6 is a schematic block diagram of the system of the present invention.
  • the core of the present invention is to refer to the GRE bidirectional tunnel implementation mechanism, and configure a binding object when each of the two routers establishes a traffic engineering TE one-way tunnel destined for the other party, and then each of the two parties will configure the binding object.
  • the information is sent to the other party; the router ⁇ receives the binding object information and binds the unidirectional tunnel whose destination is established by the Hagging to the other party as a two-way tunnel.
  • the present invention extends the existing RSVP-TE protocol.
  • Flag 8-bit flag field, currently defined as follows:
  • 0x1 requires a binding flag, valid only in the Path message
  • Name Length The length of the Session name.
  • Session Name Name of the peer RSVP tunnel to be bound.
  • binding object is not limited to the above format, and can also be set in the actual application.
  • the binding information of the RSVP-TE protocol is sent to the peer router through the path message of the RSVP-TE protocol.
  • the end router binds the tunnel established by the local router to the tunnel established by the local router as a bidirectional tunnel according to the binding object information, thereby implementing a bidirectional TE tunnel.
  • Step 101 When two routers respectively establish a traffic engineering TE one-way tunnel whose destination is the other party, configure a binding object.
  • the binding object is configured, and the binding elements in the binding object are configured.
  • the binding element includes the name of the remote RSVP-TE tunnel to be bound.
  • the destination address and the source address are three types of information.
  • the name of the peer TE tunnel to be bound is Tunnel B.
  • the source address of the Session Object carried in the RSVP packet is Tunnel A. Address, destination address is the address of Tunnel B.
  • the binding elements are not limited to the above triples.
  • the peer R2 needs to be configured similarly, that is, the name of the peer TE tunnel to be bound is Tunnel A.
  • the source address of the session object is the address of Tunnel B, and the destination address is the address of Tunnel A.
  • the two parties respectively send the configured binding object information to the other party.
  • R1 After R1 completes the existing RSVP configuration and binding object configuration of Tunnel A, it sends a Path message to the peer R2.
  • the message carries the newly extended Binding Object.
  • the Session Name of the Object is the corresponding TE of the peer router.
  • the name of the tunnel, the length is the length of the Name; the binding flag of the flag field in the Bindding Object is set to 1.
  • Step 103 The router binds the unidirectional tunnel that is established by the two parties to each other as a bidirectional tunnel according to the received binding object information.
  • R1 takes R1 as the RSVP packet to R2 as an example.
  • the process of binding Tunnel A to Tunnel B established on the R2 is described in detail.
  • Step 203 Bind the tunnel established by the peer end to the tunnel established by itself, and construct a Resv message, and then respond to R1.
  • R2 checks whether the source address of the Session Object in the binding object in the path message is the destination address of the locally established RSVP tunnel. If yes, the condition is met; otherwise, the condition is not met.
  • R2 considers that the received TunnelA message is required to bind TunnelA and TunnelB to a bidirectional tunnel.
  • the tunnel established by the peer is bound to the tunnel established by itself and is as follows. Construct a Resv message:
  • Step 205 After receiving the Resv message, the R1 confirms that the peer R2 has successfully bound the tunnel established by the local end. If the confirmation is successful, proceed to step 206; otherwise, 6 000962
  • the R1 After receiving the Resv message, the R1 analyzes the message. If the message is not carried, the device confirms that the bidirectional tunnel is not bound successfully. Otherwise, check the binding object to be bound in the binding object carried in the message. Whether the name of the peer TE tunnel is the name of the tunnel established by the peer, and whether the binding flag in the binding object carried in the message is a confirmation flag. If both conditions are met, it is confirmed that the bidirectional tunnel binding is successful; otherwise, the Han tunnel is considered to be unbound successfully.
  • Step 206 the process ends.
  • the remote R2 sends an RSVP packet to R1.
  • the process of binding the tunnel B to the local device R1 is similar to the local R1.
  • the Resv message may not be extended, that is, it does not carry the binding object information of R2. If R2 successfully binds the tunnel established by the peer to the tunnel established by itself, it responds to the Resv message to R1; otherwise, it responds to R1 with an error alarm.
  • RSVP-TE integrates the bidirectional tunnels of GRE and IPsec based on the existing advantages of QoS, TE and reliability. The advantages.
  • the RSVP-TE bidirectional tunneling technology provided by the present invention can support all the service applications supported by the GRE tunnel in addition to the original RSVP-TE service application, for example, the virtual router function and the outer tunnel as the MPLS VPN. , and interconnecting two separate routing domains through tunnels, and so on.
  • L3 VPN services can be easily provided through virtual routers or policy routing. This L3VPN technology combines RSVP-TE QoS (Quality of Service) guarantee, TE and reliability advantages, and GRE bidirectional tunnels to facilitate the establishment of VPNs.
  • RSVP-TE QoS Quality of Service
  • the following uses the virtual router function as an example to briefly explain how to use the RSVP-TE bidirectional tunnel.
  • FIG. 3 The principle of realizing the virtual router by using the RSVP-TE bidirectional TE tunnel technology is shown in Figure 3.
  • Two virtual router instances VRF Red and VRF are established on the routers PE-1 and PE-2 respectively. Blue.
  • PE-1 and PE-2 are connected to the CE (Customer Edge) device CE-1 and CE-2 interfaces to the virtual router instances VRF Red and VRF Blue. Bind the two-way TE tunnels, Tunnel 1 and Tunnel 2, between PE-1 and PE-2, and bind the virtual router instances VRF Red and VRF Blue respectively. Configure static routes or dynamic routes on the virtual router instance to access the two.
  • the CE devices of the same virtual router instance on the PE devices can access each other.
  • FIG. 4 is a schematic block diagram of a first embodiment of a router according to the present invention.
  • the router SO is configured to establish a bidirectional TE tunnel with the peer router, including: a TE tunnel establishment module S1, a binding object configuration module S2, and a tunnel binding.
  • the TE tunnel establishment module S1 is configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol.
  • the binding object configuration module S2 is connected to the TE tunnel establishment module S1, and is used to establish the TE unidirectional tunnel information established by the module S1 according to the TE tunnel.
  • the bidirectional tunnel binding object is configured.
  • the tunnel binding module S3 is connected to the TE tunnel establishment module S1, and is configured to establish a destination of the local router SO and the peer router according to the binding object information of the peer router received by the router SO.
  • the unidirectional tunnel of the other party is bound as a bidirectional tunnel.
  • the binding object configuration module S2 configures the binding object, and the router S0 sends the binding object to the peer through the path message in the extended RVSP-TE protocol.
  • the router carries the binding object information in the path message.
  • the peer router when the peer router establishes the TE unidirectional tunnel destined for the local router S0, it also needs to configure the binding object, and send the configured binding object to the local router through the path message in the extended RVSP-TE protocol. .
  • the tunnel binding module S3 can establish the destination established by the local router S0 and the peer router according to the binding object information carried in the path message.
  • the unidirectional tunnel is bound as a two-way tunnel.
  • the processing procedure is the same as that described above, and details are not described herein again.
  • the binding object checking module S4 can also be set in the router S0.
  • the binding object checking module S4 is connected to the TE tunnel establishing module S1 and the tunnel binding module S3, and is configured to check the binding object of the peer router received by the router SO according to the information of the TE unidirectional tunnel established by the TE tunnel establishing module S1. Whether the information satisfies the condition, and sends the check result to the tunnel binding module S3.
  • the binding object checking module S4 checks whether the binding object information carried by the path message satisfies the condition.
  • the specific checking process is as follows: Check the binding object in the binding message to be tied. Whether the name of the remote RSVP tunnel is the same as the name of the locally established RSVP tunnel. Check whether the destination address of the Session Object in the binding object is the source address of the locally established RSVP tunnel. Check the binding object in the path message. Whether the source address of the object is the destination address of the locally established RSVP tunnel.
  • the destination address of the Session Object is the source address of the locally established RSVP tunnel
  • the source address of the Session Object is the locally established RSVP tunnel.
  • the destination address is considered to satisfy the condition, and the tunnel module is notified to bind the tunnel established by the peer router to the tunnel established by itself to be a bidirectional tunnel.
  • the local router can send the binding success flag to the peer router through the extended Resv message.
  • the Resv message can be extended.
  • the Resv message is sent directly to the peer router.
  • the binding failure message is sent to the peer router.
  • Figure 6 shows a block diagram of the system of the present invention:
  • the system includes: a carrier edge router PE1, a PE2, and a core router RT connected through an IP network.
  • the routers of the edge routers PE1 and PE2 establish a TE unidirectional tunnel according to the RVSP-TE protocol.
  • the structure of the operator edge router is the same as that described above for the router of the present invention, and details are not described herein again.
  • PE1 and PE2 are respectively configured to establish a tunnel unidirectional tunnel with the destination address being the peer address according to the RVSP-TE protocol.
  • the tunnel established by PE1 is Tunnel 1 and the tunnel established by PE2.
  • Tunnel 2 For Tunnel 2.
  • the binding object includes: the name of the peer TE tunnel to be bound, the destination address and source address of the session object.
  • the binding object information of PE1 is: The name of the peer TE tunnel to be bound is Tunnel 2, the destination address of the session object is the source address of Tunnel 2, and the source address is the destination address of Tunnel 2.
  • the binding object information of PE2 is: The name of the peer TE tunnel to be bound is Tunnel 1, the destination address of the session object is the source address of Tunnel 1, and the source address is the destination address of Tunnel 1.
  • the PE1 sends the configured binding object information to the PE2 through the path message in the extended RVSP-TE protocol, where the binding object carries the binding object information.
  • PE2 needs to send the configured binding object information to PE1 through the path message in the extended RVSP-TE protocol.
  • the core router RT between PE1 and PE2 transmits the binding object information as it is.
  • PE1 can bind Tunnel 2 and Tunnel 1 as a bidirectional tunnel according to the binding object information carried in the path message.
  • PE2 can bind Tunnel 1 and Tunnel 2 as a bidirectional tunnel according to the binding object information carried in the path message.
  • the Resv message can be returned to the peer router to notify the peer router that the bidirectional tunnel binding is successful.
  • the binding element of the present invention is not limited to the tunnel name, the source address, and the destination address triplet.
  • the practice of binding two unidirectional tunnels into two-way tunnels through other binding elements is any change or replacement that can be easily conceived by those skilled in the art within the scope of the technology disclosed by the present invention.
  • the scope of protection of the present invention should be determined by the scope of the claims.

Landscapes

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

Abstract

La présente invention concerne un procédé destiné à mettre en place un tunnel d'ingénierie de trafic bidirectionnel, qui comprend: lorsque deux routeurs établissent des tunnels unidirectionnels d'ingénierie de trafic (TE) destinés respectivement au côté opposé, l'objet liant est configuré; les deux côtés envoient respectivement l'information sur l'objet liant configuré au côté opposé; le routeur lie les tunnels unidirectionnels destinés au côté opposé et établis respectivement par les deux côtés, au tunnel bidirectionnel selon l'information sur l'objet liant reçue. La présente invention concerne également un système et un routeur destinés à la mise en place du tunnel d'ingénierie du trafic bidirectionnel. Le tunnel bidirectionnel de la présente invention peut non seulement supporter toutes les applications de service originales du RSVP-TE, mais aussi il peut facilement supporter un service VPN (réseau privé virtuel) de couche 3 comme un tunnel GRE (d'encapsulation de route générale), dans lequel le VPN a une garantie de bande passante et un attribut TE.
PCT/CN2006/000962 2005-09-14 2006-05-15 Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant WO2007030988A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200510102484.1 2005-09-14
CNB2005101024841A CN100450088C (zh) 2005-09-14 2005-09-14 实现双向流量工程隧道的方法

Publications (1)

Publication Number Publication Date
WO2007030988A1 true WO2007030988A1 (fr) 2007-03-22

Family

ID=37390481

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/000962 WO2007030988A1 (fr) 2005-09-14 2006-05-15 Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant

Country Status (2)

Country Link
CN (1) CN100450088C (fr)
WO (1) WO2007030988A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11356294B2 (en) 2013-07-12 2022-06-07 Huawei Technologies Co., Ltd. Packet processing method and device

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100459588C (zh) * 2006-11-21 2009-02-04 华为技术有限公司 一种基于网络设备的带宽预留方法及装置
CN101163110B (zh) * 2007-11-30 2010-06-02 华为技术有限公司 部署流量工程隧道的方法及装置
CN101594289A (zh) * 2008-05-28 2009-12-02 华为技术有限公司 实现区分服务流量工程的方法及设备
CN101394361B (zh) * 2008-11-10 2011-07-27 杭州华三通信技术有限公司 报文传输方法、设备和***
CN102904808B (zh) * 2011-07-25 2017-08-25 中兴通讯股份有限公司 跨资源预留协议流量工程标签交换路径的建立方法及***

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095583A2 (fr) * 2000-06-07 2001-12-13 Siemens Aktiengesellschaft Procede pour transmettre des informations vocales par l'intermediaire d'un protocole internet
WO2003043226A1 (fr) * 2001-11-14 2003-05-22 Nokia Corporation Support de routeur mobile pour ipv6
US6665273B1 (en) * 2000-01-11 2003-12-16 Cisco Technology, Inc. Dynamically adjusting multiprotocol label switching (MPLS) traffic engineering tunnel bandwidth
US20040037296A1 (en) * 2002-08-21 2004-02-26 Kim Mi Hui Method for setting up QoS supported bi-directional tunnel and distributing L2VPN membership information for L2VPN using extended LDP
WO2004072807A2 (fr) * 2003-02-11 2004-08-26 Cisco Technology, Inc. Agencement permettant d'etablir un tunnel bidirectionnel entre un routeur mobile et un noeud correspondant

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6665273B1 (en) * 2000-01-11 2003-12-16 Cisco Technology, Inc. Dynamically adjusting multiprotocol label switching (MPLS) traffic engineering tunnel bandwidth
WO2001095583A2 (fr) * 2000-06-07 2001-12-13 Siemens Aktiengesellschaft Procede pour transmettre des informations vocales par l'intermediaire d'un protocole internet
WO2003043226A1 (fr) * 2001-11-14 2003-05-22 Nokia Corporation Support de routeur mobile pour ipv6
US20040037296A1 (en) * 2002-08-21 2004-02-26 Kim Mi Hui Method for setting up QoS supported bi-directional tunnel and distributing L2VPN membership information for L2VPN using extended LDP
WO2004072807A2 (fr) * 2003-02-11 2004-08-26 Cisco Technology, Inc. Agencement permettant d'etablir un tunnel bidirectionnel entre un routeur mobile et un noeud correspondant

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11356294B2 (en) 2013-07-12 2022-06-07 Huawei Technologies Co., Ltd. Packet processing method and device
EP3487150B1 (fr) * 2013-07-12 2024-05-15 Huawei Technologies Co., Ltd. Procédé et dispositif de traitement de paquets

Also Published As

Publication number Publication date
CN1863151A (zh) 2006-11-15
CN100450088C (zh) 2009-01-07

Similar Documents

Publication Publication Date Title
ES2830182T3 (es) Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red
US8804496B2 (en) Protecting multi-segment pseudowires
KR100496984B1 (ko) 레이블 분배 프로토콜의 확장을 이용한 ＱｏＳ지원 2계층가상 사설 망 양방향 터널 설정 및 구성정보 분배방법
ES2363410T3 (es) Método, dispositivo y sistema para la conmutación de tráfico en ingeniería de tráfico de conmutación multiprotocolo por etiqueta.
US8880727B1 (en) Transparently providing layer two (L2) services across intermediate computer networks
WO2006007769A1 (fr) Reflecteur d'etiquette de pseudo-circuit, appareil de peripherie, reseau prive virtuel a deux couches, et procede de fourniture d'un service de pseudo-circuit
JP5209116B2 (ja) パケット交換網における擬似ワイヤの確立
WO2013182059A1 (fr) Procédé et dispositif pour établir un tunnel d'ingénierie de trafic de commutation multiprotocole par étiquette
US20020110087A1 (en) Efficient setup of label-switched connections
US20070115913A1 (en) Method for implementing the virtual leased line
WO2009135399A1 (fr) Procédé d'établissement de tunnels et système de réalisation de l'établissement de tunnels
WO2008043230A1 (fr) Procédé, dispositif et système permettant d'établir un chemin commuté par étiquette bidirectionnel
WO2013053284A1 (fr) Procédé et système de mise en œuvre de réseau privé virtuel sur la base d'un tunnel d'ingénierie de trafic
WO2005122490A1 (fr) Procede de mise eu place d'un reseau prive virtuel
WO2009056034A1 (fr) Procédé, système et équipement pour établir une détection bfd pour un tunnel lsp
WO2008077300A1 (fr) Procédé et système permettant de négocier le discriminateur de session de détection de transmission bidirectionnelle d'un pseudo-fil
WO2010006528A1 (fr) Procédé, dispositif et système d'établissement de pseudo-circuit
De Clercq et al. Connecting IPv6 islands over IPv4 MPLS using IPv6 provider edge routers (6PE)
WO2015032275A1 (fr) Procédé et routeur pour établir un tunnel
WO2007030988A1 (fr) Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant
WO2011103759A1 (fr) Procédé pour l'établissement d'un chemin à commutation d'étiquettes bidirectionnel associé, et système pour sa mise en œuvre
Bocci et al. An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge
WO2008028383A1 (fr) Procédé d'identification de protocole de couche 3 dans une interconnexion à supports hétérogènes dans un réseau privé virtuel de protocole l2 et appareil et système correspondants
Martini et al. Segmented Pseudowire
JP6371399B2 (ja) インターフェースパラメーター同期方法及び装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06741852

Country of ref document: EP

Kind code of ref document: A1