WO2012013216A1 - Procédé, dispositif et système d'acheminement d'informations dans un réseau - Google Patents

Procédé, dispositif et système d'acheminement d'informations dans un réseau Download PDF

Info

Publication number
WO2012013216A1
WO2012013216A1 PCT/EP2010/060810 EP2010060810W WO2012013216A1 WO 2012013216 A1 WO2012013216 A1 WO 2012013216A1 EP 2010060810 W EP2010060810 W EP 2010060810W WO 2012013216 A1 WO2012013216 A1 WO 2012013216A1
Authority
WO
WIPO (PCT)
Prior art keywords
instance
path
layer
information
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2010/060810
Other languages
English (en)
Inventor
Claus Gruber
Franz Rambach
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Nokia Siemens Networks GmbH and Co KG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks GmbH and Co KG filed Critical Nokia Siemens Networks GmbH and Co KG
Priority to PCT/EP2010/060810 priority Critical patent/WO2012013216A1/fr
Publication of WO2012013216A1 publication Critical patent/WO2012013216A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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/02—Topology update or discovery
    • 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/64—Routing or path finding of packets in data switching networks using an overlay routing layer

Definitions

  • the invention relates to a method and to a device for convey ⁇ ing information in a network. Also, a communication system comprising at least one such device is suggested.
  • Telecommunication networks are constructed in a multi-layer fashion.
  • Network devices rely on the functionality of lower layer devices and provide additional features to upper layer devices.
  • Higher layer devices therefore have none or only an abstract view on the realization of a lower layer's function ⁇ nality (see ISO/OSI model) .
  • IP routers for example, are only aware of the (layer-3) net ⁇ work they participate in. Hence, such an IP router is aware of the layer-3 topology, costs and characteristics of
  • Enhancement processes are slow and require intricate re ⁇ quest/response mechanisms towards lower layers.
  • a client (upper) layer does not have detailed information about a server (lower) layer.
  • the client layer operates only on a virtual network topology, which is constructed from the links advertised by the server layer.
  • no optimized multi ⁇ layer paths can be computed by the client layer, wherein such optimized multi-layer path might use fewer resources compared to the non-optimized single layer path.
  • a single domain does not have the required information to compute an optimized path across multiple domains.
  • a single domain mere ⁇ ly has reachability information, i.e. it knows via which next hop a target domain can be reached.
  • no optimized mul ⁇ ti-domain path can be computed.
  • Multi-layer cooperation architectures are subject to IETF discussions using the approach of a Path Computation Elements (PCE) according to http : //en . wikipedia . org/wiki/Path_computation_element , http://www.rfc-editor.org/rfc/rfc4655.txt or http://www.rfc- editor .org/rfc/rfc5623.txt.
  • the Path Computation Element is defined by the Internet Engineering Task Force (IETF) in RFC 4655 as "an entity (component, application, or network node) that is capable of com ⁇ puting a network path or route based on a network graph and applying computational constraints".
  • a PCE is an entity capable of computing complex paths for a single or a set of services.
  • the PCE might be a network node, network management station, or dedicated computational platform which is aware of the network resources and has the ability to consider mul ⁇ tiple constraints for sophisticated path computation.
  • PCE ap- plications include computing Label Switched Paths for MPLS and GMPLS Traffic Engineering.
  • the PCE has information about its own layer or domain and se- veral PCEs may collaborate to compute an end-to-end path.
  • se- veral PCEs may collaborate to compute an end-to-end path.
  • different approa- ches exist:
  • a (first) PCE calculates and/or (re-) optimizes a path by combining information about already existing (own) topology (nodes and links) and network extensions (addi ⁇ tional links) .
  • network extensions include network extensions (addi ⁇ tional links) .
  • specific requests are sent to lower-layer PCEs in order to determine whether such a (not yet existing) link could be established.
  • the lower-layer PCEs can further process this request and send it to other PCEs.
  • the first PCE will be notified about the possibility to extend or realize the link requested.
  • such mechanism does not scale well in larger or (highly) meshed environments.
  • such re ⁇ quest/response polling mechanism may lead to a signifi ⁇ cant delay required for path computation purposes.
  • PCEs are arranged in a hierarchical fashion. If inter-domain routes are to be calculated, a domain PCE can request an inter-domain route from an inter-domain PCE . This inter-domain PCE is aware of the domains and their internal bypass route characteristics and can calculate the domain chain towards a remote des ⁇ tination without having to know the exact details of each domain. The inter-domain PCE responds to the domain PCE with the inter-domain chain information and the chain characteristics.
  • VNTM virtual network topology managers
  • PCE and VNTMs are distinct functional elements that may or may not be co-located.
  • VNT virtual network topology
  • VNTM entity is introduced for the PCE concept according to RFC 5623 and manages already established lower layer paths and therefore links in the higher layer. It can be triggered by the PCE to setup lower layer paths.
  • a first instance of the network determines a path information within a sphere of the first instance ;
  • the sphere of the first instance can be used by said first instance to determine said path information, e.g., determine at least one path across the network or a portion thereof.
  • path information is conveyed to the se ⁇ cond instance, which has no insight into the sphere of the first instance.
  • the first instance can be a topology adver ⁇ tiser, in particular a virtual topology advertiser (VTA) as will be described later.
  • VTA virtual topology advertiser
  • topology advisers of first instances can be supplied within the sphere of the first instance, the ⁇ reby increasing an availability of the overall service supplied by these topology advisers.
  • the path information may comprise a link or several links, in particular virtual not yet established links that are adver ⁇ tised or transmitted to the second instance.
  • the second instance may be deployed within a second sphere, wherein the first sphere and the se ⁇ cond sphere are separated from one another.
  • the concept of the virtual to ⁇ pology is independent from the PCE concept. As soon as paths are established in the lower layer, the higher layer may be ⁇ come ("see") aware of them automatically. Hence, the virtual topology may comprise paths of the lower layer, which are al ⁇ ready established.
  • first instance can be a physical infrastructure provider and the second instance can be a virtual network provider.
  • virtual network may comprise
  • PIP physical infrastructure provider
  • VNP virtual network provider
  • VNO virtual network operator
  • the virtual network can be regarded as a multi-layer network, wherein each instance PIP, VNP, VNO is perceived as a single layer. Paths across such virtual network are to be determined and/or signaled.
  • the higher layers, e.g. VNP, need to be informed about potential paths provided by the PIP, which can be achieved according to the solution provided her- ein.
  • said sphere of the first instance is a lay ⁇ er of a multi-layer network.
  • the second instance is part of a dif ⁇ ferent sphere or another layer of the multi-layer network, in particular an upper layer.
  • the first instance and the second instance may thus be asso ⁇ ciated with different layers of a multi-layer model (e.g., according to ISO/OSI model) .
  • the first instance provides path information to this upper layer second instance that could be used for determining or calculating an optimized path
  • VTA virtual to ⁇ pology advertiser
  • the upper layer also referred to as higher layer
  • VNT virtual network topology
  • Properties of these VNT may comprise, e.g.: costs, shared risk link group (SRLG) informa ⁇ tion, QoS properties and availability information for each link.
  • SRLG shared risk link group
  • said sphere of the first instance is a domain of a multi-domain network.
  • the second instance is part of a diffe ⁇ rent sphere or another domain of the multi-domain network.
  • the first and the second instance are part of diffe ⁇ rent domains of a multi-domain network.
  • the second instance determines an optimized path across the network utilizing said path information .
  • the path information gathered within the sphere of the first instance can be used to determine an optimized path, in particular an end-to-end path, on an upper layer or at a domain beyond said sphere of the first instance.
  • the path computation provided within the sphere of the first instance is an encapsulated and/or transparent service provi ⁇ ded to the second instance.
  • the path information compri ses at least one link and/or at least one virtual link.
  • the link may be a traffic engineering (TE) link that could be used by the upper layer for optimized path determination purposes.
  • TE traffic engineering
  • the virtual link is a link for which no resources are allocated .
  • the TE link referred to herein re ⁇ fers any virtual (established) link to a link between instan- ces of a higher layer, wherein each such TE link may actually be based on at least one path via at least one lower layer.
  • the path information is sent from the first instance to the second instance with or without a previous request from the second instance.
  • said path information may be actively pushed from the first instance to the second instance or it may be polled by the second instance.
  • the first instance and the second instance may in particular support an extended OSPF protocol, which provides services of an incremental update and/or a recovery mode.
  • the path information is processed within the sphere of the first instance and this pro ⁇ Ded path information is conveyed to the second instance of the network.
  • Such processing may comprise a filter or selection mechanism applied within the sphere of the first instance, e.g., by the first instance or by a filter or processing unit deployed within this sphere.
  • Such processing allows filtering the path information to be provided to the second instance pursuant to predefined constraints .
  • the path information is determined based on at least one of the following criteria:
  • topology information database within the sphere of the first instance
  • the path information may in particular be selected, processed or filtered according to at least one of these criteria.
  • the first instance determines optimized paths per customer in particular considering service level agreements, policies and costs for each customer.
  • the first instance determines optimized paths based on at least one of the following crite ⁇ ria :
  • the first instance utilizes or comprises a PCE functionality.
  • the PCE functionality may be used for determining path infor ⁇ mation within the sphere of the first instance and the topo ⁇ logy adviser computes paths within the sphere of the first instance that are destined for the second instance (e.g., up ⁇ per layer) .
  • the path information conveyed to the second instance comprises at least an identifi ⁇ cation associated with a link.
  • this identification can be used to address a link or a portion of the path information. Hence, if a link or path should be established, the path computation for this link does not have to be repeated, but can be addressed by said identification.
  • a network element for conveying information comprising or being associated with a processing unit that is arranged to execute the steps of the method as described herein.
  • the first instance may comprise or be associated with a pro ⁇ cessing unit. It is noted that the steps of the method stated herein may be executable on this processing unit as well. It is further noted that said processing unit can comprise at least one, in particular several means that are arranged to execute the steps of the method described herein. The means may be logically or physically separated; in particular seve ⁇ ral logically separate means could be combined in at least one physical unit.
  • Said processing unit may comprise at least one of the follo ⁇ wing: a processor, a microcontroller, a hard-wired circuit, an ASIC, an FPGA, a logic device.
  • said sphere of the first instance is a domain of a multi-domain network and/or a layer of a multi-layer network.
  • the second instance is associated with a sphere that is different from the sphere of the first instance.
  • the network element comprises at least one of the
  • a policy server a service level agreement database, a cost database, a topology database, a traffic engineering database, - wherein the first instance is arranged to determine the path information based on information provided by at least one of the policy server, the service level agreement database, the cost database, the topology database or the traffic engineering database.
  • the network element comprises a PCE functionality that is accessible to the first in ⁇ stance .
  • This PCE functionality may be based on a standardized PCE functionality and it may be implemented as a separate entity or combined with the first instance.
  • the network element comprises a filter that filters the path information before it is conveyed to the second instance.
  • a communi ⁇ cation system comprising at least one device as described herein .
  • Fig.l shows an OSPF packet header with an LSA header and an extension
  • Fig.2 shows a block diagram visualizing a virtual topology advertiser concept
  • Fig.3 shows a block diagram based on Fig.2 with a single lower layer being connected to two higher layer customers ;
  • Fig.4 shows the opposite case of Fig.3 and is also based on
  • Fig.2 with a single higher layer being connected to two lower layers
  • Fig.5 shows a schematic illustration to visualize the proc ⁇ ess of calculating and setting up a path in a multilayer network
  • Fig.6A shows a schematic diagram visualizing an advertisement or transfer of path information in a multi-layer scenario
  • Fig.6B shows a schematic diagram visualizing an advertise ⁇ ment or transfer of path information in a multi- domain scenario.
  • a lower layer may advertise TE links to an upper (or higher) layer. These TE links form a virtual network topology (VNT) of the higher layer.
  • VNT virtual network topology
  • LSPs label switched paths
  • the TE links advertised can be regar- ded as "virtual" TE links that are not yet established, since they represent lower layer LSPs that have not yet been established, i.e. they are "planned" and insofar not yet existing (virtual) .
  • a path computation entity may have to consider different layers, which may be difficult or impossible due to (operator) policies, manage ⁇ ment and other reasons that stipulate a strict separation of the layers.
  • an upper layer has no insight into its lo- was layer; therefore, the upper layer path computation entity has no knowledge of the lower layer.
  • the upper layer path computation entity requires information about the lower lay- er, i.e. it preferably requires knowing about (all) possible lower layer paths, which result in TE links in the VNT, including their corresponding properties.
  • properties comprise cost values, SRG information, free resources on a link and other QoS parameters.
  • the path computation entity is also referred to as "path cal ⁇ culator" and it may comprise or be based on a PCE functiona ⁇ lity.
  • the path calculator of a higher layer obtains the information required, e.g., regarding (all) possible lower layer paths, by using the virtual TE links. It is noted that these TE links may not be established (yet) and insofar no resources are allocated in the lower layer for such TE links.
  • Fig.2 shows a block diagram visualizing a virtual topology advertiser concept comprising in particular the following ⁇ tities of an upper (higher) layer 211 and of a lower layer 212 :
  • the Lower Policy Server 201 stores operator policies of a lower layer network. These policies may affect a vir ⁇ tual topology advertiser (VTA) 202, i.e. they define, which paths the VTA 202 computes. Also, this Lower Pol ⁇ icy Server 201 is connected to a filter 203, i.e. the Lower Policy Server 201 defines which of the computed paths should be actually advertised to the higher layer
  • the filter 203 is a lower layer filter. It provides a filter function and selects the paths that are to be an nounced to a specific customer.
  • the filter 203 can be configured for each customer and/or topology and/or TE- database.
  • the filter 203 may consider restrictions de ⁇ fined by the Lower Policy Server 201 and the SLA and cost database 204.
  • a path determined by the VTA 202 is input to the filter 203, which takes into account poli ⁇ cies as well as SLAs and outputs the result to a higher layer filter 205.
  • SLA Service Level Agreement
  • cost database 204 This database 204 stores SLAs and costs for each cos- turner. This information may be considered by the VTA 202 as well as by the (lower layer) filter 203.
  • the Lower Path Calculator 206 is also referred to as (lower) traffic engineering engine. It may be based on or comprise a PCE and it computes paths that have been requested by the lower layer. The computation is based on the information stored in a lower topology and TE- database 207.
  • the PCE may also comprise a database (also referred to as traffic engineering database (TED) ) and the actual path computation engine.
  • TED traffic engineering database
  • the TED can be used both for the VTA 202 and for the PCE 206.
  • the PCE may compute only the paths that are requested by the lower layer. Hence, these path computation results of the PCE do not have to be transmitted to any higher layer nor to the VTA 202.
  • An interface (not shown) between the PCE and the network and/or the management sys ⁇ tem can be provided, and such entities (or network nodes, or the management system) may request path compu ⁇ tations from the PCE.
  • This database 207 stores a topology, free resources and physical characteristics and/or QoS parameters of the lower layer.
  • the Higher Policy Server 208 stores policies of the op ⁇ erator of the higher layer network. It configures the filter 205, i.e. the Higher Policy Server 208 defines which of the received paths should be forwarded to a higher topology and TE-database 209.
  • This database 209 stores a virtual topology, free re ⁇ sources, costs and other QoS parameters of the higher layer.
  • the higher layer filter 205 filters the paths that should be forwarded to the higher topology and TE- database 209.
  • the filter 205 considers the policies of the higher layer.
  • the Higher Path Calculator 210 is also referred to as (higher) traffic engineering engine. It may be based on or comprise a PCE (functionality) and it computes paths that have been requested for the higher layer.
  • the com ⁇ putation is based on the information stored in the data ⁇ base 209. Hence, the Higher Path Calculator 210 computes paths in the VNT of the higher layer.
  • the VTA 202 calculates (all) possible routes and/or paths in the lower layer taking into account the poli- cies provided by the Lower Policy Server 201 and cus ⁇ tomer-specific requirements and costs provided by the database 204.
  • the path computation is conducted based on the Lower Topology and TE-database 207. All calculated paths are sent to the filters 203, 205.
  • the VTA 202 com- putes optimized (or optimal) paths per customer taking into account the costs for each customer.
  • the Higher Path Calculator 210 and/or the Lower Path Calculator 206 may comprise a (standardized) PCE, which is an entity being capable of computing a path using, e.g., a standardized interface via a PCEP (PCE Protocol) . On request, the PCE may compute the cheapest path with regard to the resources used.
  • PCEP PCEP
  • the VTA 202 considers SLAs and costs provided by the database 204. For example, a higher layer operator may have an SLA including a price agreement with a lower layer operator; hence, the VTA 202 computes the chea ⁇ pest paths considering this price agreement for the higher layer for a particular customer. It may also be the case that the lower layer has multiple higher layer customers; depen- dent on the SLA and price negotiated for each customer, the VTA 202 may compute different paths for the same source and destination .
  • the VTA 202 computes paths within the lower layer for the higher layer and the PCE computes paths for the lower layer only.
  • VTA 202 and the lower PCE may be combined into a single entity.
  • the VTA 202 may compute for all possible source and destina ⁇ tion pairs the cheapest paths and send those paths to the filter 203.
  • the filter 203 uses information provided by the Lower Policy Server 201 as well as the SLA and cost database 204 to check if all computed paths should be conveyed to the higher layer or any of the paths determined violates a policy or an SLA.
  • the filter 203 does not forward paths, i.e. the virtual TE links, which are not conform to the policy and SLA. Such separate filtering can be useful, if the VTA 202 is not able to compute the paths and take all the required poli ⁇ cies and SLA into account in parallel.
  • the Lower Policy Server 201 may comprise rules, which need to be taken into account by the VTA 202 and rules, which are to be enforced by the filter 203.
  • VTA 202 and the filter 203 in ⁇ may compute and forward (all) paths to the higher layer, which meet the requirements set forth by the Lower Policy Server 201 and the database 204.
  • An optimized (or optimal) path can be determined or computed based on at least one of the following criteria:
  • the VTA 202 may consider at least one of the following pro ⁇ perties in order to compute the paths, which are advertised as virtual TE links:
  • the costs can be provided via the SLA and cost database 204.
  • This information may comprise costs for each cos- turner for each link. Based on this information, the shortest path between two nodes can be calculated.
  • An SLA may comprise properties like a minimum availability, a maximum number of hops, a maxi ⁇ mum bit error rate (BER) acceptable, an amount of money for violating a SLA.
  • BER bit error rate
  • QoS parameters are, e.g., the physical properties of, e.g., optical networks. This information can be used to calculate the actual BER for a TE link.
  • the QoS parame ⁇ ters can be stored in the Lower Topology and TE-database 207, which may be configured during or before start-up either manually or it can be automatically initialized via a network management system (NMS) .
  • the QoS parame ⁇ ters may comprise: a BER, a latency, a jitter, a band ⁇ width, an availability.
  • the VTA 202 uses availability in ⁇ formation of each individual link and each individual node.
  • the availability can be a QoS parameter (see above) and thus be stored in and provided by the Lower Topology and TE-database 207.
  • the service type which the client (upper) layer will run on the TE links computed, may be an information to be considered by the VTA 202.
  • different QoS requirements and hence, different links in the lower layer may be admissible.
  • the database 204 may contain SLAs for each customer. In this database 204, admissible services for one customer can be linked to the SLA.
  • the VTA 202 can thus compute for each service type the optimal path, i.e. the service is mapped to QoS parameters required and the VTA 202 computes the optimal path considering the QoS require ⁇ ments. In such scenario, a maximum or minimum value for a QoS parameter can be defined or the QoS parameter can be minimized or maximized.
  • the service type may comprise real-time services, nearly real-time services or non real-time services. Based on these service types, the boundaries for the QoS parame ⁇ ters like delay and/or jitter can be set.
  • Policies can be defined by the operator and the VTA 202 may consider such policies when determining the paths.
  • the policies may comprise restrictions, e.g., which path and/or link should be (not) considered and/or (not) ad ⁇ vertised .
  • a policy may be required that a computed and an ⁇ nounced path must not traverse a node, which has a load hig ⁇ her than 80%.
  • the VTA 202 computes the paths as usual and they will be conveyed to the higher layer as desc ⁇ ribed. As soon as a node's load exceeds 80%, this node will be masked (not used) during path computation in the VTA 202.
  • an operator may decide that only a few links should be advertised to the upper layer (for example, only transit links should be directly announced to the higher layer) . So he specifies that TE links should be advertised only between the cities Kunststoff, Bremen, Frankfurt and Berlin. This policy is considered by the VTA 202, i.e. the VTA 202 computes paths between these cities.
  • the advertisement of the virtual TE links can include an identification (ID) of this link. This ID can be linked inside the VTA 202 to the actual computed path. Hence, if a virtual TE link should be established, the path computation for this link does not have to be repeated, but can be loaded from the VTA 202, which has already computed this path.
  • the actual advertisement of the virtual TE links to the hig ⁇ her layer can be either done by polling, i.e. the higher lay- er actively requests the virtual TE links from the lower lay ⁇ er and only after such a request the paths are sent to the higher layer.
  • the virtual TE links are pushed to the higher layer, i.e. the VTA 202 sends the virtual TE links to the higher layer. In both cases incremental updates can be utilized.
  • extensions to the OSPF protocol RRC 2328) can be used.
  • Such an extended interface may support incremental updates and/or a recovery mode, i.e. that all virtual TE links are sent to the higher layer.
  • new OSPF messages can be used for exchanging the vir- tual TE links between the lower and higher layer filters 203, 205.
  • the filters 203, 205 may each be modi ⁇ fied to comprise a (modified) OSPF functionality.
  • the VTA 202 computes the paths, the filter 202 checks the policies and SLAs provided by the Lower Policy Server 201 and the database 204 and forwards the TE links to the higher layer, i.e. to the filter 205. This forwarding is done by transforming a link out of the path, and announcing this link to the higher layer filter 205 using a Link State Advertisement (LSA) mes ⁇ sage as shown in Fig.l.
  • LSA Link State Advertisement
  • the LSA message shown in Fig.l comprises an OSPF packet hea ⁇ der 102 (see RFC 2328, A.3.1), an LSA header 103 (see
  • the "LS type" within the LSA header 103 may be set to "6" in ⁇ dicating a virtual TE link in a higher layer.
  • a destination address specifies an IP address of a destination of this LSA advertisement. This could be the filter 205 of the higher layer.
  • a source address specifies an IP address of the source of this LSA advertisement, which could be the VTA 202.
  • a U-Flag indicates whether or not the following information is an update of the virtual TE link.
  • An R-Flag indicates whether or not the following TE link should be removed.
  • V- A V-Flag indicates whether or not a virtual TE link is specified.
  • a "source node in higher layer” specifies an IP ad ⁇ dress of a source node in the higher layer from which the virtual TE link starts.
  • target node in higher layer specifies an IP ad- dress of a target node in the higher layer at which the virtual TE link ends.
  • a "link ID of virtual TE link" specifies (as an inte ⁇ ger) an ID of the virtual TE link if a path key mechanism is used. If this mechanism is not used, this value is set to 0.
  • a "duration of validity" specifies (as an integer in seconds) how long this TE link is valid.
  • VTA redundancy is provided, in particular increasing the availability of the service
  • the VTA stores path IDs for the virtual TE links and a virtual TE link can be addres sed via such path ID.
  • the approach suggested herein provides all required information to a client layer, such that it can compute optimal paths traver ⁇ sing both the client and the server layers.
  • the information revealed to the client (upper) layer does not have to include topology details of the server layer, which are sometimes required (by the operators) to remain hidden.
  • the approach sug- gested provides all required information to different do ⁇ mains, such that optimal paths traversing multiple domains can be computed.
  • the information revealed by the (other) do ⁇ mains may not include topology details of other do ⁇ mains, which are sometimes required (by the operators) to re- main hidden.
  • the higher layer can compute the paths based on its virtual topology.
  • the virtual topology is based on the advertised links from the lower layer. Hence, it is a significant advan ⁇ tage that the higher layer does not have to communicate with the lower layer during the path computation process.
  • Fig.3 shows a block diagram based on Fig.2 with a single lo ⁇ was layer 301 being connected to two higher layer customers 302 and 303. References already introduced with regard to Fig.2 refer to the same components.
  • Fig.3 comprises two filters 304, 305, wherein the filter 304 is associated with the customer 302 and the filter 305 is associated with the customer 303.
  • the lower layer 301 can be a layer-1 advertising some links directly to a layer-3 being the customer 302 and some other links to layer-2 being the customer 303.
  • Fig.4 shows the opposite case of Fig.3 and is also based on Fig.2 with a single higher layer 403 being connected to two lower layers 401 and 402. References already introduced with regard to Fig.2 refer to the same components.
  • the higher layer 403 may be a layer-3 obtaining advertisements from a layer-2 401 as well as from a layer-1 402.
  • the concept of the multi-layer scenario can be accordingly applied to the multi-domain scenario.
  • the multi-layer and multi-domain scenarios can be combined .
  • Fig.2 can be applied to the multi-domain scenario as follows: The blocks of the higher layer (i.e. 205, 208, 209 and 210) are associated with a domain 2 and the blocks of the lower layer (i.e. 201, 202, 203, 204, 206, 207) are associated with a domain 1.
  • the concept can be mirrored, i.e.
  • links can also be advertised in the opposite direction, i.e. from the domain 2 to the domain 1.
  • domain 2 also comprises a VTA.
  • the TE links advertised can be either transit links or links which either start or end in domain 1, domain 2 respectively.
  • the advertisement of links to domain 2 (or to domain 1) is conducted as described before for the multi-layer scenario.
  • the peering agreements can be stored in the SLA and cost da ⁇ tabase 204.
  • the amount of information that should be hidden as well as the amount of information to be shared could be indicated by or stored in the policy server 201. Based on this information, the VTA 202 may compute paths traversing its domain.
  • Fig.3 could be implemented comprising three different layers, i.e. the higher layer customer 302 is a CET layer-2 and the higher layer customer 303 is an MPLS layer-3.
  • the lower layer 301 is a DWDM layer-1.
  • the SLA and cost database 204 and the poli- cy servers 201, 208 are configured manually.
  • the Higher Topo ⁇ logy and TE-database 209 is initialized via an NMS, which transfers topology information and other relevant data like latency, jitter, etc. for each link to this database 209.
  • NMS Network-based Mobile Communications
  • Currently used resources of the network can be updated by listening to the IS-IS or OSPF-TE message exchange that oc ⁇ curs on the control plane (assuming that a GMPLS control pla ⁇ ne is running for the DWDM layer) .
  • four nodes A, B, C and D are spe ⁇ cified in the policy server 201 for which paths are to be calculated for layer-3.
  • nodes B, C, E, F, G are specified for which paths should be calculated for layer-2.
  • the VTA 202 queries the Lower Policy Server 201 and the SLA and cost database 204. Based on the input provided by the Lower Policy Server 201, the VTA 202 determines paths for the start and end node A-B, A-C, A-D, B-C, B-D and C-D. At one step of the path computa- tion, the VTA 202 considers also the input from the database 204, i.e. the VTA 202 calculates the cheapest paths for lay ⁇ er-3. Furthermore, the VTA 202 considers the SLAs (provided by said database 204), i.e. for each possible service it com ⁇ putes a path for each source and target node.
  • the VTA 202 computes the paths for layer-2. This could be achieved re-using the results from the layer-3 path calculation already conducted, i.e., the paths for the source-destination pair B-C, if the database 204 cor ⁇ responds to both layers.
  • the paths are determined by the VTA 202 considering input from the Lower Policy Server 201, the SLA and cost database 204 and the Lo ⁇ was Topology and TE-database 207.
  • the result of the VTA com ⁇ putation may reveal multiple paths for each source- destination pair specified in the policy server, each one op- timized with regard to a specified service class for each layer and/or customer as defined in the SLAs .
  • a shortest path algorithm (Dijkstra), a modified Dijkstra algorithm, heuristics or integer linear programming (ILP) can be used.
  • Dijkstra shortest path algorithm
  • ILP integer linear programming
  • the VTA may thus consider constraints that are in particular dependent on SLAs. Such constraints may require considering only links with a BER amounting to less than a predefined va- lue or links with an availability that is higher than a pre ⁇ defined value. Constraints may also be derived from service types (e.g., real time service or the like) .
  • the paths computed by the VTA are forwarded to the filters and the filters determine which paths are to be forwarded.
  • the filter 305 is passed only by paths comprising the nodes A, B, C and D.
  • the filter may check if a specified availability and other required QoS parameters are met. Based on the paths forwarded to the upper layer, TE links are determined.
  • the filter itself has two tasks: First, the filter derives virtual TE links from the paths and forwards those TE links to the higher layer. Second, the filter may check if the com- puted paths meet the requirements specified by the Lower Po ⁇ licy Server 201 and by the SLA and cost database 204. This can in particular be useful in case the VTA 202, e.g., due to performance reasons, cannot consider all constraints relevant for a path. As indicated, the functionalities of the filter and the VTA may be merged into a single component.
  • layer-2 may advertise virtual TE links to layer-3.
  • the approach presented herein can be used to support several operators at (e.g., different) lower layers.
  • Each operator has the components described in detail with regard to Fig.2 above, i.e. the VTA 202, the filter 203, the Lower Policy Server 203, the Lower Topology and TE- database 207 and the Lower Path Calculator 206.
  • the paths are conveyed via the filter 203 to the upper layer filter 205, which receives the paths from both lower layers (i.e. opera ⁇ tors) 401, 402.
  • the filter 205 conducts a policy-dependent filtering and stores the links of both operators 401, 402 in the Higher Topology and TE-database 209. This concept allows calculating optimized paths using TE links of both operators 401 and 402.
  • Fig.5 shows a schematic illustration to visualize the process of calculating and setting up a path in a multi-layer network .
  • the VTA concept is realized together with the PCE approach.
  • the virtual TE links have been calculated by the VTA and advertised to the higher layer (not shown in Fig.5) .
  • Fig.5 shows a two-layer network comprising nodes A, B, C, D of a higher layer and nodes Nl to N10 of a lower layer.
  • the node A is connected to the node Nl
  • the node B is connected to the node N5
  • the node C is connected to the node N6
  • the node D is connected to the node N10.
  • the node A and the node Nl, the node B and the node N5, the node C and the node N6, the node D and the node N10 are deployed within the same physical entity, respectively.
  • the nodes of the higher layer that are connected to nodes of the lower layer are aware of their interconnection to this lower layer. Also, on the higher layer, the following links already exist (these links can be logical or physical links) : A-B, B-C, C-D. On the lower layer, the links shown in Fig.5 exist: N1-N2, N2-N4, N4-N6, N2-N3, N3-N5, N5-N6, N6-N7, N7- N8, N8-N9, N9-N10.
  • a communication between nodes of different layers can be achieved via the advertised virtual TE links (as described herein, see block 501, wherein said block 501 comprises the structure depicted in Fig.2) and via a control plane, e.g. via the nodes A-Nl, B-N5, C-N6, D-N10.
  • the node A wants to set up a path from the node A to the node D. In order to compute the path, the node A
  • This PCE computes an optimal path using the information of the Higher Topology and TE-database 209, which includes virtual TE links of the lower layer. These virtual TE links have already been conveyed to the higher layer as described herein.
  • the path determined by the PCE of the Higher Path Calcu ⁇ lator 210 is sent back to the node A including a virtual TE link between the node A and the node C (step 512) .
  • the response of this PCE includes an additional path key for the virtual TE link between the nodes A and C.
  • a normal signaling process for the control plane may be initiated using the path key con ⁇ cept (see also RFC 5520) .
  • the node A recognizes that the first link is merely a virtual TE link, since no direct link goes from the node A to the node C.
  • the node A sends the path key to the lower layer node Nl with a request to estab ⁇ lish a path between the node A and the node C (step 513) .
  • Such forwarding and triggering of a path or LSP can be done either via a control plane message, e.g. RSVP-TE, or via a universal network interface (UNI) .
  • the node Nl asks the VTA 202 (indicated by block 501) for the corresponding path associated with the path key provided, i.e. the node Nl sends the path key to the VTA 202 (step 514) .
  • the VTA 202 provides the pre-computed path which matches the path key to the nodes Nl (step 515) .
  • the node Nl signals the provided path to be established in the lower layer (step 516) .
  • the path established on the lower layer is automatically advertised as a new TE link to the higher layer (step 517), e.g., via an OSPF LSA (broadcast).
  • OSPF LSA low-power Bluetooth subsystem
  • the node A continues the signaling process to establish the path between the node A, the node C and the node D (step 518) and to obtain a confirmation that this path is established (step 519) .
  • the complete path from the node A to the node D via the node C is set up .
  • the Node Nl does not need to know anything about the higher layer, except that it is connected to the higher node A. Al ⁇ so, all other lower layer nodes N2 to N10 have no information of the higher layer, except for the node to which each of them is directly connected. Accordingly, the higher layer no- des are not aware of any lower layer information or path other than the lower layer node to which the higher layer node is connected.
  • the approach can be applied in a similar manner, i.e. transit paths across do ⁇ mains and paths starting and ending in a domain 1 are advertised to other domains. The domain 1 receives the correspon ⁇ ding information from other domains. This information can be utilized to determine an optimized path across several do ⁇ mains. Information can be hidden by using the path key mechanism.
  • Fig.6A shows a schematic diagram visualizing an advertisement or transfer of path information 605 from a first instance 601 (in particular a VAT) of a sphere 602 to a second instance 603 of sphere 604.
  • the sphere 602 and the sphere 604 may be layers of a multi-layer environment.
  • the path information 605 may comprise at least one path, at least one link, in parti- cular at least one virtual link.
  • the path information 605 is conveyed to the second instance 603, which may poll or re ⁇ quest this path information 605 or the path information can be transmitted (pushed) to the second instance 603 by the first instance (without any previous request) .
  • Fig.6B shows a schematic diagram visualizing a multi-domain scenario.
  • a path information 610 is conveyed or advertised from a first instance 606 (in particular a VAT) of a sphere 607 to a second instance 608 of sphere 609.
  • the sphere 607 and the sphere 609 can be domains of a multi-domain environ ⁇ ment.
  • the path information 610 may comprise at least one path, at least one link, in particular at least one virtual link.
  • the path information 610 is conveyed to the second in ⁇ stance 608, which may poll or request this path information 610 or the path information 610 can be transmitted (pushed) to the second instance 608 by the first instance 606 (without any previous request) .
  • the concept suggested allows computing of optimized paths meeting predefined requirements or constraints (e.g., QoS) in a fast and scalable way. This computation can be done at a single layer without any detailed knowledge about how virtual TE links are realized on the lower layer. Hence, the techno ⁇ logy and complexity of the lower layer is hidden to the hig ⁇ her layer.
  • the virtual TE links are merely advertised, but do not have to be established at the moment of advertise ⁇ ment.
  • the TE link can be advertised to several custo ⁇ mers at the same time.
  • this information is updated in the lower layer, the path is set up, and the resource is allocated.
  • the virtual TE link is automatically replaced by an established TE link.
  • a request can be sent to a PCE with specified QoS require ⁇ ments. This PCE is aware of the network topology and the QoS parameters of each link and can therefore compute the optimal path taking into account these constraints. Only the VNT including the virtual TE link can be announced to the higher layer.
  • VTAs can be used in multi-vendor and multi- operator environments. Furthermore, the approach provided can be used for multi-domain path computation purposes.
  • Another advantage is the fact that the virtual network topo- logy including the virtual TE links can be easily advertised to the higher layer.
  • the layers can also be operated separa ⁇ tely.
  • the solution results in reduced operation expen ⁇ ditures (OPEX) .
  • OPEX expen ⁇ ditures

Landscapes

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

Abstract

L'invention porte sur un procédé et un dispositif d'acheminement d'informations dans un réseau, une première instance du réseau déterminant des informations d'itinéraire dans une sphère de la première instance; et les informations d'itinéraire étant acheminées vers une seconde instance du réseau. En outre, l'invention porte sur un système de communication comprenant au moins un tel dispositif.
PCT/EP2010/060810 2010-07-26 2010-07-26 Procédé, dispositif et système d'acheminement d'informations dans un réseau Ceased WO2012013216A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/060810 WO2012013216A1 (fr) 2010-07-26 2010-07-26 Procédé, dispositif et système d'acheminement d'informations dans un réseau

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/060810 WO2012013216A1 (fr) 2010-07-26 2010-07-26 Procédé, dispositif et système d'acheminement d'informations dans un réseau

Publications (1)

Publication Number Publication Date
WO2012013216A1 true WO2012013216A1 (fr) 2012-02-02

Family

ID=43827319

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/060810 Ceased WO2012013216A1 (fr) 2010-07-26 2010-07-26 Procédé, dispositif et système d'acheminement d'informations dans un réseau

Country Status (1)

Country Link
WO (1) WO2012013216A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2760169A1 (fr) * 2013-01-23 2014-07-30 ADVA AG Optical Networking Procédé et appareil pour fournir un service de transport dans un réseau multicouche multi-domaines
EP2863594A1 (fr) * 2013-10-18 2015-04-22 Alcatel Lucent Calcul de mesures dans un réseau avec au moins deux couches de transport
WO2015059917A1 (fr) * 2013-10-21 2015-04-30 日本電気株式会社 Procédé et dispositif de commande de réseau multicouches
CN104718729A (zh) * 2012-10-03 2015-06-17 日本电气株式会社 控制装置及其控制方法和程序
WO2015124200A1 (fr) * 2014-02-21 2015-08-27 Telefonaktiebolaget L M Ericsson (Publ) Procédé et appareil de calcul de trajet dans un réseau multicouche
WO2017063694A1 (fr) * 2015-10-14 2017-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Commande de réseau de communication multi-couche
EP4002777A1 (fr) * 2020-11-13 2022-05-25 Juniper Networks, Inc. Topologies de filtrage de calcul de chemin dans des réseaux massivement mises à l 'échelle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OKI UNIVERSITY OF ELECTRO-COMMUNICATIONS T TAKEDA NTT JL LE ROUX FRANCE TELECOM A FARREL OLD DOG CONSULTING E: "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering; rfc5623.txt", FRAMEWORK FOR PCE-BASED INTER-LAYER MPLS AND GMPLS TRAFFIC ENGINEERING; RFC5623.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 1 September 2009 (2009-09-01), XP015065682 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2904746A4 (fr) * 2012-10-03 2016-05-25 Nec Corp Appareil de commande, son procédé de commande et programme
CN104718729A (zh) * 2012-10-03 2015-06-17 日本电气株式会社 控制装置及其控制方法和程序
EP2760169A1 (fr) * 2013-01-23 2014-07-30 ADVA AG Optical Networking Procédé et appareil pour fournir un service de transport dans un réseau multicouche multi-domaines
EP2863594A1 (fr) * 2013-10-18 2015-04-22 Alcatel Lucent Calcul de mesures dans un réseau avec au moins deux couches de transport
WO2015055378A3 (fr) * 2013-10-18 2015-09-17 Alcatel Lucent Calcul de métriques dans un réseau à au moins deux couches transport
WO2015059917A1 (fr) * 2013-10-21 2015-04-30 日本電気株式会社 Procédé et dispositif de commande de réseau multicouches
JPWO2015059917A1 (ja) * 2013-10-21 2017-03-09 日本電気株式会社 マルチレイヤネットワーク制御方法および装置
WO2015124200A1 (fr) * 2014-02-21 2015-08-27 Telefonaktiebolaget L M Ericsson (Publ) Procédé et appareil de calcul de trajet dans un réseau multicouche
US20170012871A1 (en) * 2014-02-21 2017-01-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for path calculation in a multi-layer network
WO2017063694A1 (fr) * 2015-10-14 2017-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Commande de réseau de communication multi-couche
US10700967B2 (en) 2015-10-14 2020-06-30 Telefonaktiebolaget Lm Ericsson (Publ) Control of multi-layer communication network
US11336571B2 (en) 2015-10-14 2022-05-17 Telefonaktiebolaget Lm Ericsson (Publ) Control of multi-layer communication network
EP4002777A1 (fr) * 2020-11-13 2022-05-25 Juniper Networks, Inc. Topologies de filtrage de calcul de chemin dans des réseaux massivement mises à l 'échelle

Similar Documents

Publication Publication Date Title
US11451471B2 (en) Using PCE as SDN controller
CN100454841C (zh) 一种多域路由计算方法和系统
CN101471853B (zh) 一种路由计算方法、单元及系统
EP3429141B1 (fr) Trajet à commutation d'étiquette de routage de segment pour les routeurs activés sans routage de segment
CN104426766B (zh) 跨多个网络层的动态端到端网络路径建立
US8942256B1 (en) Advertising with a layer three routing protocol constituent link attributes of a layer two bundle
CN114363249B (zh) 针对多路径分段路由的带宽约束
CN104429027B (zh) 用于在电信网络中建立链路分集业务路径的方法和相关设备
US20050152284A1 (en) Scalable abstraction of topology across domain boundaries
US8295201B2 (en) System and method for providing lower-layer path validation for higher-layer autonomous systems
CN104718732B (zh) 用于为在通信网络的两个节点之间建立路径而交换信息的方法
WO2012013216A1 (fr) Procédé, dispositif et système d'acheminement d'informations dans un réseau
CN101099351A (zh) 用于触发对路径计算请求进行打包
Bryskin et al. Policy-enabled path computation framework
CN103491002B (zh) 一种获取ip链路的链路开销值的方法及系统
KR20140050547A (ko) Uni 경로 제어 장치 및 방법
Oki et al. Generalized traffic engineering protocol for multi-layer GMPLS networks
Pelsser Interdomain traffic engineering with MPLS.
Chen et al. Multipath routing in path computation element (PCE): Protocol extensions and implementation
Berger et al. Network Working Group I. Bryskin Request for Comments: 5394 Adva Optical Category: Informational D. Papadimitriou Alcatel
Arnold A Traffic Engineering Attribute for BGP
Muchanga et al. Inter-Domain Routing in Optical Networks
Yao et al. A PCE-based redundancy-aware path selection scheme for multi-layer network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10740582

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10740582

Country of ref document: EP

Kind code of ref document: A1