Patent Application
20140376371
The invention relates to a method and to a device for conveying data across at least two domains. Method and device are preferably used to provide multi-domain QoS enabled services in a communication network. Also, an according communication system is suggested.
Current internet solutions are basically composed of autonomous systems (also referred to as domains or network domains), which are interconnected via links between related domain edge nodes. Owners of autonomous systems are free to choose how their internal networks are built and operated. Usually this will comprise a structure built from network elements (nodes) and interconnection links. However, for inter-operability reasons, autonomous systems are required to use a common protocol, e.g. a border gateway protocol (BGP) as e.g. defined in RFC 4271, “A Border Gateway Protocol 4 (BGP-4)”, which enables inter-domain routing information exchange. Structures and internal operations within the different domains are often kept a secret. Hence, network topology and traffic engineering attributes such as bandwidth, latency and jitter of any network segment are usually not shared among different domains. Traditional unconstrained destination based routing only needs reachability information as usually distributed by conventional routing protocols like e.g. the above mentioned BGP-4. However, for an automatic inter-domain traffic engineered (TE) path reservation system to be able to work reliably and efficiently, some more information from other domains is required.
A meaningful multi-constrained TE-path calculation that is conducted within a single domain needs detailed information about the network topology and TE-attributes of every network segment of the domain that may be utilized for such a path. Therefore, TE information needs either to be distributed inside the domain or it may be collected and conveyed to a point of contact for control such as e.g. a Service Management System (SMS), a Network Management System (NMS) or a Path Computation Element (PCE).
On the other hand, intra-domain paths are in practice either set up via a network management hierarchy or signaled via a control plane using a signaling protocol (e.g. RSVP-TE). Network management hierarchy is a typical way to manage large networks and it usually consists of at least one NMS and multiple Element Management Systems (EMS), but can also leverage a Service Management System (SMS) to manage services. The SMS is on top of the hierarchy controlling at least one NMS, which again controls EMSs that are used to gather information from network nodes and to configure them.
BGP routers exchange UPDATE messages with both intra-domain (using iBGP) and inter-domain (using eBGP) peers to advertize connectivity information in a format of path vectors. Path vectors carry information about destination prefixes, autonomous system (AS) numbers along the path, and other mandatory and optional attributes that enable a decision about the useability and potential preferability of a route. Only the best route to every known destination is advertized further and multiple prefixes that are close to each other can be aggregated into a prefix with a larger scope.
Network and service providers and other instances using internet type infrastructures need to form multi-domain TE-paths in order to provide their customers with Quality of Service (QoS) enabled services across multiple domains. Currently, the setup of such paths is a burdensome task including negotiations, Service Level Agreements (SLA) and static configuration of routers. It can consume a significant amount of time and resources, which makes it slow, static and inefficient, and this limits its useability.
Dynamic provisioning via a control plane (CP) or a management plane (MP) would be preferable, but to efficiently deploy such a system requires that the current inter-domain model and infrastructure is taken into account and as far as possible preserved. In that, each domain may internally be structured and operated differently from each other domain with an inter-domain routing protocol as the only common denominator and glue.
It is thus an object of the invention to enable an automatic and dynamic setup of multi-domain, multi-constrained TE paths spanning several domains, wherein each domain can select, calculate and allocate its intra-domain portion of the path and related resources according to its own internal structure and mode of operation.
The object is achieved by a method and device for conveying data across at least two domains
The service may comprise any service class or any quality of service (QoS) or any other characteristics that may advantageously be utilized beyond a single domain. For example, the solution suggested allows setting up a communication path that supports a particular type of service, characterized e.g. by bandwidth and/or data rate requirements, delay, delay jitter and/or price constraints, reliability and availability expectations, etc., across domains, which could be maintained and operated separate from each other and in a completely different way.
Hence, the solution presented allows adjacent domains to use different techniques to form intra-domain TE-paths, whereas an inter-domain communication path can be determined based on network element types and implementations that are currently present in a vast majority of domains.
A related service may span across more than two domains, starting from an originating domain, passing one or more intermediate domains and ending at a destination domain. The service further may be a point-to-point, a point-to-multipoint, a multipoint-to-point, or a multipoint-to-multipoint service, and thus the at least two domains may comprise one or more originating and/or destination domains. Originating and destination domains are also called end domains of the respective service.
As any domain may take any of the roles of an end domain or an intermediate domain simultaneously, however only for different services and/or different service requests at a time, the following terminology is used throughout this specification and in the appended claims:
A domain denoted as a “first domain” has the role of a domain that initiates the advertising of a service and consequently is the destination domain of a request for that service. As such, a first domain also initiates the acceptance procedure in response to a successful service request. More details on the role, the tasks and activities of a first domain can be derived from the subsequent part of this specification.
A domain denoted as a “second domain” acts as an intermediate domain. It registers service advertisements received from first domains and forwards the service advertisements to further (second or third) domains. A second domain also registers service requests received from third (or other second) domains and forwards them to further domains in the direction towards the first domain, that advertised the related service. A second domain further receives and forwards request acceptance information originated from a first domain and destined to a third domain. More details on the role, the tasks and activities of a second domain can be derived from the subsequent part of this specification.
A domain denoted as a “third domain” receives and registers service advertisements originated by first domains and potentially forwarded by second domains. It receives path requests from users, selects suitable services and forwards related service requests in the direction towards the related first domains that advertised the respective services. In general the role of a third domain is that of an originating domain for a service request. More details on the role, the tasks and activities of a third domain can be derived from the subsequent part of this specification.
As mentioned above, a domain may simultaneously have different roles for different services.
The roles of a first, a second, and a third domain are exemplarily used throughout the subsequent part of this specification as well as in the appended claims. More specifically an arrangement comprising exactly one of each of the three types of domain roles is used in order to explain and illustrate the different roles and functions of domains in the context of the method and system disclosed.
Obviously, a scenario with “at least two domains” does not necessarily have to comprise all three types of domains as specified above. As an example a scenario without a second domain is easily imaginable. However, any person reasonably skilled in the art can in the same way imagine scenarios with more than three domains as well. Once the three types of domain roles and their behaviors are defined, it is an easy engineering task to implement related configurations with a multiplicity of domains including services with multipoint topologies as outlined above.
In an embodiment, the at least one service is utilized across the at least two domains by accepting the request directed towards the at least one service and by configuring a path across the network elements within each domain and between the domains. Inter-domain path segments may use pre-installed interconnection links between domain edge nodes.
In case a service request cannot be served, e.g. if a domain cannot provide a path and/or the resources required by the requested service, or if a service request expires due to a late or missing response, or if a requested service is outdated, or if anything else goes wrong throughout a service request or path setup phase, the domain that detects the problem sends a reject information towards the other domains involved in the service request. A domain receiving a reject information releases potentially reserved resources and removes the related service from its databases, and, if it was not the originating domain of the related request, forwards the reject information to other domains involved. If the originating domain can find a next best route candidate, it can try to establish a new path without consulting the requesting user.
As an option, the service offered (and e.g. its price) can be verified with the requestor, e.g. a user connected to the originating domain, prior to the final establishment and the usage of a path.
It is noted that the path can be set up in a different way and e.g. using different methods and means within each domain along a single inter-domain path.
In another embodiment, the at least one service is advertised, requested and/or utilized by conveying messages of an inter-domain routing protocol between the at least two domains.
It is in particular suggested to use the inter-domain routing protocol for service advertisement as well as for service requesting and service acceptance/rejection functionalities, wherein the messages of the inter-domain routing protocol specify the at least one service using a service template.
In a further embodiment, the inter-domain routing protocol is based on a border gateway protocol. The inter-domain routing protocol may in particular be based on the BGP as set forth in RFC 4271. The BGP can be amended to meet the requirements suggested herein. It is in particular noted that attributes of the BGP can be used for conveying templates that allow for advertising and utilizing services across the borders between (at least two) domains.
More specifically the BGP UPDATE message can be extended with an optional and non-transitive attribute called “eBGP service” so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service each domain is advertising, requesting, accepting or rejecting via a specific BGP router on its border (also referred to as an edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as a bandwidth, delay and/or delay jitter can be included in the template.
It is thus also an embodiment that the at least one service is advertised between the domains by utilizing a service template that is in particular conveyed via a BGP UPDATE message. In a further embodiment, the at least one service is requested between the domains by utilizing a service template that is in particular conveyed via a BGP UPDATE message. In yet another embodiment, the at least one service is accepted between the domains by utilizing a service template that is in particular conveyed via a BGP UPDATE message. It is thus a valid option that the messages of the inter-domain routing protocol are BGP UPDATE messages.
In a next embodiment,
As explained above, this embodiment covers the exemplary case of a service advertising spanning over exactly three domains, each one of them representing one of the three roles of a first, a second, and a third domain. A person reasonably skilled in the art will easily be able to adapt this example to secenarios with either two domains only, i.e. when there is no second domain, or with more than three domains, i.e. when it spans over more than one domain of the second type. In the same easy way scenarios with multipoint topology services can be adopted.
Pursuant to another embodiment,
The path request, especially if it is a TE-path request, usually provides information with respect to specific requirements of the related service, that needs the path. Such requirements may comprise bandwidth or data throughput, QoS parameters, reliability and/or availability levels of the service, etc. Thus the control entity of the third domain, which for that request takes the role of an originating domain, can select an appropriate service and convey a related service request towards the second domain. The control entity of each subsequent domain involved can select a related service and determine a path across the respective domain. Hence, after the service requesting phase a path across the domains as well as within the domains is selected (reserved).
Again, the embodiment described covers the exemplary case of a scenario spanning over exactly three domains, each one of them representing one of the three roles of a first, a second, and a third domain. A person reasonably skilled in the art will easily be able to adapt this example to secenarios with either two domains only, i.e. when there is no second domain, or with more than three domains, i.e. when it spans over more than one domain of the second type. In the same easy way scenarios with multipoint topology services can be adopted.
According to another embodiment,
Once the accept service request information has arrived at the control entity of the third domain the path can be finally established and committed for use by the requestor.
As before, this embodiment as well covers the exemplary case of a scenario spanning over exactly three domains, each one of them representing one of the three roles of a first, a second, and a third domain. A person reasonably skilled in the art will easily be able to adapt this example to secenarios with either two domains only, i.e. when there is no second domain, or with more than three domains, i.e. when it spans over more than one domain of the second type. In the same easy way scenarios with multipoint topology services can be adopted.
According to a next embodiment, the service template comprises at least one of the following:
Pursuant to yet an embodiment, the intra-domain path in the first domain, in the second domain and in the third domain is set up via the respective control entity or via a signaling protocol.
Hence, the respective control entity may configure an intra-domain path by setting up the data plane and configuring the nodes of the domain accordingly. It is also an option that a signaling protocol can be used (e.g., RSVP-TE) for setting up the intra-domain path.
According to an embodiment, the control entity is at least one of the following:
A domain controller may be a separate entity, but may as well be implemented as, or as a part of, or incorporated in, e.g. a PCE, a resource manager and/or admission controller, a policy controller, a control unit of a network element, or any other control entity associated with the domain.
The problem stated above is also solved by a device for conveying data across at least two domains, comprising a processing unit that is arranged
In a specific embodiment the processing unit is arranged to execute the method steps of at least one of a control entity of a first, a second, or a third domain as specified above. It is again noted, that a domain may simultaneously assume the roles of all three types of domains, i.e. first, second, and third domain, for different services. Thus the processing unit is to be arranged to act accordingly.
The problem stated above is also solved by a device for conveying data across at least two domains, comprising a processing unit that is arranged
It is noted that within the at least two domains the advertising domain of a service is usually (but not necessarily) different from the service requesting domain and that it potentially conveys the advertisement via at least one intermediate domain. Accordingly, the service requesting domain may potentially convey the service request via at least one intermediate domain.
It is further noted that the steps of the method stated herein may be executable on the respective processing unit.
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 several logically separate means could be combined in at least one physical unit.
Said processing unit may comprise at least one of the following: a processor, a microcontroller, a hard-wired circuit, an ASIC, an FPGA, a logic device.
The solution provided herein further comprises a computer program product directly loadable into a memory of a digital computer, comprising software code portions for performing the steps of the method as described herein.
In addition, the problem stated above is solved by a computer-readable medium, e.g., a non-volatile storage of any kind, having computer-executable instructions adapted to, when loaded to its memory, cause a computer system to perform the method as described herein.
Also, the problem stated above is solved by a communication system comprising a first domain, a second domain and a third domain,
It is again mentioned, that the invention is described herein using the best suited configuration comprising three domains, but that a person reasonably skilled in the art would easily be able to implement related equivalents with only two or with more than three domains. Thus a second domain (i.e. a domain of the type “second domain” as specified above) does not necessarily have to be present, or more than one domain of any type may be involved.
Furthermore, the problem stated above is solved by a communication system comprising at least one device as described herein.
Embodiments of the invention are shown and illustrated in the following figures:
The solution presented herein may in particular be based on the border gateway protocol (BGP) or the like or it may be based on any inter-domain routing protocol that could be utilized for interconnected domains.
The approach in particular utilizes the inter-domains routing protocol's functionality to interconnect at least two separate domains. Each domain may be maintained by a different operator or provider and it may comprise at least one connection segment.
It is suggested to use the inter-domain routing protocol for service advertisement as well as for service requesting and service acceptance functionalities.
For a better understanding it is noted, that the figures use the name “Domain C” for a “first domain”, “Domain B” for a “second domain”, and “Domain A” for a “third domain” as specified above.
The domain 401 comprises three network elements 404 to 406, wherein the network element 404 is connected to the network elements 405 and 406 and the network element 405 is further connected to the network element 406. The network elements 404 and 406 are network elements at the edge of the domain 401 and could be realized as edge routers that are based on BGP. The domain 402 comprises three network elements 407 to 409, wherein the network element 407 is connected to the network elements 408 and 409 and the network element 408 is further connected to the network element 409. The network elements 407 and 409 are network elements at the edge of the domain 402 and could be realized as edge routers that are based on BGP. The domain 403 comprises three network elements 410 to 412, wherein the network element 410 is connected to the network elements 411 and 412 and the network element 411 is further connected to the network element 412. The network elements 410 and 412 are network elements at the edge of the domain 403 and could be realized as edge routers that are based on BGP.
An Element Management System (EMS) 413 to 421 is associated with each of the network elements 404 to 412. A Network Management System (NMS) 422 controls the EMSs 413 to 415, an NMS 423 controls the EMSs 416 to 418 and an NMS 423 controls the EMSs 419 to 421. A Service Management System (SMS) 425 communicates with the NMSs 422 to 424.
Hereinafter it will be described as how services can be utilized across several domains 401 to 403. In particular a path can be set up across such domains 401 to 403 considering these services. Such path can temporarily or statically be used for conveying data across the domains. The solution advantageously allows that the respective domains 401 to 403 maintain their internal mechanisms and are, e.g., free to decide which path to choose for inter-domain routing purposes. The control plane comprising the SMS, NMS and EMS hierarchy can (but does not have to) be used for control purposes beyond the borders of the respective domain.
1. The NMS 106 advertises the services of the domain C 103 to edge nodes 107, 108 of the domain C 103.
As an example, the BGP UPDATE message can be extended with an optional and non-transitive attribute called “eBGP service” so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template.
Hence, once at least one service template has been advertised from at least one adjacent domain to the local domain, the following steps may be conducted (the numerals refer to the respective steps also shown in
Hence, after the step No.16 above, the following steps may be conducted (the numerals refer to the respective steps also shown in
Hence, the accept message to the service request (conveyed as shown in
If a failure occurs during creation of the path, e.g., if an intra-domain path cannot be calculated for some domain or a service offered is outdated or a subsequent domain does not reply quickly enough, a reject message can be sent instead of the accept message. Then, each domain releases the resources reserved and, if required, the unavailable service can be removed from the databases. If the originating domain can find a next best route candidate, it can try to establish a new path without consulting the requesting user. As an option, the services offered can be verified (e.g. the price for the connection) with the user prior to establishing the path.
It is noted that the path can be set up differently within each domain along a single inter-domain path.
According to the example shown in
In an advertising phase 501 a service template is conveyed across the domains, in the example shown from the domain C 103 via the domain B 102 to the domain A 101. The service template can be transferred utilizing a (modified) BGP UPDATE message.
In a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message.
In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in
In case the accept message is successfully delivered to the domain A 101, the service can be used via a path that is set up, which is indicated by a data exchange 505 between the domain A 101 and the domain C 103.
The design of the eBGP service-attribute may depend on, e.g., what kind of a business model is chosen and as how templates are utilized.
Hereinafter, some examples are provided. Every type of template may preferably carry enough information to specify the service or request in detail and at the same time, the template might be small enough to fit into a block so that it can be conveyed with a BGP UPDATE message. The size of a single BGP UPDATE message may in particular comprise 4096 octets. If this is regarded a major limitation, the template(s) can be split into several messages.
The examples are partially based on ETNA [BGU, BT, Ethos, NSN, TKK, Ethernet Transport Networks, Architectures of Networking, WP2 Network Architecture, 31.12.2008; available at http://www.ict-etna.eu/documents/ETNA WP2 Network and Service Architecture—D2.1 R2—Issue 2.pdf].
All templates may preferably have a portion that defines parameters of a service offered. There may be different templates, e.g.,
A single template could comprise several service offers or service requests. If the template reaches the limit of the size of the BGP UPDATE message, service offers or requests can be split into separate templates and/or messages.
It is also an option that the template comprises information regarding traffic characteristics of a service request or a service offer.
Transport, access, request and response templates may also comprise an identifier (ID) and/or an expiration time of the service template. Within the transport template, connection points, e.g., edge nodes or BGP routers can be identified. In an access template identity information may be provided that indicates to where an end host can be mapped. It is noted that aggregation information or other kind of information compression mechanisms could be applied. Such aggregation information may comprise information regarding aggregated multi-constrained paths. If different areas of a domain are advertized in more abstract service offers, some additional communication could be required to confirm that the actual level of QoS is accepted.
Request templates may have information about the requestor and a request number as well as service details that are requested (e.g., purchased). While the request is conveyed across domains, it may change its form and appearance like a request to a specific service offer each domain sends to its neighbor. An accept or reject template can otherwise be similar to the service request template, but it may have an accept or reject value set to some (e.g., HTTP style) status code indicating the reason of the decision.
An existing BGP definition can be amended by using a TE-attribute in a BGP message as suggested in this solution. Such BGP attribute may yet be optional and non-transitive, hence the use of it is not required according to BGP specifications and it will not be sent further to other domains in case it is not recognized.
When a BGP router recognizes the BGP attribute, it either may forward it to a CCE or handles the message itself depending on how the path calculation and allocation is done in this domain. The BGP may not forward the attribute to any other BGP router, be it iBGP or eBGP, because this BGP router may only advertise services it is directly selling. Even when using a distributed mechanism for TE-path calculation, only the information inside the template may be distributed to other routers. Following this logic, the respective domain which receives a service template is responsible to take into account the (e.g., traffic) characteristics and expenses of an inter-domain link.
To see if a peering eBGP router supports non-default BGP functions, a method called capability negotiations can be conducted (see RFC 3392, “Capabilities Advertisement with BGP-4”). This can be performed when routers initially make a peering connection or it can be performed later on, which enables the use of new features without any disturbance to the routing infrastructure. By using this feature, TES-BGP can be taken into service incrementally allowing only adjacent early adapters to benefit from it.
The solution presented herein in particular has the advantage that the domains providing inter-domain services remain uncoupled, i.e. they may independently maintain their internal processing, e.g., intra-domain path calculation and/or each domain may decide which CCE to use.
Another advantage is the flexibility of the approach presented, which allows implementing the functionality in an existing network by updating components of the network, e.g., the edge routers of the domains.
It is to be understood that the above description is illustrative of the invention and is not to be construed as limiting the invention. Especially, the exemplary description using the three domain model should not be considered as limiting. Various modifications and applications employing only two or more than three domains in various configurations may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2012/050016 | 1/2/2012 | WO | 00 | 7/2/2014 |
