RFC 8354

Use Cases for IPv6 Source Packet Routing in Networking (SPRING)

📅 published March 2018, from ietf

Use Cases for IPv6 Source Packet Routing in Networking (SPRING) 🦋

  • RFC number: 8354
  • Category: Informational
  • Date: March 2018
  • ISSN: 2070-1721
  • Authors: J. Brzozowski (Comcast), J. Leddy (Comcast), C. Filsfils (Cisco Systems), R. Maglione, Ed. (Cisco Systems), M. Townsley (Cisco Systems)
  • Obsoletes / Updates: The title block lists no obsoletes or updates. ✨

It's published by the IETF, which is the Internet Engineering Task Force 🌈

Abstract ✨

okay so the SPRING architecture (Source Packet Routing in Networking) is all about Segment Routing 🎀 Basically, it shows how you can steer packets through an IPv6 or MPLS network using the source routing paradigm. This doc is showing off some use cases for Segment Routing in an IPv6-only environment, and it's giving main character energy 💅

Status of This Memo 📝

this doc is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🫶

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🧐

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8354 💜

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. ⚖️

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  IPv6 SPRING Use Cases . . . . . . . . . . . . . . . . . . . .   3
  2.1.  SPRING in the Small Office  . . . . . . . . . . . . . . .   3
  2.2.  SPRING in the Access Network  . . . . . . . . . . . . . .   4
  2.3.  SPRING in Data Center . . . . . . . . . . . . . . . . . .   5
  2.4.  SPRING in Content Delivery Networks . . . . . . . . . . .   5
  2.5.  SPRING in Core Networks . . . . . . . . . . . . . . . . .   6
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  5.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🚀

okay so SPRING (Source Packet Routing in Networking) architecture runs on the source routing paradigm 👑 An ingress node steers a packet by including a controlled set of instructions, called segments, in the SPRING header. The whole architecture is described in [SEGMENT-ROUTING]. This document is the fun part: it shows some use cases for SPRING / Segment Routing in an IPv6-only environment 🦋

2. IPv6 SPRING Use Cases 🌈

The use cases in this section are not an exhaustive list of every possible scenario. This section only covers some of the most common deployment models people have imagined for Segment Routing over IPv6 (SRv6) 🧚

On top of the use cases in this document, all the SPRING use cases [RFC7855] also apply to the SRv6 data plane. So you get the whole bundle 💖

2.1. SPRING in the Small Office 🏠

An IPv6-enabled Small Office, Home Office (SOHO) gives every device in it plenty of globally routed IP addresses 😭 A small office with multiple egress points and their provider-assigned prefixes will, in turn, hand multiple IPv6 addresses to its hosts. A small office doing source and destination routing [PA-MULTIHOMING] will make sure packets leave the SOHO through the right egress, based on the delegated prefix for that link ✨

A SPRING-enabled SOHO lets you steer traffic onto a specific path, whether it's coming from end hosts in the SOHO or from a customer edge router in the SOHO. If the source-routed path gets selected at the customer edge router, that router is in charge of classifying traffic and steering it onto the correct path 💅 If the hosts in the SOHO have explicit source selection rules, classification can be based on the source address or the associated network egress point. That means no need for implicit classification techniques based on Deep Packet Inspection (DPI), which is honestly such a relief 🙌 If the host itself steers traffic onto a specific path, it is important to know which networks can interpret the SPRING header. This information can be provided as part of the host configuration, as a property of the configured IP address 🔥

Steering traffic to the right egress, or using a specific type of media (e.g., low power, Wi-Fi, wired, femtocell, Bluetooth, Multimedia over Coax Alliance (MoCA), HomePlug, etc.) inside the home itself, are obvious cases that an application running within a SOHO might care about 🍓

Steering to a specific egress point can be useful for a bunch of scenarios, including:

  • regulatory compliance;
  • performance of a particular service associated with a particular link;
  • cost imposed due to data caps or per-byte charges;
  • distinguishing between personal vs. work traffic in homes with one or more teleworkers; and
  • provision of specific services by one ISP vs. another.

