The present disclosure relates to computer networks, and in particular, multilayer computer networks.
Network infrastructures may employ multiple layer networks. For example, a network may comprise both an Internet Protocol (IP) network layer, as well as an optical network layer. Often, the separate network layers will exhibit different bandwidth availability at a particular time and for a particular application.
Multiprotocol Label Switching (MPLS) is a mechanism in high-performance networks that directs data from one network node to the next based on short path labels rather than long network addresses, avoiding complex lookups in a routing table. The labels identify virtual links (paths) between distant nodes rather than endpoints. MPLS can encapsulate packets of various network protocols. The Generalized Multi-Protocol Label Switching (GMPLS) is a protocol suite extending MPLS to manage further classes of interfaces and switching technologies other than packet interfaces and switching, such as time division multiplex, layer-2 switch, wavelength switch and fiber-switch.
A path computation element (PCE) is a system component, application, or network node that is capable of determining and finding a suitable route for conveying data between a source and a destination. In MPLS and GMPLS networks, the PCE is used to determine the path through the network that traffic should follow, and provides the route for each Label Switch Path (LSP) that is set up. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for sophisticated path computation.
Overview
Bandwidth usage for an existing communication tunnel between a first device and second device is monitored. A determination is made that additional bandwidth is required for communication between the first network device and the second network device is received. A determination is made that the addition of the additional bandwidth would exceed available bandwidth for the existing tunnel. Additional bandwidth is established between the first network device and the second network device.
Example Embodiments
With reference made to
According to example network environment 100, the first network layer 105 may be an Open System Interconnection (OSI) model layer 3 network such as an internet protocol (IP), or packet network. First network layer 105 includes multiple routers 120a-e interconnected through network links 122a-d. The second network layer 110 may be an optical network which resides at the OSI layer 0, and includes multiple optical nodes 125a-c interconnected through optical links 127a-c. Accordingly, the routers 120a-e can intercommunicate, as can optical nodes 125a-c. Furthermore, the first network layer 105 routers 120a-e can communicate with the second network layer 110 optical nodes 125a-c through network layer interfaces 115a-c.
While a layer 3 network layer is combined with an optical network layer in network environment 100, other example network environments are not limited to specific OSI layers, or network technology. For example, other example network environments may comprise OSI layer-2 networks combined with IP or layer 3 networks.
Also illustrated in
Included in PCE 130 is bandwidth on-demand functional unit 135, which is configured to provide on-demand bandwidth for communications between one or more of routers 120a-e and optical nodes 125a-c. For example, two of routers 120a-e may be communicating through a communication tunnel passing through one or more network links 122a-d. Additional bandwidth for the communication may be required that exceeds the abilities of the maximum bandwidth of the current communication tunnel. Bandwidth on demand functional unit 135 is configured to provide additional, on-demand bandwidth as described below in reference to
With reference now made to
In 210, a determination is made that additional bandwidth is required for communication between the network device and the second network device. According to one example, and as described below with reference to
In 215, a determination is made that the addition of the additional bandwidth would exceed the available bandwidth in the existing communication tunnel. For example, if a communication tunnel is using 7 gigabytes of bandwidth over 10 gigabyte network links, a request for an additional 8 gigabytes of bandwidth could not be fulfilled over the established communication tunnel. Remaining with the example of the stateful PCE, because the stateful PCE monitors the communications between the two network devices, it can perform the calculations necessary to determine whether or not the current communication tunnel is capable of providing the requested bandwidth. A non-stateful PCE, on the other hand, would not be aware that the existing tunnel is in use, much less, the current bandwidth utilization of the existing tunnel. Accordingly, a non-stateful PCE could not easily determine whether or not the request for additional bandwidth could be met by the network links utilized by the existing tunnel.
According to other examples, the established communication tunnel may communicate through networks links which can handle additional bandwidth, even though the bandwidth allocation for the established communication tunnel is less than the bandwidth needed for the communications between the first device and the second device. A stateful PCE may determine that the bandwidth necessary for communication exceeds the bandwidth allocation for the existing communication tunnel.
Finally, in 220, additional bandwidth is established between the first network device and the second network device. For example, an additional communication tunnel may be established between the first device and the second device in order to fulfill the bandwidth request received in 210. The additional communication tunnel may span two or more network layers, as shall be described below in reference to
Turning now to
Initially in
PCE 130 monitors the communications over communication tunnel 305 until bandwidth request message 310 is received by PCE 130 from router 120a. If request message 310 is a message requesting an additional 2 gigabytes of bandwidth, PCE 130 may respond by expanding existing communication tunnel 305. Specifically, because links 122a and 112b are 10 gigabyte links, and a total of 9 gigabytes is needed (the existing 7 gigabytes plus the additional 2 gigabytes), PCE may be to determine that existing communication tunnel may be expanded to accommodate the additionally requested bandwidth. On the other hand, if request message 310 requests an additional 8 gigabytes of bandwidth for communication between router 120a and router 120b, network links 122a and 122b are incapable of supporting a total bandwidth of 15 gigabytes.
Because PCE 130 is stateful, and has been monitoring existing tunnel 305, PCE 130, and bandwidth on demand functional unit 135 in particular, is aware that tunnel 305 is incapable of fulfilling the request for an additional 7 gigabytes of bandwidth as requested in request message 310. Accordingly, bandwidth on demand functional unit 135 will send message 315 to router 120a, providing a path for an additional communication tunnel 325 through second network layer 110.
If PCE 130 is aware of the topology of both first network layer 105 and second network layer 110, message 315 sent by bandwidth on-demand functional unit 135 may explicitly define the entire path from router 120a to router 120b through the second network layer 110. For example, if router 120a and router 120b communicate according to a label switched path (LSP) protocol, such as Multiprotocol Label Switching (MPLS) or Generalized Multiprotocol Label Switching (GMPLS), and PCE 130 is aware of the topology of second network layer 110, message 315 may include the entire LSP from router 120a to 120b. Specifically, message 315 may explicitly define the path for tunnel 325 which includes network layer interface 115a, optical node 125a, optical path 127a, optical node 125b, and network layer interface 115b. Upon receiving message 315, router 120a may establish a circuit for tunnel 325, and begin communicating through communication tunnel 325. Message 315 may take the form of an LSP “Create” message sent according to the Path Computation Element Protocol (PCEP). Specifically, message 315 may include an explicit route object (ERO) defining the path from router 120a to router 120b.
In order to establish tunnel 325, router 120a may first send the LSP data to router 120b, thereby establishing a circuit for tunnel 325. The sending of the LSP information to router 120b may take the form of a Resource Reservation Protocol—Traffic Engineering (RSVP-TE) message. An RSVP-TE generally allows for the establishment of MPLS LSPs, taking into consideration network constraint parameters such as available bandwidth and explicit hops.
According to another example, the creation of tunnel 325 includes PCE 130 sending message 320 to router 120b in addition to sending message 315 to router 120a. Each of messages 315 and 320 include the LSP information necessary to establish tunnel 325 for a bi-directional GMPLS LSP.
When the establishment of bandwidth on demand communication tunnel 325 is implemented in a GMPLS environment, the techniques herein may extend the PCEP LSP Create Message with the LSP_TUNNEL_INTERFACE_ID Object. Specifically, the LSP_TUNNEL_INTERFACE_ID Object is configured to communicate LSP provisioning information from the ingress node (router 120a) to the egress node (router 120b).
When the single sided provisioning model is used (i.e. only message 315 is sent from PCE 130, and message 320 is not utilized) in which RSVP-TE signaling is implemented, an LSP Request Message with an LSP_TUNNEL_INTERFACE_ID object in the RSVP TE Path message is sent from router 120a to router 120b.
Once new communication tunnel 325 is established, PCE 130 will continue to monitor the communications between routers 120a and 120b. If the bandwidth requirements for the communications change, PCE 130 may dynamically alter one or more of the communication tunnels between routers 120a and 120b. For example, if the bandwidth demands remain above 10 gigabytes, but less than the 15 gigabytes currently reserved between tunnels 305 and 325, one or both of tunnels 305 and 325 may be reduced in size. Similarly, if the required bandwidth for the communications between router 120a and 120b drop below 10 gigabytes, the size of communication tunnels 305 and 325 may be altered, including the elimination of one of the tunnels. For example, if the bandwidth requirement for the communications between routers 120a and 120b is determined to be 9 gigabytes, communication tunnel 305 may be expanded to handle 9 gigabytes of bandwidth, and communication tunnel 325 may be eliminated. On the other hand, PCE 130 may accommodate the change by simply reducing the bandwidth allocation for tunnel 325 to 2 gigabytes without making any changes to the bandwidth allocation for tunnel 305. Similarly, PCE 130 may accommodate the change by simply reducing the bandwidth allocation for tunnel 305 to 1 gigabyte without making any changes to the bandwidth allocation for tunnel 325.
With reference now made to
PCE 130 may have partial awareness of network layer interfaces through signaling provided by routers 120a-c, the routers connected to the second network layer 110 through network layer interfaces 115a-c. Specifically, PCE 130 may be receiving minimal reachability information for the optical network. In particular, PCE 130 may learn the optical addresses associated with routers 120a-c through one or more means. For example, routers 120a-c may advertise or flood network layer 105 with messages indicating that routers 120a-c have virtual interconnectivity. These signaling messages may include the optical addresses for routers 120a-c. According to other examples, the optical addresses for routers 120a-c may be tagged addresses in an intermediate to intermediate system (ISIS) network. In additional examples, the optical addresses for routers 120a-c may be flooded to first network layer 105 as stabs in an Open Shortest Path First (OSPF) environment.
Accordingly, while the process of establishing on-demand bandwidth begins in a manner similar to that of
As with the example of
PCE 130 monitors the communications over communication tunnel 305 until bandwidth request message 310 is received by PCE 130 from router 120a. Request message 310 requests an additional 8 gigabytes of bandwidth for communication between router 120a and router 120b. Just as described above in reference to
In response to message 310, bandwidth on demand functional unit 135 will send message 415 to router 120a. But, unlike message 315 of
Upon receipt of message 415, in order to determine the path through second network layer 110, router 120a may attempt to establish a successful path through a trial-and-error process. Specifically, router 120a may send message 420 to optical node 125a, which also includes the optical addresses for router 120a and router 120b. Upon receiving message 420, optical node 125a can complete the path for the additional communication through, for example, signaling over the second network layer 110. Specifically, optical node 125a may use GMPLS signaling to determine a path from network layer interface 115a, through second layer network 110 and out network layer interface 115b to router 120b.
Specifically, optical node 125a may send out or flood a plurality of signaling messages 422a and 422b, such as GMPLS signaling messages, to communicate with the other optical nodes in second network layer 110 in an attempt to find a path through second network layer 110 that can fulfill the bandwidth request made in message 310. Upon determining a successful path through the second network layer 110, communication tunnel 425 is established between router 120a and router 120b, and communication is commenced through second network layer 110.
As with the example of
With reference now made to
Unlike the example of
Accordingly, message 515 may include an ERO which defines the hop from router 120f to 120c, and also includes three CPSs, one CPS for the hop from router 120c to optical node 125a, one CPS for the hop from optical node 125c to optical node 125a, and one CPS for the hop from optical node 125a to router 120a, each of which includes a path key. Furthermore, the portion of the ERO defining the path to router 120c may be “loose,” meaning it is not explicitly defined by the ERO, and the routing devices along the path may determine the specific hops necessary to reach router 120c.
Once received at router 120c, the corresponding path key in the CPS in the LSP will be translated by node 120c. Accordingly, the LSP will be signaled to optical node 125C where the next path key in the next CPS will be translated. This process will continue until the LSP has been signaled to router 120a, at which time bandwidth on-demand communication tunnel 520 is established.
As with the examples of
Turning now to
Memory 640 may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible (e.g., non-transitory) memory storage devices. The processor 620 is, for example, a microprocessor or microcontroller that executes instructions for stateful network device 130. Thus, in general, the memory 640 may comprise one or more tangible (non-transitory) computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the processor 620), and in particular bandwidth on-demand functional unit 135, it is operable to perform the operations described herein in connection with
The techniques taught herein provide substantial benefits to multilayer network configurations. For example, the use of a stateful PCE is one of the components of the Software Defined Networks (SDN). Accordingly, the techniques taught herein are easily deployed within SDN networks. Furthermore, the techniques taught herein build on the existing PCE and RSVP-TE framework.
Furthermore, the techniques described herein address important problems faced by service providers, such as how to efficiently use and share spare bandwidth in the optical network and create services in an on-demand basis. By implementing the techniques described herein, networks with fewer resources can provide the same level of availability as networks with higher cost infrastructures.
The above description is intended by way of example only.
This application claims the benefit of Provisional Application No. 61/729,119, filed Nov. 21, 2012, the contents of which are hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
6094437 | Loehndorf, Jr. | Jul 2000 | A |
6553568 | Fijolek et al. | Apr 2003 | B1 |
6665264 | Davison et al. | Dec 2003 | B1 |
6665273 | Goguen | Dec 2003 | B1 |
7023879 | Sitaraman | Apr 2006 | B1 |
7031262 | Vasseur et al. | Apr 2006 | B2 |
7324447 | Morford | Jan 2008 | B1 |
7505467 | Buffam | Mar 2009 | B1 |
7590075 | Pirzada et al. | Sep 2009 | B2 |
7668971 | Vasseur et al. | Feb 2010 | B2 |
7733788 | Michalski et al. | Jun 2010 | B1 |
7751405 | Kompella | Jul 2010 | B1 |
7831700 | Lee | Nov 2010 | B2 |
8005133 | Smith | Aug 2011 | B2 |
8009669 | Lee | Aug 2011 | B2 |
8102877 | Liu et al. | Jan 2012 | B1 |
8259713 | Lawrence et al. | Sep 2012 | B2 |
8264962 | Vasseur et al. | Sep 2012 | B2 |
8312145 | Rabie | Nov 2012 | B2 |
8817596 | Chen et al. | Aug 2014 | B2 |
8885463 | Medved et al. | Nov 2014 | B1 |
8924581 | Acharya et al. | Dec 2014 | B1 |
9019827 | Chan | Apr 2015 | B1 |
20010027211 | Houze | Oct 2001 | A1 |
20010030785 | Pangrac et al. | Oct 2001 | A1 |
20020085559 | Gibson et al. | Jul 2002 | A1 |
20020191250 | Graves | Dec 2002 | A1 |
20030088529 | Klinker | May 2003 | A1 |
20030117973 | Thermond et al. | Jun 2003 | A1 |
20030177221 | Ould-Brahim | Sep 2003 | A1 |
20030226017 | Palekar | Dec 2003 | A1 |
20040114583 | Cetin et al. | Jun 2004 | A1 |
20040151181 | Chu | Aug 2004 | A1 |
20040156313 | Hofmeister et al. | Aug 2004 | A1 |
20040186851 | Jhingan | Sep 2004 | A1 |
20040215787 | Gibson | Oct 2004 | A1 |
20050063411 | Wang et al. | Mar 2005 | A1 |
20060039364 | Wright | Feb 2006 | A1 |
20060072474 | Mitchell | Apr 2006 | A1 |
20060165224 | Lee | Jul 2006 | A1 |
20060187950 | Bou-Diab | Aug 2006 | A1 |
20060250948 | Zamfir | Nov 2006 | A1 |
20070009045 | Mohandas | Jan 2007 | A1 |
20070133406 | Vasseur | Jun 2007 | A1 |
20070160061 | Vasseur et al. | Jul 2007 | A1 |
20070208871 | Vasseur | Sep 2007 | A1 |
20080112315 | Hu et al. | May 2008 | A1 |
20080212613 | Perkinson et al. | Sep 2008 | A1 |
20090086632 | Folkes et al. | Apr 2009 | A1 |
20090182894 | Vasseur et al. | Jul 2009 | A1 |
20100002724 | Turlington et al. | Jan 2010 | A1 |
20100121972 | Samuels et al. | May 2010 | A1 |
20110280580 | Wexler | Nov 2011 | A1 |
20120163224 | Long | Jun 2012 | A1 |
20120269053 | Yu | Oct 2012 | A1 |
20130286846 | Atlas | Oct 2013 | A1 |
20130336108 | Vasseur et al. | Dec 2013 | A1 |
Number | Date | Country |
---|---|---|
2037626 | Mar 2009 | EP |
2010017176 | Feb 2010 | WO |
Entry |
---|
Sanchez-Lopez et al., “Fast setup of end-to-end paths for bandwidth constrained applications in an IP/MPLS-ATM intergrated environment”, 2006. |
Busschbach, “Toward QoS-Capable Virtual Private Networks”, 1998. |
Taylor et al., “System-wide Information Management for Aeronautical Communications”, 2004. |
Metz, “Layer over IP/MPLS”, 2001. |
Huang et al., “Bridging Core and Edge Networks for Residential Subscribers”, 2000. |
Ahn et al., “Design and Implementation of MPLS Network Simulator Supporting LDP and CR-LDP”, 2000. |
Bradner, “Key words for use in RFSs to Indicate Requirement Levels”, RFC 2119, 1997. |
Awduche et al., “RSVP—TE: Extensions to RSVP for LSP tunnels”, RFC 3209, 2001. |
Donnet er al., “Revealing MPSL Turnnels Obscured form Traceroute”, 2012. |
Kuhn et al., “Current and Advanced Protocols over ATM: Evaluation, Implementation and Experiences”, 1996. |
Gredler et al., “Traffic Engineering by Layer-2 Overlay Networks”, Chapter 14 “Traffic Engineering and MPLS”, “The Complete IS-IS Routing Protocol”, 2005. |
Farrel et al., “Crakback Signaling Extensions for MPLS and GMPLS RSVP—TE”, RFC 4920, 2007. |
Farrel et al., “A Path Computation Element (PCE)—Based Architecture”, RFC 4655, 2006. |
Pan et al., “Fast Reroute Extensions to RSVP—TE for LSP Tunnels”, RFC 4090, 2005. |
Vasseur et al., “Patch Computation Element (PCE) Communication Protocol (PCEP)”, RFC 5440, 2009. |
Aggarwal et al., “Extensions to Resource Reservation Protocol—Traffic Engineering (RSVP—TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)”, RFC 4875, 2007. |
Faucheur et al., “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services”, RFC 3270, 2002. |
Gleeson et al., “A Framework for IP Based Virtual Private Networks”, RFC 2764, 2000. |
Valencia et al., “Cisco Layer Two Forwarding (Protocol) ‘L2F’”, RFC 2341, 1998. |
Swallow, “MPLS Traffic Engineering”, 1999. |
Rouse, “Layer Two Tunneling Protocol (L2TP) definition”, 2007. |
MediaWiki, “Tunneling—GRE/L2TP”, 2011. |
Cisco, “Implementing Tunnels”, 2004. |
Haller et al., “The Internet of Things in an Enterprise Context”, 2009. |
Cisco, “Cisco IOS XR MPLS Configuration Guide for the Cisco CRS Router Release 4.2.X”, 2013. |
Zolfagharnasab, “Reducing Packet Overhead in Mobile IPv6”, 2012. |
Mammoliti et al., “Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions”, RFC 5515, 2009. |
Farrel et al., “Inter-Domain MPLS and GMPLS Traffic Engineering—Resource Reservation Protocol—Traffic Engineering (RSVP—TE) Extensions”, RFC 5151, 2008. |
Lang et al., “RSVP—TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery”, RFC 4872, 2007. |
Faucheur, “Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels”, RFC 4804, 2007. |
Faucheur, “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering”, RFC 4124, 2005. |
Faucheur et al., “Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering”, RFC 3564, 2003. |
Berger, “Generalized Multi—Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol—Traffic Engineering (RSVP—TE) Extensions”, RFC 3473, 2003. |
Berger, “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description”, RFC 3471, 2003. |
Faucheur et al., “Multi-Protocol Label Switching (MPLS) Support for Differentiated Services”, RFC 3270, 2002. |
Townsley et al., “Layer Two Tunneling Protocol ‘L2TP’”, RFC 2661, 1999. |
Rosen et al., “Multiprotocol Label Switching Architecture”, RFC 3031, 2001. |
Andersson et al., “LDP Specification”, RFC 3036, 2001. |
International Search Report and Written Opinion in counterpart International Application No. PCT/US2013/070902, mailed Mar. 28, 2014, 10 pages. |
Number | Date | Country | |
---|---|---|---|
20140143409 A1 | May 2014 | US |
Number | Date | Country | |
---|---|---|---|
61729119 | Nov 2012 | US |