Академический Документы
Профессиональный Документы
Культура Документы
Data-plane Encodings
1 © Nokia 2019
Agenda
• Introduction
• Evolution of Segment Routing
• Conclusion
2 © Nokia 2019
Market needs
Network adapts for application and user experience
3 © Nokia 2019
Segment Routing
Value Proposition – Simplicity by “Enhanced Forwarding Behavior”
• Packet Forwarding decision is based upon “Segments”
and not upon “IP payload prefix”
• Segments are encoded as 32bits or 128bits
- 32bit Segments supported IPv6, MPLS, (or even IPv4)
dataplane
- 128bit Segments supported only upon IPv6 dataplane
- Sequence of segments represents a set of
actions/instructions imposed to the packet
• No per-flow state contained within the network
• Segments are distributed by Routing or SDN control
- No more LDP, because LDP is “Soo Sad”
- Fair balance between “distributed intelligence” and
“centralized optimization/programming”
• Perfect complement to NSH (Network Services Header)
- However, minimal context could be encoded in segments (see
4 later)
© Nokia 2019
Agenda
• Introduction
• Evolution of Segment Routing
• Conclusion
A story to compare Apples with Apples !
5 © Nokia 2019
Evolution of Segment Routing # 1
Encoding: 32bits Segments directly into MPLS Dataplane
• Do not confuse with MPLS !
- There is no ‘LDP’ with Segment Routing
• Segments encoded directly into MPLS Dataplane
• https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
• Principle used:
- Encode the Segments as a sequence of 32bit Label fields
• MPLS label itself is 20 bits added with 12 bit operational overhead/information
6 © Nokia 2019
How does segment Routing look like?
Using 32bit Segments (on dataplane it mimics MPLS)
Original
IP Header
7 © Nokia 2019
Evolution of Segment Routing # 2
Encoding: 128bits Segments directly into IPv6 Header
• Do not confuse with classic IPv6 - This is NOT classic IPv6 Routing
• Segments encoded as [Outer IPv6 header] [SRH extension header] [optional HMAC security header]
• https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-16
• Principle used:
- Based upon IPv6 Source Routing with new innovative IPv6 extension header (SRH)
- Each segment is 128 bit
• 128bit segments allow limited service semantics to be encoded (NSH not absolutely required anymore)
• Larger header overhead tax compared to MPLS encoding
• IPv6-only data-plane support
• HW forwarding ASIC considerations
- Processing long extension headers is computationally expensive
• Security consideration: semantics mix of “location” and “context” is good topic for discussion
8 © Nokia 2019
How does SRv6 Look like
Segments (128 bit) with IPv6 encapsulation
IPv6 Encapsulation
40 Byte (320 bit)
(Tunnel/Outer Header)
SRH Extension Header
8 byte fixed SRH header SRv6 Header
+
(IPv6 Dataplane Encapsulation)
(X * 128 bit/segment
Original
IP Header
Segment Routing Payload
Original (e.g. original IP Packet)
IP packet payload
(variable size)
9 © Nokia 2019
Encoding 128bit Segment
How does it look on the wire?
Customer Site or Data-Center Provider Backbone
10 © Nokia 2019
Encoding 128bit Segment
How does it look on the wire?
Customer Site or Data-Center Provider Backbone
Payload SR Headers
40 byte
SRH
8 + (x * 16) byte
IPv6
40 byte
11 © Nokia 2019
Encoding 128bit Segment
How does it look on the wire?
Customer Site or Data-Center Provider Backbone
Payload SR Headers
40 byte
SRH
8 + (x * 16) byte
IPv6
40 byte
12 © Nokia 2019
*Note1: Reference (https://datatracker.ietf.org/meeting/104/materials/slides-104-spring-the-ipv6-compressed-routing-header-crh-01)
Encoding 128bit Segment
Comparing 128bit vs 32bit encoding
Customer Site or Data-Center Provider Backbone
Payload SR Headers
40 byte
SRH
8 + (x * 16) byte
IPv6
40 byte
Payload SR Headers
4 byte/segment
13 © Nokia 2019
Evolution of Segment Routing
What is next?
• What we discussed sofar
- We have 32bit segments encoded in MPLS dataplane
- We have 128bit segments encoded in IPv6 dataplane
• So, can we not have 32bit segments encoded using native IPv6 and IPv4?
15 © Nokia 2019
How does SRoUDP Look like
Segments (32 bit) with IP encapsulation
40 byte (IPv6) or 20 byte (IPv4) IP Outer (Tunnel) Header IP Tunnel Encapsulation Header
18 © Nokia 2019
How does SRoUDP compare with SRv6?
Comparing the encoding
SRoUDP
UDP header + 3 * SID
8Byte + 3*4Byte
20 Byte
4% BW overhead
19 © Nokia 2019
*Note1: Reference (https://datatracker.ietf.org/meeting/104/materials/slides-104-spring-the-ipv6-compressed-routing-header-crh-01)
Evolution of Segment Routing - 4
Seamless Segment Routing Encoding
• Seamless Segment Routing support for
- Native IPv6 dataplane (SRoUDPv6)
- Native MPLS dataplane
- (and even native IPv4 Dataplane (SRoUDPv4))
• A Segment Routing 32bit-Segment is mapped to most appropriate data-plane encapsulation
(performance, security, availability)
- Part of Nokia NF-IX (Network Function Interconnect Framework)
- NFIX uses predominant BGP (BGP-LS, BGP-LU, BGP SR-TE, EVPN etc…) as the dominant protocol
- NFIX segment routing underlay: Advanced LFA, SRTE tunnels, scale optimization, SDN controller driven
- Note: Nokia NFIX architecture allows SRv6 as well if needed/required
• Deployment scenario
- Sweet spot: Brownfield networks (Fixed and Mobile providers)
- Easy integration of existing L2/3 and resiliency services
- Deploy proven/secure technology first and seamlessly optimize when appropriate to different types of segments
20 © Nokia 2019
Agenda
• Introduction
• Evolution of Segment Routing
• Conclusion
21 © Nokia 2019
Conclusion
Segment Routing Data-plane encoding
• SRoMPLS & SRoUDP (32bit segments) run over MPLS/IPv4/IPv6
- Good fit for brownfield networks
• Can keep using existing MPLS, IPv4 and IPv6 dataplane
• No need for forklift upgrade
• Seamless across all dataplanes
- Small BW overhead imposed by Segment Routing
- Forwarding ASIC friendly
- Well documented security properties
• SRv6 (128bit segments) runs over IPv6 network
- Innovative technology fit for IPv6 networks
- 128bit segments could contain service/context properties
• Simplification: SRv6 may use industry standard NSH header, but not a must anymore
- Ongoing work progressed at IETF