WO2005101730A1 - Systeme et procede permettant d'assurer une qualite de service dans un reseau virtuel prive - Google Patents

Systeme et procede permettant d'assurer une qualite de service dans un reseau virtuel prive Download PDF

Info

Publication number
WO2005101730A1
WO2005101730A1 PCT/CN2005/000037 CN2005000037W WO2005101730A1 WO 2005101730 A1 WO2005101730 A1 WO 2005101730A1 CN 2005000037 W CN2005000037 W CN 2005000037W WO 2005101730 A1 WO2005101730 A1 WO 2005101730A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
vpn
network
virtual private
quality
Prior art date
Application number
PCT/CN2005/000037
Other languages
English (en)
French (fr)
Inventor
Defeng Li
Guoping Li
Bin 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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=34867405&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2005101730(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP05700411A priority Critical patent/EP1708408B2/en
Priority to JP2006549833A priority patent/JP4531063B2/ja
Priority to DE200560013188 priority patent/DE602005013188D1/de
Priority to US10/586,604 priority patent/US7650637B2/en
Publication of WO2005101730A1 publication Critical patent/WO2005101730A1/zh

Links

Classifications

    • 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/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery

Definitions

  • the present invention relates to a quality of service implementation scheme for a virtual private network, and more particularly, to a quality of service implementation scheme for a virtual private network using multi-protocol label switching.
  • a virtual private network refers to establishing a private network in a public network, and data is transmitted in the public network through a secure "encryption channel”.
  • Enterprises only need to rent a local data line and connect to the local Internet (Internet), and institutions in various places can communicate with each other. At the same time, enterprises can also use the dial-up access equipment of the Internet to let their users dial up to the Internet. Can connect to the corporate network.
  • Using a VPN has the advantages of cost savings, remote access, strong scalability, easy management, and full control.
  • Multi-Protocol Label Switch (Multi-Protocol Label Switch, referred to as "MPLS") is an Internet Engineering Task Force (IETF) evolved from the tag switching of Cisco Corporation (CISCO) ).
  • MPLS is a label-based Internet Protocol (IP) routing method. It belongs to the Layer 3 switching technology. It introduces a label-based mechanism to separate routing and forwarding, and a label specifies a packet to pass. Network routing and data transmission are accomplished through a Label Switch Path ("LSP"). It converts the packet switching originally in the third layer of the IP network into the second layer of packet switching.
  • LSP Label Switch Path
  • Figure 1 shows the MPLS network structure.
  • the MPLS network 101 is composed of a label switch router 104 (Label Switch Router, abbreviated as "LSR”) in the core part and a label edge router 103 (Label Edge Router, abbreviated as "LER”) in the edge part.
  • LSR Label Switch Router
  • LER Label Edge Router
  • LER 103 is used to analyze the IP packet header, perform the Layer 3 network function, and determine the corresponding transmission level and label switch path (Label Switch Path, or "LSP").
  • Network 102 is connected to receive an external packet switched data packet (IP packet) from the external network 105 10 2; LSR 104 for establishment of the LSP, performing label switching mechanism and quality of service (Qual i ty of Service, said cartridge "QoS”) Forwarding the packet data packet 106 inside the MPLS network 101, which is composed of a control unit and a switching unit, which is located inside the network and is connected to the LER 103 and other LSR 104.
  • IP packet switched data packet IP packet
  • LSR 104 for establishment of the LSP, performing label switching mechanism and quality of service (Qual i ty of Service, said cartridge "QoS”) Forwarding the packet data packet 106 inside the MPLS network 101, which is composed of a control unit and a switching unit, which is located inside the network and is connected to the LER 103 and other LSR 104.
  • LDP Label Distribution Protocol
  • traditional routing protocols such as the development of the Shortest Path First Protocol (Open Shortes t Path Firs t) 0SPF "), etc.
  • LSP Label Distribution Protocol
  • the LER at the entrance of the MPLS core network first receives the IP packets of the external network, completes the Layer 3 network function, and adds the IP packets
  • the label becomes a packet data packet; the packet data packet is then transmitted in the LSP.
  • the LSR no longer performs layer 3 processing on the packet data packet, but forwards it through the switching unit according to its label, and finally reaches the LER at the other end of the network, that is, the exit; Finally, the LER at the MPLS egress exits the label of the packet After removing it into an IP packet, forwarding is continued according to the corresponding external network protocol. Since the MPLS technology isolates the relationship between the label distribution mechanism and the data flow, its implementation does not depend on a specific data link layer protocol, and thus can support a variety of physical layer and data link layer technologies.
  • MPLS has been widely used in the implementation of VPNs.
  • VPNs implemented with MPLS are called MPLS VPNs.
  • MPLS VPN According to the user information that the network device forwards, MPLS VPN can There are three types of VPNs: L3 (Layer 3, which is the network layer) VPN, L2 (Layer 2, which is the data link layer) VPN, and L1 (Layer 1, which is the physical layer) VPN.
  • L3 Layer 3, which is the network layer
  • L2 Layer 2, which is the data link layer
  • L1 Layer 1, which is the physical layer
  • L3 VPN working group There are L3 VPN working group and L2 VPN working group in the standard organization, which respectively study MPLS L3 VPN and MPLS L2 VPN.
  • L2 VPN working group The typical representative of MPLS L3 VPN is the border gateway protocol based on RFC 2547bis
  • BGP Border Gateway Protocol
  • MPLS VP MPLS VP
  • IP VPN IP VPN based on Virtual Router (Virtual Router, "VR” for short)
  • MARTINI MARTINI
  • KOMPELLA Virtual Router
  • VR Virtual Router
  • the MPLS L3VPN model defined by RFC2547bis is shown in Figure 2. This model includes three components: a custom edge router ("CE” for short), and a provider edge router (“PE” for short) ”) And router (P).
  • CE custom edge router
  • PE provider edge router
  • P And router
  • CE equipment is an integral part of the customer premises network. It has interfaces that are directly connected to the operator's network, usually routers. The CE does not "perceive" the existence of the VPN, nor does it need to maintain the entire routing information of the VPN.
  • a PE router is an operator edge router. It is an edge device of the operator network (also called the backbone network) and is directly connected to the CE of the user. In an MPLS network, all parts of the VPN Management is done on the PE router.
  • the router (P) is the backbone router in the operator's network. It is not directly connected to the CE. The router (P) needs to have basic MPLS signaling capabilities and forwarding capabilities.
  • CE and PE are the boundaries of the management scope of both.
  • CEs and PEs use the External Border Gateway Protocol ("EBGP") or the Internal Gateway Protocol (“IGP”) routing protocol to exchange routing information. Static routing can also be used. .
  • the CE does not need to support MPLS and does not need to sense the entire network route of the VPN. The entire network of the VPN is outsourced to the operator to complete.
  • Operator PE devices exchange VPN-wide routing information through a multi-protocol Internal Border Gateway Protocol (MP-IBGP) for short.
  • MP-IBGP multi-protocol Internal Border Gateway Protocol
  • VPN is composed of multiple sites (sites).
  • each site corresponds to a VPN routing / forwarding instance (VPN Routing / Forwarding Instance, referred to as "VRF"), which mainly includes: a series of IP routing tables, label forwarding tables, and label forwarding tables. Interface and management information (including route identification number, route filtering policy, member interface list, etc.).
  • VRF VPN Routing / Forwarding Instance
  • Interface and management information including route identification number, route filtering policy, member interface list, etc.
  • a site can belong to multiple VPNs at the same time.
  • each site is associated with at least one separate VRF.
  • the VRF of the site in the VPN actually integrates the VPN membership and routing rules of the site.
  • Message forwarding information is stored in the IP routing table and label forwarding table of each VRF.
  • the system maintains a separate set of routing tables and label forwarding tables for each VRF, thereby preventing data from leaking out of the VPN and preventing data outside the VPN from entering.
  • VPN- IPv4 address family PE routers use BGP to advertise VPN routes and use a new address family-VPN-IPv4 addresses.
  • a VPN-IPv4 address has 12 bytes, starting with an 8-byte Route Identification Number ("RD"), followed by a 4-byte IPv4 address.
  • PE uses RD to identify routing information from different VPNs. Operators can allocate RDs independently, but need to use their dedicated autonomous system (AUTOM System, "AS" for short) as part of the RD to ensure the global uniqueness of each RD.
  • a VPN-IPv4 address with an RD of zero is synonymous with a globally unique IPv4 address. After this processing, even if the 4-byte IPv4 address contained in the VPN-IPv4 address overlaps, the VPN-IPv4 address can still be globally unique.
  • the route received by the PE from the CE is an IPv4 route and needs to be imported into the VRF routing table. At this time, an RD needs to be attached. In a common implementation, set the same RD for all routes from the same user site.
  • Route Target (Route Target) attribute The Route Target attribute identifies the set of sites that can use a route, that is, which sites the route can receive, and which PE routers can receive the routes transmitted by those sites. All PE routers connected to the site specified in the Route Target will receive routes with this attribute. After the PE router receives the route containing this attribute, it adds it to the corresponding routing table. PE routers have two sets of Route Target attributes: one set is used to attach to routes received from a site, and is called Expot Route Target s (output route targets); the other set is used to determine which routes can be imported into this The site's routing table is called Impor t Route Targets. By matching the Route Target attribute carried in the route, the membership of the VP can be obtained. Matching the Route Target attribute can be used to filter the routing information received by the PE router.
  • VPN packet forwarding process In RFC2547bi s standard, VPN packets are forwarded using two layers of labels.
  • the first layer (outer layer) label is exchanged inside the backbone network, which represents an LSP from the PE to the peer PE.
  • the VPN can use this layer of label to reach the peer PE along the LSP.
  • the second layer (inner layer) label is used when reaching the CE from the peer PE.
  • the inner layer label indicates which site the packet arrives at, or more specifically, which CE it reaches. In this way, the interface that forwards the packet can be found according to the inner label. In special cases, if two sites belonging to the same VPN are connected to the same PE, then the problem of how to reach the other PE does not exist.
  • VPN routing information is published through BGP: RFC2547bi s
  • the routing information is transmitted between CE and PE through IGP or EBGP, and the PE obtains the VPN routing table and stores it in a separate VRF.
  • Each PE uses IGP to ensure normal IP connectivity and is transmitted through IBGP.
  • the YPN composes information and routes, and completes the update of their respective VRFs.
  • the routing tables of CEs are then updated by routing exchanges with directly connected CEs, thereby completing the routing exchanges between CEs.
  • BGP communication is performed at two levels : Inside the autonomous system (IBGP) and between autonomous systems (EBGP) 0 PE-PE sessions are IBGP sessions, and PE-CE sessions are EBGP sessions.
  • BGP VPN composition information and route propagation between PE routers are implemented through multi-protocol extension border gateway protocol (Mul ti protocol extensions BGP, "MBGP" for short).
  • Mul ti protocol extensions BGP “MBGP” for short.
  • MBGP multi-protocol extension border gateway protocol
  • IETF document RFC2283 “Mul t iprotocol Extensions for BGP- 4" (Chinese name can be translated as "Multi-protocol Extension of Border Gateway Protocol-4").
  • MBGP is backward compatible. It can support both traditional IPv4 address families and other address families (such as VPN-IPv4 address family).
  • the route target carried by MBGP ensures that the route of a specific VPN can only be known by other members of this VPN, making communication between BGP / MPLS VP members possible.
  • QoS quality of service
  • the above solution does not currently have a mature MPLS YPN QoS solution, which results in a consequence that cannot meet user requirements. The main reason for this is that different NBVPNs accessed by the same group of PEs share resources by multiplexing the outer labels in the MPLS label stack.
  • the Provider Provisioned Virtual Private Networks (PPVPN) working group assigned by the IETF provider was divided into two working groups after the Vienna Conference in July 2003: L2 VPN and L3 VPN, in their latest charter None of them includes QoS solutions. In their current VPN reference model, QoS problems still exist. In IETF's "draf t-martini-12circuit-trans- mpls- 10. txt” and “draf t-martini- 12circuit_encap-mpls-04.
  • Nbvpn-decomp a general network-based virtual private network (Network Based Virtual Private Network, referred to as "NBVPN")
  • GYPN Generalized Virtual Private Network
  • Y.nbvpn-decom some functional entities are classified, the purpose of which is to simplify the VPN problem in order to define the technologies and mechanisms required by the network operator to provide the desired VPN network, but the reference model in Y.nbvpn-decomp
  • the corresponding QoS problem is the same as the VPN reference model and QoS problem proposed by the IETF.
  • the main object of the present invention is to provide a system and method for ensuring service quality in a virtual private network, so that the MPLS VPN QoS problem can have a practical solution.
  • the present invention provides a system for guaranteeing quality of service in a network-based virtual private network, including: a logical bearer network, which uses a multi-protocol label switching technology to configure a label switching path for reserved bandwidth in a basic nIP network It is formed by connecting various routers and is dedicated to transmitting services with service quality requirements.
  • a bearer control network is used to maintain the logical bearer network and route the services.
  • the bearer control network includes a centralized resource controller for managing network resources of the logical bearer network, maintaining a network topology of the logical bearer network, performing resource calculation and routing, and sending routes for the router. Instructing to allocate resources and perform access control in the logical bearer network, and maintain membership information for each of the virtual private networks And connection relationship information to realize automatic discovery and unilateral configuration of member relationships.
  • the centralized resource controller is deployed in each domain of the logical bearer network, and each of the centralized resource controllers is interconnected to communicate the topology, resource information, and the virtual private network of the logical bearer network Routing information.
  • the logical bearer network and the bearer control network publish routes of the virtual private network in an out-of-band manner, maintain membership of the virtual private network, and maintain access relationships between sites of the virtual private network.
  • the various routers include a backbone network edge router, an intermediate transfer router, and a core router.
  • the backbone network edge router is used to identify a virtual private network with a service shield volume requirement, and a service shield volume entered from the virtual private network.
  • the required service is encapsulated with a label stack indicated by the centralized resource controller, and the quality of service fields of all the labels in the label stack are set according to the priority of the service, and the encapsulated service data packet is passed through the logical bearer network.
  • the intermediate transfer router is used to implement static or dynamic configuration of label switching paths, multi-protocol label switching of differentiated service modes, and functions of processing flows by type;
  • the core router is used to implement multi-protocol labels of differentiated service modes The ability to exchange and process streams by type.
  • the centralized resource controller includes an interface management module, a protocol processing module, a membership relationship maintenance module, a topology and resource management module, a routing management module, and an automatic discovery signaling module.
  • the interface management module is used to implement and manage external resources.
  • the protocol processing module is configured to process a protocol for the centralized resource controller to communicate with various external devices, and forward communication data to the membership maintenance module and topology according to the protocol requirements And a resource management module, a routing management module, and an automatic discovery signaling module, the protocol processing module sends and receives communication data through the interface management module;
  • the membership relationship maintenance module is configured to maintain the membership information of the virtual private network and the access relationship information between the virtual private website points; the topology and resource management module is used to manage the topology relationship of the logical bearer network And resources; the routing management module is used to manage the routing relationship of the virtual private network; the automatic discovery signaling module is used to automatically change changes, and notify the membership maintenance module, the topology, and resource management The module corrects the corresponding information.
  • the invention also provides a method for guaranteeing the quality of service in a network-based virtual private network, which includes the following steps:
  • A In a cornerstone IP network, a multi-protocol label switching technology is used to construct a logical bearer by configuring a label switching path that reserves bandwidth. Network, this logical bearer network is dedicated to services with quality of service requirements;
  • step C When a service with quality of service needs to be transmitted, mark the priority of the service into the quality of service field of the routing label of the multi-protocol label switching data packet that encapsulates the service data flow, and assign the service according to the centralized resource controller.
  • the route is transmitted through the logical bearer network.
  • the centralized resource controller deploys one in each domain of the logical bearer network.
  • the route may be a serial label switching path determined by a label stack.
  • step C the same value is set for the quality of service fields of all labels in the service routing label stack.
  • the method further includes the steps of: dynamically adjusting the topology and resources of the logical bearer network using a multi-protocol label switching traffic engineering technique.
  • the priority of the service may be determined by the type of the service.
  • the method includes the following steps: judging whether the receiving and sending sites of the service have service shield requirements, and if so, using the logical bearer network To transmit the service, otherwise use other resources of the basic IP network to transmit the service.
  • the judgment of whether the receiving and sending sites of the service have service quality requirements includes the following sub-steps: E1 compares the routing destinations of the receiving and sending sites, and determines whether the receiving and sending sites are ordinary access relationships, and if so, Go to step E2;
  • E2 compares the routing destinations with quality of service requirements of the receiving and sending sites, determines whether the receiving and sending sites are access relationships that require service shields, and if so, determines that the service between the receiving and sending sites has Good service quality requirements, otherwise it is determined that there is no service quality requirement for the services between the receiving and sending sites.
  • the centralized resource controller has a unique route assigned to each pair of sites with quality of service requirements.
  • the technical solution of the present invention is different from the prior art in that a part of resources are pre-configured for QoS-VPN dedicated (referred to as a VPN logical bearer network) in the basic IP network through MPLS technology, and referenced in the current VPN
  • a centralized resource controller is added to the model to maintain the network topology and resources of the VPN-LBN, as well as the membership information and access relationship information of each QoS-VPN, and allow control and routing based on the resource status of the logical bearer network Calculate to ensure that the accessed services can get the quality of service they want.
  • the QoS problem of MPLS VPN has promoted operators to develop a VPN with QoS guarantee; it has solved the complexity and planability of large VPN network operations, cross-domain operations, Manageable and operational features; unify MPLS L3 / L2 / L1 VPN to provide QoS solutions.
  • FIG. 1 is a schematic diagram of an MPLS network structure
  • FIG. 2 is an MPLS L3VPN model defined by RFC2547b is
  • FIG. 3A is a flowchart of a method for ensuring quality of service in a virtual private network provided by the present invention
  • FIG. 4 is a reference model of a QoS_VPN architecture according to an embodiment of the present invention
  • FIG. 5 is a VPN-LBN using MPLS technology according to an embodiment of the present invention
  • FIG. 6 is a VPN-CRC according to an embodiment of the present invention Schematic diagram of internal structure and external connection relationship.
  • FIG. 3A is a flowchart of a method for ensuring service quality in a virtual private network provided by the present invention. It includes the following steps: First, in the basic IP network, a multi-protocol label switching technology is used to construct a logical bearer network by configuring a label switching path that reserves bandwidth.
  • the logical bearer network is dedicated to transmitting services with service quality requirements (step S 10 ); Then, deploying a centralized resource controller for centrally managing the resources of the logical bearer network (step S20); finally, when a service with a quality of service requirement needs to be transmitted, the priority of the service is marked to encapsulate the service In the quality of service field of the routing label stack of the multi-protocol label switching data packet of the data flow, according to the route allocated by the centralized resource controller, it is routed to the peer to be sent through the logical bearer network (step S30).
  • the present invention pre-configures a part of resources for QoS-VPN dedicated by MPLS technology in the basic IP network, and then maintains its VPN-LBN network topology and resources through a configured centralized resource controller, with various membership information and access Relationship information, thereby ensuring that the accessed service can obtain the required quality of service.
  • FIG. 3B shows a flowchart for implementing the above method.
  • capacity planning is performed: a network-based virtual private network (Network Based Virtual Private Network, referred to as "NBVPN") service that requires QoS guarantee is divided into a special service type
  • the present invention is called a QoS-VPN service, and this NBVPN is called a QoS-VPN.
  • a network operator should be able to identify this service when accessing this service.
  • the simplest method (of course not limited to this) is
  • the interfaces or sub-interfaces connected to these sites are identified on the PEs of the sites accessing the QoS-VPN, and the services entering from these interfaces or sub-interfaces are considered to be QoS-VP services.
  • the network operator needs to determine the current and expected QoS -VPN services to plan the capacity of QoS-VPN services, including topology, routing, bandwidth, etc. Then proceed to step 110, configure VPN-Logical Bearer Network (Logical Bearer
  • LBN NetWork, referred to as "LBN”).
  • LBN NetWork, referred to as "LBN”
  • an LBN is pre-configured in the basic IP network using MPLS technology for QoS-VPN alone.
  • QoS-VPN service flows routing, resource allocation, allowance control, and label forwarding are only in VPN-LBN.
  • a VPN-CRC is deployed in each domain in the VPN-LBN, which is generally separated from the data plane equipment of the VPN.
  • the VPN-CRC is responsible for resource calculation, access control, resource allocation, and routing between VPN sites.
  • the MPLS label stack representing the route is delivered to the ingress PE, and maintains membership information for each QoS-VPN, accesses the relationship information, and processes necessary signaling.
  • the reason for deploying one in each domain This CRC is because if only one global CRC is deployed, too much information needs to be coordinated when the network is huge.
  • a domain is a logical area divided by an operator, such as a province or a city. The size of the domain can be determined according to the actual processing capacity of the CRC. In the above embodiment, the topology and bandwidth of the QoS-VPN network are statically allocated.
  • MPLS traffic engineering Traffic Enginering, referred to as "TE"
  • TE Traffic Enginering
  • the VPN-CRC calculates and delivers the access path between the sites. Because all available resource information in VPN-LBN, as well as membership information and access relationship information in QoS-VPN are recorded in VPN-CRC, YPN-CRC can use this information for each pair of sites with QoS requirements The access path is calculated, and the path is delivered to each PE, which is executed by the PE. Because of this processing method, the path between each pair of sites with QoS requirements is uniquely determined.
  • step 140 marking the service priority and transmitting it through the VPN-LBN.
  • these service flows can still be divided into different types, such as voice, video, and data.
  • These service types can be identified and marked at the ingress PE. Different priorities.
  • the priorities are mapped to the EXP-all of the labels in the label stack of the routing information delivered by the VPN-CRC to the ingress PE (because of the labels). The stack labels need to be popped up when they are forwarded along these routes.
  • the method further includes the following sub-steps: comparing the routing destinations of the receiving and sending sites, and determining whether the receiving and sending sites are ordinary access relationships If yes, go to the next step, otherwise end.
  • determining whether the receiving and sending sites of the service have service quality requirements is determined by the following methods: By comparing the routing targets of the receiving and sending sites, it is determined whether the receiving and sending sites are accesses with service quality requirements.
  • the QoS-VPN framework is divided into two levels: a logical bearer network (log ica bearer layer, which can also become a bearer layer), and a bearer control layer.
  • the logical bearer layer is formed by using MPLS technology to connect PEs, CRs, and ITRs by configuring bandwidth-reserved LSPs in accordance with the advance capacity planning.
  • the bearer control network consists of several VPN-CRCs.
  • Each domain is configured with a VPN-CRC (excluding the backup of the VPN-CRC).
  • the YPN-CRC manages VPN-LB network resources (including bandwidth, processor, and buffers). ), Maintaining the network topology of the VPN-LBN, performing resource calculation, routing, sending routing instructions to the PE, allocating resources within the VPN-LBN, access control, and maintaining a membership information table for each QoS-VPN, connecting Relation information table and related signaling in order to realize automatic discovery of membership relationships and unilateral configuration.
  • QoS-VPN resources are allocated in a pre-configured VPN-LBN and explicit routing is selected through VPN-CRC.
  • the VPN services of Besteffect t are still not available.
  • the allocated network resources follow the traditional VPN mechanism for routing and forwarding.
  • the VPN-LBN consists of PE, ITR, CR, and LSPs connecting these routers. LSPs can be statically configured or dynamically established based on capacity planning and traffic measurement data.
  • MPLS TE technologies such as Fast Reroute (FRR) can be used to dynamically adjust the LSP bandwidth and maintain the VPN-LBN topology.
  • FRR Fast Reroute
  • VPN-CRC the corresponding QoS requirements determined according to the service level agreement (SSLA) between the user and the operator are also transmitted to the VPN-CRC with the service request, VPN- CRC (if necessary, the participation of other VPN-CRCs in the VPN bearer control network is required) to determine whether to allow access based on the network resources. If access is allowed, VPN-CRC will calculate the route that can meet the QoS requirements, and route information Sent to the ingress PE, the routing information is a series of LSPs representing an ingress PE from the ingress PE to the ingress PE.
  • SSLA service level agreement
  • the ingress PE will record these routing information and its associated QoS-VPN (via VPN-ID) and local and remote sites ( Through the site ID), all services belonging to the QoS-VPN and the local site to the remote site are forwarded through this route, unless the ingress PE receives another routing instruction.
  • the ingress PE identifies the QoS-VPN from related information such as the interface or sub-interface. After a QoS-VPN service flow enters the network, the ingress PE obtains the flow description information (usually including the source address, source port, destination address, destination port, and protocol type).
  • the packet / frame is encapsulated with a label stack indicated by the VPN-CRC, different EXP bit groups are set for all the labels in the label stack for different data types (voice / video / data), and the data packets / frames are introduced VPN-LBN, when the data flow is transmitted in the ITR on the route, all follow DiffServ-aware MPLS technology.
  • VPN-CRC the most important equipment in the solution of the present invention-YPN-CRC is introduced in detail.
  • the VPN bearer control network is composed of VPN-CRC in each domain, and is the control plane and management plane of the VPN bearer layer.
  • the 'VPN-CRC should have the following functions: intra-domain resource calculation, routing Selection, permission control, inter-domain resource request, network topology maintenance, membership relationship information maintenance, access relationship information maintenance and automatic discovery, unilaterally configured signaling, etc.
  • VPN-CRC can support policy management, SLA management, LSP traffic measurement, and interfaces with Authentication Authorization and Accounting Server ("AAA Server").
  • VPN-CRC 10 mainly includes the following modules: Interface management module 111, which is used to implement and manage the interface for communication with external devices. For example, communication with VPN-CRC 20 upstream, VPN-CRC 30 downstream, ITR 40, and ER 50. The protocols involved in these communications are explained below.
  • the system function module 112 is used to provide an underlying platform that supports the normal operation of the entire VPN-CRC 10. In a preferred embodiment of the present invention, the system function module 112 is an operating system in the VPN-CRC 10.
  • the protocol processing module 113 is configured to process a protocol for the VPN-CRC 10 to communicate with various external devices.
  • the communication data is forwarded to the membership maintenance module 114, the topology and resource management module 115, the routing management module 116, and the automatic discovery signaling module 117 according to the protocol requirements.
  • the protocol processing module 113 sends and receives communication data through the interface management module 111.
  • the member relationship maintenance module 114 is configured to maintain a member relationship information table and an access relationship information table.
  • Membership information table (membershi information table) contains information of site members belonging to the same QoS-VPN, the table is the site ID in the same QoS-VPN The list is indexed by VPN-ID.
  • the access relationship information table (connect information table e) contains the access relationship between members of the same QoS-VPN, that is, which other sites a site can visit.
  • the table can be accessed through the member information table and the route of each site. Target s is obtained. If the expor t Route Target of one site in the same QoS-VPN and the impor t Route Target of the other site are the same, then There is an access relationship between them.
  • the VPN-CRC 10 performs admission control, it needs to refer to the access relationship information table.
  • QoS-VPN sites can establish full mesh, Hub-Spoke, or other topological relationships.
  • the topology and resource management module 115 is configured to manage the topology and resources of the VPN-LBN.
  • the topology relationship is the connection relationship between the nodes in the VPN-LBN.
  • the resource mainly refers to the bandwidth reserved on these connection relationships.
  • the topology and resource recording and maintenance of VPN-LBN are independent of the basic network.
  • the initial resource data of VPN-LBN needs to be manually configured according to the results of capacity planning.
  • the route management module 116 is configured to uniformly manage all QoS-VPN routing relationships.
  • the automatic discovery signaling module 117 is used for automatic discovery of changes. Automatic discovery means that the access relationship information is not manually configured in VPN-CRC 10, but is provided automatically by an external device (such as PE). When the information obtained by the automatic discovery signaling module 117 includes a change in the membership relationship or the LBN topology relationship, the automatic discovery signaling module 117 will notify the membership maintenance module 114 or the topology and resource management module 115 to make corresponding modifications.
  • the VPN-CRC In order to maintain and transmit the QoS-VPN access relationship information, the VPN-CRC needs to maintain the access relationship between QoS-VPN members, that is, the topology of the QoS-VPN site. This can be (but not limited to) recording each QoS-VPN Two site lists are implemented, one is a list of sites allowed to send, and the other is a list of sites allowed to receive. To support the automatic discovery of modification of QoS-VPN membership and access relationship information, when adding or deleting sites in QoS-VPN, related update messages should be transmitted between PE and VPN-CRC. The VPN-CRC should update the member information table and access relationship information table.
  • routes for these new sites to access other sites will be calculated, and routes will be indicated to relevant PEs, and these PEs will update their QoS-routing information tables
  • the remote PEs sense the increase of these sites, they will trigger their own local sites to access the service requests of these new sites, the VPN bearer control network will perform the same process, and finally all sites will learn the routing information of mutual access.
  • the VPN-CRC will release and delete the site-related resources, and notify the relevant PE to delete the relevant entry in the QoS routing information table. Detecting the deletion of a site will trigger their deletion of resources about their local site access to these deleted sites.
  • the topology and resource table 118 is used to store the topology and resources of the VPN-LBN.
  • the routing table 119 is configured to store a QoS_VPN route (essentially, a set of destination addresses that can be accessed by each site).
  • the destination address set consists of several address prefixes or addresses.
  • VPN-CRC service request including VPN-ID, local site ID, remote site ID, and QoS requirements
  • resource calculation, routing, and admission control are performed.
  • the response needs to be transmitted to the upstream VPN-CRC until it reaches the ingress PE. Otherwise, the VPN-CRC
  • the routing information determined by the CRC is transmitted upstream until the entire routing information (label stack) is sent to the ingress PE.
  • the ingress forwards the data from the local site to the remote site, it sets the label according to the description of the CE-PE service flow.
  • the EXP bit groups of all tags in the stack are transmitted from the routes calculated above, but different types of services in the same direction are distinguished by the EXP bit groups and transmitted according to the MPLS-DifferServ mechanism.
  • the PE should support static LSP configuration or dynamic establishment through CR-LDP / RSVP-TE
  • the LSP is in order to achieve pre-configuration and dynamic adjustment of VPN-LBN, and should support flow classification, so that the EXP bit set can be set for the label stack received from VPN-CRC.
  • the QoS routing information table is stored in the PE. The table mainly stores the following information: VPN-ID, local site, remote site (accessible destination address set in the remote site), routing between the local site and the remote site .
  • the admission control response is received from the VPN-CRC, if the response is "access permitted", the routing and QoS information will be included.
  • the ingress PE will record this information in the QoS information table, which is maintained separately for each QoS-VPN According to the VPN-ID index, in the information of each QoS-VPN, an entry is recorded for each site pair (a local site to a remote site), and the ingress PE queues and schedules according to the QoS routing information table. , Shaping, marking, policy, MPLS encapsulation, and then forwarding in the VPN-LBN according to the route determined by the label stack.
  • the intermediate transport router ITR should support static LSP configuration or dynamically establish LSPs through CR-LDP / RSVP-TE in order to achieve pre-configuration and dynamic adjustment of VPN-LBN. It should also support DiffServ-aware MPLS and process flows by type.
  • the core router CR in the IP backbone network only needs to support DiffServ-aware MPLS and process flows by type. The following describes the method of QoS-VPN isolation using VPN addresses.
  • the VP address can consist of a globally unique VPN-ID in the VPN-LBN and a private address associated with L3 / L2 / L1 VPN, such as IPV4 / IPV6 / IPX address in L3 VPN, data link address in L2 VPN, L1VPN Cross-connection identification in the VPN address scheme.
  • the addresses of different sites in different QoS-VPNs can overlap. Since the VPN-ID is globally unique in the VPN-LBN, the composed VPN address will also be unique in the VPN-LBN. .
  • the QoS routing information table can distinguish different QoS-VPN information by VPN-ID, so as to achieve isolation between QoS-VPNs.
  • the following describes the routing and forwarding methods.
  • QoS-VPN routing is maintained in the QoS routing information table of the PE. Its granularity is the QoS-VPN site pair, that is, all services have the same route from a local site to a remote site.
  • the route lookup at the ingress PE is divided into For two levels, the first level finds the QoS-VPN that belongs to the local site according to different VPN-ID indexes, and the second level searches searches for the local site and remote site pairs in the QoS-VPN, and associates with the remote site It is the aggregated address in the remote site. When the destination address in the service flow matches the aggregated address associated with the remote site in the site pair, the search is considered successful.
  • the ingress PE determines routing information (the MPLS label stack designated by VPN-CRC) for the service flow, and marks the EXP bit group in the routing information label. If one of the two levels of lookups fails, the ingress PE can reject the service flow.
  • routing information the MPLS label stack designated by VPN-CRC
  • QoS-VPN forwarding is based on MPLS technology, using the label stack issued by VPN-CRC and the EXP bit set set by the ingress PE for the service flow.
  • the MPLS-DiffServ mechanism is used according to the outer label to ensure service bandwidth and forwarding priority, thereby ensuring QoS-VPN quality of service (bandwidth, delay, jitter, packet loss rate).
  • the following describes the interface and signaling requirements between various devices, including between PE and CE, between VPN-CRC and operator routers (including PE, ITR, CR), interfaces between VPN-CRC and VPN-CRC, and protocol.
  • the interface between PE and CE transmits user information, such as topology, the aggregated private addresses of CE-connected sites (such as private IPv4 / IPv6 / IP addresses in L3VPN, data link addresses in L2VPN, and cross-connections in L1VPN Identification;), service request (including flow identification).
  • user information such as topology, the aggregated private addresses of CE-connected sites (such as private IPv4 / IPv6 / IP addresses in L3VPN, data link addresses in L2VPN, and cross-connections in L1VPN Identification;), service request (including flow identification).
  • the interface between the VPN-CRC and the PE allows the VPN-CRC to instruct the PE to process the service flow of each site. It is necessary to specify a corresponding protocol for this excuse, which can be extended based on the structure of this article on the basis of COPS.
  • the protocol needs to support the following functions:
  • the ingress PE sends a service request (including VPN-ID, local site ID, expor t Route Target, remote site ID, and QoS requirements) to the VPN-CRC.
  • the QoS requirements include the service type and its bandwidth, priority, and delay. , Jitter limit, loss rate limit, MTU, etc., it determines the service quality requirements for each site according to the SLA between the user and the operator.
  • the VPN-CRC determines whether there is an access relationship between the local site and the remote site based on the site ID and the expor t Route Target in the service request. (The VPN-CRC needs to pass service request information to the relevant VPN-CRC and egress PE.
  • the admission control result of the VPN bearer control network is "deny” or "accept”, the result is notified to the ingress PE.
  • the admission control is “allowed”, the VPN-CRC notifies the ingress PE of the route (representing a set of serial LSP label stacks) about the site pair.
  • the PE in the QoS routing information table for each QoS-VPN This record is created for each site pair.
  • the PE corresponding to the changed site should send an update message to the VPN-CRC in the local domain, and the VPN-CRC sends to the neighboring VPN-CRC. Pass the message and finally send it to the peer PE, related
  • the VPN-CRC will update the membership information table and the access relationship information table, and the relevant PE will update the corresponding entry in the QoS routing information table.
  • the PE sends the aggregated YPN address information of the site to which it is connected to the VPN-CRC.
  • the VPN-CRC is published in the VPN bearer control network and finally released to the relevant PE. This function can be implemented through the BGP protocol that T displays.
  • all PEs will store the aggregated VPN addresses of the QoS-VPN sites they access in the QoS routing information table.
  • the PE receives the service flow, it can determine the route and the EXP bit based on the QoS routing information table and the flow identifier. group.
  • the interface between the VPN-CRC and the PE, ITR, and CR in the domain should support the following functions:
  • VPN-CRC The interface between VPN-CRC is used to implement resource allocation and routing of services between QoS-VPN sites across domains. It is necessary to define a separate protocol for this interface, and COPS or BGP can be extended to complete the corresponding functions.
  • the protocol needs to support the following functions:
  • the VPN-CRC is allowed to notify the downstream VPN-CRC of the inter-domain QoS-VPN service identification information (local site ID, remote site ID, VPN-ID). (3) Allow the VPN-CRC to notify the downstream VPN-CRC of the QoS requirements of the inter-domain QoS-VPN service (including the service type and its bandwidth, priority, delay limit, jitter limit, loss rate limit, etc.).
  • VPN-CRC and other VPN-CRC are allowed to exchange inter-domain service level specifications (service le specifcation, abbreviated as "SLS") and routing information.
  • SLS service le specifcation
  • the case of hybrid QoS-VPN is discussed below. In some cases, some sites of a VPN have QoS requirements, while other sites do not have QoS requirements. This type of VPN is called a hybrid QoS-VPN.
  • Hybrid QoS-VPN can be divided into two parts. One part is composed of those sites with QoS requirements, called sub-QoS-VPN, and the other part is composed of sites without QoS requirements, called sub-VPN.
  • sub_QoS-VPN For sub_QoS-VPN, its QoS guarantee can adopt the above-mentioned MPLS NBVPN solution with centralized resource control to ensure QoS.
  • Route Target is used to determine the access relationship of the entire VPN (including sub-QoS-VPN and sub-VPN).
  • VPN-CRC can be used to determine it.
  • QoS Route Target (routing target with QoS requirements) is introduced to maintain sub-QoS.
  • -VPN access relationship information table, QoS Route Target s and Route Target s have the same format.
  • VPN-CRC performs intra-domain routing in the topology information table and the resource information table.
  • the routing algorithm can be fixed, such as Time Dependent Routing (referred to as "TDR") / state-dependent routing (S ta te Dependent Routing, "SDR” for short).
  • TDR Time Dependent Routing
  • SDR state-dependent routing
  • an inter-domain routing table should be maintained in the VPN-CRC to determine the inter-domain LSP through the QoS signaling protocol to discover adjacent downstream VPN-CRCs.
  • the VPN-CRC inter-domain routing table can be manually configured or automatically generated by running a dynamic routing protocol.
  • the following discusses how to provide QoS-VPN across different network providers. 'In order to support QoS-VPN in the networks of different providers, their Autonomous System Boundary Router (ASBR) should communicate with each other to transmit VPN service request signaling and VPN services. If the VPN-CRC is deployed on both networks, their VPN-CRC can communicate with each other. At this time, these VPN-CRCs only exchange and map the inter-network SLA. At this time, the VPN-CRC only manages the intra-network link resources.
  • ASBR Autonomous System Boundary Router
  • ASBR Manage the inter-network link resources through the specified SLA to complete the function of the ingress PE in the case of the internal QoS-VPN of the operator. If one of the network operators does not deploy VPN-CRC, it will use other QoS mechanisms. Two ASBRs should map QoS requirements to each other, and the final degree of QoS guarantee will depend on the VPN QoS implementation mechanisms of other network providers.

Description

虚拟专用网的保证服务质量的系统及其方法
技术领域 本发明涉及虛拟专用网络的服务质量实现方案，特别涉及使用多 协议标签交换的虚拟专用网的服务质量实现方案。
背景技术 虛拟专用网 （Virtual Private Networking, 简称 "VPN" )是指 在公共网络中建立专用网络， 数据通过安全的 "加密通道"在公共网 络中传播。企业只需要租用本地的数据专线，连接上本地的 Internet (因特网）， 各地的机构就可以互相传递信息； 同时， 企业还可以利 用 Internet的拨号接入设备， 让自己的用户拨号到 Internet上， 就 可以连接进入企业网中。 使用 VPN有节省成本、 提供远程访问、 扩展 性强、 便于管理和实现全面控制等优点。 多协议标签交换（Multi- protocol Label Switch, 简称 "MPLS" ) 是由思科公司 （CISCO) 的标记交换（Tag Switching) 演变而来的国 际互联网工程任务组 （ Internet Engineering Task Force, 筒称 "IETF" ) 的标准协议。 MPLS 是基于标签的互联网协议 （ internet Protocol, 筒称 "IP")路由选择方法， 它属于第三层交换技术， 引 入了基于标签的机制， 把选路和转发分开， 由标签来规定一个分组通 过网络的路由， 数据传输通过标签交换路径 （Label Switch Path, 筒称 "LSP") 完成， 它将原本在 IP网络的第三层的包交换转换成第 二层的包交换。在标签中， 包含一个 3比特的 EXP字段用来实现 QoS。 图 1示出了 MPLS网络结构。 MPLS网络 101由核心部分的标签交 换路由器 104 (Label Switch Router, 简称 "LSR" )、 边缘部分的标 签边缘路由器 103 (Label Edge Router, 简称 "LER" )组成。 其中 LER 103用于分析 IP 包头， 执行第三层网络功能， 决定相应的传送 级别和标签交换路径 （Label Switch Path, 筒称 "LSP" )， 它与外部 网络 102相连接， 从外部网络 102接收外部分组交换数据包（IP包） 105 ; LSR 104 用于建立 LSP , 执行标签交换机制和服务质量保证 ( Qual i ty of Service, 筒称 "QoS" ), 转发 MPLS网络 101内部的分 组数据包 106， 它由控制单元和交换单元组成， 它处在网络内部， 与 LER 103和其他 LSR 104相连。
MPLS的标签交换的工作流程如下： 最初由标签分发协议（Label Di s tr ibut ion Protocol , 简称 "LDP" )和传统路由协议， 比如开发 最短路优先协议 ( Open Shortes t Path Firs t , 筒称 "0SPF" )等， 在 LSR中建立路由表和标签映射表； 在网络运行中， 首先在 MPLS核 心网入口处的 LER接收外部网络的 IP包， 完成第三层网络功能， 并 给 IP包加上标签成为分组数据包；接着该分组数据包在 LSP中传输。 此时 LSR不再对分组数据包进行第三层处理，只是根据其标签通过交 换单元进行转发， 最终达到网络另一端即出口处的 LER; 最后在 MPLS 出口处的 LER将该分组数据包的标签去掉成 IP包后按照相应外部网 络协议继续进行转发。 由于 MPLS技术隔绝了标签分发机制与数据流的关系， 因此， 它 的实现并不依赖于特定的数据链路层协议，进而可支持多种的物理层 和数据链路层技术。 目前实现了在帧中继（Frame Relay, 筒称" FR" )、 异步传输模式 （Asynchronous Transfer Mode, 简称 "ATM" )和点到 点协议（Point- to- Point Protocol , 简称 "PPP" )链路以及国际电 气电子工程师协会 ( Ins t i tute of Electrical and Electronics Engineers , 简称 "IEEE" ) 802. 3协议的局域网上使用 MPLS的业务。 采用 MPLS网络进行 IP业务转发，可以简化层与层之间的路由转发过 程， 加快 MPLS交换速度， 提高网络效率， 同时能满足不同等级业务 的传送， 所以说 MPLS既有交换机的高速度与流量控制能力， 又具备 了路由器灵活的功能和服务质量保证机制。
MPLS已经被广泛应用于 VPN的实现， 借助 MPLS实现的 VPN被称 为 MPLS VPN。 根据网络设备转发依据的用户信息， MPLS VPN可以划 分为 L3 (层 3, 即网络层） VPN, L2 (层 2， 即数据链路层） VPN, L1 (层 1， 即物理层） VPN 三种类型。 目前在互联网工程任务组
( INTERNET ENGINEERING TASK FORCE, 简称 "IETF")标准组织中， 有 L3 VPN工作组和 L2 VPN工作組， 分别研究 MPLS L3 VPN和 MPLS L2 VPN。 MPLS L3 VPN的典型代表是基于 RFC 2547bis 的边界网关协议
(Border Gateway Protocol, 筒称 "BGP" ) /MPLS VP 和基于虛拟 路由器 （Virtual Router, 简称 "VR" ) 的 IP VPN„ MPLS L2 VPN的 典型代表是 MARTINI, KOMPELLA, 以及多种虚拟专用局域网子网段
(Virtual Private LAN Segment, 筒称 "VPLS" ) 实现方案。 此外， 国际电信联盟 -电信标准部 ( International Telecommunication Union Telecommunication Standardization Sector, 筒称 "ITU-T" ) 的 SG13/Q11 对 LI VPN 的研究比较多， 目前有 Y. llvpnarch, Y. llvpnsdr等草案建议。他们的参考模型的结构都类似，对于 VPN QoS 问题的处理都类似，要么没有考虑，要么是利用网络自身的 DiffServ (差异服务模式）能力， 因此都不能解决 VPN的 QoS问题， 而且不能 解决该问题的原因也相同， 在这方面可以将他们归为相同的技术。 下面以 RFC2547bis 作为这一类技术的代表对现有技术进行说 明， 由于他们和 ITU-T, IETF的 L2 VPN和 L3 VPN的参考模型具有相 同的结构， 在解决 QoS问题上的困难是相同的。 RFC2547bis所定义的 MPLS L3VPN模型如图 2所示， 该模型包括 三个组成部分：用户网边缘路由器（Custom Edge Router,筒称" CE" )、 骨干网边缘路由器 （Provider Edge Router, 筒称 "PE" )和路由器 (P)。
CE设备是用户驻地网络的一个组成部分， 有接口直接与运营商 的网络相连， 一般是路由器。 CE "感知" 不到 VPN的存在， 也不需要 维护 VPN的整个路由信息。
PE路由器即运营商边缘路由器，是运营商网络 (也称之为骨干网） 的边缘设备， 与用户的 CE直接相连。 MPLS网络中， 对 VPN的所有处 理都在 PE路由器上完成。 路由器（P )是运营商网络中的骨干路由器，它不和 CE直接相连。 路由器 （P ) 需要有 MPLS基本信令能力和转发能力。
CE和 PE的划分主要是从运营商与用户的管理范围来划分的， CE 和 PE是两者管理范围的边界。
CE与 PE之间使用外部边界网关协议 ( Exter ior Border Gateway Protocol , 筒称 "EBGP" ) 或是内部网关协议 ( Inter ior Gateway Protocol , 简称 "IGP" )路由协议交换路由信息， 也可以使用静态路 由。 CE不必支持 MPLS , 不需要感知 VPN的整网路由， VPN的整网路 由外包给运营商来完成。 运营商 PE设备之间通过多协议内部网关协 议 ( Mul t i-protocol Internal Border Gateway Protocol , 简称 "MP-IBGP" ) 交换 VPN的整网路由信息。 以下介绍 RFC2547bi s标准规定的 MPLS L3VPN的相关属性：
YRF: VPN是由多个站点（Si te)组成的。 在 PE上， 每个站点对应一个 虚拟专用网路由 /转发实例 （VPN Rout ing/Forwarding ins tance, 简 称 "VRF" ), 它主要包括： IP路由表、 标签转发表、 使用标签转发表 的一系列接口以及管理信息（包括路由识别号、 路由过滤策略、 成员 接口列表等）。 (修改理由： 上述说明用户站点是 VPN的一个组成部分， 用上述 的话来描述会导致描述不清楚的， 因此删除）一个站点可以同时属于 多个 VPN。 在实现中， 每一个站点至少关联一个单独的 VRF。 VPN 中 站点的 VRF实际上综合了该站点的 VPN成员关系和路由规则。报文转 发信息存储在每个 VRF的 IP路由表和标签转发表中。系统为每个 VRF 维护一套独立的路由表和标签转发表，从而防止了数据泄漏出 VPN之 夕卜， 同时防止了 VPN之外的数据进入。
VPN- IPv4地址族: PE路由器之间使用 BGP来发布 VPN路由， 并使用了新的地址族 —— VPN- IPv4地址。 一个 VPN- IPv4地址有 12个字节， 开始是 8字节的路由识别号 ( Route Di s t ingui sher , 简称 "RD" ), 后面是 4字节的 IPv4地址。 PE使用 RD对来自不同 VPN的路由信息进行标识。 运营商可以独立地 分配 RD， 但是需要把他们专用的自治系统 （ Au t onomou s Sys tem, 筒 称 "AS" )号作为 RD的一部分来保证每个 RD的全局唯一性。 RD为零 的 VPN-IPv4地址同全局唯一的 IPv4地址是同义的。通过这样的处理 以后， 即使 VPN- IPv4地址中包含的 4字节 IPv4地址重叠， VPN- IPv4 地址仍可以保持全局唯一。
PE从 CE接收的路由是 IPv4路由， 需要引入 VRF路由表中， 此 时需要附加一个 RD。 在通常的实现中， 为来自于同一个用户站点的 所有路由设置相同的 RD。
Route Target (路由目标）属性： Route Target 属性标识了可以使用某路由的站点的集合， 即该 路由可以被哪些站点所接收， PE 路由器可以接收哪些站点传送来的 路由。 与 Route Target中指明的站点相连的 PE路由器， 都会接收到 具有这种属性的路由。 PE路由器接收到包含此属性的路由后， 将其 加入到相应的路由表中。 PE路由器存在两个 Route Target属性的集合： 一个集合用于附 加到从某个站点接收的路由上， 称为 Expor t Route Target s (输出 路由目标）； 另一个集合用于决定哪些路由可以引入此站点的路由表 中， 称为 Impor t Route Target s (输入路由目标）。 通过匹配路由所携带的 Route Target属性， 可以获得 VP 的成 员关系。 匹配 Route Target属性可以用来过滤 PE路由器接收的路由 息。
VPN报文的转发过程: 在 RFC2547bi s标准中， VPN报文转发使用两层标签方式。 第一 层（外层）标签在骨干网内部进行交换， 代表了从 PE到对端 PE的一 条 LSP, VPN ¾文利用这层标签， 就可以沿着 LSP到达对端 PE。 从对 端 PE到达 CE时使用第二层（内层）标签， 内层标签指示了报文到达 哪个站点， 或者更具体一些， 到达哪一个 CE。 这样， 据内层标签， 就可以找到转发报文的接口。 特殊情况下， 属于同一个 VPN的两个站 点连接到同一个 PE, 则如何到达对方 PE的问题不存在， 只需要解决 如^] "到达对端 CE。 通过 BGP发布 VPN路由信息： 在 RFC2547bi s标准中， CE与 PE之间通过 IGP或 EBGP来传播路 由信息， PE得到该 VPN的路由表， 存储在单独的 VRF中。 各个 PE之 间通过 IGP来保证通常 IP的连通性，通过 IBGP来传播 YPN组成信息 和路由， 并完成各自 VRF的更新。 再通过与直接相连 CE之间的路由 交换来更新 CE的路由表， 由此完成各个 CE之间的路由交换。 BGP通信在两个层次上进行： 自治系统内部（ IBGP ) 以及自治系 统之间 （ EBGP )0 PE- PE会话是 IBGP会话， 而 PE- CE会话是 EBGP会 话。
BGP在 PE路由器之间的 VPN组成信息和路由传播， 通过多协议 扩展边界网关协议 ( Mul t i protocol extens ions BGP, 简称 "MBGP" ) 来实现。 关于 MBGP 的详细内容可以参考 IETF 的文档 RFC2283 《Mul t iprotocol Extens ions for BGP- 4》（中文名称可译为 《边界 网关协议- 4 的多协议扩展》）。 MBGP 向下兼容， 既可以支持传统的 IPv4地址族， 又可以支持其他地址族（比如 VPN- IPv4地址族）。 通 过 MBGP携带的 route target (路由目标）确保了特定 VPN的路由只能 被这个 VPN的其他成员知道， 使 BGP/MPLS VP 成员间的通信成为可 能。 当通过 VPN传输数据时， 用户经常指定其服务质量（QoS)。 比如： 指定传输数据的优先级。 该传输数据的优先级越高， VPN在保证传输 可靠性的基础上越先传输。 在实际应用中， 上述方案目前并未有成熟 的 MPLS YPN QoS方案， 由此造成不能满足用户需求的后果。 造成这种情况的主要原因在于， 由同一组 PE接入的不同 NBVPN 之间通过复用 MPLS标签栈中的外层标签来同享资源。 虽然理论上可 以通过部署 DiffServ- aware (通过 IP的差异化服务编码点 （ DSCP ) 字段来进行不同优先级的转发） 或类似的方案来保证外层隧道的资 源， 但在这些参考模型中， 每个 VPN中没有一个设备了解骨干网络中 的资源状况， 由于在每个节点几个 VPN之间存在资源竟争， 而且都不 知道骨干网络中的资源状况， 因此为每个 VPN保证资源比较困难， 这 种共享竟争的机制给保证 VPN的服务质量保证带来了更多复杂性。
IETF 的提供者指配的虚拟专用网 ( Provider Provisioned Virtual Private Networks, 简称 "PPVPN" ) 工作组在 2003年 7月 维也纳会议后分为两个工作組： L2 VPN 和 L3 VPN, 在它们最新的 charter中，都没有包括 QoS解决方案，它们现在的 VPN参考模型中， QoS 问 题 仍 然 存 在 。 在 IETF 的 《 draf t- martini - 12circuit - trans- mpls- 10. txt 》 和 《draf t- martini- 12circuit_encap-mpls - 04. txt；》 (这两篇文稿是 L2VPN的基础 )中，对于 QoS问题，都表示 "QoS related issues are not discussed in this draft" ( QoS相关问题没有在这个草案中 讨论）， 在 《draft- ietf- 13νριι- rfc2547bis- 01. txt》 （该文稿是 BGP/ PLS VPN的基础） 中， 对于 VPN的 QoS 问题， 只是筒单的说 " existing L3 QoS capabilities can be applied to labeled packets through the use of the "experimental" bits in the shim header" (现存的 L3 QoS能力可以通过使用标签包头部的实验比特来 解决）， 但问题是 L3 QoS本身也是一个复杂的未解决的问题。 因此， L2VPN/L3YPN中的 QoS问题都还没有解决。
在 2003年 7月份 ITU- T SG13会议上，通过了研究通用 VPN( GVPN ) 的提议， 草案建议 γ. nbvpn-decomp作为通用基于网络的虛拟专用网 ( Network Based Virtual Pr ivate Network, 简称 "NBVPN" ) 功能 分解的初始文本， 是通用虛拟专用网（ General ized Virtual Pr ivate Network, 简称 "GYPN" )构建块分类的基础。 在 Y. nbvpn-decom 中， 对一些功能实体进行了分类， 其目的是简化 VPN问题， 以便定义网络 运营商提供所希望的 VPN网络需要的技术和机制，但 Y. nbvpn-decomp 中的参考模型和相应的 QoS问题与 IETF提出的 VPN参考模型和 QoS 问题都相同， 因此， QoS问题也没有很好地解决， 这样， 整个 VPN模 型就不会足够通用，以满足希望提供有 QoS保证的 VPN业务的运营商 的需求， 而且 VPN用户虽然被允许接入， 但不能保证向他们在使用异 步传输模式 ( Asynchronous Transfer Mode, 简称 "ATM" ) /帧中继
( Frame Relay, 简称 "FR" ) /数字数据网络（ Digi tal Data Network, 简称 "DDN" ) 时得到他们需要的资源。
发明内容 有鉴于此，本发明的主要目的在于提供一种虚拟专用网中保证服 务质量的系统及其方法， 使得 MPLS VPN QoS问题可以有一种实用的 解决方案。 为实现上述目的，本发明提供了一种基于网络的虛拟专用网中保 证服务质量的系统， 包含： 逻辑承载网， 使用多协议标签交换技术通过在基础 nIP 网络中 配置预留带宽的标签交换路径连接各种路由器而形成，专用于传输有 服务质量需求的业务； 承载控制网，用于对所述逻辑承载网进行维护并对所述业务进行 路由。 其中， 所述承载控制网包含集中式资源控制器， 用于管理所述逻 辑承载网的网络资源， 维护所述逻辑承载网的网络拓朴， 进行资源计 算和路由选择， 为所述路由器发送路由指示， 在所述逻辑承载网内分 配资源并进行接入控制，为每一个所述虚拟专用网维护成员关系信息 和连接关系信息， 实现成员关系的自动发现和单边配置。 所述集中式资源控制器在所述逻辑承载网的每一个域中部署一 个， 各个所述集中式资源控制器相互连接， 交流所述逻辑承载网的拓 朴、 资源信息以及所述虛拟专用网的路由信息。 所述逻辑承载网和所述承载控制网通过带外的方式发布所述虛 拟专用网的路由、 维护所述虚拟专用网的成员关系、 维护所述虛拟专 用网各站点之间的访问关系。 所述各种路由器包含骨干网边缘路由器、中间转接路由器与核心 路由器， 所述骨干网边缘路由器用于识别有服务盾量需求的虛拟专用网， 对从该虛拟专用网进入的有服务盾量需求的业务用所述集中式资源 控制器指示的标签栈进行封装，根据该业务的优先级设置所述标签栈 中所有标签的服务质量字段，将封装好的业务数据包通过所述逻辑承 载网传输； 所述中间转接路由器用于实现标签交换路径的静态或动态配置、 区别服务模式的多协议标签交换和按类型处理流的功能； 所述核心路由器用于实现区别服务模式的多协议标签交换和按 类型处理流的功能。 所述集中式资源控制器包含接口管理模块、协议处理模块、 成员 关系维护模块、拓朴和资源管理模块、路由管理模块和自动发现信令 模块， 所述接口管理模块用于实现并管理和外部设备进行通信的接口； 所述协议处理模块用于对所述集中式资源控制器与各种外部设 备通信的协议进行处理，并根据协议要求将通信数据转发给所述成员 关系维护模块、拓朴和资源管理模块、路由管理模块和自动发现信令 模块， 所述协议处理模块通过所述接口管理模块收发通信数据； 所述成员关系维护模块用于维护所述虛拟专用网的成员关系信 息和所述虛拟专用网站点间访问关系信息； 所述拓朴和资源管理模块用于管理所述逻辑承载网的拓朴关系 和资源； 所述路由管理模块用于管理所述虚拟专用网的路由关系； 所述自动发现信令模块用于变更的自动发现，并通知所述成员关 系维护模块、 所述拓朴和资源管理模块修正相应的信息。 本发明还提供了一种基于网络的虛拟专用网中保证服务质量的 方法， 包含以下步骤： A 在基石出 IP网络中， 使用多协议标签交换技术通过配置预留带 宽的标签交换路径构造逻辑承载网，该逻辑承载网专用于有服务质量 需求的业务；
B部署用于集中管理所述逻辑承载网资源的集中式资源控制器；
C 需要传输有服务质量需求的业务时，将该业务的优先级标记到 封装该业务数据流的多协议标签交换数据包的路由标签的服务质量 字段中， 按照所述集中式资源控制器分配的路由， 通过所述逻辑承载 网传输。 其中，所述集中式资源控制器在所述逻辑承载网的每一个域中部 署一个。 所述路由可以是由标签栈确定的串行标签交换路径。 所述步骤 C中，对所述业务路由标签栈中全部标签的服务质量字 段设置相同的数值。 所述方法还包含以下步骤： 使用多协议标签交换流量工程技术动态调整所述逻辑承载网的 拓朴和资源。 在所述步骤 C 中， 所述业务的优先級可以由所述业务的类型确 定。 当所述虛拟专用网同时包含有服务质量需求的站点和没有服务 质量需求的站点时， 包含以下步驟： 判断业务的收、发站点是否都有服务盾量需求， 如果是则使用逻 辑承载网内的资源传输该业务， 否则使用所述基础 IP网络的其他资 源传输该业务。 所述对业务的收、发站点是否都有服务质量需求的判断包含以下 子步骤： E1 比较所述收、 发站点的路由目标， 判断所述收、 发站点是否 为普通访问关系， 如果是则进入步骤 E2 ;
E2 比较所述收、 发站点的有服务质量需求的路由目标， 判断所 述收、发站点是否为有服务盾量需求的访问关系， 如果是则判定所述 收、 发站点之间的业务具有良务质量需求， 否则判定所述收、 发站点 之间的业务没有服务质量需求。 所述集中式资源控制器为每一对有服务质量需求的站点分配的 路由是唯一。 通过比较可以发现， 本发明的技术方案与现有技术的区别在于， 通过在基础 IP网络中通过 MPLS技术预配置一部分资源给 QoS-VPN专 用 （称为 VPN逻辑承载网）， 并在当前 VPN参考模型中增加集中式资 源控制器， 用于维护 VPN- LBN的网络拓朴和资源， 以及每个 QoS- VPN 的成员关系信息和访问关系信息，并根据逻辑承载网的资源状态进行 允许控制和路由计算， 保证接入的业务都能得到它们希望的服务质 量。
这种技术方案上的区别， 带来了较为明显的有益效果， 即解决了
MPLS VPN的 QoS问题， 对于运营商开展具有 QoS保证的 VPN起到了 推动作用； 解决了 VPN大网络运营、 跨域运营中的复杂性和可规划、 可管理、 可运营的特性; 统一了 MPLS L3/L2/L1 VPN的提供 QoS的解 决方案。
附图说明 图 1是 MPLS网络结构示意图； 图 2是 RFC2547b i s所定义的 MPLS L3VPN模型； 图 3A是本发明提供的一种虛拟专用网中保证服务质量的方法的 流程图； 图 3B是根据本发明的一个实施例的实现 QoS - VPN的方法流程 图；
图 4是根据本发明的一个实施例的 QoS_VPN构架的参考模型； 图 5是根据本发明的一个实施例的使用 MPLS技术的 VPN- LBN; 图 6是根据本发明的一个实施例的 VPN - CRC内部结构及对外连 接关系示意图。
具体实施方式 为使本发明的目的、技术方案和优点更加清楚， 下面将结合附图 对本发明作进一步地详细描述。 请参阅图 3A, 其为本发明提供的一种虚拟专用网中保证服务质 量的方法的流程图。 它包含以下步骤： 首先， 在基础 IP网络中， 使 用多协议标签交换技术通过配置预留带宽的标签交换路径构造逻辑 承载网，该逻辑承载网专用于传输有服务质量需求的业务（步骤 S 10)； 然后， 部署用于集中管理所述逻辑承载网资源的集中式资源控制器 (步骤 S20) ; 最后， 当需要传输有服务质量需求的业务时， 将该业务 的优先级标记到封装该业务数据流的多协议标签交换数据包的路由 标签栈的服务质量字段中， 按照所述集中式资源控制器分配的路由， 通过所述逻辑承载网路由到需发送的对端（步骤 S 30) 。 本发明通过在基础 IP网络中通过 MPLS技术预配置一部分资源给 QoS-VPN专用， 然后通过配置的集中资源控制器来维护其 VPN- LBN的 网络拓朴和资源， 以各种成员关系信息和访问关系信息， 由此保证接 入的业务能得 其所要求的服务质量。 现举一个实施例来说明本方法的具体实现过程。 图 3B示出了实现上述方法的流程图， 在步骤 100, 进行容量规 划： 将需要 QoS 保证的基于网络的虛拟专用网 （Network Based Virtual Private Network, 简称 "NBVPN" ) 业务划分为一个特殊业 务类型， 本发明称之为 QoS- VPN业务， 这种 NBVPN称为 QoS- VPN, 网 络运营商在接入这种业务时应该能够识別这种业务， 最筒单的方法 (当然不限于此）是在接入 QoS-VPN的站点的 PE上识別出这些站点 连接的接口或子接口， 认为从这些接口或子接口进入的业务都是 QoS-VP 业务， 网络运营商需要根据当前和预期的 QoS-VPN业务来规 划 QoS- VPN业务的容量， 包括拓朴， 路由， 带宽等。 此后进入步驟 110, 配置 VPN-逻辑承载网 （Logical Bearer
NetWork, 简称 "LBN" )。 根据容量规划的结果， 使用 MPLS技术在基 础 IP网络中预配置一个 LBN给 QoS-VPN单独使用， 对于 QoS-VPN业 务流， 其路由选择， 资源分配， 允许控制和标签转发仅在 VPN- LBN 中处理， 对于没有 QoS需求的 VPN业务流， 在基础网络中没有预配置 的部分资源中根据现存的 VPN机制进行路由和转发。 此后进入步驟 120, 部署 VPN-集中式资源控制器（Centralized Resource Controler, 简称 "CRC" )。 在 VPN- LBN中的每个域中部署 一个 VPN- CRC, —般是和 VPN的数据平面设备分离， VPN-CRC 负责 VPN站点之间的资源计算， 接入控制， 资源分配， 路由选择， 将表示 路由的 MPLS标签栈下发给入口 PE, 并为每个 QoS- VPN维护成员关系 信息， 访问关系信息， 并处理必要的信令。 之所以在每一个域部署一 个 CRC是因为如果只部署一个全局 CRC, 则当网络巨大时需要协调的 信息太多。 域是运营商自己划分的逻辑区域， 例如一个省或一个市， 可以根据 CRC的实际处理能力来决定域的范围大小。 上述实施例中， QoS-VPN网络的拓朴和带宽是静态分配的， 在本 发明的另一个较佳实施例中， 使用 MPLS 流量工程 （ Traff i c Eng i neer ing , 简称 " TE" )技术来动态调整 VPN- LBN拓朴和带宽， 以 进行 LSP的保护或容量变更。 此后进入步骤 130 , VPN- CRC计算并下发站点之间访问路径。 因 为 VPN- LBN中所有的可用资源信息以及 QoS- VPN中的成员关系信息和 访问关系信息都记录在 VPN-CRC中，因此 YPN-CRC可以才艮据这些信息 为每一对有 QoS 需求的站点计算访问路径， 并且把路径下发到各个 PE中， 由 PE来具体执行。 因为有这种处理方式， 因此每一对有 QoS 需求的站点之间的路径都是唯一确定的。 此后进入步骤 140， 标记业务优先级并通过 VPN - LBN传输。 在 每个 QoS-VPN中， 虽然两个站点之间的所有业务的路由完全相同， 但 这些业务流仍可以分为不同类型， 如语音， 视频， 数据， 这些业务类 型可以在入口 PE识别并标记不同的优先级，在入口 PE对这些不同优 先级的数据流进行 MPLS封装时， 将优先级映射到 VPN- CRC下发给入 口 PE的表示路由信息的标签栈中的所有标签的 EXP (因为标签栈的 标签在沿着这些路由转发时要进行弹出操作，所有标签的 EXP设置相 同将可以保留业务流的优先级信息）， 这样在 VPN- CRC确定了两个站 点之间业务的路由和带宽后， 其中不同的业务等级可以通过 MPLS-Di ffServ (区别服务模式）进行转发， 保证各自的时延 /抖动 / 包丟失等要求， 从而保证 VPN的 QoS. 需要说明的是， 对于混合 QoS- VPN， 可以将其分成两部分， 一部 分由具有 QoS要求的站点组成， 上述机制可以应用于这部分， 另一部 分由没有 QoS要求的站点组成， 遵循已有的 VPN机制。 即： 在接收到 业务时， 需判断业务的收、 发站点是否都有服务质量需求， 如果是则 使用逻辑承载网内的资源传输该业务， 否则使用所述基础 IP 网络的 其他资源传输该业务。 并且， 在对业务的收、 发站点进行是否都有服 务廣量需求的判断前还包括以下子步驟： 比较所述收、发站点的路由 目标， 判断所述收、 发站点是否为普通访问关系， 如果是则进入后续 步骤， 否则结束。 其中， 判断业务的收、发站点是否都有服务质量需求是通过以下 方式来判断的： 通过比较所述收、 发站点的路由目标， 判断所述收、 发站点是否为有服务质量需求的访问关系， 若是， 则业务的收、 发站 点都有服务质量需求， 否则， 业务的收、 发站点未有服务质量需求。 下面结合图 4说明 QoS _ VPN的总体框架。 在本发明的一个较佳实施例中， QoS-VPN框架分为两个层次： 逻 辑承载网 ( log ica l bearer layer , 也可以成为還辑承载层）， 承载 控制网 （bearer control layer )。 逻辑承载层是使用 MPLS技术根据 预先的容量规划通过配置预留带宽的 LSP连接 PE, CR, ITR形成的。 承载控制网由若干个 VPN-CRC组成， 每个域配置有一个 VPN- CRC (不包括 VPN-CRC的备份）， YPN-CRC管理 VPN-LB 的网络资源 (包 括带宽， 处理器， 緩冲区）， 维护 VPN- LBN的网络拓朴， 进行资源计 算， 路由选择， 给 PE发送路由指示， 在 VPN-LBN内分配资源， 接入 控制， 并为每个 QoS-VPN维护成员关系信息表， 连接关系信息表和相 关的信令以便实现成员关系自动发现和单边配置。 下面介绍 VPN - LBN的划分方式。 为保证 QoS- VPN网络可靠传送，有必要将 QoS- VPN业务和尽力转 发 （Bes t effor t ) 业务（包括没有 QoS 需求的 VPN 业务以及普通 Interne t业务）在资源分配和路由方面分开， QoS-VPN的资源在预配 置的 VPN- LBN中分配并通过 VPN-CRC选择显式路由， 而 Be s t effor t 的 VPN业务仍然在剩下的没有分配的网络资源中遵循传统的 VPN机制 进行路由和转发。 如图 5表示， VPN-LBN由 PE、 ITR、 CR以及连接这些路由器的 LSP 组成， LSP可以静态配置或著根据容量规划和流量测量数据动态建立。
• 为进行 LSP的保护或者容量的改变， MPLS TE如快速重路由（ Fas t Reroute , 筒称 " FRR" )等技术可以用于动态调整 LSP带宽， 并维护 VPN- LBN拓朴。 当 QoS- VPN 的本地站点到远端站点的业务请求从 PE 传送到
VPN-CRC , 才 据用户和运营商之间的服务水平协议 （Serv i ce Leve l Agreement , 筒称 "SLA" )确定的相应的 QoS需求也随着该业务请求 传送到 VPN- CRC , VPN-CRC (如有必要， 需要 VPN承载控制网中其他 VPN-CRC的参与 )根据网络资源情况确定是否允许接入， 如果允许接 入， VPN-CRC将计算能够满足 QoS要求的路由， 并将路由信息发送给 入口 PE ,路由信息是一个代表一组从入口 PE到出口 PE的串联的 LSP， 入口 PE将记录这些路由信息和所属的 QoS-VPN (通过 VPN- ID)和本地 站点与远端站点（通过站点 ID )， 所有属于该 QoS- VPN和本地站点到 远端站点的业务都通过该路由进行转发， 除非入口 PE收到另外的路 由指示。 入口 PE 从接口或子接口等相关信息识别 QoS-VPN， 当一个 QoS-VPN业务流进入网络后， 入口 PE获得流描述信息（通常包括源 地址， 源端口， 目的地址， 目的端口， 协议类型）， 然后将包 /帧用 VPN- CRC指示的标签栈进行封装， 对不同的数据类型 （语音 /视频 /数 据） 为标签栈中所有的标签设置不同的 EXP位组， 并将数据包 /帧引 入 VPN- LBN , 当数据流在路由上的 ITR 中传送时， 均遵循 DiffServ- aware MPLS技术。 下面详细介绍本发明方案中最重要的设备一一 YPN - CRC。
VPN承载控制网由各域中的 VPN- CRC组成， 是 VPN承载层的控制 平面和管理平面， 在本发明的一个较佳实施例中， 'VPN- CRC应该具有 如下功能： 域内资源计算， 路由选择， 允许控制， 域间资源请求， 网 络拓朴维护， 成员关系信息维护， 访问关系信息维护和自动发现， 单 边配置的信令等。 而且， VPN- CRC可以支持策略管理， SLA管理， LSP 流量测量， 以及和认证、 授权和记帐服务器 （ Authentication Authorization and Accounting Server, 筒称 "AAA Server" ) 的接 口。
VPN- CRC的内部结构及对外连接关系如图 6所示。 VPN - CRC 10 主要包含以下模块： 接口管理模块 111 ,用于实现并管理和外部设备进行通信的接口。 例如与上游的 VPN-CRC 20、 下游的 VPN- CRC 30、 ITR 40以及 ER 50 的通信。 这些通信涉及到的协议将在下文中说明。 系统功能模块 112, 用于提供支承整个 VPN - CRC 10正常运行的 底层平台。 在本发明的一个较佳实施例中， 该系统功能模块 112 是 VPN -CRC 10中的操作系统。 协议处理模块 113， 用于对 VPN -CRC 10与各种外部设备通信的 协议进行处理。并根据协议要求将通信数据转发给成员关系维护模块 114、 拓朴和资源管理模块 115、 路由管理模块 116和自动发现信令 模块 117, 协议处理模块 113通过接口管理模块 111收发通信数据。 成员关系维护模块 114， 用于维护成员关系信息表和访问关系信 息表。 成员关系信息表 ( membershi information table )是包含属 于同一 QoS-VPN的站点成员的信息，该表是同一 QoS-VPN中的站点 ID 的列表， 通过 VPN- ID 索引。 访问关系信息表 ( connect ivi ty informa t ion tabl e ) 包含同一 QoS- VPN的成员之间的访问关系, 即 一个站点能够访问哪一些其他站点，该表可以通过成员信息表和每个 站点的 Route Target s (路由目标）得到， 如果同一个 QoS-VPN中的 一个站点的 expor t Route Target (输出路由目标）和另一个站点的 impor t Route Target (输入路由目标）相同， 则这两个站点之间存 在访问关系。 在 VPN-CRC 10进行允许控制时， 需要参考访问关系信 息表。 通过访问关系信息表， QoS-VPN 站点之间可以组建全网状、 Hub-Spoke或者其它拓朴关系。 拓朴和资源管理模块 115 , 用于管理 VPN - LBN的拓朴关系和资 源。 拓朴关系是 VPN - LBN中各个节点的连接关系， 资源主要是指这 些连接关系上预留的带宽。 VPN- LBN的拓朴和资源的记录和维护独立 于基础网络， VPN- LBN的初始资源数据需要根据容量规划的结果手工 配置。 路由管理模块 116 , 用于统一管理所有 QoS-VPN的路由关系。 自动发现信令模块 117， 用于变更的自动发现。 自动发现是指访 问关系信息并非人为配置在 VPN - CRC 10 中， 而是由外部设备（如 PE ) 自动提供的。 当自动发现信令模块 117得到的信息中包括了成员 关系或者 LBN拓朴关系的变化，则自动发现信令模块 117将通知成员 关系维护模块 114或拓朴和资源管理模块 115进行相应的修改。 为维护和传送 QoS- VPN 的访问关系信息， VPN- CRC 需要维护 QoS- VPN成员之间的访问关系， 即 QoS-VPN站点的拓朴， 这可以通过 (当然不限于）记录每个 QoS- VPN的两个 s i te列表来实现， 一个是 允许发送的站点列表， 一个是允许接收的站点列表。 为支持 QoS- VPN 成员关系和访问关系信息的修改的自动发现， 在增加或删除 QoS-VPN 中的站点时， 相关的更新消息应该在 PE和 VPN-CRC之间传送， 涉及 到的 VPN-CRC应该更新成员信息表和访问关系信息表。 通过这种机 制， 可以实现单边配置， 即在 QoS-VPN站点增加或删除时或者站点之 间的访问关系发生变化时，只需要对站点增删或者访问关系变化的一 个站点的 PE上进行配置，这些配置将触发更新消息在相关的 VPN- CRC 和 PE上自动传送，接收到更新消息的 VPN- CRC将更新对应的 QoS-VPN 成员关系信息表和访问关系信息表。 在增加 QoS- VPN站点时， 业务请求（包括 VPN-ID, 本地站点 ID, -远端站点 ID, QoS要求）将传递到本域 VPN-CRC, VPN- CRC (如果必 须，需要相关 VPN-CRC参与）将为增加的站点访问其它站点计算资源， 如果允许这些站点的增加， 将计算这些新增站点访问其它站点的路 由， 并将路由指示给相关 ΡΕ, 这些 ΡΕ更新它们的 QoS-路由信息表， 当远端 PE感知到这些站点的增加， 将触发它们自己的本地站点访问 这些新增站点的业务请求， VPN承载控制网将执行相同处理， 最后所 有站点将得知相互访问的路由信息。 在删除站点时， VPN- CRC除了更新相关的成员关系信息表和访问 关系信息表外， 将释放和删除的站点相关的资源， 并通知相关 PE删 除 QoS路由信息表中相关条目， 当远端 PE感知到站点的删除， 将触 发它们关于自己的本地站点访问这些已删除站点的资源删除。 拓朴和资源表 118， 用于存储 VPN - LBN的拓朴关系和资源。 路由表 119 , 用于存储 QoS_VPN的路由 （实质上是各个站点可被 访问的目的地址集合）。 该目的地址集合由若干个地址前缀或地址组 成。
VPN-CRC从本域入口 PE的业务请求（包括 VPN- ID,本端站点 ID, 远端站点 ID, QoS要求）或者其它 VPN-CRC的资源请求时， 将进行 资源计算， 路由选择和允许控制（如果需要， 还要将资源请求传送到 下游 VPN- CRC ), 如果其中涉及到的某个 VPN- CRC资源计算的结果是 "拒绝 ，，， 需要将该响应一直向上游 VPN-CRC 传送， 直到到达入口 PE。 否则， 需要将本 VPN- CRC确定的路由信息向上游传送， 直到将全 程的路由信息 （标签栈）发送给入口 PE。 入口在转发从本端站点到 远端站点的数据时，根据 CE到 PE的业务流的描述设置标签栈中所有 标签的 EXP位组， 这样， 从本端站点到远端站点的业务都从上述计算 的路由上传送， 但相同方向不同类型的业务通过 EXP位组区分， 按照 MPLS-Di ffServ机制传送。 下面说明对图 4中 VPN承载层中的 PE、 ITR和 CR的功能需求。 PE应该支持静态 LSP 配置或者通过 CR-LDP/RSVP- TE动态建立
LSP以便实现预配置以及 VPN-LBN的动态调整，而且应该支持流分类， 以便能为从 VPN-CRC接收到的标签栈设置 EXP位组。 PE中保存了 QoS 路由信息表， 该表主要保存了以下信息： VPN - ID , 本地站点， 远端 站点 （远端站点中可以访问的目的地址集合）， 本地站点和远端站点 之间的路由。 当从 VPN-CRC接收到允许控制响应， 如果响应是 "允许接入"， 路由和 QoS信息将包含在内， 入口 PE在 QoS信息表中将记录这些信 息， 它为每个 QoS- VPN分别维护这些信息， 根据 VPN- ID索引， 在每 个 QoS- VPN的信息中，为每个站点对（一个本地站点到一个远端站点） 记录一个条目， 根据 QoS路由信息表， 入口 PE进行队列， 调度， 整 形， 标记， 策略， MPLS封装， 然后在 VPN- LBN中才艮据标签栈确定的 路由进行转发。 中间传送路由器 ITR 应该支持静态 LSP 配置或者通过 CR-LDP/RSVP-TE动态建立 LSP以便实现预配置以及 VPN-LBN的动态 调整， 而且应该支持 Di ffServ- aware MPLS和按类型处理流。 IP 骨干网络中的核心路由器 CR 只需要支持 Di ffServ- aware MPLS和按类型处理流。 下面说明借助 VPN地址进行 QoS - VPN之间隔离的方法。
VP 地址可以由 VPN-LBN中全局唯一的 VPN-ID和 L3/L2/L1 VPN 相关的私有地址组成， 如， L3 VPN中的 IPV4/IPV6/IPX地址， L2 VPN 中的数据链路地址， L1VPN中的交叉连接标识， 在这种 VPN地址方案 中，不同 QoS-VPN中各站点的地址可以重叠， 由于 VPN-ID在 VPN-LBN 中全局唯一， 组成的 VPN地址也将在 VPN-LBN内唯一。
QoS路由信息表可以通过 VPN-ID区分不同 QoS- VPN的信息， 从 而实现 QoS-VPN之间的隔离。 下面说明路由和转发的方法。
QoS- VPN路由在 PE的 QoS路由信息表中维护，其粒度是 QoS- VPN 的站点对，即一个本地站点到一个远端站点之间的所有业务的路由相 同， 在入口 PE的路由查找是分为两级的， 第一级根据不同 VPN- ID索 引 ,找到与本地站点所属的 QoS-VPN,第二级查找搜索针对该 QoS-VPN 中的本地站点和远端站点对，和远端站点关联的是远端站点中的聚合 地址， 当业务流中的目的地址和站点对中与远端站点关联的聚合地址 匹配时， 认为搜索成功。 在两级查找成功后， 入口 PE为该业务流确 定路由信息（VPN- CRC指定的 MPLS标签栈）， 并标记路由信息标签中 的 EXP位组。 如果， 两级查找之一失败， 则入口 PE可以拒绝该业务 流。
QoS-VPN转发基于 MPLS技术， 使用 VPN- CRC下发的标签栈和入 口 PE为业务流设置的 EXP位組， 根据外层标签采用 MPLS-DiffServ 机制， 保证了业务带宽和转发优先级， 从而保证了 QoS- VPN的服务质 量（带宽， 时延， 抖动， 丢包率）。 下面说明各个设备之间的接口和信令需求， 包括 PE和 CE之间、 VPN-CRC和运营商路由器（包括 PE， ITR, CR )之间 , VPN- CRC和 VPN-CRC 之间的接口和协议。
PE和 CE之间的接口传送用户信息， 如拓朴， CE连接的站点的聚 合的私有地址 (如 L3VPN中的私有 IPv4/ IPv6/IP 地址， L2VPN中的 数据链路地址， L1VPN中的交叉连接标识；)， 业务请求（包括流标识）。
VPN-CRC和 PE之间的接口允许 VPN- CRC指示 PE处理每个站点的 业务流， 有必要为该借口规定相应的协议， 可以在 COPS基础上根据 本文中的结构扩展。 该协议需要支持如下功能：
(1) 入口 PE向 VPN- CRC发送业务请求（包括 VPN- ID， 本地站点 ID, expor t Route Target , 远端站点 ID， QoS要求）， QoS要求包括 业务类型及其带宽， 优先级， 时延， 抖动限制， ^失率限制， MTU等， 它根据用户和运营商之间的 SLA确定针对每个站点的服务质量要求。 (2) VPN- CRC根据业务请求中的站点 ID和 expor t Route Target 确定本地站点和远端站点之间是否存在访问关系 （ VPN-CRC需要将业 务请求信息传递到相关的 VPN- CRC和出口 PE ), 在存在访问关系时， 无论 VPN承载控制网的允许控制结果是 "拒绝" 或 "接受"， 都将该 结果通知入口 PE。 (3) 在允许控制 "允许"时， VPN-CRC将关于该站点对的路由（表 示一组串联 LSP的标签栈）通知给入口 PE， PE在 QoS路由信息表中为 每个 QoS- VPN的每个站点对创建该记录。
(4) 在为 QoS-VPN中增加或删除站点时，或者站点间的访问关系 变化时， 变化发生站点对应的 PE应向本域 VPN-CRC发送更新消息， VPN-CRC向相邻 VPN- CRC传递该消息， 最终发送给对端 PE, 相关的 VPN-CRC将更新成员关系信息表和访问关系信息表， 相关的 PE将更 新 QoS路由信息表中的相应表项。
(5) PE将它所连接站点的聚合 YPN地址信息发送给 VPN-CRC, VPN-CRC在 VPN承载控制网中发布， 并最终发布给相关的 PE, 该功能 可以通过 T展现有的 BGP协议实现， 最后， 所有 PE将在 QoS路由信 息表中保存它所接入的 QoS- VPN各站点的聚合 VPN地址， 当 PE收到 业务流时， 可以 居 QoS路由信息表和流标识确定路由和 EXP位组。 而且， VPN-CRC和域内 PE, ITR, CR之间的接口应该支持如下功
A匕 .
fi ! (1) 允许 VPN- CRC为每种业务类别配置 MPLS DiffServ PHB。
(2) 允许 PE/ITR/CR等路由器向 VPN-CRC报告 LSP状态， 当链路 或路由器发生故障时， 路由器将向本域 VPN- CRC上报， VPN- CRC将这 些故障信息在 VPN承载控制网中发布，这些 VPN - CRC重新为它们预留 的路由计算资源， 当一些路由需要更新时， VPN-CRC应该将新路由发 送给相关入口 PE。
VPN-CRC之间的接口用于实现跨域的 QoS-VPN站点之间业务的资 源分配和路由选择。 有必要为该接口定义单独的协议， 可以对 C0PS或者 BGP进行扩 展来完成相应的功能。 该协议需要支持如下功能：
(1)允许 VPN- CRC向下游 VPN- CRC申请为跨域 QoS- VPN站点之间 的业务分配承载资源。
(2)允许 VPN- CRC将域间的 QoS-VPN业务标识信息（本地站点 ID， 远端站点 ID, VPN-ID )通知给下游 VPN- CRC。 (3)允许 VPN- CRC将 域间的 QoS-VPN业务的 QoS需求（包括业务 类型及其带宽， 优先级， 时延限制， 抖动限制， 丟失率限制等）通知 给下游 VPN- CRC。
(4)允许 VPN- CRC请求相邻的 VPN译放为域间的 QoS- VPN业务分 配的承载资源。
(5)允许 VPN- CRC向其它 VPN- CRC查询它为域间 QoS-VPN业务的 资源分配状态。
(6)允许 VPN-CRC向其他 VPN-CRC通知查询响应。
(7)允许 VPN-CRC 和其他 VPN- CRC 交换域间业务等级规格 ( servi ce leve l specif icat ion, 简称 "SLS" )和路由信息。 下面讨论混合 QoS- VPN的情况。 在某些情况下， VPN的一些站点有 QoS要求，而其他站点没有 QoS 要求， 这种 VPN称为混合 QoS- VPN。 混合 QoS- VPN可以分为两部分， 一部分由那些有 QoS要求的站点组成， 称为 sub- QoS-VPN, 另一部分 由那些没有 QoS要求的站点组成， 称为 sub- VPN。对于 sub_QoS- VPN, 其 QoS保证可以采用上述集中资源控制保证 QoS的 MPLS NBVPN方案, 对于 sub- VPN，仍然遵循 IETF L3YPN/L2VP 工作组的相关 RFC和 draf t 来实现。 Route Target 用于确定整个 VPN (包括 sub-QoS-VPN 和 sub-VPN )的访问关系，可以釆用 VPN-CRC来确定，另外引入 QoS Route Target (有 QoS需求的路由目标）来维护 sub-QoS- VPN的访问关系信息 表， QoS Route Target s和 Route Target s格式相同， 比较了 Route Target确定站点之间的普通访问关系后，继续比较 QoS Route Target (如果两个站点之一的业务请求中存在）， 如果比较通过， 则这两个 站点之间的业务具有 QoS要求， 这两个站点都属于 sub- QoS- VPN。 否 则将它们归为 sub- VPN。 下面讨论域内 QoS_VPN和域间 QoS-VPN的情况。 域内 QoS-VPN路由选择和域间路由是资源管理和允许控制的基 础。
VPN-CRC通过在拓朴信息表和资源信息表中进行域内路由选择， 路由选择的算法可以是固定的， 例如时间相关路由 （Time Dependen t Rout ing , 简称 "TDR" ) /状态相关路由 ( S ta te Dependent Rout ing , 筒称 "SDR" )。 而且， VPN- CRC 中应该维护一个域间路由表用于通过 QoS信令协议确定域间 LSP， 以发现相邻的下游 VPN- CRC。
VPN-CRC的域间路由表可以手工配置或运行动态路由协议自动产 生。 下面讨论跨不同网络提供商如何提供 QoS-VPN。 ' 为了在不同提供商的网络中支持 QoS-VPN, 他们的自治系统边界 路由器 ( Autonomous Sys tem Boundary Router , 简称 "ASBR" )应该 互通以传送 VPN业务请求信令和 VPN业务。 如果双方网络都部署了 VPN-CRC, 他们的 VPN- CRC可以互通， 此时， 这些 VPN- CRC之间仅交 换和映射网间 SLA， 此时， VPN- CRC仅管理网内链路资源， ASBR通过 规定的 SLA管理网间链路资源，完成运营商内部 QoS- VPN情况下的入 口 PE的功能， 如果其中一个网络运营商没有部署 VPN- CRC , 而是釆 用了其他的 QoS机制， 两个 ASBR应该相互映射 QoS需求，则最终 QoS 保证的程度将依赖于其他网络提供商的 VPN QoS实现机制。
虽然通过参照本发明的某些优选实施例， 已经对本发明进行了图示和 描述， 但本领域的普通技术人员应该明白， 可以在形式上和细节上对 其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精 神和范围。

Claims

权 利 要 求
1. 一种虛拟专用网中保证服务质量的系统， 其特征在于， 包含： 逻辑承载网， 使用多协议标签交换技术通过在基础 IP网络中配 置预留带宽的标签交换路径连接各种路由器而形成，专用于传输有服 务质量需求的业务； 承载控制网， 用于对所述逻辑承载网进行维护， 为所述业务分配 所述路由，以及将该业务的优先级标记到封装到该业务数据流的多协 议标签交换数据包的路由标签的服务质量字段中，并按照所述分配的 路由， 使所述业务通过所述逻辑承载网路由到需发送的对端。
2. 根据权利要求 1所述的虛拟专用网中保证服务质量的系统， 其特征在于， 所述承载控制网包含集中式资源控制器， 用.于管理所述 逻辑承载网的网络资源， 维护所述逻辑承载网的网络拓朴， 进行资源 计算和业务路由选择， 为所述路由器发送业务路由指示， 在所述逻辑 承载网内分配资源并进行接入控制，为每一个所述虚拟专用网维护成 员关系信息和连接关系信息， 实现成员关系的自动发现和单边配置。
3. 根据权利要求 2所述的虛拟专用网中保证服务质量的系统， 其特征在于，所述集中式资源控制器在所述逻辑承载网的每一个域中 部署一个， 各个所述集中式资源控制器相互连接， 交流所述逻辑承载 网的拓朴、 资源信息以及所述虚拟专用网的路由信息。
4. 根据权利要求 1所述的虛拟专用网中保证服务质量的系统， 其特征在于，所述逻辑承载网和所述承载控制网通过带外的方式发布 所述虛拟专用网的路由、 维护所述虛拟专用网的成员关系、 维护所述 虛拟专用网各站点之间的访问关系。
5. 根据权利要求 2所述的虚拟专用网中保证服务质量的系统， 其特征在于， 所述各种路由器包括骨干网边缘路由器、 中间转接路由 器与核心路由器， 其中： 所述骨干网边缘路由器： 用于识别有服务质量需求的虛拟专用 网，并对从该虚拟专用网进入的有服务质量需求的业务用所述集中式 资源控制器指示的标签栈进行封装，然后根据该业务的优先级设置所 述标签栈中所有标签的服务盾量字段，将封装好的业务数据包通过所 述逻辑承载网传输； 所述中间转接路由器： 用于标签交换路径的静态或动态配置、 以 及区别服务模式的多协议标签交换和按类型处理流； 所述核心路由器：用于区别服务模式的多协议标签交换和按类型 处理流。
6. 根据权利要求 2所述的虚拟专用网中保证服务质量的系统， 其特征在于， 所述集中式资源控制器包含接口管理模块、 协议处理模 块、 成员关系维护模块、 拓朴和资源管理模块、 路由管理模块和自动 发现信令模块， 其中： 所述接口管理模块用于实现并管理虚拟专用网和外部设备进行 通信的接口；
. 所述协议处理模块用于对所述集中式资源控制器与各种外部设 备通信的协议进行处理，并根据协议要求将通信数据转发给所述成员 关系维护模块、拓朴和资源管理模块、路由管理模块和自动发现信令 模块， 所述协议处理模块通过所述接口管理模块收发通信数据； 所述成员关系维护模块用于维护所述虚拟专用网的成员关系信 息和所述虚拟专用网站点间访问关系信息； 所述拓朴和资源管理模块用于管理所述逻辑承载网的拓朴关系 和资源； 所迷路由管理模块用于管理所述虛拟专用网的路由关系； 所迷自动发现信令模块用于变更的自动发现，并通知所述成员关 系维护模块、 所述拓朴和资源管理模块修正相应的信息。
7. 一种虛拟专用网中保证服务质量的方法， 其特征在于， 包含 以下步骤：
A 在基 IP网络中， 使用多协议标签交换技术通过配置预留带 宽的标签交换路径构造逻辑承载网，该逻辑承载网专用于传输有服务 质量需求的业务；
B 部署用于集中管理所述逻辑 载网资源的集中式资源控制器；
C 需要传输有服务质量需求的业务时，将该业务的优先级标记到 封装该业务数据流的多协议标签交换数据包的路由标签栈的服务质 量字段中， 按照所述集中式资源控制器分配的路由， 通过所述逻辑承 载网路由到需发送的对端。
8. 根据权利要求 7所述的虚拟专用网中保证服务质量的方法， 其特征在于， 步骤 B和步骤 C之间还包括： 集中式资源控制器计算并 下发站点之间的访问路至虛拟专用网的路由器，以便所述路由器保存 集中式资源控制器分配的路由。
9. 根据权利要求 7所述的虚拟专用网中保证服务质量的方法， 其特征在于， 所述路由是由标签栈确定的串行标签交换路径。
10. 根据权利要求 7所述的虛拟专用网中保证服务质量的方法， 其特征在于， 所述步驟 C中， 对所述业务路由标签栈中全部标签的服 务质量字段设置相同的数值。
11. 根据权利要求 7所述的虚拟专用网中保证服务质量的方法， 其特征在于， 所述方法还包括： 使用多协议标签交换流量工程技术动 态调整所述逻辑承载网的拓朴和资源。
12. 根据权利要求 7所述的虛拟专用网中保证服务质量的方法， 其特征在于， 在所述步骤 C中， 所述业务的优先级是由所述业务的类 型确定的。
13. 根据权利要求 Ί所述的虛拟专用网中保证服务质量的方法, 其特征在于还包括以下步驟： 判断业务的收、发站点是否都有服务质量需求， 如果是则使用逻 辑承载网内的资源传输该业务， 否则使用所述基础 IP网络的其他资 源传输该业务。
14.根据权利要求 13所述的虛拟专用网中保证服务质量的方法， 其特征在于， 在对业务的收、发站点进行是否都有服务质量需求的判 断前还包括以下子步骤： 比较所述收、 发站点的路由目标， 判断所述收、 发站点是否为普 通访问关系， 如果是则进入后续步骤， 否则结束。
15、 如权利要求 13所述的虛拟专用网中保证服务质量的方法， 其特征在于， 判断业务的收、 发站点是否都有服务质量需求是通过以 下方式来判断的：通过比较所述收、发站点的路由目标，判断所述收、 发站点是否为有服务质量需求的访问关系， 若是， 则业务的收、 发站 点都有服务质量需求， 否则， 业务的收、 发站点未有服务质量需求。。
16. 根据权利要求 7所述的虛拟专用网中保证服务质量的方法， 其特征在于，所述集中式资源控制器为每一对有服务质量需求的站点 分配的路由唯一。
PCT/CN2005/000037 2004-01-20 2005-01-12 Systeme et procede permettant d'assurer une qualite de service dans un reseau virtuel prive WO2005101730A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP05700411A EP1708408B2 (en) 2004-01-20 2005-01-12 A system and method of ensuring quality of service in virtual private network
JP2006549833A JP4531063B2 (ja) 2004-01-20 2005-01-12 仮想私設網においてサービス品質を保証するためのシステムおよびその方法
DE200560013188 DE602005013188D1 (de) 2004-01-20 2005-01-12 System und verfahren zur sicherstellung der dienstqualität in einem virtuellen privaten netzwerk
US10/586,604 US7650637B2 (en) 2004-01-20 2005-01-12 System for ensuring quality of service in a virtual private network and method thereof

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB200410002614XA CN100384172C (zh) 2004-01-20 2004-01-20 基于网络的虚拟专用网中保证服务质量的系统及其方法
CN200410002614.X 2004-01-20

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US10/587,707 A-371-Of-International US7832410B2 (en) 2004-04-14 2005-03-18 Electronic atomization cigarette
US11/587,707 A-371-Of-International US20070246120A1 (en) 2004-05-06 2005-04-27 Multi-Layer Oversewn System
US12/944,123 Continuation US8393331B2 (en) 2004-04-14 2010-11-11 Electronic atomization cigarette

Publications (1)

Publication Number Publication Date
WO2005101730A1 true WO2005101730A1 (fr) 2005-10-27

Family

ID=34867405

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/000037 WO2005101730A1 (fr) 2004-01-20 2005-01-12 Systeme et procede permettant d'assurer une qualite de service dans un reseau virtuel prive

Country Status (7)

Country Link
US (1) US7650637B2 (zh)
EP (1) EP1708408B2 (zh)
JP (1) JP4531063B2 (zh)
CN (1) CN100384172C (zh)
AT (1) ATE425616T1 (zh)
DE (1) DE602005013188D1 (zh)
WO (1) WO2005101730A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1811728A1 (en) * 2006-01-18 2007-07-25 Huawei Technologies Co., Ltd. Method, system and device of traffic management in a multi-protocol label switching network
WO2007124251A1 (en) * 2006-04-20 2007-11-01 At & T Knowledge Ventures, L.P. Method for updating a virtual private network in a multi-protocol label switching network
CN103686445A (zh) * 2013-12-03 2014-03-26 浙江宇视科技有限公司 一种视频监控网络中Qos动态调整方法和装置
EP2003821B2 (en) † 2006-04-26 2020-04-15 Huawei Technologies Co., Ltd. A strategic provider edge router
CN114205295A (zh) * 2017-12-06 2022-03-18 华为技术有限公司 在计算机网络中建立虚拟网络路由

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10511573B2 (en) * 1998-10-30 2019-12-17 Virnetx, Inc. Agile network protocol for secure communications using secure domain names
KR100693059B1 (ko) * 2005-01-24 2007-03-12 삼성전자주식회사 Ｍｐｌｓ 기반의 ｖｐｎ 제공 장치 및 방법
US20060174035A1 (en) * 2005-01-28 2006-08-03 At&T Corp. System, device, & method for applying COS policies
US8179902B2 (en) * 2005-07-15 2012-05-15 Cisco Technology, Inc. Method and system for automatic generation of route distinguishers for virtual private networks
CN1913523A (zh) 2005-08-09 2007-02-14 华为技术有限公司 实现层级化虚拟私有交换业务的方法
CN100514912C (zh) * 2005-08-19 2009-07-15 华为技术有限公司 一种基于区分服务的Pipe模型实现方法
CN100450065C (zh) * 2005-09-09 2009-01-07 华为技术有限公司 一种提供虚拟专用网站点之间通信的方法
GB2438017A (en) * 2006-05-02 2007-11-14 Skype Ltd Controlling communication quality by generating instructions providing a remedy to users to improve communication quality
CN100596100C (zh) * 2006-08-29 2010-03-24 华为技术有限公司 实现多协议标签交换网络差分业务流量工程的方法和系统
US8422357B1 (en) * 2007-02-16 2013-04-16 Amdocs Software Systems Limited System, method, and computer program product for updating an inventory of network devices based on an unscheduled event
US8135013B2 (en) * 2007-04-06 2012-03-13 International Business Machines Corporation Internet protocol switch and use of the switch for switching a frame
US8144709B2 (en) * 2007-04-06 2012-03-27 International Business Machines Corporation Method, system and computer processing an IP packet, routing a structured data carrier, preventing broadcast storms, load-balancing and converting a full broadcast IP packet
US8705549B2 (en) * 2007-04-06 2014-04-22 International Business Machines Corporation Structure and implementation of universal virtual private networks
US8391185B2 (en) * 2007-05-29 2013-03-05 Cisco Technology, Inc. Method to transport bidir PIM over a multiprotocol label switched network
FR2920624B1 (fr) * 2007-09-03 2010-03-12 Alcatel Lucent Procede d'etablissement d'une connexion bidirectionnelle point a multipoint
CN101159656B (zh) * 2007-11-12 2011-05-11 华为技术有限公司 一种报文采样的方法、系统及设备
CN101471815B (zh) * 2007-12-27 2012-04-04 华为技术有限公司 一种服务承载网的配置方法和装置
US9455924B2 (en) 2008-01-02 2016-09-27 Media Network Services As Device and system for selective forwarding
CN101499970B (zh) * 2008-02-02 2012-12-12 迈普通信技术股份有限公司 Ip电信网中保证用户服务质量的带宽分配方法
US9112909B2 (en) * 2008-02-13 2015-08-18 Futurewei Technologies, Inc. User and device authentication in broadband networks
US20110032843A1 (en) 2008-04-10 2011-02-10 Oktavian Papp Setting up a virtual private network using virtual lan identifiers
JP4599429B2 (ja) * 2008-05-13 2010-12-15 日本電信電話株式会社 通信システム及び通信方法
US7925785B2 (en) * 2008-06-27 2011-04-12 Microsoft Corporation On-demand capacity management
US20090327460A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Application Request Routing and Load Balancing
CN101340374B (zh) * 2008-08-28 2011-01-19 杭州华三通信技术有限公司 控制传输优先级的方法、系统、装置和用户网络边缘设备
CN101355516B (zh) * 2008-09-09 2011-10-26 中兴通讯股份有限公司 一种为不同虚拟专用网提供服务质量策略的方法和系统
CN101677455A (zh) * 2008-09-19 2010-03-24 三星电子株式会社 协助网络寻找目的节点的方法
US7804781B2 (en) 2008-11-20 2010-09-28 At&T Intellectual Property I, L.P. Methods and apparatus to detect border gateway protocol session failures
US20100250747A1 (en) * 2009-03-31 2010-09-30 Jeyhan Karaoguz ADAPTIVE MULTIPLE PATHWAY SESSION SETUP TO SUPPORT QoS SERVICES
EP2249525B1 (en) * 2009-05-06 2012-10-31 Alcatel Lucent Traffic-engineered connection establishment across resource domains for data transport
WO2011079441A1 (zh) * 2009-12-30 2011-07-07 中兴通讯股份有限公司 多协议标签交换系统中网络拓扑的更新方法及系统
US8416775B2 (en) 2010-05-19 2013-04-09 Juniper Networks, Inc. Systems and methods for equal-cost multi-path virtual private LAN service
US9928483B2 (en) 2011-04-20 2018-03-27 Level 3 Communication, Llc Automated topology change detection and policy based provisioning and remediation in information technology systems
CN107071087B (zh) * 2011-08-17 2021-01-26 Nicira股份有限公司 逻辑l3路由
CN102377630A (zh) * 2011-10-13 2012-03-14 华为技术有限公司 基于流量工程隧道的虚拟专用网络实现方法及系统
EP2592808B1 (en) * 2011-11-14 2017-03-15 Alcatel Lucent Method and equipment for establishing a connection through a virtual private network
CN102546434B (zh) * 2012-02-15 2015-12-16 杭州华三通信技术有限公司 一种DVPN大规模组网的方法和Spoke
US9300570B2 (en) * 2012-05-22 2016-03-29 Harris Corporation Multi-tunnel virtual private network
CN103475581B (zh) * 2012-06-06 2017-08-25 华为技术有限公司 一种网络标签分配方法、设备与系统
US9438564B1 (en) * 2012-09-18 2016-09-06 Google Inc. Managing pooled VPN proxy servers by a central server
US9071514B1 (en) * 2012-12-17 2015-06-30 Juniper Networks, Inc. Application-specific connectivity loss detection for multicast virtual private networks
CN104054305A (zh) * 2012-12-26 2014-09-17 华为技术有限公司 一种ip数据包的发送方法及标签交换路由器
CN104168194B (zh) * 2013-05-15 2018-01-02 华为技术有限公司 集群网络路径控制方法、设备和集群网络系统
CN104219147B (zh) * 2013-06-05 2018-10-16 中兴通讯股份有限公司 边缘设备的vpn实现处理方法及装置
ES2530542B1 (es) * 2013-08-29 2015-12-09 Vodafone España, S.A.U. Sistema de comunicaciones, elemento de red y procedimiento para facilitar el encaminamiento de paquetes de datos
ES2530592B1 (es) * 2013-08-29 2015-12-09 Vodafone España, S.A.U. Sistema de comunicaciones, elementos de red y procedimiento para facilitar el encaminamiento de paquetes de datos
CN104579893A (zh) * 2013-10-18 2015-04-29 宇宙互联有限公司 传输路径控制系统
CN111654433B (zh) * 2015-07-31 2021-08-31 华为技术有限公司 路由规则的获取方法、设备和系统
CN105407045A (zh) * 2015-10-19 2016-03-16 国家电网公司 基于安全隔离的路由器虚拟化方法
CN106936713B (zh) * 2015-12-30 2020-02-21 华为技术有限公司 一种标签管理方法，数据流处理方法及设备
CN106454201B (zh) * 2016-09-13 2020-04-24 国网天津市电力公司 一种基于ims网络的视频会议接入服务质量保证方法
US10382396B2 (en) * 2016-12-28 2019-08-13 Mellanox Technologies, Ltd. Utilizing management network for secured configuration and platform management
US10673702B2 (en) * 2017-06-19 2020-06-02 Cisco Technology, Inc. Validation of layer 3 using virtual routing forwarding containers in a network
JP6805194B2 (ja) * 2018-02-15 2020-12-23 日本電信電話株式会社 経路情報転送装置、経路情報転送方法および経路情報転送プログラム
US10491715B1 (en) * 2019-01-11 2019-11-26 Architecture Technology Corporation IP packet translation to piggyback networking information
US11218569B1 (en) 2019-01-11 2022-01-04 Architecture Technology Corporation IP packet translation for low-overhead out-of-band data embedding
CN112737802B (zh) * 2019-10-28 2023-04-07 中盈优创资讯科技有限公司 互联网专线管理方法及系统
CN110932902A (zh) * 2019-11-29 2020-03-27 中国人民解放军国防科技大学 一种跨域交换资源动态分配方法
CN111565149B (zh) * 2020-04-03 2022-04-08 烽火通信科技股份有限公司 一种在ldp rlfa frr场景下远端会话保活的方法及装置
US11936522B2 (en) * 2020-10-14 2024-03-19 Connectify, Inc. Selecting and operating an optimal virtual private network among multiple virtual private networks
CN117278360B (zh) * 2023-11-22 2024-02-09 北京派网科技有限公司 基于虚拟专用网络的网络通信方法、装置以及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1321025A (zh) * 1999-12-27 2001-11-07 日本电气株式会社 使用ip－vpn功能的atm边缘节点交换设备
JP2002101126A (ja) * 2000-09-25 2002-04-05 Hitachi Ltd 通信方法
KR20030058028A (ko) * 2001-12-29 2003-07-07 엘지전자 주식회사 에이티엠 엠피엘에스 브이피엔 백본 망의 서비스 품질지원 방법

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6912232B1 (en) * 1998-10-19 2005-06-28 At&T Corp. Virtual private network
US6493349B1 (en) * 1998-11-13 2002-12-10 Nortel Networks Limited Extended internet protocol virtual private network architectures
US6363053B1 (en) * 1999-02-08 2002-03-26 3Com Corporation Method and apparatus for measurement-based conformance testing of service level agreements in networks
US6678264B1 (en) † 1999-06-30 2004-01-13 Nortel Networks Limited Establishing connections with a pre-specified quality of service across a communication network
US6882643B1 (en) * 1999-07-16 2005-04-19 Nortel Networks Limited Supporting multiple services in label switched networks
JP2001189754A (ja) * 1999-12-28 2001-07-10 Toshiba Corp ＱｏＳ提供方式、ルータ装置、ＱｏＳサーバ、ユーザ端末及びＱｏＳ提供方法
JP2001237876A (ja) * 2000-02-21 2001-08-31 Nec Corp Ｉｐ仮想プライベート網の構築方法及びｉｐ仮想プライベート網
JP3790655B2 (ja) * 2000-03-06 2006-06-28 富士通株式会社 ラベルスイッチネットワークシステム
ATE262244T1 (de) * 2000-04-13 2004-04-15 Operax Ab Netzoptimierungsmethode
JP3518483B2 (ja) * 2000-05-17 2004-04-12 日本電気株式会社 トラヒック識別条件検索シーケンス番号付与方法及びそのシステム並びに制御記録媒体
US6886043B1 (en) * 2000-06-28 2005-04-26 Nortel Networks Limited Communications network
US20020114274A1 (en) * 2000-09-19 2002-08-22 Sturges James H. Packet based network for supporting real time applications
EP1294202A1 (en) * 2001-09-18 2003-03-19 Lucent Technologies Inc. A method of sending data packets through a MPLS network, and a MPLS network
EP1331766A1 (en) † 2001-12-20 2003-07-30 Alcatel A telecommunications system employing virtual service network architecture
US20030204596A1 (en) * 2002-04-29 2003-10-30 Satyendra Yadav Application-based network quality of service provisioning
US7417950B2 (en) * 2003-02-03 2008-08-26 Ciena Corporation Method and apparatus for performing data flow ingress/egress admission control in a provider network
US8312145B2 (en) * 2003-12-22 2012-11-13 Rockstar Consortium US L.P. Traffic engineering and bandwidth management of bundled links

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1321025A (zh) * 1999-12-27 2001-11-07 日本电气株式会社 使用ip－vpn功能的atm边缘节点交换设备
JP2002101126A (ja) * 2000-09-25 2002-04-05 Hitachi Ltd 通信方法
KR20030058028A (ko) * 2001-12-29 2003-07-07 엘지전자 주식회사 에이티엠 엠피엘에스 브이피엔 백본 망의 서비스 품질지원 방법

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1811728A1 (en) * 2006-01-18 2007-07-25 Huawei Technologies Co., Ltd. Method, system and device of traffic management in a multi-protocol label switching network
WO2007124251A1 (en) * 2006-04-20 2007-11-01 At & T Knowledge Ventures, L.P. Method for updating a virtual private network in a multi-protocol label switching network
EP2003821B2 (en) † 2006-04-26 2020-04-15 Huawei Technologies Co., Ltd. A strategic provider edge router
CN103686445A (zh) * 2013-12-03 2014-03-26 浙江宇视科技有限公司 一种视频监控网络中Qos动态调整方法和装置
CN114205295A (zh) * 2017-12-06 2022-03-18 华为技术有限公司 在计算机网络中建立虚拟网络路由
CN114205295B (zh) * 2017-12-06 2023-06-06 华为技术有限公司 在计算机网络中建立虚拟网络路由

Also Published As

Publication number Publication date
JP2007519345A (ja) 2007-07-12
CN100384172C (zh) 2008-04-23
EP1708408A1 (en) 2006-10-04
US7650637B2 (en) 2010-01-19
CN1649320A (zh) 2005-08-03
EP1708408B1 (en) 2009-03-11
EP1708408B2 (en) 2012-05-23
US20080172732A1 (en) 2008-07-17
JP4531063B2 (ja) 2010-08-25
EP1708408A4 (en) 2007-02-14
DE602005013188D1 (de) 2009-04-23
ATE425616T1 (de) 2009-03-15

Similar Documents

Publication Publication Date Title
US7650637B2 (en) System for ensuring quality of service in a virtual private network and method thereof
KR102057980B1 (ko) 네트워크 서비스를 위한 경로 계산 요소 중앙 제어기(PCECCs)
US7733883B2 (en) Method for implementing a virtual leased line
US8493980B2 (en) Transport networks supporting virtual private networks, and configuring such networks
US8693323B1 (en) System and method for managing communications in an access network
KR100693059B1 (ko) Ｍｐｌｓ 기반의 ｖｐｎ 제공 장치 및 방법
US7283529B2 (en) Method and system for supporting a dedicated label switched path for a virtual private network over a label switched communication network
KR100496984B1 (ko) 레이블 분배 프로토콜의 확장을 이용한 ＱｏＳ지원 2계층가상 사설 망 양방향 터널 설정 및 구성정보 분배방법
EP1816789B1 (en) A method and system for controlling the selection of the transmitting path for the media flow in the next generation network
US20040165600A1 (en) Customer site bridged emulated LAN services via provider provisioned connections
EP1811728B1 (en) Method, system and device of traffic management in a multi-protocol label switching network
US7742477B1 (en) Interconnectivity between autonomous systems
WO2008011818A1 (fr) Procédé de fourniture d'un service réseau local privé virtuel à hiérarchie et système réseau
Cisco Configuring MPLS and VPN
Smith Introduction to MPLS
Joseph et al. Network convergence: Ethernet applications and next generation packet transport architectures

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005700411

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006549833

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 10586604

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 2005700411

Country of ref document: EP