Information in the SPRING header, whether it was imposed by the end host itself, a customer edge router, or within the ISP's access network, may be useful at the far ends of the data communication too 🦋 For example, an application running on an end host with application support in a data center can use the SPRING header as a channel to include information that affects how the data center itself treats it. That allows application-level steering and load balancing without relying on implicit application-classification techniques at the edge of the data center 🧚 Also, as more and more application traffic gets encrypted, being able to pull out (and put into the SPRING header) just enough information for the network and data center to load balance and steer traffic properly becomes more and more important 😭🫶

2.2. SPRING in the Access Network 📡

Access networks deliver all kinds of traffic from the service provider's network to the home, and from the home back toward the service provider's network 💜

For bandwidth management or related purposes, the service provider may want to link certain types of traffic to specific physical or logical downstream capacity pipes 🌸

This mapping is not the same thing as classification and scheduling. In the cable access network, these pipes are represented at the Data-Over-Cable Service Interface Specification [DOCSIS] layer as different service flows, which are better thought of as distinct data links 🔥 So creating this separation lets an operator tell different types of content apart and do a bunch of different things with these pipes, like byte capping, regulatory compliance functions, and billing 💅

In a cable operator's environment, these downstream pipes could be a DOCSIS [DOCSIS] service flow, a service group, or a specific Quadrature Amplitude Modulation (QAM) as in Annex B of [ITU.J83] 🌈

The operator may also want to map traffic from the home that's heading toward the service provider's network onto specific upstream capacity pipes. Information carried in a packet's SPRING header could provide the target pipe for that specific packet ✨ The access device would not need to know the specific details about the packet to do this mapping. Instead, it would only need to know how to interpret the SPRING header and how to map it to the target pipe 🧠✨

2.3. SPRING in Data Center 🖥️

Some data center operators are moving their infrastructure from IPv4 to native IPv6 only, so they can deal with IPv4 address depletion and get to larger scale 📈 In that kind of environment, source routing (as enabled by SRv6) can be used to steer traffic across specific paths through the network. The specific path may also include a given function that one or more nodes on the path are asked to perform 🎀

One of the fundamental requirements for a data center architecture is to provide scalable, isolated tenant networks. In those scenarios, Segment Routing can be used to build a construct that steers traffic across that specific path and identifies specific nodes, tenants, and functions 👑

2.4. SPRING in Content Delivery Networks 🎬

Online video apps and new video-capable IP devices have caused an explosion of video traffic moving across network operator infrastructures 😭📺 To reduce the capital and operational impact of this massive influx of online video traffic, and to bring traditional TV services to new devices and screens, network operators are increasingly turning to Content Delivery Networks (CDNs) 💖

Several studies showed the benefits of connecting caches in a hierarchical structure, following the hierarchical nature of the Internet 🌳 In a cache hierarchy, one cache sets up peering relationships with its neighbor caches. There are two types of relationships: parent and sibling. A parent cache is basically one level up in the cache hierarchy, and a sibling cache is on the same level. Multiple levels of hierarchy are commonly used to build an efficient cache architecture 🧚

In an environment where each single cache system can be uniquely identified by its own IPv6 address, you can build a list containing a sequence of the caches in a hierarchy. At each node (cache) in the list, the presence of the requested content gets checked. If the requested content is found at the cache (a cache hits scenario), the sequence ends, even if there are more nodes in the list. Otherwise, the next element in the list (the next node/cache) gets examined 🔍✨

2.5. SPRING in Core Networks ✨

okay so traffic on the network keeps growing 📈, and literally every kind of traffic (video, gaming, calls, everything) is getting squished onto the same network architecture 😭. so the network operators are starting to hit some new problems, and it's kind of a lot 💀

some operators are already building, or plan to build soon, an IPv6-only native infrastructure for their core network 🌐. these operators are also looking at setting up an explicit path based on the IPv6 source address for specific types of traffic, so they can use their network infrastructure efficiently 🧚. and here's the lowkey genius part: some operators are assigning (or plan to assign) IPv6 prefix(es) to their IPv6 customers based on region or geography 🗺️. that means the subscriber's IPv6 prefix can tell you where the customer is located 👀. in that kind of setup, the edge nodes of the network could use the IPv6 source address to steer traffic and forward it through a specific path other than the optimal path 🦋. the way that works is giving it main character energy 👑

