GMPLS update - 82: adding new parameters in custom computed-path configuration

Adding new #attributes in custom #computed-path configuration GMPLS module. The new attributes #node-id and #link-id adds support for specifying the #path #segment with respect to the #TE-Node and #TE-Link. This helps in describing the tunnel path using the nodes and links along the way. The #address information of the individual links are #automatically #populated based on the specified node-id and link-id configuration. This adds support for specifying the tunnel computed-path without knowing the address information, but using only the links on the way.

#GMPLS update 82 ...
[commit bd3f992063bcfb377c765dd1f0626fafb9d99910] (https://github.com/nes-repo/NES-Open-Switch/commit/bd3f992063bcfb377c765dd1f0626fafb9d99910)

GMPLS update - 76: adding new parameters in custom actual-path configuration

Adding new #attributes in custom #actual-path configuration GMPLS module. The new attributes #node-id and #link-id adds support for specifying the #path #segment with respect to the #TE-Node and #TE-Link. This helps in describing the tunnel path using the nodes and links along the way. The #address information of the individual links are #automatically #populated based on the specified node-id and link-id configuration. This adds support for specifying the tunnel actual-path without knowing the address information, but using only the links on the way.

#GMPLS update 76 ...
[commit 92d0937aef9875c5c567a439870f698f91555c63] (https://github.com/nes-repo/NES-Open-Switch/commit/92d0937aef9875c5c567a439870f698f91555c63)

GMPLS update - 74: adding new parameters in custom explicit-path configuration

Adding #new #attributes in custom #explicit-path configuration GMPLS module. The new attributes #node-id and #link-id adds support for specifying the #path #segment with respect to the #TE-Node and #TE-Link. This helps in describing the tunnel path using the nodes and links along the way. The #address information of the individual links are #automatically #populated based on the specified node-id and link-id configuration. This adds support for specifying the tunnel explicit-path without knowing the address information, but using only the links on the way.

#GMPLS update 74 ...
[commit 37d335c7865164d7d1a7b2d968e91a301d48866d] (https://github.com/nes-repo/NES-Open-Switch/commit/37d335c7865164d7d1a7b2d968e91a301d48866d)

GMPLS update - 55: adding standard tunnel activation handler

Added the #tunnel #activation #handler in GMPLS module. This will change the #tunnel #state as #active / #not-in-service effectively #enabling / #disabling the tunnel operation. On activating the tunnel depending on the tunnel type further actions will change. For a #static tunnel, the #bandwidth #reservation will be performed on the lower links and the #external #paths will be found in that process. The #cross-connects and the #segments will be created and they will be further made active, effectively cascading the activation operation. For #dynamically #signaled #tunnels the signaling modules will take over the further operations.

#GMPLS update 55 ...
[commit 43fbc1683644f5b2fba96ab5dde255d140e50345] (https://github.com/nes-repo/NES-Open-Switch/commit/43fbc1683644f5b2fba96ab5dde255d140e50345)

GMPLS update - 48: optimizing standard extended GMPLS tunnel entries

Optimized #standard #extended GMPLS #tunnel entries in GMPLS module. #Reduced some of the #address #variables used on the GMPLS tunnel entries and #removed the pointer to the #extra #parameter. The addresses used for the #RSVP #Notify mechanism has been reduced. These include the #upstream-notify-recepient, #downstream-notify-recepient, #upstream-notify-request-address and #downstream-notify-request-address. The downstream-notify-request-address is the address sent out in the PATH message for requesting the downstream nodes to sent Notify messages when needed, also the upstream-notify-request-address is the address sent out in the RESV message for requesting the upstream nodes to sent Notify messages when needed. The upstream-notify-recepient is the address received in Notify Request in the PATH message from the upstream - which is the default value used in the corresponding downstream-notify-request-address - similarly the downstream-notify-recepient is the address received in Notify Request in the RESV message from the downstream - which is the default value used in the corresponding upstream-notify-request-address. The upstream-notify-recepient is kept in the #PATH #state-block and downstream-notify-request-address in the #outgoing #PATH #state-block. The downstream-notify-recepient is kept in the #RESV #state-block and upstream-notify-request-address in the #forwarded #RESV #state-block. The extra parameters are not used as extended tunnel entries are already in place.

#GMPLS update 48 ...
[commit 90d4d660357ffefb58a7efcbef9dba39f1e453a1] (https://github.com/nes-repo/NES-Open-Switch/commit/90d4d660357ffefb58a7efcbef9dba39f1e453a1)

TED update - 20: adding new TE-Link switching-capability index

Added new #indexing on the #TE-Link #based on the #switching-type and #lsp-encoding-type in the TED module. This will enable to #look-up TE-Link based on the #switching-capability-descriptors available on the link. This will be useful when computing #path for #LSPs of specific #switching-type and #encoding-type. The switching-capability-descriptor of a TE-Link is #derived from it's underlying #component #links. This enables to create #TE-Links #over higher capacity #server-layers e.g. #Ethernet capable TE-Links created over #SDH / #OTN server-layers.

#TED update 20 ...
[commit 4719c883875c413d03d3f37ec04933399fd52ff4] (https://github.com/nes-repo/NES-Open-Switch/commit/4719c883875c413d03d3f37ec04933399fd52ff4)

TED update - 13: optimizing TE-Link link-reservation entries

#Optimized #TE-Link #link-reservation entries in TED module. The #reservation #priority has been added to the link-reservation entries, so that #preemption feature can be optimally implemented for #path #computation procedures. The #link-reservation #index has been made #compact by removing the 4 integer indexes and #replaced them with a #generic 16 byte #wide #index. This helps to keep traffic-engineering module to be less specific to the MPLS framework, as the generic index can be used from other modules as well. Also this makes link-reservation database more easily usable. The #preemption is used for #high #priority #path #setup #requests in the #traffic-engineering module. Preemption is used when #resource #crunch is experienced on a TE-Link for these requests. The #previously placed #low #priority resource #reservations will reused for performing current high priority request. The existing low priority reservations of will be either #teared #down or #moved to a different TE-Link. The bandwidth that got available from handling the low priority reservations will be used for current high priority path setup request.

#TED update 13 ...
[commit dcc8fa6c7a1eeddf3954da8671719bdb4ed62d25] (https://github.com/nes-repo/NES-Open-Switch/commit/dcc8fa6c7a1eeddf3954da8671719bdb4ed62d25)

TED update - 7: adding inter TE-Link cross-connect parameters

Added new node level inter #TE-Link #cross-connect information in TED module. This enables to draw the #possible #cross-connect #constraint present between TE-Links of a node. When this configuration is present in a node, that will be the only possible cross-connects between the specified links. But on the absence of this configuration in a node, links can be inter-connected in any possible combination - i.e. no constraint exist for cross-connect between links. When the #cross-connect is between TE-Links of #different #media #types, a possible #media #conversion has to be performed as per the #adjustment-capability information configured. Hence the TE-Links involved in a cross-connect may be part of same media layer or different media layers. On nodes with #hardware #constraint on link cross-connect this information will be useful in expressing the limitation. This could be used to #compute #path for #tunnel #LSPs in complex networks.

#TED update 7 ...
[commit 9f54195ad7587eb0e6abc23f23426f1a0f7a4160] (https://github.com/nes-repo/NES-Open-Switch/commit/9f54195ad7587eb0e6abc23f23426f1a0f7a4160)

TED update - 4: adding extended TED parameter framework

Added #extended #custom #TED #parameter s in TED module. The new TED #framework include #node, #link, #link-address and #node-adjacency #databases on the network. The node database include s all TE nodes present in the network. The TE-Links configured on each node is captured in the link database, the addresses by which the links are identified is available in the link-address database. The adjacency information between the nodes and their neighbors are available in node-adjacency database. The #locally #configured #TE-Link information is directly fed to the TED database, also the #TE information #available #from the #external #signaling modules (e.g. #OSPF-TE, #ISIS-TE) is also captured in the TED database. The TED database is used to efficiently #compute #path for #tunnel #LSPs.

#TED update 4 ...
[commit 77ac9c70e846cd31b39d39b67b4b749e437fde8e] (https://github.com/nes-repo/NES-Open-Switch/commit/77ac9c70e846cd31b39d39b67b4b749e437fde8e)

GMPLS update - 3: added standard GMPLS TE management framework

Added #standard #GMPLS #TE #tunnel #management #framework in GMPLS module. This adds the #extended #GMPLS #attribute s to the TE tunnel/LSP s. The GMPLS attributes like #switching-type, #LSP-encoding, #payload-type, #protection-type, #directionality, #path-computation-model, etc ... can be specified for the tunnels. Also the #LSP path level information can be separately indicated. The #statistics information of the #reverse #path for #bidirectional #LSP s is specified. The #LSP level #error #logging is also provided as part of the standard GMPLS framework.

#GMPLS update 3 ...
[commit d426b23529baec4326e9f8d092c4c5834a305a52] (https://github.com/nes-repo/NES-Open-Switch/commit/d426b23529baec4326e9f8d092c4c5834a305a52)

GMPLS update - 2: added standard MPLS TE management framework

Added #standard #MPLS #TE #tunnel management #framework in GMPLS module. This adds the facility for #create / #modify / #remove TE #tunnel/ #LSP s. The resource requirement for LSP s can be separately specified as #bandwidth #constraint. The #path #constraint for the LSP s can be specified as explicit route configuration. The #run-time real #path information of the LSP s is also provided as part of the standard framework.

#GMPLS update 2 ...
[commit 2b32223486638d73c9c724ab1398da0939641907] (https://github.com/nes-repo/NES-Open-Switch/commit/2b32223486638d73c9c724ab1398da0939641907)

GMPLS update - 1: created new GMPLS and TED modules in the system

Created #Generalized #Multi-Protocol #Label #Switching ( #GMPLS ) and #Traffic #Engineering #Database ( #TED ) modules in the system. The GMPLS module will assist the operator in creating transport paths - #tunnel s - in the network. The TED module will hold the information about the network necessary for planning resource optimized paths - tunnel s - in the network and provides  traffic engineering capability to GMPLS module. With the help of TED the GMPLS module will create transport #Label #Switched #Path s ( #LSP ) in the network with optimum resource ( e.g. #bandwidth ) utilization.

#GMPLS update 1 + #TED update 1 ...
[commit 0cc8969658eaab27d351dfc95a2b4ef658507edd] (https://github.com/nes-repo/NES-Open-Switch/commit/0cc8969658eaab27d351dfc95a2b4ef658507edd)

MSTP update - 18: adding STP path verctor utities

Added #STP #path #vector #utilities in MSTP module. This introduces the STP path vector comparison routine, which is used while processing xSTP PDU s. This decides whether specific path vector is superior to other ones or not.

#802-1S #MSTP update 18 ...
[commit 8742177261b48f47f81a04176045267634979afa]