Nokia NSP:Centralized SDN control across inter-domain routing (Extended)

Nokia NSP:Centralized SDN control across inter-domain routing (Extended)

Hello everyone. My name is Anand Raj. I’m a product manager on the Network Services Platform. And I’m here to talk about a specific application called IP/MPLS Optimization. This application is basically a PCE. It also does resource controlling. The two main things that this application does are path computation, optimization and resource control. What I’m going to show you today is a specific use case, which service providers may be interested in. And what it does is inter-domain path computation. What you see here is the Network Services Platform login page. There is a plethora of applications available here. We’re going to the IP/MPLS Optimization application. But prior to that, let me show you a little bit on the slides on what the application is. The NSP IP/MPLS Optimization application provides centralized SDN control across inter-domains. And what we’re going to show you is how the NRC-P computes a path end-to-end with intelligent path computation while optimally allocating resources. The key thing is you want to maximize path optimization while administering and scaling router domains the way you want. The challenge today is we have lack of inter-domain coordination. So while you have multiple domains in your network, in order to be able to successfully route a path across these domains, you need to distribute routing and control information across these domains. And that may be a challenge for some of the devices in the network as the amount of control information can quickly scale up. So what the NRC-P does is first provide visibility into these domains. And it also provides an ability for the operator to realize that these prefixes or these IP addresses are reachable within the domain itself. And from that point on, it simply goes along and computes the best path across the domains. So the NSP provides centralized control by supporting multiple instances even on the same routers. We’ll see in our application, as I switch to my web client, how the NSP discovers the different domains, how it overlays the domains on top of the common routers and how it calculates the path. So one quick thing is we support both technologies, which is creating paths via RSVP, which is a technology that is being used by service providers today. We also support Segment Routing, which is a new and upcoming technology and which is quite scalable. However, one of the challenges in Segment Routing is the ability to contain the information with a few Segment Routing labels, and that’s why we have something called the Max SID Depth problem. While spanning across IGP domains if you’re spanning across multiple routers in the multiple domains, it’s almost impossible to supply an ERO with as many labels as you want. Therefore we have some optimization techniques that we will showcase primarily in how we can reduce the ERO across these multiple domains. So the solution is really to provide centralized control. And also if you have the ability to specify Anycast as Segment Routing labels for your border points as shown in this diagram here. In this diagram we’ve got a three-domain network. You’ve got Anycast representation on the border point between Instance 1 and Instance 0, which are really two router domains. And you’ve got Anycast representation between Instance 1 and Instance 2. So what we do is, while we can optimally calculate a path across these domains, we can only specify if you want to contain the Segment Routed label stack, to the only Anycast segment representations. We offer two solutions in the space. Solution 1 is you can specify Loose Hop Anycast ASBRs if they are present. And Solution 2 is you can specify Loose Hop ASBRs. The difference between the two options is that if Anycast is available, the NSP takes advantage of the presence of Anycast labels and computes a path using Anycast labels. In the second option, if Anycast labels aren’t available, then we specify simply the best border router to reach from one domain to the other domains, and therefore ERO specification is really a list of the most optimal border routers. Mind you, the NSP does in fact calculate the best path, because it simply does a graph computation from the source to destination across these multiple domains. This is simply possible because we are able to discover all the domains; we are able to discover the inter-connection points; and we’re also able to discover all the reachabilities. So when we pick the exact path, we then realize how to best specify the path using what’s available to us. So that’s why in Option 1 you’ve got Anycast SIDs, if you use Anycast SIDs. In Option 2 where you don’t have Anycast capabilities, we specify the border routers. Now between solution 1 and 2 there’s a fallback mechanism. If, for example, you cannot determine the ideal pair of Anycast, or if Anycast information isn’t available, you automatically fall back to Option 2. And that’s what we’ll showcase today. Here we have the NSP IP/MPLS Optimization application. As you can see, there is a map pane here and you’ve got your list of LSPs that are currently available in the system. The application also lists all the current IP addresses and their reachabilities. So let’s go and see all the domains it’s connected to. If I click on “All” there are about three domains here and the way these domains are shown is simply by the link colors. If you want to understand what these domains are, you can actually drop the list down here to see the different TopologyIds that we’re getting. All the different discovery that is done here is done by BGP LS and therefore you see that the TopologyId is based on the BGP LS parameters. So you have the IGP instance ID, the AS number, and the BGP LS identifier. They uniquely discover these domains. Since these domains are on multiple routers, you can see that this common ASBR router supports domains number 10 and 20. This ASBR router supports domains 20 and 30. If you want to look at the level of Anycast SIDs you have to look at some of these routers on which the Anycast SIDs are advertised. So, for example, on this ASBR, which has a router ID of, if I specify all the prefixes that I’m advertising from this router, you can see that I have… …a bunch of Anycast prefixes that I’m generating. This specifically here – this 200221 – is an Anycast prefix that is generated by this router here. So if I go and specify the Anycast prefix and I search on that…. So if you look at Anycast prefix 200200 that advertises from both routers 221 and 223, and that’s how you can indicate if it’s an Anycast SID. Now we’ll go back to the list of LSPs. And the first thing we’ll try and do is we’ll basically connect a path all the way from the domain on the left to the domain on the right. As you can see these are multiple ISIS domains and because reachability is contained in each of these domains, node 219 – if it needs to generate a path or connect a path across these domains can only do so by connecting to its next hop router. So because the NSP learns all the prefixes and reachabilities, it is easily able to connect a path from end to end. We’ll see how. Let’s go on the CLI to connect an LSP. As you can see, there are two LSPs here. Each of the LSPs start from Las Vegas 219 which is shown in the domain on the west. And they traverse across domain 20 and terminate on domain 190. So if you look at the definition of the LSP, you have a destination address specified – the wording cspf, pce-computation, pce-report enable, and control. These are simply PCE options that determine the amount of control that the PCC client needs to award for the LSP to the NRC-P. So pce-computation instructs the NSP to compute a path. The pce-report reports the state of the LSP once the NSP provides a PCE path. And the pce-control instructs the NSP to be able to control the LSP should it need to reroute. Now one different thing that you’ll see here, which is path-profile 20, this is specified and has no particular significant meaning on the PCC. It’s just a number that’s added here. This path profile, however, has significance on the NSP So I’m going to simply unshut this LSP. So now if I go onto my NSP, you can see that this LSP is now up and is routed. So it’s Segment Routed type. Its operational status is UP. It starts from 219 and ends at 190. So if you look at the actual highlight of the LSP, you’ll see a bunch of routers that are highlighted and not the paths. So we’ll check on the highlight again, close the control here. So essentially what this means is that if a path is originating from 219, its transit points are potentially 198, 199 and 221, 223 across the two domains to get to the destination, which is 190. So we’re transiting through various domains and we’re picking the best Anycast pair here. And to get details of the Anycast pair, drop down the LSP and you’ll see the ERO specification here, which is basically an Anycast SID. If I expand this link here just to show you in a little more detail, you can see that the original SID is simply an Anycast as well. So both these routers here, 198 and 199, which are the transit ASBRs, provide an Anycast SID in terms of distribution into this particular domain. So that’s the first ERO specified. 221 and 223, as you saw before, provide 200200 into this domain. These Anycast SIDs are only sent within this domain. So 200200, which also has an Anycast IP address, is not sent to the first domain. And that’s a key thing. So in the ERO specification you can see how you’ve got the first Anycast SID, the second Anycast SID, and the destination. That’s how the NSP provides the ERO across domains, to enable path computation across domains. Obviously in this situation because we’re supplying the Anycast SIDs as EROs, the actual path is not known. So in order to do that, we’ll be developing a feature set in later releases that actually goes and inquires the exact path from the very routers. Now I’m going back to my CLI and I’m turning on another LSP. In this case, this LSP and this LSP, the definitions are similar, except the path-profile is different. It’s 21 here. So just a little more on the path-profile. As I mentioned before, there’s no significance on the PCC. However, on the NSP, what path-profile 20 translates to is instructions for the NSP to compute an Anycast pair path, using Anycast SIDs if possible. Similarly on 21, with the name “LooseHop”, we’re instructing the NSP to compute a path based on the best node SID ERO for inter-domain ASBRs. So once we go back to our demo there, and if I look at this LSP here, and if I overlay this LSP, you can see that I only have some of the border routers highlighted. This is clearer if I go into the 3D view, as you can see. The first LSP spans across Anycast and the second LSP picks the best nodes to transit across the ASBRs. So these are particular options that we were talking about before with respect to computing inter-domain connection paths. And all of these LSPs, while I supply them from the CLI, I can also supply them from the NSP itself. So I can simply create a path name here. And I’m supplying the PCC address, which is the destination there. So I’m perusing from right to left here, from the east domain to the west domain. And I’m going to specify my profile ID of 20. Click Submit. And you can see going from east to west domains again it picks the best Anycast pair to transit across the domains to the destination. So based on the video, you can see the NSP computes inter-domain paths using the two options that I specified. One is a Loose Hop Anycast and the second option is the Loose Hop Node SID. So this is how the NSP enables the operators to compute inter-domain paths using any of these options as I described. Stay tuned for more videos on inter-domain connection points.

2 thoughts on “Nokia NSP:Centralized SDN control across inter-domain routing (Extended)

  1. nokia baest


Leave a Reply

Your email address will not be published. Required fields are marked *