WO2012084626A1 - Method for inter-domain communications - Google Patents

Method for inter-domain communications Download PDF

Info

Publication number
WO2012084626A1
WO2012084626A1 PCT/EP2011/072692 EP2011072692W WO2012084626A1 WO 2012084626 A1 WO2012084626 A1 WO 2012084626A1 EP 2011072692 W EP2011072692 W EP 2011072692W WO 2012084626 A1 WO2012084626 A1 WO 2012084626A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
domain
per
network domain
border router
Prior art date
Application number
PCT/EP2011/072692
Other languages
French (fr)
Inventor
Pedro A. ARANDA GUTIÉRREZ
Original Assignee
Telefonica, S.A.
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 Telefonica, S.A. filed Critical Telefonica, S.A.
Publication of WO2012084626A1 publication Critical patent/WO2012084626A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/033Topology update or discovery by updating distance vector protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing

Definitions

  • the present invention generally relates to a method for inter-domain communications between end network domains through an intermediate network domain, and more particularly to a method comprising explicitly notifying the intermediate network domain border router to the end network domains border routers about its relay capabilities.
  • IP networks are data networks which use the IP protocol. Data packets are switched in network nodes known as routers and transmitted between nodes through links. The switching decision is taken locally at each node.
  • Network Layer Reachability Information (NLRI) is exchanged between nodes in order to distribute reachability information and allow end-to-end data exchange between network nodes. NLRI is exchanged using so-called routing protocols.
  • the Internet is an extremely complex IP network, which inter-connects realms known as Autonomous System (AS).
  • AS is defined as a set of network nodes which exhibit a common and coherent routing policy with regards to a set of networks [6]. Routing protocols in IP networks can be classified by their scope. Interior routing protocols, such as RIP [2], OSPF [1 ], etc. are used within the scope of an AS. Exterior routing protocols are used to exchange information between the different ASes. Currently, the only network exterior protocol is the Border Gateway Protocol v4 (BGP- 4) [8].
  • IPv6 IPv6
  • IPv6 IPv6
  • the BGP-4 protocol is used in IPv4 networks and has been extended to cope with the IPv6 protocol [5].
  • Multiprotocol BGP-4 (mpBGP) as defined currently [7] supports IPv6 [5], route exchange for Virtual Private Networks (VPNs) in Multiprotocol Label Switching (MPLS) [9] et. al. Routing information exchange using BGP-4 always involved two and only two communicating parties, known as border routers. In order to exchange routing information regarding a specific routing protocol between ASes, information about the protocols supported by them is exchanged between the border routers during the establishment of the BGP-4 session. In this context, the supported protocols are called capabilities.
  • the process of capability exchange as currently defined in [4], contemplates an implicit agreement on the minimum common set of supported protocols on the negotiating networks. Thus, e. g. if one AS supports IPv4, IPv6 and mpBGP and the other AS supports IPv4 and IPv6 only, the capability exchange process will limit the routing information exchange between the ASes to IPv4 and IPv6.
  • IP networks One of the main factors in the evolution of IP networks is the possibility to transport non-IPv4 traffic over them using so-called tunnels. They allow encapsulating non-IP data packets in an IP packet, which then can be sent over an IP network. Examples for this technique are the IP in IP tunnel [10] or the tunnels used to connect IPv6 domains over and IPv4 network [3]. Tunnelling in IP networks involves creating an outer IP packet, which is used for transport purposes in the IP network. This outer packet contains the inner packet which is not understood by the IP network.
  • Figure 1 shows the general tunnelling mechanism.
  • the upper part of the figure shows the generalised packet format used when tunnelling.
  • the lower part of the figure shows the processing the packet is subjected to.
  • An outer header is prepended to the inner packet by the encapsulating device (A). This outer header is understood by the switching device (or devices) (B) and used by them to forward the packet towards its destination.
  • the destination is the decapsulating device (C) which removes the outer header and recovers the inner packet.
  • Figure 2 shows a basic Inter-domain Scenario, where the clouds 1 , 2 and 3 represent network domains, such as IP Autonomous Systems (AS), and the boxes 4, 5, 6 and 7 represent the border routers.
  • domains 1 and 3 support a networking technology that is not supported by domain 2.
  • border routers 4 and 5 will perform a capability exchange and determine that they can exchange IPv4 routing information, but not of the particular networking technology supported by AS 1 and AS 3. The same will happen between border routers 6 and 7.
  • An extra device that encapsulates the special traffic over IP will be needed in AS 1 and AS 3.
  • These devices not only encapsulate the user traffic, but also perform the routing information exchange for the technology AS 2 does not support. This routing information exchange ensures reachability from domain 1 to domain 3 and vice-versa.
  • the routing information and traffic information exchange is represented by the dotted line between the encapsulating devices 8 and 9 will be configured manually by the operator.
  • the intermediate autonomous system rejects the capabilities related to the technologies which it does not implement. That is, with reference to Fig. 2, let's suppose that AS 1 and AS 3 both support IPv4 and IPv6 and AS2 supports only IPv4. Today, when the capabilities exchange is performed, the end systems AS 1 and AS 3 tell the central one AS 2 that they support IPv4 and IPv6, while the central system AS 2 responds to them saying that it only supports IPv4 and then they agree to use all IPv4 only.
  • the intermediate system AS 2 is not aware of the tunnelling and tunnels are not aware that they are passing through the intermediate system AS 2. In general, this leads to the establishment of parallel topologies in the network with fictitious links between the tunnels which can result in loops, prolonged interruptions, etc.
  • AS 3 IPv4 + IPv6
  • AS 1 does not know that AS 3 supports IPv6 or, conversely, AS 3 does not realize that AS 1 supports MPLS.
  • Decoupling the transported traffic from the underlying transport infrastructure allows rapid technological advance but it also presents some disadvantages for the underlying carrier infrastructure, the most important of which is lack of control over the traffic it is carrying.
  • the present invention relates to a method for inter-domain communications, comprising transmitting information regarding a first network technology from a first network domain to a third network domain, or vice versa, through a second or intermediate network domain which does not support said first network technology, wherein in order to perform said sending of information the method comprises previously carrying out the next steps: - performing a first capabilities exchange between a border router of said first network domain and a first border router of said intermediate network domain; and
  • the method of the invention comprises, as part of said first and second capabilities exchanges, automatically and explicitly notifying said first border router of the intermediate network domain to said border router of the first network domain and said second border router of the intermediate network domain to said border router of the third network domain, that the intermediate network domain can relay natively routing information regarding said first network technology, despite not being able to handle said first technology in the data plane.
  • the intermediate network says that although it does not support a particular technology it is ready to carry routing information related thereto to another extreme, in which there is another network that does support it. With said 'CAN RELAY' option such information is explicitly present in every border router of the intermediate network domain.
  • the method comprises transmitting said routing information regarding said first network technology through said intermediate network domain without the control plane intervening on its infrastructure.
  • the method also comprises, according to an embodiment, transmitting data information implemented according to said first network technology through a data plane logically or physically separated from said control plane.
  • the method is not limited to the use of tunnelling mechanisms for the transmission on data, for an embodiment it comprises transmitting said data information implemented according to the first network technology through a tunnel established between the first and third network domains, said tunnel becomes a neutral virtual cable between network domains for which no routing information is transmitted.
  • This provides the above mentioned separation between data plane and control plane (routing) that currently do not exist.
  • the method of the invention provides a more easily evolving capacity towards environments in which the control plane and data plane are separated logically and physically (as, e.g., MPLS).
  • the method comprises, as per an embodiment, performing said transmission through the intermediate network domain natively by means of extensions to allow information regarding multiple network technologies to be transported over an inter-domain routing information exchange protocol, such as the Border Gateway Protocol 4, or BGP-4.
  • an inter-domain routing information exchange protocol such as the Border Gateway Protocol 4, or BGP-4.
  • said network domains are autonomous systems.
  • the method comprises, as part of respective capabilities exchanges analogous to said first and second ones, automatically and explicitly notifying the first border router of the intermediate network domain to the border routers of a plurality of network domains and/or said second border router of the intermediate network domain to the border routers of a plurality of network domains, that the intermediate network domain can relay natively routing information regarding at least said first network technology, such that a plurality of network domains are aware of that notifying information.
  • the method comprises using said explicit notifications, which provide knowledge about at least the first technology into which the data information is implemented, for controlling the data traffic circulating between the first and third network domains, or between any of said plurality of network domains.
  • An application which is carried out by the method of the invention, for an embodiment, is that of controlling the data traffic by performing one or more of the next actions:
  • the method comprises providing the explicit notifications to a management system, such as by including them as control information of an inter- domain routing protocol, such as the Border Gateway Protocol 4, or BGP-4.
  • a management system such as by including them as control information of an inter- domain routing protocol, such as the Border Gateway Protocol 4, or BGP-4.
  • the method comprises, for an embodiment, including said control information into a management database, such as the Management Information Base, or MIB.
  • a management database such as the Management Information Base, or MIB.
  • the access to said control information is carried out, according to an embodiment of the method of the first aspect through a command line interface, for example by means of a management protocol, such as the Simple Network Management Protocol (SNMP).
  • SNMP Simple Network Management Protocol
  • Figure 1 shows schematically a general tunnelling mechanism
  • Figure 2 shows a basic Inter-domain Scenario including three network domains, where routing information and traffic information is exchanged between 1 and 3 in an encapsulated form;
  • Figure 3 shows an alternative scenario to that of Figure 2, where the tunnelling functionality has been collapsed into the border routers of the end network domains.
  • Network domains 1 , 2 and 3 support a common set of technologies ⁇ T u ..., T n ⁇ .
  • Network domains 1 and 3 additionally, support a networking technology T new , which is not supported by domain 2.
  • the proposed method involves the following steps:
  • border routers 4 and 5 perform a capability exchange, where border router 4 sends a capability set ⁇ T ..., T n ,T new j to router 5 and router 5 sends a capability set ⁇ T ..., T n j to router 4.
  • Border router 5 responds to this handshake that it supports the set of technologies /T 7 ,..., 7 and that it can proxy routing information for T new . This is achieved by marking the capability for T new as 'CAN RELAY'.
  • border routers 4 and 5 will exchange routing information regarding all technologies included in capability set
  • Network Layer Reachability Information for T new from domain 1 will reach 3 and vice versa through network domain 2.
  • the tunnelling devices can be used to transport traffic between the two network domains 1 , 3 over network domain 2.
  • Routing information for technologies families that have been marked as 'CAN RELAY' is exchanged as-is in network domain 2 and not subject to any routing protocol computations.
  • the network domain 1 does not know that network domain 3 supports a specific technology, such as IPv6 or, conversely, network domain 3 does not realize that network domain 1 supports another specific technology, such as MPLS.
  • IPv6 a specific technology
  • MPLS another specific technology
  • this invention is implemented in IP networks.
  • the network domains 1 , 2 and 3 are Autonomous Systems and border routers 4, 5, 6 and 7 are running, for example, the BGP-4 [8] routing protocol.
  • BGP-4 has a capability exchange mechanism [4], which would have to be extended to implement the 'CAN RELAY' feature.
  • This invention offers a solution to bridge the time-gap from the moment clients adopt a certain technology until the provider domain is ready to support it.
  • This invention automates the end-to-end tunnel establishment process.
  • This process is difficult to automate with routing information only. It requires interaction at the Command Line Interface (CLI) level or automatic systems where the control plane of the intermediate network influences its core infrastructure.
  • CLI Command Line Interface

