-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-dmm-srv6-mobile-uplane.txt
1680 lines (1121 loc) · 62.9 KB
/
draft-ietf-dmm-srv6-mobile-uplane.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
DMM Working Group S. Matsushima, Ed.
Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils
Expires: January 14, 2021 M. Kohno
P. Camarillo, Ed.
Cisco Systems, Inc.
D. Voyer
Bell Canada
C. Perkins
Futurewei
July 13, 2020
Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-09
Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6)
to the user-plane of mobile networks. The network programming nature
of SRv6 accomplish mobile user-plane functions in a simple manner.
The statelessness of SRv6 and its ability to control both service
layer path and underlying transport can be beneficial to the mobile
user-plane, providing flexibility, end-to-end network slicing and SLA
control for various applications. This document describes the SRv6
mobile user plane.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021.
Matsushima, et al. Expires January 14, 2021 [Page 1]
Internet-Draft SRv6 Mobile User-Plane July 2020
Copyright Notice
Copyright (c) 2020 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, as 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 are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. A 3GPP Reference Architecture . . . . . . . . . . . . . . . . 6
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9
5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14
5.3.3. Extensions to the interworking mechanisms . . . . . . 17
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 18
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 20
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 21
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 22
6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 23
6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 24
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 24
8. Network Slicing Considerations . . . . . . . . . . . . . . . 24
9. Control Plane Considerations . . . . . . . . . . . . . . . . 25
Matsushima, et al. Expires January 14, 2021 [Page 2]
Internet-Draft SRv6 Mobile User-Plane July 2020
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
In mobile networks, mobility management systems provide connectivity
over a wireless link to stationary and non-stationary nodes. The
user-plane establishes a tunnel between the mobile node and its
anchor node over IP-based backhaul and core networks.
This document shows the applicability of SRv6 (Segment Routing IPv6)
to mobile networks.
Segment Routing [RFC8402] is a source routing architecture: a node
steers a packet through an ordered list of instructions called
"segments". A segment can represent any instruction, topological or
service based.
SRv6 applied to mobile networks enables a source-routing based mobile
architecture, where operators can explicitly indicate a route for the
packets to and from the mobile node. The SRv6 Endpoint nodes serve
as mobile user-plane anchors.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
o CNF: Cloud-native Network Function
o NFV: Network Function Virtualization
o PDU: Packet Data Unit
o PDU Session: Context of an UE connects to a mobile network.
o UE: User Equipment
o UPF: User Plane Function
o VNF: Virtual Network Function (including CNFs)
The following terms used within this document are defined in
[RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
Matsushima, et al. Expires January 14, 2021 [Page 3]
Internet-Draft SRv6 Mobile User-Plane July 2020
SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding
SID.
The following terms used within this document are defined in
[RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint
Node and Reduced SRH.
The following terms used within this document are defined in [NET-
PGM]: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 Segment Endpoint
Behavior.
2.2. Conventions
An SR Policy is resolved to a SID list. A SID list is represented as
<S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID
to visit and S3 is the last SID to visit along the SR path.
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
- Source Address is SA, Destination Address is DA, and next-header is
SRH
- SRH with SID list <S1, S2, S3> with Segments Left = SL
- Note the difference between the <> and () symbols: <S1, S2, S3>
represents a SID list where S1 is the first SID and S3 is the last
SID to traverse. (S3, S2, S1; SL) represents the same SID list but
encoded in the SRH format where the rightmost SID in the SRH is the
first SID and the leftmost SID in the SRH is the last SID. When
referring to an SR policy in a high-level use-case, it is simpler
to use the <S1, S2, S3> notation. When referring to an
illustration of the detailed packet behavior, the (S3, S2, S1; SL)
notation is more convenient.
- The payload of the packet is omitted.
SRH[n]: A shorter representation of Segment List[n], as defined in
[RFC8754]. SRH[SL] can be different from the DA of the IPv6 header.
o gNB::1 is an IPv6 address (SID) assigned to the gNB.
o U1::1 is an IPv6 address (SID) assigned to UPF1.
o U2::1 is an IPv6 address (SID) assigned to UPF2.
o U2:: is some other IPv6 address (SID) assigned to UPF2.
2.3. Predefined SRv6 Endpoint Behaviors
The following SRv6 Endpoint Behaviors are defined in
[I-D.ietf-spring-srv6-network-programming].
o End.DT4: decapsulate and forward using a specific IPv4 table
lookup.
Matsushima, et al. Expires January 14, 2021 [Page 4]
Internet-Draft SRv6 Mobile User-Plane July 2020
o End.DT6: decapsulate and forward using a specific IPv6 table
lookup.
o End.DX4: decapsulate the packet and forward through a particular
outgoing interface -or set of OIFs- configured with the SID.
o End.DX6: decapsulate and forward through a particular outgoing
interface -or set of OIFs- configured with the SID.
o End.DX2: decapsulate the L2 frame and forward through a particular
outgoing interface -or set of OIFs- configured with the SID.
o End.T: forward through the shortest path using a specific IPv6
table.
o End.X: forward through an L3 adjacency with the SID.
New SRv6 behaviors are defined in Section 6 of this document to
mechanisms described in this document.
3. Motivation
Mobile networks are becoming more challenging to operate. On one
hand, traffic is constantly growing, and latency requirements are
tighter; on the other-hand, there are new use-cases like distributed
NFVi that are also challenging network operations.
The current architecture of mobile networks does not take into
account the underlying transport. The user-plane is rigidly
fragmented into radio access, core and service networks, connected by
tunneling according to user-plane roles such as access and anchor
nodes. These factors have made it difficult for the operator to
optimize and operate the data-path.
In the meantime, applications have shifted to use IPv6, and network
operators have started adopting IPv6 as their IP transport. SRv6,
the IPv6 dataplane instantiation of Segment Routing [RFC8402],
integrates both the application data-path and the underlying
transport layer into a single protocol, allowing operators to
optimize the network in a simplified manner and removing forwarding
state from the network. It is also suitable for virtualized
environments, like VNF/CNF to VNF/CNF networking.
SRv6 defines the network-programming concept
[I-D.ietf-spring-srv6-network-programming]. Applied to mobility,
SRv6 can provide the user-plane behaviors needed for mobility
management. SRv6 takes advantage of the underlying transport
awareness and flexibility together with the ability to also include
services to optimize the end-to-end mobile dataplane.
The use-cases for SRv6 mobility are discussed in
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases].
Matsushima, et al. Expires January 14, 2021 [Page 5]
Internet-Draft SRv6 Mobile User-Plane July 2020
4. A 3GPP Reference Architecture
This section presents a reference architecture and possible
deployment scenarios.
Figure 1 shows a reference diagram from the 5G packet core
architecture [TS.23501].
The user plane described in this document does not depend on any
specific architecture. The 5G packet core architecture as shown is
based on the latest 3GPP standards at the time of writing this draft.
+-----+
| AMF |
+-----+
/ | [N11]
[N2] / +-----+
+------/ | SMF |
/ +-----+
/ / \
/ / \ [N4]
/ / \ ________
/ / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
Figure 1: 3GPP 5G Reference Architecture
o gNB: gNodeB with N3 interface towards packet core (and N2 for
control plane)
o UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane)
o UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane)
o SMF: Session Management Function
o AMF: Access and Mobility Management Function
o DN: Data Network e.g. operator services, Internet access
This reference diagram does not depict a UPF that is only connected
to N9 interfaces, although the description in this document also work
for such UPFs.
Each session from a UE gets assigned to a UPF. Sometimes multiple
UPFs may be used, providing richer service functions. A UE gets its
IP address from the DHCP block of its UPF. The UPF advertises that
IP address block toward the Internet, ensuring that return traffic is
routed to the right UPF.
Matsushima, et al. Expires January 14, 2021 [Page 6]
Internet-Draft SRv6 Mobile User-Plane July 2020
5. User-plane behaviors
This section introduces an SRv6 based mobile user-plane.
In order to simplify the adoption of SRv6, we present two different
"modes" that vary with respect to the use of SRv6. The first one is
the "Traditional mode", which inherits the current 3GPP mobile user-
plane. In this mode GTP-U [TS.29281] is replaced by SRv6, however
the N3, N9 and N6 interfaces are still point-to-point interfaces with
no intermediate waypoints as in the current mobile network
architecture.
The second mode is the "Enhanced mode". This is an evolution from
the "Traditional mode". In this mode the N3, N9 or N6 interfaces
have intermediate waypoints -SIDs- that are used for Traffic
Engineering or VNF purposes. This results in optimal end-to-end
policies across the mobile network with transport and services
awareness.
In both, the Traditional and the Enhanced modes, we assume that the
gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6
interfaces are SRv6).
In addition to those two modes, we introduce two mechanisms for
interworking with legacy access networks (those where the N3
interface is unmodified). In this document we introduce them as a
variant to the Enhanced mode, however they are equally applicable to
the Traditional mode.
One of these mechanisms is designed to interwork with legacy gNBs
using GTP/IPv4. The second mechanism is designed to interwork with
legacy gNBs using GTP/IPv6.
This document uses SRv6 Segment Endpoint Behaviors defined in
[I-D.ietf-spring-srv6-network-programming] as well as new SRv6
Segment Endpoint Behaviors designed for the mobile user plane that
are defined in this document Section 6.
5.1. Traditional mode
In the traditional mode, the existing mobile UPFs remain unchanged
except for the use of SRv6 as the data plane instead of GTP-U. There
is no impact to the rest of the mobile system.
In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1
with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored
here to replace GTP encapsulation with the SRv6 encapsulation, while
Matsushima, et al. Expires January 14, 2021 [Page 7]
Internet-Draft SRv6 Mobile User-Plane July 2020
not changing anything else. There will be a unique SRv6 SID
associated with each PDU Session.
The traditional mode minimizes the changes required to the mobile
system; hence it is a good starting point for forming a common
ground.
Our example topology is shown in Figure 2. In traditional mode the
gNB and the UPFs are SR-aware. In the descriptions of the uplink and
downlink packet flow, A is an IPv6 address of the UE, and Z is an
IPv6 address reachable within the Data Network DN. A new SRv6
function End.MAP, defined in Section 6.2, is used.
________
SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node
Figure 2: Traditional mode - example topology
5.1.1. Packet flow - Uplink
The uplink packet flow is as follows:
UE_out : (A,Z)
gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
When the UE packet arrives at the gNB, the gNB performs a
H.Encaps.Red operation. Since there is only one SID, there is no
need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA
U1::1. U1::1 represents an anchoring SID specific for that session
at UPF1. gNB obtains the SID U1::1 from the existing control plane
(N2 interface).
When the packet arrives at UPF1, the SID U1::1 identifies a local
End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to
the next UPF (U2).
When the packet arrives at UPF2, the SID U2::1 corresponds to an
End.DT function. UPF2 decapsulates the packet, performs a lookup in
a specific table associated with that mobile network and forwards the
packet toward the data network (DN).
Matsushima, et al. Expires January 14, 2021 [Page 8]
Internet-Draft SRv6 Mobile User-Plane July 2020
5.1.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF2_in : (Z,A)
UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2
When the packet arrives at the UPF2, the UPF2 maps that flow into a
PDU Session. This PDU Session is associated with the segment
endpoint <U1::2>. UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with no SRH since
there is only one SID.
Upon packet arrival on UPF1, the SID U1::2 is a local End.MAP
function. This function maps the SID to the next anchoring point and
replaces U1::2 by gNB::1, that belongs to the next hop.
Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4,
End.DX6 or End.DX2 behavior (depending on PDU Session Type). The gNB
decapsulates the packet, removing the IPv6 header and all its
extensions headers, and forwards the traffic toward the UE.
5.2. Enhanced Mode
Enhanced mode improves scalability, provides traffic engineering
capabilities and allows service programming
[I-D.ietf-spring-sr-service-programming], thanks to the use of
multiple SIDs in the SID list (instead of a direct connectivity in
between UPFs with no intermediate waypoints as in Traditional Mode).
Thus, the main difference is that the SR policy MAY include SIDs for
traffic engineering and service programming in addition to the
anchoring SIDs at UPFs.
Additionally in this mode the operator may choose to aggregate
several devices under the same SID list (e.g. stationary residential
meters connected to the same cell) to improve scalability.
The gNB control-plane (N2 interface) is unchanged, specifically a
single IPv6 address is provided to the gNB.
The gNB MAY resolve the IP address received via the control plane
into a SID list using a mechanism like PCEP, DNS-lookup, LISP
control-plane or others.
Matsushima, et al. Expires January 14, 2021 [Page 9]
Internet-Draft SRv6 Mobile User-Plane July 2020
Note that the SIDs MAY use the arguments Args.Mob.Session if required
by the UPFs.
Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the
gNB and the UPF are SR-aware. The Figure shows two service segments,
S1 and C1. S1 represents a VNF in the network, and C1 represents an
intermediate router used for Traffic Engineering purposes to enforce
a low-latency path in the network. Note that both S1 and C1 are not
required to have an N4 interface.
+----+ SRv6 _______
SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node
-| S1 |-
+----+
SRv6 node
VNF
Figure 3: Enhanced mode - Example topology
5.2.1. Packet flow - Uplink
The uplink packet flow is as follows:
UE_out : (A,Z)
gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> H.Encaps.Red<S1,C1,U2::1>
S1_out : (gNB, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (gNB, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4, End.DT6, End.DT2U
UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's
control plane associates that session from the UE(A) with the IPv6
address B. gNB's control plane does a lookup on B to find the
related SID list <S1, C1, U2::1>.
When gNB transmits the packet, it contains all the segments of the SR
policy. The SR policy includes segments for traffic engineering (C1)
and for service programming (S1).
Nodes S1 and C1 perform their related Endpoint functionality and
forward the packet.
When the packet arrives at UPF2, the active segment (U2::1) is an
End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing
Matsushima, et al. Expires January 14, 2021 [Page 10]
Internet-Draft SRv6 Mobile User-Plane July 2020
the IPv6 header with all its extension headers) and forwards toward
the data network.
5.2.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow w/
SID list <C1,S1, gNB>
UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> H.Encaps.Red
C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
S1_out : (U2::1, gNB)(Z,A) -> PSP
gNB_out : (Z,A) -> End.DX4/End.DX6/End.DX2
When the packet arrives at the UPF2, the UPF2 maps that particular
flow into a UE PDU Session. This UE PDU Session is associated with
the policy <C1, S1, gNB>. The UPF2 performs a H.Encaps.Red
operation, encapsulating the packet into a new IPv6 header with its
corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the gNB, the IPv6 DA corresponds to an
End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
underlying traffic). The gNB decapsulates the packet, removing the
IPv6 header and forwards the traffic toward the UE.
5.3. Enhanced mode with unchanged gNB GTP behavior
This section describes three mechanisms for interworking with legacy
gNBs that still use GTP: one for IPv4, the other for IPv6.
In the interworking scenarios as illustrated in Figure 4, gNB does
not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6.
To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added.
The SRGW maps the GTP traffic into SRv6.
The SRGW is not an anchor point and maintains very little state. For
this reason, both IPv4 and IPv6 methods scale to millions of UEs.
_______
IP GTP SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node
Figure 4: Example topology for interworking
Matsushima, et al. Expires January 14, 2021 [Page 11]
Internet-Draft SRv6 Mobile User-Plane July 2020
Both of the mechanisms described in this section are applicable to
either the Traditional Mode or the Enhanced Mode.
5.3.1. Interworking with IPv6 GTP
In this interworking mode the gNB at the N3 interface uses GTP over
IPv6.
Key points:
o The gNB is unchanged (control-plane or user-plane) and
encapsulates into GTP (N3 interface is not modified).
o The 5G Control-Plane (N2 interface) is unmodified; one IPv6
address is needed (i.e. a BSID at the SRGW).
o The SRGW removes GTP, finds the SID list related to the IPv6 DA,
and adds SRH with the SID list.
o There is no state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. An SR policy is
shared across UEs.
o When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo].
o In the uplink, the IPv6 DA BSID steers traffic into an SR policy
when it arrives at the SRGW-UPF1.
An example topology is shown in Figure 5.
S1 and C1 are two service segments. S1 represents a VNF in the
network, and C1 represents a router configured for Traffic
Engineering.
+----+
IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6
+------+ TE
SR Gateway
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
5.3.1.1. Packet flow - Uplink
The uplink packet flow is as follows:
Matsushima, et al. Expires January 14, 2021 [Page 12]
Internet-Draft SRv6 Mobile User-Plane July 2020
UE_out : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates
the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the
GTP TEID T are the ones received in the N2 interface.
The IPv6 address that was signaled over the N2 interface for that UE
PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the
SRGW. Hence the packet is routed to the SRGW.
When the packet arrives at the SRGW, the SRGW identifies B as an
End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes
the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own
SRH containing the SIDs bound to the SR policy associated with this
BindingSID. There is one instance of the End.M.GTP6.D SID per PDU
type.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6. UPF2 then decapsulates (removing the outer
IPv6 header with all its extension headers) and forwards the packet
toward the data network.
5.3.1.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB>
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red
C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A)
S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A)
SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation,
Matsushima, et al. Expires January 14, 2021 [Page 13]
Internet-Draft SRv6 Mobile User-Plane July 2020
encapsulating the packet into a new IPv6 header with its
corresponding SRH.
C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active
SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header
and all its extensions headers. The SRGW generates new IPv6, UDP and
GTP headers. The new IPv6 DA is the gNB which is the last SID in the
received SRH. The TEID in the generated GTP header is an argument of
the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet toward the gNB. There is one instance
of the End.M.GTP6.E SID per PDU type.
Once the packet arrives at the gNB, the packet is a regular IPv6/GTP
packet. The gNB looks for the specific radio bearer for that TEID
and forward it on the bearer. This gNB behavior is not modified from
current and previous generations.
5.3.1.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in
the SRH inserted by the UPF2. The UPF2 must have the UE states since
it is the UE's session anchor point.
For the uplink traffic, the state at the SRGW does not necessarily
need to be unique per PDU Session; the SR policy can be shared among
UEs. This enables more scalable SRGW deployments compared to a
solution holding millions of states, one or more per UE.
5.3.2. Interworking with IPv4 GTP
In this interworking mode the gNB uses GTP over IPv4 in the N3
interface
Key points:
o The gNB is unchanged and encapsulates packets into GTP (the N3
interface is not modified).
o In the uplink, traffic is classified by SRGW's Uplink Classifier
and steered into an SR policy. The SRGW is a UPF1 functionality
and can coexist with UPF1's Uplink Classifier functionality.
o SRGW removes GTP, finds the SID list related to DA, and adds a SRH
with the SID list.
An example topology is shown in Figure 6. In this mode the gNB is an
unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before,
the SRGW maps the IPv4/GTP traffic to SRv6.
Matsushima, et al. Expires January 14, 2021 [Page 14]
Internet-Draft SRv6 Mobile User-Plane July 2020
S1 and C1 are two service segment endpoints. S1 represents a VNF in
the network, and C1 represents a router configured for Traffic
Engineering.
+----+
IPv4/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6
+------+ TE
SR Gateway
Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
5.3.2.1. Packet flow - Uplink
The uplink packet flow is as follows:
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
unchanged IPv4/GTP
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1) (A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates
the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and
the GTP TEID are the ones received at the N2 interface.
When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
Classifier rule for incoming traffic from the gNB, that steers the
traffic into an SR policy by using the function H.M.GTP4.D. The SRGW
removes the IPv4, UDP and GTP headers and pushes an IPv6 header with
its own SRH containing the SIDs related to the SR policy associated
with this traffic. The SRGW forwards according to the new IPv6 DA.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6 which performs the decapsulation (removing the
outer IPv6 header with all its extension headers) and forwards toward
the data network.
Matsushima, et al. Expires January 14, 2021 [Page 15]
Internet-Draft SRv6 Mobile User-Plane July 2020
5.3.2.2. Packet flow - Downlink
The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,SRGW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A)
SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a
lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::SA:DA:TEID>. The UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its
corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active
SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header
and all its extensions headers. The SRGW generates an IPv4, UDP and
GTP headers. The IPv4 SA and DA are received as SID arguments. The
TEID in the generated GTP header is also the arguments of the
received End.M.GTP4.E SID. The SRGW pushes the headers to the packet
and forwards the packet toward the gNB.
When the packet arrives at the gNB, the packet is a regular IPv4/GTP
packet. The gNB looks for the specific radio bearer for that TEID
and forward it on the bearer. This gNB behavior is not modified from
current and previous generations.
5.3.2.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in
the SRH inserted by the UPF. The UPF must have this UE-base state
anyway (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per
UE/session basis according to an Uplink Classifier. There is state
for steering the different sessions in the form of a SR Policy.
However, SR policies are shared among several UE/sessions.
Matsushima, et al. Expires January 14, 2021 [Page 16]
Internet-Draft SRv6 Mobile User-Plane July 2020
5.3.3. Extensions to the interworking mechanisms
In this section we presented three mechanisms for interworking with
gNBs and UPFs that do not support SRv6. These mechanisms are used to
support GTP over IPv4 and IPv6.
Even though we have presented these methods as an extension to the
"Enhanced mode", it is straightforward in its applicability to the
"Traditional mode".
Furthermore, although these mechanisms are designed for interworking
with legacy RAN at the N3 interface, these methods could also be
applied for interworking with a non-SRv6 capable UPF at the N9
interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not).
5.4. SRv6 Drop-in Interworking
In this section we introduce another mode useful for legacy gNB and
UPFs that still operate with GTP-U. This mode provides an
SRv6-enabled user plane in between two GTP-U tunnel endpoints.
In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and
vice-versa.
Unlike other interworking modes, in this mode both of the mobility
overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or
N9 interface to realize an intermediate SR policy.
+----+
-| S1 |-
+-----+ / +----+ \
| gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+
+-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF |
GTP[N3]\ +--------+ / +----+ +--------+ +-----+
-| SRGW-A |- SRv6 SR Gateway-B GTP
+--------+ TE
SR Gateway-A
Figure 7: Example topology for SRv6 Drop-in mode
The packet flow of Figure 7 is as follows:
Matsushima, et al. Expires January 14, 2021 [Page 17]
Internet-Draft SRv6 Mobile User-Plane July 2020
gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z)
GW-A_out: (SRGW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z) ->U::1 is an
End.M.GTP6.D.Di
SID at SRGW-A
S1_out : (SRGW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z)
C1_out : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z) ->U1b::TEID is an
End.M.GTP6.E
SID at SRGW-B
UPF_out : (A,Z)
When a packet destined to Z to the gNB, which is unmodified, it
performs encapsulation into a new IP, UDP and GTP headers. The IPv6
DA, U::1, and the GTP TEID are the ones received at the N2 interface.
The IPv6 address that was signaled over the N2 interface for that PDU
Session, U::1, is now the IPv6 DA. U2b:: is an SRv6 Binding SID at
SRGW-A. Hence the packet is routed to the SRGW.
When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an
End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW
removes the IPv6, UDP and GTP headers, and pushes an IPv6 header with
its own SRH containing the SIDs bound to the SR policy associated
with this Binding SID. There is one instance of the End.M.GTP6.D.Di
SID per PDU type.
S1 and C1 perform their related Endpoint functionality and forward
the packet.
Once the packet arrives at SRGW-B, the SRGW identifies the active SID
as an End.M.GTP6.E function. The SRGW removes the IPv6 header and
all its extensions headers. The SRGW generates new IPv6, UDP and GTP
headers. The new IPv6 DA is U::1 which is the last SID in the
received SRH. The TEID in the generated GTP header is an argument of
the received End.M.GTP6.E SID. The SRGW pushes the headers to the
packet and forwards the packet toward UPF2b. There is one instance
of the End.M.GTP6.E SID per PDU type.
Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP
packet. The UPF looks for the specific rule for that TEID to forward
the packet. This UPF behavior is not modified from current and
previous generations.
6. SRv6 Segment Endpoint Mobility Behaviors