Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 1 of 12
`
`
`
`
`Exhibit F
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 2 of 12
`I 1111111111111111 11111 111111111111111 IIIII 111111111111111 IIIIII IIII IIII IIII
`US0077 60664 B2
`
`c12) United States Patent
`Gupta
`
`(IO) Patent No.:
`(45) Date of Patent:
`
`US 7,760,664 B2
`*Jul. 20, 2010
`
`(54) DETERMINING AND PROVISIONING PATHS
`INA NETWORK
`
`(76)
`
`Inventor: Sanyogita Gupta, 8 Colasurdo Ct.,
`Edison, NJ (US) 08820-4420
`
`( *) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 1005 days.
`
`This patent is subject to a terminal dis(cid:173)
`claimer.
`
`(21) Appl. No.: 11/101,136
`
`(22)
`
`Filed:
`
`Apr. 7, 2005
`
`(65)
`
`Prior Publication Data
`
`US 2006/0067236 Al
`
`Mar. 30, 2006
`
`5,377,262 A
`5,526,414 A
`5,764,740 A *
`6,091,720 A
`6,981,065 Bl*
`7,173,912 B2 *
`2002/0029298 Al *
`2003/0071840 Al
`2003/0189919 Al
`2004/0107277 Al
`2005/0097108 Al*
`2005/0169179 Al*
`2006/0015617 Al*
`
`12/1994 Bales et al. ............ 379/221.06
`6/1996 Bedard et al ........... 379/221.01
`6/1998 Holender ............... 379/112.05
`7/2000 Bedard et al.
`12/2005 Lu ............................. 709/251
`2/2007 Jaber et al. .................. 370/254
`3/2002 Wilson ....................... 709/316
`4/2003 Huang et al.
`10/2003 Gupta et al.
`6/2004 Levesque et al.
`5/2005 Wang et al. ................. 707/100
`8/2005 Antal et al. ................. 370/231
`1/2006 Castro et al. ................ 709/226
`
`OTHER PUBLICATIONS
`
`International Search Report for PCT/US2005/034418 mailed Dec.
`27, 2006.
`European Search Report for European Application 05857725.5,
`dated Aug. 25, 2009.
`Notice of Rejection for Japanese Patent Application No. 2007-
`534687, mailed Jul. 31, 2009 (with English Translation).
`
`Related U.S. Application Data
`
`* cited by examiner
`
`(60) Provisional application No. 60/614,609, filed on Sep.
`30, 2004.
`
`(51)
`
`(52)
`
`(58)
`
`(56)
`
`Int. Cl.
`H04L 12128
`(2006.01)
`G06F 151177
`(2006.01)
`G06F 15116
`(2006.01)
`U.S. Cl. ....................... 370/254; 370/389; 370/400;
`709/220; 709/249
`Field of Classification Search ......... 370/235-240,
`370/254-258, 400--401; 709/220, 249
`See application file for complete search history.
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,284,852 A
`4,669,113 A
`4,788,421 A
`5,297,137 A
`
`8/ 1981 Szybicki et al. .. ... ... 379/221.01
`5/ 1987 Ash et al.
`... ... .. ... ... 379/221.01
`11/1988 Ogawa et al.
`............ 250/201.5
`3/1994 Ofek et al. .................. 370/403
`
`Primary Examiner-Tri H Phan
`
`(57)
`
`ABSTRACT
`
`A network provisioning system for establishing a path
`between two networks is disclosed wherein a common net(cid:173)
`work device between those networks is modeled as a link
`between a first network element in one network and a second
`network element in a second network. A network routing
`graph is created by an inventory subsystem in a routing man(cid:173)
`ager by inventorying the physical network elements and links
`in the network. The inventory subsystem then models those
`elements/links as a plurality of nodes and links between the
`nodes. At least one common network device, such as a digital
`cross connect connecting the two networks, is modeled as a
`link instead of a node. A routing engine then uses the network
`routing graph, including the link modeled from the common
`network device, to provision a path between the networks.
`
`14 Claims, 5 Drawing Sheets
`
`102
`
`Network Configuration Management System
`
`304
`
`Routing Engine
`
`Service Activation
`System
`
`306
`
`~31_2~ -3 - s~ / \
`
`3 o
`
`Element Adapter
`
`313
`
`314
`
`316
`
`318
`
`320
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 3 of 12
`
`Network Configuration Management System (102)
`
`•
`•
`---------~-----~-----
`
`I
`
`'
`I
`I
`I
`I
`
`I
`
`I
`I
`I
`I
`I
`I
`
`d Network (llO)
`Manage
`\
`
`Network
`Management
`System (126)
`
`----......
`
`-+ Links (120)
`
`Network
`Element (114)
`....... --
`
`I , ,
`,
`
`I
`I
`I
`I
`I
`
`Network
`Element
`(116)
`I
`I
`~ - - - - -_ __ , I
`I
`I
`
`Network
`Element
`(116)
`
`Links (122)
`
`•
`
`Broadband Network (112)
`
`Element
`Management
`System (128)
`
`, , ,
`, , , , ,
`
`FIG. 1
`(Prior Art)
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`2' :-'
`
`N
`~o
`N
`0 ....
`
`0
`
`('D
`('D
`
`rJJ =(cid:173)
`.....
`....
`0 ....
`
`Ul
`
`d r.,;_
`
`-....l
`~
`
`0--,
`
`0--, = O'I
`~ = N
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 4 of 12
`
`FIG. 2
`
`NETWORK CONFIGURATION MANAGEMENT SYSTEM
`
`102
`
`_,,_,,_,,_ .. _,,-+ .. - .. _ .. _,, _____ ,_ .. _ .. _ .. _.,--:-.. - .. ----:-.. - .. _ .. _ .. ---\,.-.. ----.. -"-
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`2' :-'
`
`N
`~o
`N
`0 ....
`
`0
`
`('D
`('D
`
`rJ'1 =(cid:173)
`.....
`N
`0 ....
`
`Ul
`
`r204
`
`d r.,;_
`
`-....l
`~
`
`0--,
`
`0--, = O'I
`~ = N
`
`r--
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`- - - - r
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`---.
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`\
`\
`\
`\
`\
`\
`\
`\
`\
`\
`\
`\
`
`,
`I
`
`'
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`/
`, _ ,ni:
`
`202
`
`I
`I
`
`'
`
`I
`I
`
`"'---~.,.
`
`I
`I
`
`'
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`205
`
`\
`\
`
`'
`
`\
`\
`\
`\
`\
`\
`\
`\
`\
`
`\
`,
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 5 of 12
`
`102"-.
`
`Network Configuration Management System
`
`~
`......
`.,,,
`
`304
`
`L
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`~ = :-
`
`N
`0
`N
`
`~
`
`0 ....
`
`0
`
`......
`.,,,
`t--.
`322 I Inventory
`---.J Database
`.,,,
`......
`
`314
`
`r:::
`
`,...
`
`316---+-
`
`Routing
`Node
`~
`
`/
`
`318
`
`NMS/EMS
`Table
`
`320
`
`Routing
`Model
`Database
`
`~ ~ ~1-nv_e_n-to_ry_S-ub_s_y-st_e_, .._._J Routing Engine
`"'
`
`/
`306
`
`3"'
`
`308
`
`/
`
`I+------+! Service Activation
`System
`. . \
`310
`
`\
`
`rJJ =(cid:173)
`('D a
`0 ....
`
`Ul
`
`~
`
`Element Adapter
`
`I
`
`•
`
`...
`
`324
`I I/
`Cross-
`Connection v1
`Status
`Database
`
`313"
`
`+
`
`FIG. 3
`
`d
`rJl.
`-....l
`~
`
`0--,
`
`0--, = O'I
`~ = N
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 6 of 12
`
`FIG. 4
`
`407
`I
`DCS
`
`r407B
`
`I
`
`2 4088
`
`408
`
`403
`J_
`
`\ .. vMvn•n~i: •v L
`
`l
`
`402 '- { Dnl ITHI~ \
`
`407A
`
`-b
`
`401
`
`,,_ 405
`
`Y. 9A
`
`4098
`
`406
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`~ = :-'
`
`N
`~o
`N
`0 ....
`
`0
`
`rJJ =-('D
`.....
`0 ....
`
`('D
`
`,i;...
`
`Ul
`
`d r.,;_
`
`-....l
`~
`
`0--,
`
`0--, = O'I
`~ = N
`
`

`

`U.S. Patent
`
`Jul. 20, 2010
`
`Sheet 5 of 5
`
`US 7,760,664 B2
`
`c:, --
`
`U"')
`
`----
`
`____ 'i _____ _
`--~--
`
`c.o
`
`c::> --
`
`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 7 of 12
`
`Ln
`
`I , , , ,
`
`I
`I
`I
`I
`I
`I
`I
`
`I ,
`
`I
`
`I
`
`C>
`IJ'1
`
`-
`
`I
`'
`\
`
`I '
`~\
`
`' ' '
`' \
`
`\
`\
`\
`
`\ ' ' ' ' ' ' ' ' '
`
`I
`
`I
`,
`'
`\
`I
`\
`I
`\
`I
`\
`I
`\
`I
`\
`I
`\
`I
`~~-
`
`I~
`
`C"'J
`c:,
`IJ'1
`
`c::, --
`
`C"'J
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 8 of 12
`
`US 7,760,664 B2
`
`1
`DETERMINING AND PROVISIONING PATHS
`INA NETWORK
`
`This application claims the benefit of U.S. Provisional
`Application No. 60/614,609, filed Sep. 30, 2004, which is
`hereby incorporated herein by reference.
`
`BACKGROUND OF THE INVENTION
`
`Communications networks, such as next generation broad(cid:173)
`band networks, have become increasingly complex due to
`increased size, numerous intermixed technologies/protocols
`( e.g., ATM, Frame Relay, etc.), and the intermixing of equip(cid:173)
`ment manufactured by numerous different vendors. As a
`result, network configuration management systems that can 15
`provision virtual trunks and circuits within these networks are
`becoming increasingly important. Such network configura(cid:173)
`tion management systems function to determine the paths/
`routes between network equipment, herein referred to as net(cid:173)
`work elements, and to communicate with those network 20
`elements to realize desired trunks or circuits that facilitate the
`transmission of traffic across the network.
`In general, network configuration management systems
`have traditionally determined the paths available by modeling
`portions of network elements as nodes on a graph and the
`links/interconnections between these portions as
`links
`between the nodes. More particularly, prior systems typically
`modeled every port of every network element as a node on the
`graph and modeled every physical link that interconnected
`these ports to one another as links that interconnected the 30
`nodes of the graph. The network model was then used to
`provision virtual trunks, which formed paths between net(cid:173)
`work elements in the network. Once these virtual trunks were
`provisioned, virtual circuits could then be established across
`these trunks to support traffic flow from one point to another 35
`in the network.
`FIG. 1 shows an exemplary prior art network configuration
`management system 102 and a network 110 managed by
`system 102. The network configuration management system
`102 functions to determine a preferred path between two
`points in a network (i.e., between two network elements) and
`for provisioning a communications connection across this
`path by communicating with the managed network 110. Man(cid:173)
`aged network 110 consists primarily of broadband network
`112 which, in turn, consists of a plurality of network elements 45
`114-118 interconnected by physical links and virtual trunks
`and circuits represented in FIG. 1 by links 120-124. The
`network elements comprise varying technologies and proto(cid:173)
`cols and may be manufactured by different vendors. Managed
`network 110 further comprises network management sys- 50
`terns, such as network management system (NMS) 126, and
`element management systems, such as element management
`system (EMS) 128. These systems are typically provided by
`the network element manufacturers and typically function to
`perform the actual configuration and management of the indi- 55
`vidual network elements.
`NMSs and EMSs may function to control both the network
`elements and the links between those elements. However
`some may not control the links between the elements and,
`instead, only manage the network elements themselves. For
`example, an NMS, such as NMS 126, may function to col(cid:173)
`lectively manage a set of network elements 114 and the physi-
`cal links 120 between them, thus forming a collectively man(cid:173)
`114.
`aged
`sub-network having network
`elements
`Accordingly, when network traffic arrives at an ingress port 65
`into one of the network elements 114, such as port 130, the
`NMS 126 determines a set of links and network element
`
`2
`cross-connects to interconnect port 130 to an egress port, such
`as port 132. The NMS 126 then provisions the network ele(cid:173)
`ments to realize this interconnection. In another example,
`some management systems, such as EMS 128, may only
`5 manage one or more network elements 118, but not the links
`124 between them. Here, a higher layer entity, such as the
`Network Configuration Management System 102, deter(cid:173)
`mines the links between network elements 118 required to
`10 create a path and then instructs the EMS to perform the
`necessary cross-connects within network elements 118 to
`realize the complete path.
`FIG. 1 also shows how some network elements, such as
`network elements 116, are not managed by either an NMS or
`EMS. Specifically, a higher layer entity, once again such as
`Network Configuration Management System 102, directly
`communicates with these elements to perform network con(cid:173)
`figuration functions. In this case, Network Configuration
`Management System 102 would configure any cross-con(cid:173)
`nects within network elements 116 as well as any links
`between network elements. Thus, as shown in FIG. 1, to
`facilitate traffic flow across broadband network 112, for
`example from port 130 on network element 114 to network
`25 element 118, the combination of Network Configuration
`Management System 102, NMS 126 and EMS 128 will col(cid:173)
`lectively determine an appropriate network path across and
`between network elements 114, 116 and then provision vir-
`tual trunks and circuits across network 112.
`One difficulty with prior methods of using network con(cid:173)
`figuration management systems, such as those described
`above, is that the modeling of the network elements, physical
`links, and virtual trunks and circuits results in very large,
`inefficient models that do not adapt well to diverse network
`elements and large networks. Specifically, such large models
`result in correspondingly large and complex network model
`graphs which, in tum, create performance and scalability
`issues due to the demanding processing requirements associ-
`40 ated with such graphs. Therefore, in one prior attempt at
`solving this problem and to reduce the aforementioned dis(cid:173)
`advantages, a network model was created based on how the
`ingress and egress ports of each network element can be
`interconnected within themselves and to other network ele-
`ments. Specifically, in this prior attempt, a simplified routing
`graph was created by the network configuration management
`system whereby, instead of modeling each port of a network
`element as a node on a routing graph, an entire network
`element itself could be represented as one or more routing
`nodes or, in some cases, multiple network elements could be
`represented as a single routing node. Referring to FIG. 2, for
`example, network elements 114 ofFIG.1 that are managed by
`NMS 126 are modeled as a single node 201. Additionally,
`network elements 118, which are managed by both EMS 128
`and the Network Configuration Management System 102 are
`also modeled as a single routing node 204. Network elements
`116 are each modeled as individual routing nodes, since the
`Network Configuration Management System 102 manages
`60 both the network element and the link between the elements.
`In such a model, therefore, the individual physical hardware
`links are not each modeled but, rather, one or more network
`elements are modeled as a single routing node based on how
`those network elements and the links between them are man(cid:173)
`aged. Such an attempt is generally described in pending U.S.
`patent application Ser. No. 10/118,187, filed Apr. 8, 2002 and
`entitled "Determining and Provisioning Paths Within a Net-
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 9 of 12
`
`US 7,760,664 B2
`
`3
`work of Communication Elements" (hereinafter referred to as
`the "'187 application"), which is hereby incorporated by ref(cid:173)
`erence herein in its entirety.
`
`SUMMARY OF THE INVENTION
`
`While the prior methods of creating network models for
`routing traffic across networks and between multiple net(cid:173)
`works are advantageous in many regards, as discussed above
`they are limited in certain regards. In particular, while pro(cid:173)
`cessing associated with network routing can be greatly sim(cid:173)
`plified using the prior methods, such processing can still be
`resource and overhead intensive. This is especially the case as
`networks using different speeds and/or protocols are being
`interconnected to provide new and more complex services to
`customers.
`Accordingly, the present inventor has invented a network
`provisioning system for establishing a path between two net(cid:173)
`works wherein a common network device between those
`networks is modeled as a link between a first network element
`in one network and a second network element in a second
`network. In one embodiment, a network routing graph is
`created by an inventory subsystem in a routing manager by
`inventorying the physical network elements and links in the
`network. The inventory subsystem then models those ele(cid:173)
`ments/links as a plurality of virtual nodes and links between
`the nodes. At least one common network device, such as a
`digital cross connect located at a junction between the two
`networks, is modeled as a link instead of a node. A routing
`engine then uses the network routing graph, including the link
`modeled from the common network device, to provision a
`path between the two networks. Thus, since fewer nodes are
`represented in a network graph of the modeled network, route
`processing is reduced, resulting in a corresponding reduction
`in overhead and resources required to route network traffic
`from one node to another.
`
`DESCRIPTION OF THE DRAWING
`
`FIG. 1 shows a prior art managed broadband network and
`a network configuration management system for determining
`and provisioning routing paths within the network;
`FIG. 2 shows a network routing model whereby some
`network elements are combined and treated as single routing
`nodes;
`FIG. 3 shows an illustrative network configuration man(cid:173)
`agement system;
`FIG. 4 shows a network routing model whereby Digital
`Cross Connect Systems (DCSs) are used to interconnect dif(cid:173)
`ferent network nodes; and
`FIG. 5 shows a network routing model in accordance with
`the principles of the present invention whereby DCSs are
`modeled as links.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`FIG. 3 shows an illustrative network configuration man(cid:173)
`agement system, such as Network Configuration Manage(cid:173)
`ment System (NCMS) 102 in FIGS. 1 and 2. As discussed
`above, NCMS 102 determines preferred routing paths
`between two ports within the network by modeling the net(cid:173)
`work paths as a plurality of routing nodes and links between
`the nodes, and for using these paths to provision virtual trunks
`and circuits within the networks. To accomplish this function,
`NCMS 102 includes, among other components, a routing
`manager 304 and inventory database 322. The routing man(cid:173)
`ager 304 provides end-to-end connection management func-
`
`4
`tions including the determination and provisioning of routing
`paths in broadband network 112 in FIG. 1. In order to accom(cid:173)
`plish these functions, routing manager 304 comprises an
`inventory subsystem 306, a routing engine 308 and a service
`5 activation system 310. The routing manager 304 is connected
`to the various network elements via an element adapter 312
`and connection 313. Broadly, the routing manager 304 main(cid:173)
`tains a topological graph comprising nodes and links that
`model the broadband network 112. This graph is used to
`10 determine and provision routing paths between, for example,
`two ports within the network. These paths are then used to
`provision virtual trunks and circuits.
`The inventory subsystem 306 builds and maintains the
`topological graph in accordance with modeling methods such
`15 as those described above in association with the '187 appli(cid:173)
`cation. This graph is maintained, illustratively, in three data(cid:173)
`base tables: routing link table 314, routing node table 316, and
`NMS/EMS table 318. The routing engine 308 determines a
`routing path for traffic through the network using the network
`20 graph maintained by the inventory subsystem 306. The ser(cid:173)
`vice activation system 310 then uses the determined routing
`path to provision the actual virtual trunk or virtual circuit.
`Specifically, the service activation system 310 activates the
`routing engine 308 to obtain a routing path given two end-
`25 points and then invokes the element adapter 312 which inter(cid:173)
`faces with network elements, NMSs and EMSs to physically
`provision the determined path. As such, the element adapter
`312 functions as an interface between the routing manager
`304 and theNMSs 126, EMSs 128, and network elements 116
`30 in managed broadband network 112. As one skilled in the art
`will recognize, there is typically a specific element adapter
`designed for use with NMSs, EMSs, and network elements
`manufactured by different manufacturers. As such, a network
`management system may have multiple element adapters, or
`35 different modules in one element adapter. Accordingly, once
`the service activation system determines a routing path, it
`invokes the appropriate adapter( s) or adapter module( s) to
`communicate the required configuration settings to the man(cid:173)
`agement systems/elements 126,128, and 116 to provision the
`40 determined path.
`As one skilled in the art will recognize, and as is further
`discussed herein below, network traffic may be required to
`traverse multiple separate networks. These different networks
`may be interconnected with cross connects, such as digital
`45 cross connects (DCSs).As such, itis necessary for the NCMS
`102 to also have available configuration and status informa(cid:173)
`tion related to these DCSs. This configuration and status
`information is, illustratively, maintained in cross-connection
`status database 324. Thus, in provisioning the aforemen-
`50 tioned path, service activation system 310 may also refer to
`cross-connection status database 324.
`The prior illustrative method described in the '187 appli(cid:173)
`cation for using an NMS to simplify routing graphs is advan(cid:173)
`tageous in many regards. By eliminating the need to inventory
`55 individual ports and by reducing the number of nodes neces(cid:173)
`sary to consider in routing network traffic from one point to
`another, the processing overhead and timeliness associated
`with making routing decisions is greatly reduced. Addition(cid:173)
`ally, such an approach adds considerable flexibility in design-
`60 ing and maintaining routing graphs. Specifically, as described
`in that application, instead of inventorying and maintaining a
`database of each port in a network and the interconnections
`between those ports, it is only necessary to inventory the
`routing nodes and the links between the routing nodes that,
`65 for example, may consist of several network elements.
`As one skilled in the art will recognize, the method
`described in the '187 application is primarily focused on
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 10 of 12
`
`US 7,760,664 B2
`
`5
`network routing at layer 2 of the network. As is well under(cid:173)
`stood, networks have been modeled as operating at different
`layers. One model for such network layers is known as the
`Open System Interconnection (OSI) model, which generally
`defines 7 different layers in the network. Layer 2 is also
`known as the data link layer and is the layer at which the
`physical medium is shared and where data link and media
`access are controlled. For example, in Ethernet networks,
`layer 2 is the layer at which network routing between media
`access control (MAC) addresses ofindividual hardware com(cid:173)
`ponents is performed.
`The above-described network model at layer 2 of a network
`is primarily useful within a single network. However, with
`increasingly complex and large networks it has become nec(cid:173)
`essary to cross network boundaries in order to route network 15
`traffic from one destination to another. In many cases, the
`different networks rely on different protocols, operate at dif(cid:173)
`ferent speeds and may even operate using a different physical
`medium (e.g., copper vs. optical fiber). In order to intercon(cid:173)
`nect such networks, DCSs or other similar devices, such as 20
`optical cross connect systems (OCSs), are used. As used
`herein, a DCS is any device that interconnects networks to
`facilitate traffic routing from one network to another or to link
`portions of networks using one protocol or traffic rate to
`another portion using a different protocol or rate. Such DCSs 25
`are very well known in the art and serve to efficiently manage
`disparate traffic protocols and line speeds in telecommunica(cid:173)
`tions system central offices as well as remote field locations
`and other locations such as within hotels and even at user
`premises. Such DCSs may be used in a variety of different
`applications. For example, DCSs may be used at a customer
`premises to interface with both voice protocol networks and a
`number of different data protocol networks in order to aggre(cid:173)
`gate and cross connect these networks to a high-speed copper
`wire or optical fiber loop. Additionally, DCSs may be used in
`a digital loop carrier (DLC) capacity to aggregate networks
`using multiple protocols for transmission across a SONET
`ring network. In another common implementation, such
`DCSs may be used within, illustratively, a telecommunica(cid:173)
`tions central office in order to manage and cross connect
`channels from multiple SO NET rings that are employed in an
`access network and/or a metro or inter-office network. Other
`uses ofDCS are well known and will be obvious to one skilled
`in the art.
`FIG. 4 shows one illustrative routing map wherein DCSs 45
`are used to connect networks to facilitate traffic flow from one
`network to another. In particular, FIG. 4 shows routing nodes
`401-406, each of which represents, illustratively, a network,
`such as broadband network 112, or a portion of a network,
`such as the group of network elements 116 also in FIG. 1. As
`such, each of the routing nodes 401-406 illustratively has a
`plurality of network elements that are modeled, for routing
`purposes, as a single routing node with an ingress port and an
`egress port, such as ports 130 and 134, respectively, in FIG. 1.
`The networks represented by each of routing nodes 401-406
`may, for example, operate using a different protocol or speed
`and, therefore, DCSs, such as DCSs 407, 408 and 409, may be
`used to aggregate and/or disaggregate traffic in order to facili(cid:173)
`tate the transmission of that traffic between and over the
`different networks interconnected by the DCSs. For example,
`routing nodes 402 and 405 may represent well-known OC-3
`networks operating at an illustrative speed of 155.52 Mb/s
`while the networks represented by nodes 403 and 406 may be
`well-known OC-12 networks operating at an illustrative
`622.08 Mb/s rate. DCSs 407 and 408 aggregate and/or disag(cid:173)
`gregate the data between the networks represented by nodes
`402 and 403 and DCS 409 aggregates and disaggregates the
`
`6
`traffic between the networks represented by nodes 405 and
`406. Typically, paths through DCSs 407-409 are provisioned
`in a relatively static manner. For example, a path from port
`407 A, associated with node 402, to port 407B, associated
`5 with node 403, is provisioned on DCS 407 in order to provide
`connectivity between the networks represented by nodes 402
`and 403. Connections between ports 408A/408B and 409A/
`409B are similarly provisioned to connect nodes 402/403 and
`405/406, respectively. Thus, one skilled in the art will recog-
`10 nize that DCSs 407-409 function as common nodes between
`the respective networks.
`As one skilled in the art will recognize, a DCS, such as any
`one ofDCSs 407-409, functions similarly in some respects to
`a network switch, such as a router or ATM switch. However,
`such routers/switches typically operate as a function at least
`in part of the signaling accompanying traffic transiting the
`network and, hence, such routers/switches are typically
`closely tied to specific services provided by a network service
`provider. A DCS is typically not used for such purposes.
`Instead, a DCS is typically used for transmission manage(cid:173)
`ment at a higher level of the network. Specifically, unlike
`most telecom services where switch control is an inherent
`element of the service provided to customers and is closely
`tied to the protocol used at layer 2 of the network, DCSs are
`typically used as an engineering and provisioning control
`mechanism at layer 1 in the network (i.e., the physical layer of
`thenetwork).As such, DCSs are typically not used to dynami(cid:173)
`cally alter switching over a short time period, as are routers
`and other types of switches. Additionally, DCSs are not typi-
`30 cally controlled as a function of signaling from a customer but
`are, instead, controlled directly by, for example, engineers at
`the service provider. Also unlike simpler network switches, a
`typical DCS facilitates the provisioning of network paths and
`connections across the DCS that are typically constant over a
`35 period of hours to months.
`As service providers, such as telecommunication service
`providers, strive to provide more advanced features to con(cid:173)
`sumers, interconnections and junctions between networks,
`such as those created by DCSs 407-409 and other similar
`40 devices, become greater in number and grow in importance.
`These interconnection devices must be taken into account
`when developing a network routing strategy. Traditionally, in
`making routing decisions, the network configuration man-
`agement system modeled devices such as DCSs as one or
`more separate routing nodes. The present inventor have dis(cid:173)
`covered, however, that such a modeling ofDCSs increases the
`routing processing required due to a larger number of"hops"
`necessary to traverse nodes in the routing model. This
`increases both the time and overhead necessary to, for
`50 example, generate the aforementioned routing graphs. There(cid:173)
`fore, the present inventor have further discovered that, in
`addition to simplifying routing decisions at layer 2 of a net(cid:173)
`work, as described in the '187 application, it is desirable to
`also simplify the routing graph at layer 1 of the network.
`55 Specifically, instead of treating DCSs as a separate node (or
`multiple nodes corresponding the ports on the DCS) in the
`network, it is also desirable to model DCSs differently in
`order to further simplify the routing graphs/decisions. More
`particularly, in part since DCSs and other similar devices are
`60 relatively static in configuration, the present inventor have
`discovered that such devices may be treated as links, such as
`would be formed by a physical cable, instead of nodes that
`require processing as an affirmative routing hop.
`As described above in association with the '187 applica-
`65 tion, prior to provisioning network paths in a network, such as
`network 112 in FIG. 1, a network configuration management
`system, such as NCMS 126 in FIG. 1 will inventory the
`
`

`

`Case 1:20-cv-07529 Document 1-6 Filed 09/14/20 Page 11 of 12
`
`US 7,760,664 B2
`
`7
`network elements and links in the network. Once these ele(cid:173)
`ments and links are defined, the NCMS generates a routing
`graph showing the network topology in terms of routing
`nodes and links to be used in provisioning trunks/circuits
`across the network. FIG. 5 is a simplified representation of 5
`such a routing map. In particular, routing nodes 401-406 are
`as described above in association with FIG. 4. Each of those
`routing nodes consists, for example, of a plurality of network
`elements that are modeled at a high level as a single routing
`node in order to decrease the processing overhead required to 10
`provision the aforementioned trunks/circuits. However,
`instead of modeling the ports ofDCSs 407-409 of FIG. 4 as
`individual nodes, or as multiple nodes, those illustrative
`DCSs are modeled as links 501,502 and 503. Links 501,502
`and 503 are used in the routing graph of FIG. 5 to represent 15
`DCSs 407,408 and 409, respectively. Accordingly, in accor(cid:173)
`dance with the principles of the present invention, a cross(cid:173)
`connect, such as a DCS, is not modeled as one or more routing
`nodes having various links connecting ports to each other and
`to external ports on other network elements. Instead, such a 20
`cross-connect is modeled as a separate link between network
`elements in one or more networks. Accordingly, the routing
`map is greatly simplified.
`One skilled in the art will recognize that, as DCSs or other
`network components are added or deleted, the NCMS will 25
`inventory the network elements and links between the ele(cid:173)
`ments, treating DCSs as links as described above. Specifi(cid:173)
`cally, this inventory is conducted by the inventory subsystem
`306 of FIG. 3. As a part of this inventory, routing link table
`314, routing node table 316, NMS/EMS table 318 and cross 30
`connection status database 324 are updated with information
`about the links, nodes and cross connections in and between
`the networks managed by the NCMS 102. Therefore, in this
`inventory, information concerning each DCS will be updated
`in the cross-connection status database and those same DCSs 35
`will be updated as links in the routing link table. As a result,
`when service activation system 310 invokes the routing
`engine 308 to provision a path, that engine will treat the DCSs
`as links to be provisioned and not one or more network nodes
`corresponding to the ports on the DCS. When network traffic 40
`traverses a particular DCS, configuration and status informa(cid:173)
`tion related to that DCS is retrieved from cross connection
`status database 324 to identify how the path across the DCS
`should be provisioned to route the traffic to the approp