Abstract

Comprises performing: - a first capabilities exchange between a border router (4) of a first network domain (1) and a first border router (5) of an intermediate network domain (2), and - a second capabilities exchange between a second border router (6) of the intermediate network domain (2) and a border router (7) of a third network domain (3); It also comprises, as part of the first and second capabilities exchanges, automatically and explicitly notifying the first border router (5) of the intermediate network domain (2) to the border router (4) of the first network domain (1) and the second border router (6) of the intermediate network domain (2) to the border router (7) of the third network domain (3), that the intermediate network domain (2) can relay natively routing information regarding the first network technology, despite not being able to handle said first technology in the data plane.

Description

Method for inter-domain communications
Field of the art
The present invention generally relates to a method for inter-domain communications between end network domains through an intermediate network domain, and more particularly to a method comprising explicitly notifying the intermediate network domain border router to the end network domains border routers about its relay capabilities. Prior State of the Art
IP networks are data networks which use the IP protocol. Data packets are switched in network nodes known as routers and transmitted between nodes through links. The switching decision is taken locally at each node. Network Layer Reachability Information (NLRI) is exchanged between nodes in order to distribute reachability information and allow end-to-end data exchange between network nodes. NLRI is exchanged using so-called routing protocols.
The Internet is an extremely complex IP network, which inter-connects realms known as Autonomous System (AS). An AS is defined as a set of network nodes which exhibit a common and coherent routing policy with regards to a set of networks [6]. Routing protocols in IP networks can be classified by their scope. Interior routing protocols, such as RIP [2], OSPF [1 ], etc. are used within the scope of an AS. Exterior routing protocols are used to exchange information between the different ASes. Currently, the only network exterior protocol is the Border Gateway Protocol v4 (BGP- 4) [8].
The commercial success of the Internet has resulted in the exhaustion of IPv4 addresses. To cope with this problem and preserve the end-to-end principle of the Internet, a new version of IP is being introduced and deployed in the network, which is known as IPv6. This new version increases the available addressing space by increasing the IP address field length from 32 bits to 128 bits. The BGP-4 protocol is used in IPv4 networks and has been extended to cope with the IPv6 protocol [5].
In order to support IPv6 addresses, BGP-4 has extended by the so-called multiprotocol extensions. Multiprotocol BGP-4 (mpBGP) as defined currently [7] supports IPv6 [5], route exchange for Virtual Private Networks (VPNs) in Multiprotocol Label Switching (MPLS) [9] et. al. Routing information exchange using BGP-4 always involved two and only two communicating parties, known as border routers. In order to exchange routing information regarding a specific routing protocol between ASes, information about the protocols supported by them is exchanged between the border routers during the establishment of the BGP-4 session. In this context, the supported protocols are called capabilities. The process of capability exchange, as currently defined in [4], contemplates an implicit agreement on the minimum common set of supported protocols on the negotiating networks. Thus, e. g. if one AS supports IPv4, IPv6 and mpBGP and the other AS supports IPv4 and IPv6 only, the capability exchange process will limit the routing information exchange between the ASes to IPv4 and IPv6.
One of the main factors in the evolution of IP networks is the possibility to transport non-IPv4 traffic over them using so-called tunnels. They allow encapsulating non-IP data packets in an IP packet, which then can be sent over an IP network. Examples for this technique are the IP in IP tunnel [10] or the tunnels used to connect IPv6 domains over and IPv4 network [3]. Tunnelling in IP networks involves creating an outer IP packet, which is used for transport purposes in the IP network. This outer packet contains the inner packet which is not understood by the IP network.
Similar mechanisms are used in MPLS networks [9], where the outer header contains labels which are used in the MPLS switching nodes to provide a switching mechanism which is more efficient than the IP lookup table.
Figure 1 shows the general tunnelling mechanism. The upper part of the figure shows the generalised packet format used when tunnelling. The lower part of the figure shows the processing the packet is subjected to. An outer header is prepended to the inner packet by the encapsulating device (A). This outer header is understood by the switching device (or devices) (B) and used by them to forward the packet towards its destination. The destination is the decapsulating device (C) which removes the outer header and recovers the inner packet.
In this context, the current solutions to provide connectivity of specific technological islands -e.g. networks using IPv6 over an IPv4 or ATM or Ethernet networks over an MPLS infrastructure- decouple the underlying carrier infrastructure from the technology it provides connectivity to.
Figure 2 shows a basic Inter-domain Scenario, where the clouds 1 , 2 and 3 represent network domains, such as IP Autonomous Systems (AS), and the boxes 4, 5, 6 and 7 represent the border routers. In this scenario, domains 1 and 3 support a networking technology that is not supported by domain 2. For a service point of view, and in order to interconnect clients in domains 1 and 3, tunnels must be used. In an IP environment and from a routing point of view, when the BGP-4 sessions are established, border routers 4 and 5 will perform a capability exchange and determine that they can exchange IPv4 routing information, but not of the particular networking technology supported by AS 1 and AS 3. The same will happen between border routers 6 and 7. An extra device that encapsulates the special traffic over IP will be needed in AS 1 and AS 3. These devices (represented by triangles 8 and 9) not only encapsulate the user traffic, but also perform the routing information exchange for the technology AS 2 does not support. This routing information exchange ensures reachability from domain 1 to domain 3 and vice-versa. The routing information and traffic information exchange is represented by the dotted line between the encapsulating devices 8 and 9 will be configured manually by the operator.
Problems with existing solutions:
Now, when establishing the capabilities exchange between border routers only the capabilities which are supported in those networks to which the border routers belong are indicated, but no information is given about the technologies not supported by a central network (2 in Figure 2) but which routing information is ready to carry there through.
Therefore, at present: either the technology of the two end networks (1 and 3 in Figure 2) must be implemented in the central network (2), or said end networks (1 and 3) manage to mount a tunnel and the intermediate network (2) does not even realize.
Now, the intermediate autonomous system rejects the capabilities related to the technologies which it does not implement. That is, with reference to Fig. 2, let's suppose that AS 1 and AS 3 both support IPv4 and IPv6 and AS2 supports only IPv4. Today, when the capabilities exchange is performed, the end systems AS 1 and AS 3 tell the central one AS 2 that they support IPv4 and IPv6, while the central system AS 2 responds to them saying that it only supports IPv4 and then they agree to use all IPv4 only.
The intermediate system AS 2 is not aware of the tunnelling and tunnels are not aware that they are passing through the intermediate system AS 2. In general, this leads to the establishment of parallel topologies in the network with fictitious links between the tunnels which can result in loops, prolonged interruptions, etc.
In general the border routers of the central system AS 2 perform the capabilities exchanges independently. It could give the following case: AS 1 : IPv4 + MPLS
AS 2: IPv4
AS 3: IPv4 + IPv6 Currently, the AS 1 does not know that AS 3 supports IPv6 or, conversely, AS 3 does not realize that AS 1 supports MPLS.
Presently, when a tunnel is established, it is responsible for transporting both the data and the traffic routing information within. Having no knowledge of the external situation, this can lead to situations in which the tunnel is routed along paths that are not optimal.
Decoupling the transported traffic from the underlying transport infrastructure allows rapid technological advance but it also presents some disadvantages for the underlying carrier infrastructure, the most important of which is lack of control over the traffic it is carrying.
Currently, there is no way for an intermediate domain to signal that it is willing to allow tunnelled traffic for a specific inner protocol to pass through its infrastructure. Additionally, tunnelling devices have to be configured, generally manually, although there are proposals which provide an automatic generation of tunnels, such is the case of US7570638B2 and RFC5747 (available online at http://www.rfc- archive. org/getrfc.php?rfc=5747&tag=4over6-Transit-Solution-Using-IP-Encapsulation- and-MP-BGP-Extensions), but they are not based in the above mentioned intermediate domain signalling. Moreover, in the system disclosed by US7570638B2 the control plane of the intermediate network influences its core infrastructure. Description of the Invention
It is necessary to offer an alternative to the state of the art, which covers the gaps found therein, particularly those related to the lack of control information about the traffic circulating through an intermediate network domain of an Inter-domain Scenario.
To that end, the present invention relates to a method for inter-domain communications, comprising transmitting information regarding a first network technology from a first network domain to a third network domain, or vice versa, through a second or intermediate network domain which does not support said first network technology, wherein in order to perform said sending of information the method comprises previously carrying out the next steps: - performing a first capabilities exchange between a border router of said first network domain and a first border router of said intermediate network domain; and
- performing a second capabilities exchange between a second border router of said intermediate network domain and a border router of said third network domain.
On contrary to conventional method, the method of the invention comprises, as part of said first and second capabilities exchanges, automatically and explicitly notifying said first border router of the intermediate network domain to said border router of the first network domain and said second border router of the intermediate network domain to said border router of the third network domain, that the intermediate network domain can relay natively routing information regarding said first network technology, despite not being able to handle said first technology in the data plane.
By said explicit notification, or 'CAN RELAY' option, the intermediate network says that although it does not support a particular technology it is ready to carry routing information related thereto to another extreme, in which there is another network that does support it. With said 'CAN RELAY' option such information is explicitly present in every border router of the intermediate network domain.
For an embodiment, the method comprises transmitting said routing information regarding said first network technology through said intermediate network domain without the control plane intervening on its infrastructure.
The method also comprises, according to an embodiment, transmitting data information implemented according to said first network technology through a data plane logically or physically separated from said control plane.
Although the method is not limited to the use of tunnelling mechanisms for the transmission on data, for an embodiment it comprises transmitting said data information implemented according to the first network technology through a tunnel established between the first and third network domains, said tunnel becomes a neutral virtual cable between network domains for which no routing information is transmitted. This provides the above mentioned separation between data plane and control plane (routing) that currently do not exist. Hence, by the method of the invention provides a more easily evolving capacity towards environments in which the control plane and data plane are separated logically and physically (as, e.g., MPLS).
A for the transmission of routing information regarding the first network technology is concerned, the method comprises, as per an embodiment, performing said transmission through the intermediate network domain natively by means of extensions to allow information regarding multiple network technologies to be transported over an inter-domain routing information exchange protocol, such as the Border Gateway Protocol 4, or BGP-4.
For an embodiment, said network domains are autonomous systems.
Until now the method of the invention has been described with reference to the communications, through the intermediate network domain, between two respective end network domains, the above referred as first and third ones, but for other embodiments the method comprises, as part of respective capabilities exchanges analogous to said first and second ones, automatically and explicitly notifying the first border router of the intermediate network domain to the border routers of a plurality of network domains and/or said second border router of the intermediate network domain to the border routers of a plurality of network domains, that the intermediate network domain can relay natively routing information regarding at least said first network technology, such that a plurality of network domains are aware of that notifying information.
For an embodiment, the method comprises using said explicit notifications, which provide knowledge about at least the first technology into which the data information is implemented, for controlling the data traffic circulating between the first and third network domains, or between any of said plurality of network domains.
An application which is carried out by the method of the invention, for an embodiment, is that of controlling the data traffic by performing one or more of the next actions:
- tuning specific network parameters to optimise the transport of a specific traffic;
- charging data traffic differently according to its type; and
- intercepting specific data traffic for legal requirements and evaluating from the type and amount of a specific traffic when is worthwhile for the intermediate network domain to be modified to support said first network technology.
As per an embodiment, the method comprises providing the explicit notifications to a management system, such as by including them as control information of an inter- domain routing protocol, such as the Border Gateway Protocol 4, or BGP-4.
The method comprises, for an embodiment, including said control information into a management database, such as the Management Information Base, or MIB.
The access to said control information is carried out, according to an embodiment of the method of the first aspect through a command line interface, for example by means of a management protocol, such as the Simple Network Management Protocol (SNMP).
Brief Description of the Drawings
The previous and other advantages and features will be more fully understood from the following detailed description of some embodiments, with reference to the attached drawings (some of which have already been referred for the description done in the Prior State of the Art section), which must be considered in an illustrative and non-limiting manner, in which:
Figure 1 shows schematically a general tunnelling mechanism;
Figure 2 shows a basic Inter-domain Scenario including three network domains, where routing information and traffic information is exchanged between 1 and 3 in an encapsulated form; and
Figure 3 shows an alternative scenario to that of Figure 2, where the tunnelling functionality has been collapsed into the border routers of the end network domains.
Detailed Description of several Embodiments
In order to provide a detailed technical description of the invention, all involved parties will be designated with the numbering used in Figure 2. This numbering is also used in Figure 3, which presents an alternative scenario, where the tunnelling functionality has been collapsed into the border routers. Both figures are equivalent, regarding the proposed method.
The following assumptions are made:
• Network domains 1 , 2 and 3 support a common set of technologies {Tu..., Tn}.
• Network domains 1 and 3, additionally, support a networking technology Tnew, which is not supported by domain 2.
The proposed method involves the following steps:
1 . When network domains 1 and 2 are connected, border routers 4 and 5 perform a capability exchange, where border router 4 sends a capability set {T ..., Tn,Tnewj to router 5 and router 5 sends a capability set {T ..., Tnj to router 4. Border router 5 responds to this handshake that it supports the set of technologies /T7,..., 7 and that it can proxy routing information for Tnew. This is achieved by marking the capability for Tnew as 'CAN RELAY'.
At this point, border routers 4 and 5 will exchange routing information regarding all technologies included in capability set
Figure imgf000009_0001
When network domains 2 and 3 are interconnected, the equivalent process occurs between border routers 6 and 7.
At this point, Network Layer Reachability Information for Tnew from domain 1 will reach 3 and vice versa through network domain 2.
Once network domain 1 has processed the routing information for Tnew coming from network domain 3 and vice versa, the tunnelling devices can be used to transport traffic between the two network domains 1 , 3 over network domain 2.
Routing information for technologies families that have been marked as 'CAN RELAY' is exchanged as-is in network domain 2 and not subject to any routing protocol computations.
Currently, the network domain 1 does not know that network domain 3 supports a specific technology, such as IPv6 or, conversely, network domain 3 does not realize that network domain 1 supports another specific technology, such as MPLS. By means of the present invention, particularly thanks to the 'CAN RELAY' option such information is explicitly present in every border router 5, 6 of network domain 2.
For an embodiment, this invention is implemented in IP networks. In this case, the network domains 1 , 2 and 3 are Autonomous Systems and border routers 4, 5, 6 and 7 are running, for example, the BGP-4 [8] routing protocol. BGP-4 has a capability exchange mechanism [4], which would have to be extended to implement the 'CAN RELAY' feature. Advantages of the Invention:
The main advantages of the proposed procedure in comparison with State of the Art solutions are:
• This invention offers a solution to bridge the time-gap from the moment clients adopt a certain technology until the provider domain is ready to support it.
• This invention automates the end-to-end tunnel establishment process. Nowadays, this process is difficult to automate with routing information only. It requires interaction at the Command Line Interface (CLI) level or automatic systems where the control plane of the intermediate network influences its core infrastructure.
• The deployment path for new technologies is simplified; o Native routing information is exchanged from the moment of the first deployment of a new technology in the inter-domain links. I.e., Intermediate network domain 2 transparently carries routing information of a new protocol or technology (and hence of a service) through its control plane without investing in new equipment or improvements to its existing equipment to support this new technology. o Routing information for Tnew is handled by BGP-4 border routers: when AS2 decides to support this new technology, the migration consists in disabling the tunnelling devices or the tunnelling functionality in the border routers.
• Intermediate network domain 2 has knowledge of the technologies it needs to support in order to offer new services to its clients (network domains 1 and 3), said knowledge serving to determine when it is profitable to offer this service to its clients natively, so that they can stop using tunnelling. A person skilled in the art could introduce changes and modifications in the embodiments described without departing from the scope of the invention as it is defined in the attached claims.
ACRONYMS AND ABBREVIATIONS
AS Autonomous System
BGP-4 Border Gateway Protocol v4
CLI Command Line Interface
DPI Deep Packet Inspection
eBGP Exterior BGP-4
iBGP Interior BGP-4
mpBGP Multiprotocol BGP-4
MPLS Multiprotocol Label Switching
NLRI Network Layer Reachability Information
VPN Virtual Private Network
OSPF charter. http://www.ietf.org/html.charters/ospf- charter.html. Last visit, 08-Mar-2010.
RIP version 2. http://tools.ietf.org/html/rfc2453. Last visit, 08- Mar-2010.
B. Carpenter and K. Moore. Connection of IPv6 Domains via IPv4 Clouds, http://www.faqs.org/rfcs/rfc3056.html, February 2001 . Last visit, 08-Mar-2010.
Ravi Chandra and John G. Scudder. Capabilities Advertisement with BGP-4. http://www.ietf.org/rfc/rfc3392.txt, November 2002. Last visit, 08-Mar-2010.
S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification, http://tools.ietf.org/html/rfc2460, December 1998. Last visit, 08-Mar-2010.
John Hawkinson and Tony Bates. Guidelines for creation, selection, and registration of an Autonomous System (AS). http://tools.ietf.org/html/rfc1930, March 1996. Last visit, 08-Mar- 2010.
P. Marques and F. Dupont. Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. http://tools.ietf.org/html/rfc2545. Last visit, 08-Mar-2010.
Yakov Rekhter, Tony Li, and Susan Hares. A Border Gateway Protocol 4 (BGP-4). http://tools.ietf.org/html/rfc4271 , January 2006. Last visit, 08-Mar-2010.
E. Rosen and Y. Rekhter. BGP/MPLS IP Virtual Private Networks, http://tools.ietf.org/html/rfc4364, February 2006. Last visit, 08-Mar-2010.
W. Simpson. IP in IP Tunneling. http://www.faqs.org/rfcs/rfc1853.html, October 1995. Last visit, 08-Mar-2010.

Claims

Claims
1 . - Method for inter-domain communications, comprising transmitting information regarding a first network technology from a first network domain (1 ) to a third network domain (3), or vice versa, through a second or intermediate network domain (2) which does not support said first network technology, wherein in order to perform said sending of information the method comprises previously carrying out the next steps:
- performing a first capabilities exchange between a border router (4) of said first network domain (1 ) and a first border router (5) of said intermediate network domain (2); and
- performing a second capabilities exchange between a second border router (6) of said intermediate network domain (2) and a border router (7) of said third network domain (3);
the method being characterised in that it comprises, as part of said first and second capabilities exchanges, automatically and explicitly notifying said first border router (5) of the intermediate network domain (2) to said border router (4) of the first network domain (1 ) and said second border router (6) of the intermediate network domain (2) to said border router (7) of the third network domain (3), that the intermediate network domain (2) can relay natively routing information regarding said first network technology, despite not being able to handle said first technology in the data plane.
2. - Method as per claim 1 , comprising transmitting said routing information regarding said first network technology through said intermediate network domain (2) without the control plane intervening on its infrastructure.
3.- Method as per claim 2, comprising transmitting data information implemented according to said first network technology through a data plane logically or physically separated from said control plane.
4. - Method as per any of the previous claims, comprising transmitting said data information implemented according to said first network technology through a tunnel established between said first (1 ) and third (3) network domains.
5. - Method as per any of the previous claims, comprising transmitting said routing information regarding said first network technology through said intermediate network domain (2) natively by means of extensions to allow information regarding multiple network technologies to be transported over an inter-domain routing information exchange protocol.
6. - Method as per any of the previous claims, wherein said network domains (1 , 2, 3) are autonomous systems.
7. - Method as per claim 6 when depending on claim 5, wherein said information exchange protocol is the Border Gateway Protocol 4, or BGP-4.
8.- Method as per any of the previous claims, comprising, as part of respective capabilities exchanges analogous to said first and second ones, automatically and explicitly notifying said first border router (5) of the intermediate network domain (2) to the border routers of a plurality of network domains and/or said second border router (6) of the intermediate network domain (2) to the border routers of a plurality of network domains, that the intermediate network domain (2) can relay natively routing information regarding at least said first network technology.
9. - Method as per any of the previous claims, comprising using said explicit notifications, which provides knowledge about at least the first technology into which the data information is implemented, for controlling the data traffic circulating between said first (1 ) and third (3) network domains.
10. - Method as per claim 9, comprising controlling said data traffic by performing at least one of tuning specific network parameters to optimise the transport of a specific traffic, charging data traffic differently according to its type, intercepting specific data traffic for legal requirements and evaluating from the type and amount of a specific traffic when is worthwhile for the intermediate network domain (2) to be modified to support said first network technology.
1 1 . - Method as per any of the previous claims, comprising providing said explicit notifications to a management system.
12. - Method as per claim 1 1 , comprising carrying out said explicit notifications providing by including said notifications as control information of an inter-domain routing protocol.
13. - Method as per claim 12, wherein said information inter-domain routing protocol is the Border Gateway Protocol 4, or BGP-4.
14. - Method as per claim 12, comprising including said control information into a management database.
15. - Method as per claim 14, wherein said management database is the Management Information Base, or MIB.
16. - Method as per claim 14 or 15, comprising accessing said control information through a command line interface.
17. - Method as per claim 16, comprising accessing said control information through a management protocol.
18. - Method as per claim 17, wherein said management protocol is the Simple Network Management Protocol, or SNMP.
PCT/EP2011/072692 2010-12-20 2011-12-14 Method for inter-domain communications WO2012084626A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ESP201031889 2010-12-20
ES201031889A ES2388288B1 (en) 2010-12-20 2010-12-20 METHOD FOR COMMUNICATIONS BETWEEN DOMAINS.

Publications (1)

Publication Number Publication Date
WO2012084626A1 true WO2012084626A1 (en) 2012-06-28

Family

ID=45558002

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/072692 WO2012084626A1 (en) 2010-12-20 2011-12-14 Method for inter-domain communications

Country Status (3)

Country Link
AR (1) AR084363A1 (en)
ES (1) ES2388288B1 (en)
WO (1) WO2012084626A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3073774A1 (en) 2015-03-23 2016-09-28 Thomson Licensing Automatic configuration of a wireless residential access network
CN111698454A (en) * 2019-03-12 2020-09-22 浙江宇视科技有限公司 Inter-domain resource pushing method and device for dynamically selecting optimal path

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050259655A1 (en) * 2004-05-20 2005-11-24 Alcatel Open service discovery and routing mechanism for configuring cross-domain telecommunication services
US7570638B2 (en) 2005-05-18 2009-08-04 Fujitsu Limited Inter-domain routing technique using MPLS

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6553423B1 (en) * 1999-05-27 2003-04-22 Cisco Technology, Inc. Method and apparatus for dynamic exchange of capabilities between adjacent/neighboring networks nodes
EP1751935B1 (en) * 2004-05-20 2009-01-07 Alcatel Lucent Open service discovery and routing mechanism for configuring cross-domain telecommunication services

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050259655A1 (en) * 2004-05-20 2005-11-24 Alcatel Open service discovery and routing mechanism for configuring cross-domain telecommunication services
US7570638B2 (en) 2005-05-18 2009-08-04 Fujitsu Limited Inter-domain routing technique using MPLS

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
B. CARPENTER; K. MOORE, CONNECTION OF IPV6 DOMAINS VIA IPV4 CLOUDS, February 2001 (2001-02-01), Retrieved from the Internet <URL:http://www.faqs.org/rfcs/rfc3056.html>
E. ROSEN; Y. REKHTER, BGP/MPLS IP VIRTUAL PRIVATE NETWORKS, February 2006 (2006-02-01), Retrieved from the Internet <URL:http://tools.ietf.org/html/rfc4364>
JOHN HAWKINSON; TONY BATES, GUIDELINES FOR CREATION, SELECTION, AND REGISTRATION OF AN AUTONOMOUS SYSTEM (AS, 8 March 2010 (2010-03-08), Retrieved from the Internet <URL:http://tools.ietf.org/html/rfc1930>
OSPF CHARTER, 8 March 2010 (2010-03-08), Retrieved from the Internet <URL:http://www.ietf.org/html.charters/ospf- charter.html>
P. MARQUES; F. DUPONT, USE OF BGP-4 MULTIPROTOCOL EXTENSIONS FOR IPV6 INTER-DOMAIN ROUTING, 8 March 2010 (2010-03-08), Retrieved from the Internet <URL:http://tools.ietf.org/html/rfc2545>
RAVI CHANDRA; JOHN G. SCUDDER, CAPABILITIES ADVERTISEMENT WITH BGP-4, November 2002 (2002-11-01), Retrieved from the Internet <URL:http://www.ietf.org/rfc/rfc3392.txt>
RIP VERSION 2, 8 March 2010 (2010-03-08), Retrieved from the Internet <URL:http://tools.ietf.org/html/rfc2453>
S. DEERING; R. HINDEN, INTERNET PROTOCOL, VERSION 6 (IPV6) SPECIFICATION, December 1998 (1998-12-01), Retrieved from the Internet <URL:http://tools.ietf.org/html/rfc2460>
W. SIMPSON, IP IN IP TUNNELING, 8 March 2010 (2010-03-08), Retrieved from the Internet <URL:http://www.faqs.org/rfcs/rfc1853.htm>
WU Y CUI X LI TSINGHUA UNIVERSITY C METZ G NALAWADE S BARBER P MOHAPATRA CISCO SYSTEMS J ET AL: "A Framework for Softwire Mesh Signaling, Routing and Encapsulation across IPv4 and IPv6 Backbone Networks; draft-wu-softwire-mesh-framew ork-00.txt", 20060617, 17 June 2006 (2006-06-17), XP015045086, ISSN: 0000-0004 *
YAKOV REKHTER; TONY LI; SUSAN HARES, A BORDER GATEWAY PROTOCOL 4 (BGP-4, January 2006 (2006-01-01)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3073774A1 (en) 2015-03-23 2016-09-28 Thomson Licensing Automatic configuration of a wireless residential access network
WO2016150817A1 (en) 2015-03-23 2016-09-29 Thomson Licensing Automatic configuration of a wireless residential access network
US10749749B2 (en) 2015-03-23 2020-08-18 Interdigital Madison Patent Holdings, Sas Automatic configuration of a wireless residential access network
CN111698454A (en) * 2019-03-12 2020-09-22 浙江宇视科技有限公司 Inter-domain resource pushing method and device for dynamically selecting optimal path
CN111698454B (en) * 2019-03-12 2022-12-23 浙江宇视科技有限公司 Inter-domain resource pushing method and device for dynamically selecting optimal path

Also Published As

Publication number Publication date
ES2388288B1 (en) 2013-06-11
ES2388288A1 (en) 2012-10-11
AR084363A1 (en) 2013-05-08

Similar Documents

Publication Publication Date Title
CN107637031B (en) Path computation element central controller for network traffic
US9729348B2 (en) Tunnel-in-tunnel source address correction
US20210135902A1 (en) Deterministic forwarding across l2 and l3 networks
EP1713197B1 (en) A method for implementing the virtual leased line
EP2933958B1 (en) Segment routing - egress peer engineering (SP-EPE)
US9306855B2 (en) System and method for using label distribution protocol (LDP) in IPv6 networks
US20210377173A1 (en) Data forwarding method and related apparatus
US7486659B1 (en) Method and apparatus for exchanging routing information between virtual private network sites
US7710872B2 (en) Technique for enabling traffic engineering on CE-CE paths across a provider network
US7765306B2 (en) Technique for enabling bidirectional forwarding detection between edge devices in a computer network
US20060062218A1 (en) Method for establishing session in label switch network and label switch node
US20080123651A1 (en) Path diversity for customer-to-customer traffic
WO2009086931A1 (en) Setting up a virtual private network
EP3989511A1 (en) Supporting multiple transport options for border gateway protocol
US20140136714A1 (en) Method for exchanging information about network resources
US6785273B1 (en) Traffic engineering for an application employing a connectionless protocol on a network
WO2012084626A1 (en) Method for inter-domain communications
EP3941006B1 (en) System and method for carrying and optimizing internet traffic over a source-selected path routing 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: 11813873

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: 11813873

Country of ref document: EP

Kind code of ref document: A1