there are a few reasons an operator might want a source-based path that goes through some specific middle or intermediate points in the network 💅:

  • the operator may want to use some high-bandwidth links for a specific type of traffic (like video), so they don't have to overdimension all the links in the network 🎬
  • the operator may want to set up a specific path for delay-sensitive applications ⏱️
  • the operator may need to select one (or multiple) specific exit point(s) at peering points when different peering points are available 🚪
  • the operator may need to set up a source-based path for specific services, so they can reach servers hosted in facilities that aren't always reachable through the optimal path 🏢
  • the operator may need to provision guaranteed disjoint paths (a so-called "dual-plane network") for diversity purposes 🧩

ngl all of these scenarios would need some form of traffic engineering capabilities in an IPv6-only network environment 🔥 that's the whole vibe, periodt 💖

3. IANA Considerations 🎀

no IANA actions for this one, bestie 🌸

4. Security Considerations 🔒

okay, real talk for a sec 🫶. this document is just presenting use cases for the SPRING architecture and potential IPv6 extensions to think about, so it doesn't introduce any security considerations on its own 📝. BUT. there are a bunch of security concerns with source routing at the IP layer, and those are covered in [RFC5095] 🚨. it's expected that any solution that handles these use cases will also handle those security concerns 🛡️. this is so important, don't skip it, it's not optional energy 😤

5. References ✨

5.1. Normative References 💜

[RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
           Litkowski, S., Horneffer, M., and R. Shakir, "Source
           Packet Routing in Networking (SPRING) Problem Statement
           and Requirements", RFC 7855, DOI 10.17487/RFC7855,
           May 2016, <https://www.rfc-editor.org/info/rfc7855>.

5.2. Informative References 📚

[DOCSIS]   CableLabs, "New Generation of DOCSIS Technology", October
           2013, <http://www.cablelabs.com/news/
           new-generation-of-docsis-technology/>.

[ITU.J83]  ITU-T, "Digital multi-programme systems for television,
           sound and data services or cable distribution", ITU-T
           Recommendation J.83, December 2007,
           <https://www.itu.int/rec/T-REC-J.83/en>.

[PA-MULTIHOMING]
           Baker, F., Bowers, C., and J. Linkova, "Enterprise
           Multihoming using Provider-Assigned Addresses without
           Network Prefix Translation: Requirements and Solution",
           Work in Progress, draft-ietf-rtgwg-enterprise-pa-
           multihoming-03, February 2018.

[RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
           of Type 0 Routing Headers in IPv6", RFC 5095,
           DOI 10.17487/RFC5095, December 2007,
           <https://www.rfc-editor.org/info/rfc5095>.

[SEGMENT-ROUTING]
           Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
           Litkowski, S., and R. Shakir, "Segment Routing
           Architecture", Work in Progress, draft-ietf-spring-
           segment-routing-15, January 2018.

Acknowledgements 🫶

the authors want to thank Brian Field, Robert Raszuk, Wes George, Eric Vyncke, Fred Baker, John G. Scudder, Adrian Farrel, Alvaro Retana, Bruno Decraene, and Yakov Rekhter for their valuable comments and inputs to this document 💖 you're all iconic 👑

Contributors 🌈

many people contributed to this document 🦋. the authors would like to thank and recognize them and their contributions, because these contributors provided invaluable concepts and content for this document's creation ✨

Ida Leung
Independent
Email: ida@brumund.ca


Stefano Previdi
Cisco Systems
Via Del Serafico, 200
Rome  00142
Italy
Email: stefano@previdi.net


Christian Martin
Arista Networks
Email: cmartin@arista.com

Authors' Addresses 💅

John Brzozowski
Comcast

Email: john_brzozowski@cable.comcast.com


John Leddy
Comcast

Email: John_Leddy@cable.comcast.com


Clarence Filsfils
Cisco Systems
Brussels
Belgium

Email: cfilsfil@cisco.com


Roberta Maglione (editor)
Cisco Systems
Via Torri Bianche 8
Vimercate  20871
Italy

Email: robmgl@cisco.com


Mark Townsley
Cisco Systems

Email: townsley@cisco.com
📦 where this page comes from