There's been considerable industry interest surrounding SPRING, also known as Segment-Routing. Many operators are incorporating SPRING technology into their networks currently running RSVP-TE. In some cases, the objective is to migrate all services to utilize SPRING-based LSPs. In other cases, there may be a need to manage some application traffic over RSVP-TE LSPs in conjunction with applications using SPRING-based LSPs. In either case, there is a need to manage traffic and capacity across both the RSVP-TE and SPRING domains. While there are a range of options for managing through this period of network transition, all carry varying tradeoffs. An overview of these options is captured within this IETF draft.
In this post, we’ll discuss some key challenges associated with managing bandwidth allocation across the SPRING and RSVP-TE domains while a subsequent post will focus on the functionality that Juniper Networks has developed to help operators dynamically manage the coexistence of RSVP-TE and SPRING in their networks. Juniper Networks objective is to enable customers to deploy SPRING in their networks in a minimally disruptive manner, while maximizing the utilization of all deployed network resources.
Enabling Graceful SPRING Adoption
While SPRING enables a range of new applications and capabilities, it does create tradeoffs in terms of instrumentation and traffic management capabilities. Functions historically embedded within network elements, are to be managed by a centralized controller. Under SPRING, awareness of available network resources and traffic placement is not distributed throughout the network. While this dramatically reduces the amount of state that a network element must maintain, it requires that the network elements and controller have very granular and current interface utilization information.
As operators with global networks begin introducing SPRING-based application traffic into their networks they must do so without negatively impacting existing traffic which may not be readily portable to a SPRING or controller-driven model of forwarding (e.g.: ). This means that application traffic traversing an RSVP-TE and SPRING enabled network must be carefully managed. A critical step in managing this migration is insuring that the controller infrastructure has the necessary visibility into network traffic loads.
Juniper Telemetry Interface (JTI) facilitates exporting granular and timely platform statistics enabling operators to start to develop the systems to feed critical data to their controller infrastructure. Developing the ability to understand the traffic loads in the network is a critical preparatory step in enabling SPRING within existing networks. (Previous Blog postings provide additional details regarding use of the JTI. here and here.)
With SPRING, traffic simply "shows up" and may be forwarded within the MPLS domain using labels (e.g.: Node-SIDs and Anycast-SIDs). There is not necessarily a well-defined notion of a transit LSP or in many cases a clear point of ingress into the MPLS domain. This means that operators require a new toolkit to manage their traffic and understand where traffic may be coming from and going to within their networks.
In the RSVP-TE model, an LSP's point of ingress provides a very useful point for traffic instrumentation as well as a point for path re-optimization if traffic demands change. SPRING traffic, however, relies upon the controller to have an awareness of link utilization and the available capacity in the network. Unless all RSVP-TE traffic is controller , LSPs are not signaled from the RSVP-TE domain with an awareness of actual network utilization. This lack of visibility into actual network utilization based on SPRING traffic loads may result in overbooking links, potentially resulting in congestion and lost traffic. Alternatively, statically carving out bandwidth for each type of traffic results in wasting capacity as capacity can be stranded in one domain or another.
Given the nascent state of controller deployments and the need to adjust to dynamic traffic conditions as operators begin to inject SPRING application traffic into their networks, there's a need to inform the RSVP-TE domain as to changes in available capacity. The RSVP-TE domain needs to adapt to the actual SPRING traffic utilization and potentially move traffic elsewhere.
Finally, all of this needs to take place without the introduction of new protocols or introduce potentially new interoperability considerations. Not a trivial set of requirements given the pervasive deployment of RSVP-TE in today’s Internet.
Our next blog post discusses how JunOS enables this ...
 For the purposes of this discussion we assume that all traffic is either SPRING or RSVP-TE traffic. There may be additional traffic types on these links which must be accounted for. (e.g.: LDP, native IP, etc.) However, for most operators considering the deployment of SPRING who have a need for controlled bandwidth management we presume that the existing network traffic is all RSVP or SPRING traffic.