draft-ietf-dmm-srv6-mobile-uplane-08.txt   draft-ietf-dmm-srv6-mobile-uplane-09.txt 
DMM Working Group S. Matsushima DMM Working Group S. Matsushima, Ed.
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: December 25, 2020 M. Kohno Expires: January 14, 2021 M. Kohno
P. Camarillo P. Camarillo, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C. Perkins C. Perkins
Futurewei Futurewei
June 23, 2020 July 13, 2020
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-08 draft-ietf-dmm-srv6-mobile-uplane-09
Abstract Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
to the user-plane of mobile networks. The network programming nature to the user-plane of mobile networks. The network programming nature
of SRv6 accomplish mobile user-plane functions in a simple manner. of SRv6 accomplish mobile user-plane functions in a simple manner.
The statelessness of SRv6 and its ability to control both service The statelessness of SRv6 and its ability to control both service
layer path and underlying transport can be beneficial to the mobile layer path and underlying transport can be beneficial to the mobile
user-plane, providing flexibility, end-to-end network slicing and SLA user-plane, providing flexibility, end-to-end network slicing and SLA
control for various applications. This document describes the SRv6 control for various applications. This document describes the SRv6
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Predefined SRv6 Functions . . . . . . . . . . . . . . . . 4 2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. A 3GPP Reference Architecture . . . . . . . . . . . . . . . . 6 4. A 3GPP Reference Architecture . . . . . . . . . . . . . . . . 6
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9
5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14
5.3.3. SRv6 Drop-in Interworking . . . . . . . . . . . . . . 16 5.3.3. Extensions to the interworking mechanisms . . . . . . 17
5.3.4. Extensions to the interworking mechanisms . . . . . . 18 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17
6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 18
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 20 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 20
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 21 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 21
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 22 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 22
6.7. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 23 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 23
6.8. End.Limit: Rate Limiting function . . . . . . . . . . . . 23 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 24
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 24 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 24
8. Network Slicing Considerations . . . . . . . . . . . . . . . 24 8. Network Slicing Considerations . . . . . . . . . . . . . . . 24
9. Control Plane Considerations . . . . . . . . . . . . . . . . 25 9. Control Plane Considerations . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Implementations . . . . . . . . . . . . . . . . . . 28 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
In mobile networks, mobility management systems provide connectivity In mobile networks, mobility management systems provide connectivity
while mobile nodes move. While the control-plane of the system over a wireless link to stationary and non-stationary nodes. The
signals movements of a mobile node, the user-plane establishes a user-plane establishes a tunnel between the mobile node and its
tunnel between the mobile node and its anchor node over IP-based anchor node over IP-based backhaul and core networks.
backhaul and core networks.
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
to those mobile networks. SRv6 provides source routing to networks to mobile networks.
so that operators can explicitly indicate a route for the packets to
and from the mobile node. SRv6 endpoint nodes serve as the anchors Segment Routing [RFC8402] is a source routing architecture: a node
of mobile user-plane. 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 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Terminology 2.1. Terminology
o AMBR: Aggregate Maximum Bit Rate
o Anchor: An topological endpoint of an UE
o APN: Access Point Name (commonly used to identify a network or
class of service)
o BSID: SR Binding SID [RFC8402]
o CNF: Cloud-native Network Function o CNF: Cloud-native Network Function
o gNB: gNodeB
o NH: The IPv6 next-header field.
o NFV: Network Function Virtualization o NFV: Network Function Virtualization
o PDU: Packet Data Unit o PDU: Packet Data Unit
o Session: Context of an UE connects to a mobile network. o PDU Session: Context of an UE connects to a mobile network.
o SID: A Segment Identifier which represents a specific segment in a
segment routing domain.
o SRH: The Segment Routing Header.
[I-D.ietf-6man-segment-routing-header]
o TEID: Tunnel Endpoint Identifier
o UE: User Equipment o UE: User Equipment
o UPF: User Plane Function o UPF: User Plane Function
o VNF: Virtual Network 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
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 2.2. Conventions
o NH=SRH means that NH is 43 with routing type 4. An SR Policy is resolved to a SID list. A SID list is represented as
o Multiple SRHs may be present inside each packet, but they must <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID
follow each other. The next-header field of each SRH, except the to visit and S3 is the last SID to visit along the SR path.
last one, must be NH-SRH (43 type 4).
o For simplicity, no other extension headers are shown except the (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
SRH.
o The SID type used in this document is SRv6 SID. - 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 gNB::1 is an IPv6 address (SID) assigned to the gNB.
o U1::1 is an IPv6 address (SID) assigned to UPF1. o U1::1 is an IPv6 address (SID) assigned to UPF1.
o U2::1 is an IPv6 address (SID) assigned to UPF2. o U2::1 is an IPv6 address (SID) assigned to UPF2.
o U2:: is some other IPv6 address (SID) assigned to UPF2. o U2:: is some other IPv6 address (SID) assigned to UPF2.
o 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.
o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:
* IPv6 header with source and destination addresses SA and DA
respectively, and next-header SRH, with SID list <S1, S2, S3>
with SegmentsLeft = SL
* The payload of the packet is not represented.
o 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. (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 behavior, the (S3, S2, S1; SL) notation is more
convenient.
o SRH[SL] represents the SID pointed by the SL field in the first
SRH. In our example, SRH[2] represents S1, SRH[1] represents S2
and SRH[0] represents S3.
o SRH[SL] can be different from the DA of the IPv6 header.
2.3. Predefined SRv6 Functions 2.3. Predefined SRv6 Endpoint Behaviors
The following functions are defined in The following SRv6 Endpoint Behaviors are defined in
[I-D.ietf-spring-srv6-network-programming]. [I-D.ietf-spring-srv6-network-programming].
o End.DT4 means to decapsulate and forward using a specific IPv4 o End.DT4: decapsulate and forward using a specific IPv4 table
table lookup. lookup.
o End.DT6 means to decapsulate and forward using a specific IPv6 o End.DT6: decapsulate and forward using a specific IPv6 table
table lookup. lookup.
o End.DX4 means to decapsulate the packet and forward through a o End.DX4: decapsulate the packet and forward through a particular
particular outgoing interface -or set of OIFs- configured with the
SID.
o End.DX6 means to decapsulate and forward through a particular
outgoing interface -or set of OIFs- configured with the SID. outgoing interface -or set of OIFs- configured with the SID.
o End.DX2 means to decapsulate the L2 frame and forward through a o End.DX6: decapsulate and forward through a particular outgoing
particular outgoing interface -or set of OIFs- configured with the interface -or set of OIFs- configured with the SID.
SID. o End.DX2: decapsulate the L2 frame and forward through a particular
o End.T means to forward using a specific IPv6 table lookup. outgoing interface -or set of OIFs- configured with the SID.
o End.X means to forward through a link configured with the SID. o End.T: forward through the shortest path using a specific IPv6
o T.Encaps.Red means encapsulation without pushing SRH (resulting in table.
"Reduced" packet size). o End.X: forward through an L3 adjacency with the SID.
o PSP means Penultimate Segment Pop. The packet is subsequently
forwarded without the popped SRH.
New SRv6 functions are defined in Section 6 to support the needs of New SRv6 behaviors are defined in Section 6 of this document to
the mobile user plane. mechanisms described in this document.
3. Motivation 3. Motivation
Mobility networks are becoming more challenging to operate. On one Mobile networks are becoming more challenging to operate. On one
hand, traffic is constantly growing, and latency requirements are hand, traffic is constantly growing, and latency requirements are
more strict; on the other-hand, there are new use-cases like NFV that tighter; on the other-hand, there are new use-cases like distributed
are also challenging network management. NFVi that are also challenging network operations.
The current architecture of mobile networks does not take into The current architecture of mobile networks does not take into
account the underlying transport. The user-plane is rigidly account the underlying transport. The user-plane is rigidly
fragmented into radio access, core and service networks, connected by fragmented into radio access, core and service networks, connected by
tunneling according to user-plane roles such as access and anchor tunneling according to user-plane roles such as access and anchor
nodes. These factors have made it difficult for the operator to nodes. These factors have made it difficult for the operator to
optimize and operate the data-path. optimize and operate the data-path.
In the meantime, applications have shifted to use IPv6, and network In the meantime, applications have shifted to use IPv6, and network
operators have started adopting IPv6 as their IP transport. SRv6, operators have started adopting IPv6 as their IP transport. SRv6,
the IPv6 dataplane instantiation of Segment Routing [RFC8402], the IPv6 dataplane instantiation of Segment Routing [RFC8402],
integrates both the application data-path and the underlying integrates both the application data-path and the underlying
transport layer into a single protocol, allowing operators to transport layer into a single protocol, allowing operators to
optimize the network in a simplified manner and removing forwarding optimize the network in a simplified manner and removing forwarding
state from the network. It is also suitable for virtualized state from the network. It is also suitable for virtualized
environments, VNF/CNF to VNF/CNF networking. environments, like VNF/CNF to VNF/CNF networking.
SRv6 specifies network-programming (see SRv6 defines the network-programming concept
[I-D.ietf-spring-srv6-network-programming]). Applied to mobility, [I-D.ietf-spring-srv6-network-programming]. Applied to mobility,
SRv6 can provide the user-plane functions needed for mobility SRv6 can provide the user-plane behaviors needed for mobility
management. SRv6 takes advantage of underlying transport awareness management. SRv6 takes advantage of the underlying transport
and flexibility to improve mobility user-plane functions. 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 The use-cases for SRv6 mobility are discussed in
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. [I-D.camarilloelmalky-springdmm-srv6-mob-usecases].
4. A 3GPP Reference Architecture 4. A 3GPP Reference Architecture
This section presents a reference architecture and possible This section presents a reference architecture and possible
deployment scenarios. deployment scenarios.
Figure 1 shows a reference diagram from the 5G packet core Figure 1 shows a reference diagram from the 5G packet core
architecture [TS.23501]. architecture [TS.23501].
The user plane described in this document does not depend on any The user plane described in this document does not depend on any
specific architecture. The 5G packet core architecture as shown is specific architecture. The 5G packet core architecture as shown is
based on the latest 3GPP standards at the time of writing this draft. based on the latest 3GPP standards at the time of writing this draft.
Other architectures can be seen in [I-D.gundavelli-dmm-mfa] and
[WHITEPAPER-5G-UP].
+-----+ +-----+
| AMF | | AMF |
+-----+ +-----+
/ | [N11] / | [N11]
[N2] / +-----+ [N2] / +-----+
+------/ | SMF | +------/ | SMF |
/ +-----+ / +-----+
/ / \ / / \
/ / \ [N4] / / \ [N4]
/ / \ ________ / / \ ________
/ / \ / \ / / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
Figure 1: 3GPP 5G Reference Architecture Figure 1: 3GPP 5G Reference Architecture
o gNB: gNodeB o gNB: gNodeB with N3 interface towards packet core (and N2 for
o UPF1: UPF with Interfaces N3 and N9 control plane)
o UPF2: UPF with Interfaces N9 and N6 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 SMF: Session Management Function
o AMF: Access and Mobility Management Function o AMF: Access and Mobility Management Function
o DN: Data Network e.g. operator services, Internet access o DN: Data Network e.g. operator services, Internet access
This reference diagram does not depict a UPF that is only connected This reference diagram does not depict a UPF that is only connected
to N9 interfaces, although the description in this document also work to N9 interfaces, although the description in this document also work
for such UPFs. for such UPFs.
Each session from an UE gets assigned to a UPF. Sometimes multiple Each session from a UE gets assigned to a UPF. Sometimes multiple
UPFs may be used, providing richer service functions. A UE gets its 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 from the DHCP block of its UPF. The UPF advertises that
IP address block toward the Internet, ensuring that return traffic is IP address block toward the Internet, ensuring that return traffic is
routed to the right UPF. routed to the right UPF.
5. User-plane behaviors 5. User-plane behaviors
This section describes some mobile user-plane behaviors using SRv6. This section introduces an SRv6 based mobile user-plane.
In order to simplify the adoption of SRv6, we present two different 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 "modes" that vary with respect to the use of SRv6. The first one is
the "Traditional mode", which inherits the current 3GPP mobile user- the "Traditional mode", which inherits the current 3GPP mobile user-
plane. In this mode there is no change to mobility networks plane. In this mode GTP-U [TS.29281] is replaced by SRv6, however
architecture, except that GTP-U [TS.29281] is replaced by SRv6. 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". In this mode the SR policy The second mode is the "Enhanced mode". This is an evolution from
contains SIDs for Traffic Engineering and VNFs, which results in the "Traditional mode". In this mode the N3, N9 or N6 interfaces
effective end-to-end network slices. 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 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 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6
interfaces are SRv6). interfaces are SRv6).
We introduce two mechanisms for interworking with legacy access In addition to those two modes, we introduce two mechanisms for
networks (N3 interface is unmodified). In this document we introduce interworking with legacy access networks (those where the N3
them applied to the Enhanced mode, although they could be used in interface is unmodified). In this document we introduce them as a
combination with the Traditional mode as well. 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 One of these mechanisms is designed to interwork with legacy gNBs
using GTP/IPv4. The second method is designed to interwork with using GTP/IPv4. The second mechanism is designed to interwork with
legacy gNBs using GTP/IPv6. legacy gNBs using GTP/IPv6.
This document uses SRv6 functions defined in This document uses SRv6 Segment Endpoint Behaviors defined in
[I-D.ietf-spring-srv6-network-programming] as well as new SRv6 [I-D.ietf-spring-srv6-network-programming] as well as new SRv6
functions designed for the mobile user plane. The new SRv6 functions Segment Endpoint Behaviors designed for the mobile user plane that
are detailed in Section 6. are defined in this document Section 6.
5.1. Traditional mode 5.1. Traditional mode
In the traditional mode, the existing mobile UPFs remain unchanged 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 except for the use of SRv6 as the data plane instead of GTP-U. There
is no impact to the rest of mobile system. is no impact to the rest of the mobile system.
In existing 3GPP mobile networks, an UE PDU Session is mapped 1-for-1 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 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored
here to replace GTP encapsulation with the SRv6 encapsulation, while here to replace GTP encapsulation with the SRv6 encapsulation, while
not changing anything else. There will be a unique SRv6 SID not changing anything else. There will be a unique SRv6 SID
associated with each UE PDU Session. associated with each PDU Session.
The traditional mode minimizes the changes required to the mobile The traditional mode minimizes the changes required to the mobile
system; it is a good starting point for forming a common basis. 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 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 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 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 IPv6 address reachable within the Data Network DN. A new SRv6
function End.MAP, defined in Section 6.2, is used. function End.MAP, defined in Section 6.2, is used.
________ ________
SRv6 SRv6 / \ SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
skipping to change at page 8, line 28 skipping to change at page 8, line 31
+--+ +-----+ +------+ +------+ \________/ +--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node SRv6 node
Figure 2: Traditional mode - example topology Figure 2: Traditional mode - example topology
5.1.1. Packet flow - Uplink 5.1.1. Packet flow - Uplink
The uplink packet flow is as follows: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red <U1::1> gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
When the UE packet arrives at the gNB, the gNB performs a When the UE packet arrives at the gNB, the gNB performs a
T.Encaps.Red operation. Since there is only one SID, there is no 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 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 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 at UPF1. gNB obtains the SID U1::1 from the existing control plane
(N2 interface). (N2 interface).
When the packet arrives at UPF1, the SID U1::1 identifies a local 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 End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to
the next UPF (U2). the next UPF (U2).
When the packet arrives at UPF2, the SID U2::1 corresponds to an When the packet arrives at UPF2, the SID U2::1 corresponds to an
End.DT function. UPF2 decapsulates the packet, performs a lookup in End.DT function. UPF2 decapsulates the packet, performs a lookup in
a specific table associated with that mobile network and forwards the a specific table associated with that mobile network and forwards the
packet toward the data network (DN). packet toward the data network (DN).
5.1.2. Packet flow - Downlink 5.1.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) UPF2_in : (Z,A)
UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red <U1::1> UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
gNB_out : (Z,A) -> End.DX4 or End.DX6 gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2
When the packet arrives at the UPF2, the UPF2 maps that flow into a When the packet arrives at the UPF2, the UPF2 maps that flow into a
UE PDU Session. This UE PDU Session is associated with the segment PDU Session. This PDU Session is associated with the segment
endpoint <U1::1>. UPF2 performs a T.Encaps.Red operation, endpoint <U1::2>. UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with no SRH since encapsulating the packet into a new IPv6 header with no SRH since
there is only one SID. there is only one SID.
Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 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 function. This function maps the SID to the next anchoring point and
replaces U1::1 by gNB::1, that belongs to the next hop. 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 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4,
or End.DX6 function. The gNB decapsulates the packet, removing the End.DX6 or End.DX2 behavior (depending on PDU Session Type). The gNB
IPv6 header and all its extensions headers, and forwards the traffic decapsulates the packet, removing the IPv6 header and all its
toward the UE. extensions headers, and forwards the traffic toward the UE.
5.2. Enhanced Mode 5.2. Enhanced Mode
Enhanced mode improves scalability, traffic steering and service Enhanced mode improves scalability, provides traffic engineering
programming [I-D.ietf-spring-sr-service-programming], thanks to the capabilities and allows service programming
use of multiple SIDs, instead of a single SID as done in the [I-D.ietf-spring-sr-service-programming], thanks to the use of
Traditional mode. multiple SIDs in the SID list (instead of a direct connectivity in
between UPFs with no intermediate waypoints as in Traditional Mode).
The main difference is that the SR policy MAY include SIDs for Thus, the main difference is that the SR policy MAY include SIDs for
traffic engineering and service programming in addition to the UPFs traffic engineering and service programming in addition to the
SIDs. 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 The gNB control-plane (N2 interface) is unchanged, specifically a
single IPv6 address is given to the gNB. single IPv6 address is provided to the gNB.
o The gNB MAY resolve the IP address into a SID list using a The gNB MAY resolve the IP address received via the control plane
mechanism like PCEP, DNS-lookup, small augment for LISP control- into a SID list using a mechanism like PCEP, DNS-lookup, LISP
plane, etc. control-plane or others.
Note that the SIDs MAY use the arguments Args.Mob.Session if required Note that the SIDs MAY use the arguments Args.Mob.Session if required
by the UPFs. by the UPFs.
Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 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, 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 a S1 and C1. S1 represents a VNF in the network, and C1 represents an
constraint path on a router requiring Traffic Engineering. S1 and C1 intermediate router used for Traffic Engineering purposes to enforce
belong to the underlay and don't have an N4 interface, so they are a low-latency path in the network. Note that both S1 and C1 are not
not considered UPFs. required to have an N4 interface.
+----+ SRv6 _______ +----+ SRv6 _______
SRv6 --| C1 |--[N3] / \ SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/ +--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node SRv6 node \ +----+ / SRv6 node
-| S1 |- -| S1 |-
+----+ +----+
SRv6 node SRv6 node
CNF VNF
Figure 3: Enhanced mode - Example topology Figure 3: Enhanced mode - Example topology
5.2.1. Packet flow - Uplink 5.2.1. Packet flow - Uplink
The uplink packet flow is as follows: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red<S1,C1,U2::1> 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) S1_out : (gNB, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (gNB, U2::1)(A,Z) -> PSP C1_out : (gNB, U2::1)(A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 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 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 control plane associates that session from the UE(A) with the IPv6
address B and GTP TEID T. gNB's control plane does a lookup on B to address B. gNB's control plane does a lookup on B to find the
find the related SID list <S1, C1, U2::1>. related SID list <S1, C1, U2::1>.
When gNB transmits the packet, it contains all the segments of the SR When gNB transmits the packet, it contains all the segments of the SR
policy. The SR policy can include segments for traffic engineering policy. The SR policy includes segments for traffic engineering (C1)
(C1) and for service programming (S1). and for service programming (S1).
Nodes S1 and C1 perform their related Endpoint functionality and Nodes S1 and C1 perform their related Endpoint functionality and
forward the packet. forward the packet.
When the packet arrives at UPF2, the active segment (U2::1) is an When the packet arrives at UPF2, the active segment (U2::1) is an
End.DT4/6 which performs the decapsulation (removing the IPv6 header End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing
with all its extension headers) and forwards toward the data network. the IPv6 header with all its extension headers) and forwards toward
the data network.
5.2.2. Packet flow - Downlink 5.2.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow w/ UPF2_in : (Z,A) -> UPF2 maps the flow w/
SID list <C1,S1, gNB> SID list <C1,S1, gNB>
UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 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) C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
S1_out : (U2::1, gNB)(Z,A) -> PSP S1_out : (U2::1, gNB)(Z,A) -> PSP
gNB_out : (Z,A) -> End.DX4 or End.DX6 gNB_out : (Z,A) -> End.DX4/End.DX6/End.DX2
When the packet arrives at the UPF2, the UPF2 maps that particular 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 flow into a UE PDU Session. This UE PDU Session is associated with
the policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Red the policy <C1, S1, gNB>. The UPF2 performs a H.Encaps.Red
operation, encapsulating the packet into a new IPv6 header with its operation, encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the gNB, the IPv6 DA corresponds to an Once the packet arrives at the gNB, the IPv6 DA corresponds to an
End.DX4 or End.DX6 (depending on the underlying traffic). The gNB End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
decapsulates the packet, removing the IPv6 header and all its underlying traffic). The gNB decapsulates the packet, removing the
extensions headers and forwards the traffic toward the UE. IPv6 header and forwards the traffic toward the UE.
5.3. Enhanced mode with unchanged gNB GTP behavior 5.3. Enhanced mode with unchanged gNB GTP behavior
This section describes two mechanisms for interworking with legacy This section describes three mechanisms for interworking with legacy
gNBs that still use GTP: one for IPv4, the other for IPv6. gNBs that still use GTP: one for IPv4, the other for IPv6.
In the interworking scenarios as illustrated in Figure 4, gNB does In the interworking scenarios as illustrated in Figure 4, gNB does
not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6. not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6.
To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added.
The SRGW maps the GTP traffic into SRv6. The SRGW maps the GTP traffic into SRv6.
The SRGW is not an anchor point and maintains very little state. For 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. this reason, both IPv4 and IPv6 methods scale to millions of UEs.
_______ _______
IP GTP SRv6 / \ IP GTP SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/ +--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node SR Gateway SRv6 node
Figure 4: Example topology for interworking Figure 4: Example topology for interworking
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 5.3.1. Interworking with IPv6 GTP
In this interworking mode the gNB uses GTP over IPv6 via the N3 In this interworking mode the gNB at the N3 interface uses GTP over
interface IPv6.
Key points: Key points:
o The gNB is unchanged (control-plane or user-plane) and o The gNB is unchanged (control-plane or user-plane) and
encapsulates into GTP (N3 interface is not modified). encapsulates into GTP (N3 interface is not modified).
o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6
address is needed (i.e. a BSID at the SRGW). address is needed (i.e. a BSID at the SRGW).
o The SRGW removes GTP, finds the SID list related to DA, and adds o The SRGW removes GTP, finds the SID list related to the IPv6 DA,
SRH with the SID list. and adds SRH with the SID list.
o There is no state for the downlink at the SRGW. o There is no state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW; using Enhanced o There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. A SR policy can mode results in fewer SR policies on this node. An SR policy is
be shared across UEs. shared across UEs.
o When a packet from the UE leaves the gNB, it is SR-routed. This o When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo]. simplifies network slicing [I-D.ietf-lsr-flex-algo].
o In the uplink, the IPv6 DA BSID steers traffic into an SR policy o In the uplink, the IPv6 DA BSID steers traffic into an SR policy
when it arrives at the SRGW-UPF1. when it arrives at the SRGW-UPF1.
An example topology is shown in Figure 5. In this mode the gNB is an An example topology is shown in Figure 5.
unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before,
the SRGW maps IPv6/GTP traffic to SRv6.
S1 and C1 are two service segments. S1 represents a VNF in the S1 and C1 are two service segments. S1 represents a VNF in the
network, and C1 represents a router configured for Traffic network, and C1 represents a router configured for Traffic
Engineering. Engineering.
+----+ +----+
IPv6/GTP -| S1 |- ___ IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
skipping to change at page 13, line 34 skipping to change at page 13, line 44
is bound to End.DT4/6. UPF2 then decapsulates (removing the outer is bound to End.DT4/6. UPF2 then decapsulates (removing the outer
IPv6 header with all its extension headers) and forwards the packet IPv6 header with all its extension headers) and forwards the packet
toward the data network. toward the data network.
5.3.1.2. Packet flow - Downlink 5.3.1.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps the flow with UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB> <C1, S1, SRGW::TEID,gNB>
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 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) 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) 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 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A) gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs 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, lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::TEID, gNB>. The UPF2 performs a T.Encaps.Red operation, SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
C1 and S1 perform their related Endpoint processing. C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active 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 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 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 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 received SRH. The TEID in the generated GTP header is an argument of
skipping to change at page 14, line 21 skipping to change at page 14, line 30
and forward it on the bearer. This gNB behavior is not modified from and forward it on the bearer. This gNB behavior is not modified from
current and previous generations. current and previous generations.
5.3.1.3. Scalability 5.3.1.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in 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 the SRH inserted by the UPF2. The UPF2 must have the UE states since
it is the UE's session anchor point. it is the UE's session anchor point.
For the uplink traffic, the state at the SRGW does not necessarily For the uplink traffic, the state at the SRGW does not necessarily
need to be unique per UE PDU Session; the state state can be shared need to be unique per PDU Session; the SR policy can be shared among
among UEs. This enables much more scalable SRGW deployments compared UEs. This enables more scalable SRGW deployments compared to a
to a solution holding millions of states, one or more per UE. solution holding millions of states, one or more per UE.
5.3.2. Interworking with IPv4 GTP 5.3.2. Interworking with IPv4 GTP
In this interworking mode the gNB uses GTP over IPv4 in the N3 In this interworking mode the gNB uses GTP over IPv4 in the N3
interface interface
Key points: Key points:
o The gNB is unchanged and encapsulates packets into GTP (the N3 o The gNB is unchanged and encapsulates packets into GTP (the N3
interface is not modified). interface is not modified).
skipping to change at page 15, line 23 skipping to change at page 15, line 27
SR Gateway SR Gateway
Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
5.3.2.1. Packet flow - Uplink 5.3.2.1. Packet flow - Uplink
The uplink packet flow is as follows: The uplink packet flow is as follows:
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
unchanged IPv4/GTP unchanged IPv4/GTP
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.GTP4.D function 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) S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1) (A,Z) -> PSP C1_out : (SRGW, U2::1) (A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates 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 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. 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 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 Classifier rule for incoming traffic from the gNB, that steers the
traffic into an SR policy by using the function T.M.GTP4.D. The SRGW 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 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 its own SRH containing the SIDs related to the SR policy associated
with this traffic. The SRGW forwards according to the new IPv6 DA. with this traffic. The SRGW forwards according to the new IPv6 DA.
S1 and C1 perform their related Endpoint functionality and forward S1 and C1 perform their related Endpoint functionality and forward
the packet. the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which 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 is bound to End.DT4/6 which performs the decapsulation (removing the
outer IPv6 header with all its extension headers) and forwards toward outer IPv6 header with all its extension headers) and forwards toward
the data network. the data network.
5.3.2.2. Packet flow - Downlink 5.3.2.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,SRGW::SA:DA:TEID> <C1, S1,SRGW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 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) C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, SRGW::SA:DA:TEID)(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 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A) gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs 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, lookup in the table associated to A and finds the SID list <C1, S1,
SRGW::SA:DA:TEID>. The UPF2 performs a T.Encaps.Red operation, SRGW::SA:DA:TEID>. The UPF2 performs a H.Encaps.Red operation,
encapsulating the packet into a new IPv6 header with its encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the SRGW, the SRGW identifies the active 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 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 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 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 TEID in the generated GTP header is also the arguments of the
skipping to change at page 16, line 45 skipping to change at page 17, line 5
For the downlink traffic, the SRGW is stateless. All the state is in 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 the SRH inserted by the UPF. The UPF must have this UE-base state
anyway (since it is its anchor point). anyway (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per 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 UE/session basis according to an Uplink Classifier. There is state
for steering the different sessions in the form of a SR Policy. for steering the different sessions in the form of a SR Policy.
However, SR policies are shared among several UE/sessions. However, SR policies are shared among several UE/sessions.
5.3.3. SRv6 Drop-in Interworking 5.3.3. Extensions to the interworking mechanisms
SRv6 drop-in interworking mode provides SRv6 user plane in between In this section we presented three mechanisms for interworking with
GTP-U tunnel endpoints. This mode employs two SRGWs to do GTP-U gNBs and UPFs that do not support SRv6. These mechanisms are used to
traffic to SRv6 mapping on one SRGW, and vice versa. support GTP over IPv4 and IPv6.
Unlike other interworking modes, both of the mobility overlay Even though we have presented these methods as an extension to the
endpoints use GTP-U. Two SRGWs are deployed in either N3 or N9 "Enhanced mode", it is straightforward in its applicability to the
interface to realize an intermediate SR policy. "Traditional mode".
The SRGW behaviors for this mode are equivalent with other modes Furthermore, although these mechanisms are designed for interworking
except in IPv6 GTP case on the GTP-U to SRv6 direction. Due to that with legacy RAN at the N3 interface, these methods could also be
only one exception, it is enough that this section focuses to applied for interworking with a non-SRv6 capable UPF at the N9
describe IPv6 GTP case on one direction with an illustration. 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 |- -| S1 |-
+-----------+ / +----+ \ +-----+ / +----+ \
| UPF2a/gNB |- SRv6 / SRv6 \ +----+ +------+ +-------+ | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+
+-----------+ \ [N9]/ VNF -| C1 |---| UPF1b|------| UPF2b | +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF |
GTP \ +------+ / +----+ +------+ +-------+ GTP[N3]\ +--------+ / +----+ +--------+ +-----+
-| UPF1a|- SRv6 SR Gateway-B GTP -| SRGW-A |- SRv6 SR Gateway-B GTP
+------+ TE +--------+ TE
SR Gateway-A SR Gateway-A
Figure 7: Example topology for SRv6 Drop-in
5.3.3.1. Packet flow Figure 7: Example topology for SRv6 Drop-in mode
The packet flow of Figure 7 is as follows: The packet flow of Figure 7 is as follows:
UPF2a/gNB_out: (UPF2a/gNB, U2b::)(GTP: TEID T)(A,Z) gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z)
SRGW-A_out : (SRGW-A, S1)(U2b::, U1b::TEID, C1; SL=3)(A,Z) -> U2b:: is an GW-A_out: (SRGW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z) ->U::1 is an
End.M.GTP6.D.Di End.M.GTP6.D.Di
SID at SRGW-A SID at SRGW-A
S1_out : (SRGW-A, C1)(U2b::, U1b::TEID, C1; SL=2)(A,Z) S1_out : (SRGW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z)
C1_out : (SRGW-A, U1b::TEID)(U2b::, U1b::TEID, C1; SL=1)(A,Z) C1_out : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
SRGW-B_out : (SRGW-B, U2b::)(GTP: TEID T)(A,Z) -> U1b::TEID is an GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z) ->U1b::TEID is an
End.M.GTP6.E End.M.GTP6.E
SID at SRGW-B SID at SRGW-B
UPF2b_out : (A,Z) UPF_out : (A,Z)
When a packet destined to Z arrives at the UPF2a, or gNB, which is When a packet destined to Z to the gNB, which is unmodified, it
unmodified, performs encapsulates the packet into a new IPv6, UDP and performs encapsulation into a new IP, UDP and GTP headers. The IPv6
GTP headers. The IPv6 DA, U2b::, and the GTP TEID are the ones DA, U::1, and the GTP TEID are the ones received at the N2 interface.
received at the N2 interface.
The IPv6 address that was signalled over the N2 interface for that UE The IPv6 address that was signaled over the N2 interface for that PDU
PDU Session, U2b::, is now the IPv6 DA. U2b:: is an SRv6 Binding SID Session, U::1, is now the IPv6 DA. U2b:: is an SRv6 Binding SID at
at SRGW-A. Hence the packet is routed to the SRGW. SRGW-A. Hence the packet is routed to the SRGW.
When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an 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 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 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 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 with this Binding SID. There is one instance of the End.M.GTP6.D.Di
SID per PDU type. SID per PDU type.
S1 and C1 perform their related Endpoint functionality and forward S1 and C1 perform their related Endpoint functionality and forward
the packet. the packet.
Once the packet arrives at SRGW-B, the SRGW identifies the active SID 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 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 all its extensions headers. The SRGW generates new IPv6, UDP and GTP
headers. The new IPv6 DA is U2b:: which is the last SID in the 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 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 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 packet and forwards the packet toward UPF2b. There is one instance
of the End.M.GTP6.E SID per PDU type. of the End.M.GTP6.E SID per PDU type.
Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP 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 packet. The UPF looks for the specific rule for that TEID to forward
the packet. This UPF behavior is not modified from current and the packet. This UPF behavior is not modified from current and
previous generations. previous generations.
5.3.4. Extensions to the interworking mechanisms 6. SRv6 Segment Endpoint Mobility Behaviors
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).
6. SRv6 SID Mobility Functions
6.1. Args.Mob.Session 6.1. Args.Mob.Session
Args.Mob.Session provide per-session information for charging, Args.Mob.Session provide per-session information for charging,
buffering and lawful intercept (among others) required by some mobile buffering and lawful intercept (among others) required by some mobile
nodes. The Args.Mob.Session argument format is used in combination nodes. The Args.Mob.Session argument format is used in combination
with End.Map, End.DT and End.DX functions. Note that proposed format with End.Map, End.DT and End.DX behaviors. Note that proposed format
is applicable for 5G networks, while similar formats could be is applicable for 5G networks, while similar formats could be
proposed for legacy networks. proposed for legacy networks.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QFI |R|U| PDU Session ID | | QFI |R|U| PDU Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDU Sess(cont')| |PDU Sess(cont')|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Args.Mob.Session format Args.Mob.Session format
o QFI: QoS Flow Identifier [TS.38415] o QFI: QoS Flow Identifier [TS.38415]
o R: Reflective QoS Indication [TS.23501]. This parameter indicates o R: Reflective QoS Indication [TS.23501]. This parameter indicates
the activaton of reflective QoS towards the UE for the transfered the activation of reflective QoS towards the UE for the
packet. Reflective QoS enables the UE to map UL User Plane transferred packet. Reflective QoS enables the UE to map UL User
traffic to QoS Flows without SMF provided QoS rules. Plane traffic to QoS Flows without SMF provided QoS rules.
o U: Unused and for future use. MUST be 0 on transmission and o U: Unused and for future use. MUST be 0 on transmission and
ignored on receipt. ignored on receipt.
o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent
is TEID. is TEID.
Arg.Mob.Session is required in case that one SID aggregates multiple Arg.Mob.Session is required in case that one SID aggregates multiple
PDU Session. Since the SRv6 function is likely NOT to be PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated
instantiated per PDU session, Args.Mob.Session helps the UPF to per PDU session, Args.Mob.Session helps the UPF to perform the
perform the functions which require per QFI and/or per PDU Session behaviors which require per QFI and/or per PDU Session granularity.
granularity.
6.2. End.MAP 6.2. End.MAP
The "Endpoint function with SID mapping" function (End.MAP for short) The "Endpoint behavior with SID mapping" behavior (End.MAP for short)
is used in several scenarios. Particularly in mobility, End.MAP is is used in several scenarios. Particularly in mobility, End.MAP is
used in the UPFs for the PDU Session anchor functionality. used in the UPFs for the PDU Session anchor functionality.
When a SR node N receives a packet destined to S and S is a local When a SR node N receives a packet destined to S and S is a local
End.MAP SID, N does the following: End.MAP SID, N does the following:
1. Lookup the IPv6 DA in the mapping table 1. Lookup the IPv6 DA in the mapping table
2. update the IPv6 DA with the new mapped SID ;; Ref1 2. update the IPv6 DA with the new mapped SID ;; Ref1
3. IF segment_list > 1 3. IF segment_list > 1
4. insert a new SRH 4. insert a new SRH
skipping to change at page 19, line 47 skipping to change at page 20, line 4
used in the UPFs for the PDU Session anchor functionality. used in the UPFs for the PDU Session anchor functionality.
When a SR node N receives a packet destined to S and S is a local When a SR node N receives a packet destined to S and S is a local
End.MAP SID, N does the following: End.MAP SID, N does the following:
1. Lookup the IPv6 DA in the mapping table 1. Lookup the IPv6 DA in the mapping table
2. update the IPv6 DA with the new mapped SID ;; Ref1 2. update the IPv6 DA with the new mapped SID ;; Ref1
3. IF segment_list > 1 3. IF segment_list > 1
4. insert a new SRH 4. insert a new SRH
5. forward according to the new mapped SID 5. forward according to the new mapped SID
Ref1: The SIDs in the SRH are NOT modified. Ref1: The SIDs in the SRH are NOT modified.
6.3. End.M.GTP6.D 6.3. End.M.GTP6.D
The "Endpoint function with IPv6/GTP decapsulation into SR policy" The "Endpoint behavior with IPv6/GTP decapsulation into SR policy"
function (End.M.GTP6.D for short) is used in interworking scenario behavior (End.M.GTP6.D for short) is used in interworking scenario
for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, for the uplink toward from the legacy gNB using IPv6/GTP. Suppose,
for example, this SID is associated with an SR policy <S1, S2, S3> for example, this SID is associated with an SR policy <S1, S2, S3>
and an IPv6 Source Address A. and an IPv6 Source Address A.
When the SR Gateway node N receives a packet destined to S and S is a When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D SID, N does: local End.M.GTP6.D SID, N does:
1. IF NH=UDP & UDP_DST_PORT = GTP THEN 1. IF NH=UDP & UDP_DST_PORT = GTP THEN
2. copy TEID to form SID S3 2. copy TEID to form SID S3
3. pop the IPv6, UDP and GTP headers 3. pop the IPv6, UDP and GTP headers
skipping to change at page 20, line 32 skipping to change at page 20, line 33
7. set the outer IPv6 NH ;; Ref1 7. set the outer IPv6 NH ;; Ref1
8. forward according to the S1 segment of the SRv6 Policy 8. forward according to the S1 segment of the SRv6 Policy
9. ELSE 9. ELSE
10. Drop the packet 10. Drop the packet
Ref1: The NH is set based on the SID parameter. There is one Ref1: The NH is set based on the SID parameter. There is one
instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
NH is already known in advance. For the IPv4v6 PDU Session Type, in NH is already known in advance. For the IPv4v6 PDU Session Type, in
addition we inspect the first nibble of the PDU to know the NH value. addition we inspect the first nibble of the PDU to know the NH value.
The prefix of last segment(S3 in above example) SHOULD be followed by The prefix of last segment (S3 in above example) SHOULD be followed
an Arg.Mob.Session argument space which is used to provide the by an Arg.Mob.Session argument space which is used to provide the
session identifiers. session identifiers.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway. gateway.
6.4. End.M.GTP6.D.Di 6.4. End.M.GTP6.D.Di
The "Endpoint function with IPv6/GTP decapsulation into SR policy for The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for
Drop-in Mode" function (End.M.GTP6.D.Di for short) is used in SRv6 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6
drop-in interworking scenario described in Section 5.3.3. The drop-in interworking scenario described in Section 5.4. The
difference between End.M.GTP6.D as another variant of IPv6/GTP difference between End.M.GTP6.D as another variant of IPv6/GTP
decapsulation function is that the original IPv6 DA of GTP packet is decapsulation function is that the original IPv6 DA of GTP packet is
preserved as the last SID in SRH. Suppose, for example, this SID is preserved as the last SID in SRH. Suppose, for example, this SID is
associated with an SR policy <S1, S2, S3> and an IPv6 Source Address associated with an SR policy <S1, S2, S3> and an IPv6 Source Address
A. A.
When the SR Gateway node N receives a packet destined to S and S is a When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP6.D.Di SID, N does: local End.M.GTP6.D.Di SID, N does:
1. IF NH=UDP & UDP_DST_PORT = GTP THEN 1. IF NH=UDP & UDP_DST_PORT = GTP THEN
skipping to change at page 21, line 31 skipping to change at page 21, line 34
The prefix of last segment(S3 in above example) SHOULD be followed by The prefix of last segment(S3 in above example) SHOULD be followed by
an Arg.Mob.Session argument space which is used to provide the an Arg.Mob.Session argument space which is used to provide the
session identifiers. session identifiers.
The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
gateway. gateway.
6.5. End.M.GTP6.E 6.5. End.M.GTP6.E
The "Endpoint function with encapsulation for IPv6/GTP tunnel" The "Endpoint behavior with encapsulation for IPv6/GTP tunnel"
function (End.M.GTP6.E for short) is used in interworking scenario behavior (End.M.GTP6.E for short) is used in interworking scenario
for the downlink toward the legacy gNB using IPv6/GTP. for the downlink toward the legacy gNB using IPv6/GTP.
The prefix of End.M.GTP6.E SID MUST be followed by the The prefix of End.M.GTP6.E SID MUST be followed by the
Arg.Mob.Session argument space which is used to provide the session Arg.Mob.Session argument space which is used to provide the session
identifiers. identifiers.
When the SR Gateway node N receives a packet destined to S, and S is When the SR Gateway node N receives a packet destined to S, and S is
a local End.M.GTP6.E SID, N does the following: a local End.M.GTP6.E SID, N does the following:
1. IF NH=SRH & SL = 1 THEN ;; Ref1 1. IF NH=SRH & SL = 1 THEN ;; Ref1
skipping to change at page 22, line 4 skipping to change at page 22, line 16
2. store SRH[0] in variable new_DA 2. store SRH[0] in variable new_DA
3. store TEID in variable new_TEID from IPv6 DA ;; Ref2 3. store TEID in variable new_TEID from IPv6 DA ;; Ref2
4. pop IP header and all its extension headers 4. pop IP header and all its extension headers
5. push new IPv6 header and GTP-U header 5. push new IPv6 header and GTP-U header
6. set IPv6 DA to new_DA 6. set IPv6 DA to new_DA
7. set IPv6 SA to A 7. set IPv6 SA to A
8. set GTP_TEID to new_TEID 8. set GTP_TEID to new_TEID
9. lookup the new_DA and forward the packet accordingly 9. lookup the new_DA and forward the packet accordingly
10. ELSE 10. ELSE
11. Drop the packet 11. Drop the packet
Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID. Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID.
Ref2: TEID is extracted from the argument space of the current SID. Ref2: TEID is extracted from the argument space of the current SID.
The source address A SHOULD be an End.M.GTP6.D SID instantiated at an The source address A SHOULD be an End.M.GTP6.D SID instantiated at an
SR gateway. SR gateway.
6.6. End.M.GTP4.E 6.6. End.M.GTP4.E
The "Endpoint function with encapsulation for IPv4/GTP tunnel" The "Endpoint behavior with encapsulation for IPv4/GTP tunnel"
function (End.M.GTP4.E for short) is used in the downlink when doing behavior (End.M.GTP4.E for short) is used in the downlink when doing
interworking with legacy gNB using IPv4/GTP. interworking with legacy gNB using IPv4/GTP.
When the SR Gateway node N receives a packet destined to S and S is a When the SR Gateway node N receives a packet destined to S and S is a
local End.M.GTP4.E SID, N does: local End.M.GTP4.E SID, N does:
1. IF (NH=SRH and SL = 0) or ENH=4 THEN 1. IF (NH=SRH and SL = 0) or ENH=4 THEN
2. store IPv6 DA in buffer S 2. store IPv6 DA in buffer S
3. store IPv6 SA in buffer S' 3. store IPv6 SA in buffer S'
4. pop the IPv6 header and its extension headers 4. pop the IPv6 header and its extension headers
5. push UDP/GTP headers with GTP TEID from S 5. push UDP/GTP headers with GTP TEID from S
skipping to change at page 23, line 5 skipping to change at page 23, line 15
S' has the following format: S' has the following format:
0 127 0 127
+----------------------+--------+--------------------------+ +----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+ +----------------------+--------+--------------------------+
128-a-b a b 128-a-b a b
IPv6 SA Encoding for End.M.GTP4.E IPv6 SA Encoding for End.M.GTP4.E
6.7. T.M.GTP4.D 6.7. H.M.GTP4.D
The "Transit with tunnel decapsulation and map to an SRv6 policy" The "SR Policy Headend with tunnel decapsulation and map to an SRv6
function (T.M.GTP4.D for short) is used in the direction from legacy policy" behavior (H.M.GTP4.D for short) is used in the direction from
IPv4 user-plane to SRv6 user-plane network. legacy IPv4 user-plane to SRv6 user-plane network.
When the SR Gateway node N receives a packet destined to a IW- When the SR Gateway node N receives a packet destined to a IW-
IPv4-Prefix, N does: IPv4-Prefix, N does:
1. IF Payload == UDP/GTP THEN 1. IF Payload == UDP/GTP THEN
2. pop the outer IPv4 header and UDP/GTP headers 2. pop the outer IPv4 header and UDP/GTP headers
3. copy IPv4 DA, TEID to form SID B 3. copy IPv4 DA, TEID to form SID B
4. copy IPv4 SA to form IPv6 SA B' 4. copy IPv4 SA to form IPv6 SA B'
5. encapsulate the packet into a new IPv6 header ;;Ref1 5. encapsulate the packet into a new IPv6 header ;;Ref1
6. set the IPv6 DA = B 6. set the IPv6 DA = B
skipping to change at page 23, line 35 skipping to change at page 23, line 45
the inner payload. the inner payload.
The SID B has the following format: The SID B has the following format:
0 127 0 127
+-----------------------+-------+----------------+---------+ +-----------------------+-------+----------------+---------+
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+ +-----------------------+-------+----------------+---------+
128-a-b-c a b c 128-a-b-c a b c
T.M.GTP4.D SID Encoding H.M.GTP4.D SID Encoding
The SID B MAY be an SRv6 Binding SID instantiated at the first UPF The SID B MAY be an SRv6 Binding SID instantiated at the first UPF
(U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy]. (U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy].
The prefix of B' SHOULD be an End.M.GTP4.E SID with its format The prefix of B' SHOULD be an End.M.GTP4.E SID with its format
instantiated at an SR gateway with the IPv4 SA of the receiving instantiated at an SR gateway with the IPv4 SA of the receiving
packet. packet.
6.8. End.Limit: Rate Limiting function 6.8. End.Limit: Rate Limiting behavior
The mobile user-plane requires a rate-limit feature. For this The mobile user-plane requires a rate-limit feature. For this
purpose, we define a new function "End.Limit". The "End.Limit" purpose, we define a new behavior "End.Limit". The "End.Limit"
function encodes in its arguments the rate limiting parameter that behavior encodes in its arguments the rate limiting parameter that
should be applied to this packet. Multiple flows of packets should should be applied to this packet. Multiple flows of packets should
have the same group identifier in the SID when those flows are in an have the same group identifier in the SID when those flows are in an
same AMBR group. The encoding format of the rate limit segment SID same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of
is as follows: the rate limit segment SID is as follows:
+----------------------+----------+-----------+ +----------------------+----------+-----------+
| LOC+FUNC rate-limit | group-id | limit-rate| | LOC+FUNC rate-limit | group-id | limit-rate|
+----------------------+----------+-----------+ +----------------------+----------+-----------+
128-i-j i j 128-i-j i j
End.Limit: Rate limiting function argument format End.Limit: Rate limiting behavior argument format
If the limit-rate bits are set to zero, the node should not do rate If the limit-rate bits are set to zero, the node should not do rate
limiting unless static configuration or control-plane sets the limit limiting unless static configuration or control-plane sets the limit
rate associated to the SID. rate associated to the SID.
7. SRv6 supported 3GPP PDU session types 7. SRv6 supported 3GPP PDU session types
The 3GPP [TS.23501] defines the following PDU session types: The 3GPP [TS.23501] defines the following PDU session types:
o IPv4 o IPv4
o IPv6 o IPv6
o IPv4v6 o IPv4v6
o Ethernet o Ethernet
o Unstructured o Unstructured
SRv6 supports the 3GPP PDU session types without any protocol SRv6 supports the 3GPP PDU session types without any protocol
overhead by using the corresponding SRv6 functions (End.DX4, End.DT4 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4
for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions). End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU
Unstructured PDUs are not supported. sessions).
8. Network Slicing Considerations 8. Network Slicing Considerations
A mobile network may be required to implement "network slices", which A mobile network may be required to implement "network slices", which
logically separate network resources. User-plane functions logically separate network resources. User-plane behaviors
represented as SRv6 segments would be part of a slice. represented as SRv6 segments would be part of a slice.
[I-D.ietf-spring-segment-routing-policy] describes a solution to [I-D.ietf-spring-segment-routing-policy] describes a solution to
build basic network slices with SR. Depending on the requirements, build basic network slices with SR. Depending on the requirements,
these slices can be further refined by adopting the mechanisms from: these slices can be further refined by adopting the mechanisms from:
o IGP Flex-Algo [I-D.ietf-lsr-flex-algo] o IGP Flex-Algo [I-D.ietf-lsr-flex-algo]
o Inter-Domain policies o Inter-Domain policies
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
skipping to change at page 25, line 19 skipping to change at page 25, line 31
9. Control Plane Considerations 9. Control Plane Considerations
This document focuses on user-plane behavior and its independence This document focuses on user-plane behavior and its independence
from the control plane. from the control plane.
The control plane could be the current 3GPP-defined control plane The control plane could be the current 3GPP-defined control plane
with slight modifications to the N4 interface [TS.29244]. with slight modifications to the N4 interface [TS.29244].
Alternatively, SRv6 could be used in conjunction with a new mobility Alternatively, SRv6 could be used in conjunction with a new mobility
control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6],
hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in
[I-D.gundavelli-dmm-mfa] or in conjunction with FPC conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new
[I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes mobility control-planes and its applicability to an SRv6 user-plane
and its applicability to SRv6 is out of the scope of this document. is out of the scope of this document.
Section 11 allocates SRv6 endpoint function types for the new
functions defined in this document. Control-plane protocols are
expected to use these function type codes to signal each function.
SRv6's network programming nature allows a flexible and dynamic UPF Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for
placement. the new behaviors defined in this document.
10. Security Considerations 10. Security Considerations
TBD The security considerations for Segment Routing are discussed in
[RFC8402]. More specifically for SRv6 the security considerations
and the mechanisms for securing an SR domain are discussed in
[RFC8754]. Together, they describe the required security mechanisms
that allow establishment of an SR domain of trust to operate
SRv6-based services for internal traffic while preventing any
external traffic from accessing or exploiting the SRv6-based
services.
The technology described in this document is applied to a mobile
network that is within the SR Domain.
This document introduces new SRv6 Endpoint Behaviors. Those
behaviors do not need any especial security consideration given that
it is deployed within that SR Domain.
11. IANA Considerations 11. IANA Considerations
IANA is requested to allocate, within the "SRv6 Endpoint Types" sub- IANA is requested to allocate, within the "SRv6 Endpoint Behaviors"
registry belonging to the top-level "Segment-routing with IPv6 sub-registry belonging to the top-level "Segment Routing Parameters"
dataplane (SRv6) Parameters" registry registry [I-D.ietf-spring-srv6-network-programming], the following
[I-D.ietf-spring-srv6-network-programming], the following values: values:
+-------------+-----+-------------------+-----------+ +-------+-----+-------------------+-----------+
| Value/Range | Hex | Endpoint function | Reference | | Value | Hex | Endpoint behavior | Reference |
+-------------+-----+-------------------+-----------+ +-------+-----+-------------------+-----------+
| TBA | TBA | End.MAP | [This.ID] | | TBA | TBA | End.MAP | [This.ID] |
| TBA | TBA | End.M.GTP6.D | [This.ID] | | TBA | TBA | End.M.GTP6.D | [This.ID] |
| TBA | TBA | End.M.GTP6.E | [This.ID] | | TBA | TBA | End.M.GTP6.Di | [This.ID] |
| TBA | TBA | End.M.GTP4.E | [This.ID] | | TBA | TBA | End.M.GTP6.E | [This.ID] |
| TBA | TBA | End.Limit | [This.ID] | | TBA | TBA | End.M.GTP4.E | [This.ID] |
+-------------+-----+-------------------+-----------+ | TBA | TBA | End.Limit | [This.ID] |
+-------+-----+-------------------+-----------+
Table 1: SRv6 Mobile User-plane Endpoint Types Table 1: SRv6 Mobile User-plane Endpoint Behavior Types
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Daisuke Yokota, Bart Peirens, The authors would like to thank Daisuke Yokota, Bart Peirens,
Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
Shekhar and Aeneas Dodd-Noble for their useful comments of this work. Shekhar, Aeneas Dodd-Noble and Carlos Jesus Bernardos for their
useful comments of this work.
13. Contributors 13. Contributors
Kentaro Ebisawa Kentaro Ebisawa
Toyota Motor Corporation Toyota Motor Corporation
Japan Japan
Email: ebisawa@toyota-tokyo.tech Email: ebisawa@toyota-tokyo.tech
Tetsuya Murakami
Arrcus, Inc.
United States of America
Email: tetsuya.ietf@gmail.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-07 (work in progress), ietf-spring-segment-routing-policy-07 (work in progress),
May 2020. May 2020.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-15 (work in draft-ietf-spring-srv6-network-programming-16 (work in
progress), March 2020. progress), June 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[TS.23501]
3GPP, "System Architecture for the 5G System", 3GPP TS
23.501 15.0.0, November 2017.
14.2. Informative References 14.2. Informative References
[I-D.ali-spring-network-slicing-building-blocks] [I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer,
"Building blocks for Slicing in Segment Routing Network", "Building blocks for Slicing in Segment Routing Network",
draft-ali-spring-network-slicing-building-blocks-02 (work draft-ali-spring-network-slicing-building-blocks-02 (work
in progress), November 2019. in progress), November 2019.
[I-D.auge-dmm-hicn-mobility-deployment-options] [I-D.auge-dmm-hicn-mobility-deployment-options]
Auge, J., Carofiglio, G., Muscariello, L., and M. Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn- (hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-03 (work in progress), January mobility-deployment-options-04 (work in progress), July
2020. 2020.
[I-D.camarillo-dmm-srv6-mobile-pocs]
Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A.,
Matsushima, S., and d. daniel.voyer@bell.ca, "Segment
Routing IPv6 for mobile user-plane PoCs", draft-camarillo-
dmm-srv6-mobile-pocs-02 (work in progress), April 2019.
[I-D.camarilloelmalky-springdmm-srv6-mob-usecases] [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S.,
Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use-
Cases", draft-camarilloelmalky-springdmm-srv6-mob- Cases", draft-camarilloelmalky-springdmm-srv6-mob-
usecases-02 (work in progress), August 2019. usecases-02 (work in progress), August 2019.
[I-D.gundavelli-dmm-mfa]
Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01
(work in progress), September 2018.
[I-D.ietf-dmm-fpc-cpdp] [I-D.ietf-dmm-fpc-cpdp]
Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13
(work in progress), March 2020. (work in progress), March 2020.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-07 (work in progress), April 2020. algo-08 (work in progress), July 2020.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central- Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017. epe-10 (work in progress), December 2017.
[I-D.ietf-spring-sr-service-programming] [I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-ietf-spring-sr-service- Segment Routing", draft-ietf-spring-sr-service-
programming-02 (work in progress), March 2020. programming-02 (work in progress), March 2020.
[I-D.rodrigueznatal-lisp-srv6] [I-D.rodrigueznatal-lisp-srv6]
Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
Camarillo, P., and C. Filsfils, "LISP Control Plane for Camarillo, P., and C. Filsfils, "LISP Control Plane for
SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-03 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-03
(work in progress), January 2020. (work in progress), January 2020.
[TS.23501]
3GPP, "System Architecture for the 5G System", 3GPP TS
23.501 15.0.0, November 2017.
[TS.29244] [TS.29244]
3GPP, "Interface between the Control Plane and the User 3GPP, "Interface between the Control Plane and the User
Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017.
[TS.29281] [TS.29281]
3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
December 2017. December 2017.
[TS.38415] [TS.38415]
3GPP, "Draft Specification for 5GS container (TS 38.415)", 3GPP, "Draft Specification for 5GS container (TS 38.415)",
3GPP R3-174510 0.0.0, August 2017. 3GPP R3-174510 0.0.0, August 2017.
Appendix A. Implementations Appendix A. Implementations
This document introduces new SRv6 functions. These functions have an This document introduces new SRv6 Endpoint Behaviors. These
open-source P4 implementation available in behaviors have an open-source P4 implementation available in
<https://github.com/ebiken/p4srv6>. <https://github.com/ebiken/p4srv6>.
There are also implementations in M-CORD NGIC and Open Air Interface Additionally, a full implementation of this document is available in
(OAI). Further details can be found in Linux Foundation FD.io VPP project since release 20.05. More
[I-D.camarillo-dmm-srv6-mobile-pocs]. information available here: <https://docs.fd.io/vpp/20.05/d7/d3c/
srv6_mobile_plugin_doc.html>.
There are also experimental implementations in M-CORD NGIC and Open
Air Interface (OAI).
Authors' Addresses Authors' Addresses
Satoru Matsushima Satoru Matsushima (editor)
SoftBank SoftBank
Tokyo Tokyo
Japan Japan
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
Email: cf@cisco.com Email: cf@cisco.com
Miya Kohno Miya Kohno
Cisco Systems, Inc. Cisco Systems, Inc.
Japan Japan
skipping to change at page 29, line 15 skipping to change at page 30, line 4
Cisco Systems, Inc. Cisco Systems, Inc.
Belgium Belgium
Email: cf@cisco.com Email: cf@cisco.com
Miya Kohno Miya Kohno
Cisco Systems, Inc. Cisco Systems, Inc.
Japan Japan
Email: mkohno@cisco.com Email: mkohno@cisco.com
Pablo Camarillo Garvia (editor)
Pablo Camarillo Garvia
Cisco Systems, Inc. Cisco Systems, Inc.
Spain Spain
Email: pcamaril@cisco.com Email: pcamaril@cisco.com
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
 End of changes. 132 change blocks. 
347 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/