< draft-clt-dmm-tn-aware-mobility-04.txt   draft-clt-dmm-tn-aware-mobility-05.txt >
DMM Working Group U. Chunduri, Ed. DMM Working Group U. Chunduri, Ed.
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Informational Futurewei Intended status: Informational Futurewei
Expires: January 9, 2020 S. Bhaskaran Expires: May 7, 2020 S. Bhaskaran
Altiostar Altiostar
J. Kaippallimalil
Futurewei
J. Tantsura J. Tantsura
Apstra, Inc. Apstra, Inc.
L. Contreras L. Contreras
Telefonica Telefonica
P. Muley P. Muley
Nokia Nokia
J. Kaippallimalil November 4, 2019
Futurewei
July 8, 2019
Transport Network aware Mobility for 5G Transport Network aware Mobility for 5G
draft-clt-dmm-tn-aware-mobility-04 draft-clt-dmm-tn-aware-mobility-05
Abstract Abstract
This document specifies a framework and a mapping function for 5G This document specifies a framework and a mapping function for 5G
mobile user plane with transport network slicing, integrated with mobile user plane with transport network slicing, integrated with
Mobile Radio Access and a Virtualized Core Network. The integrated Mobile Radio Access and a Virtualized Core Network. The integrated
approach is specified in a way to fit into the 5G core network approach is specified in a way to fit into the 5G core network
architecture defined in [TS23.501]. architecture defined in [TS23.501].
It focuses on an optimized mobile user plane functionality with It focuses on an optimized mobile user plane functionality with
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4
1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 5 2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 6
2.1. Integrated Approach with TNF in SBI . . . . . . . . . . . 6 2.1. XHaul Transport Network . . . . . . . . . . . . . . . . . 7
2.1.1. Transport Network Function and Interfaces . . . . . . 7 2.2. Mobile Transport Network Context (MTNC) and Scalability . 8
2.1.2. Functionality for E2E Management . . . . . . . . . . 7 2.3. Transport Network Function (TNF) . . . . . . . . . . . . 9
2.2. TNF as part of existing 5G Control Function . . . . . . . 9 2.4. TNF Interfaces . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Mobile Transport Network Context and Scalability . . 11 2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 10
2.2.2. MTNC Identifier in the Data Packet . . . . . . . . . 12 2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 11
3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 12 2.7. Functionality for E2E Management . . . . . . . . . . . . 12
3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 13 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 13
3.2. Path Steering Support to native IP user planes . . . . . 15 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 14
3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 15 3.2. Path Steering Support to native IP user planes . . . . . 16
4. Other TE Technologies Applicability . . . . . . . . . . . . . 15 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 4. Other TE Technologies Applicability . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix A. New Control Plane and User Planes . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 17
A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 19 Appendix A. New Control Plane and User Planes . . . . . . . . . 20
Appendix B. PPR with various 5G Mobility procedures . . . . . . 20 A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 20
B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. PPR with various 5G Mobility procedures . . . . . . 21
B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 21 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 22
B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 22 B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP],
[TS.23.502-3GPP] and [TS.23.503-3GPP]. User Plane Functions (UPF) [TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a
are the data forwarding entities in the 5GC architecture. The comprehensive set of functions for access mobility, session handling
architecture allows the placement of Branching Point (BP) and Uplink and related functions for subscription management, authentication and
Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G- policy among others. These network functions (NF) are defined using
AN can be a radio access network or any non-3GPP access network, for a service-based architecture (SBA) that allows NFs to expose their
example, WLAN. The IP address is anchored by a PDU session anchor functions via an API and common service framework. The architecture
UPF (PSA UPF). also defines slicing aspects where the Network Slice Selection
Function (NSSF) assists the Access Mobility Manager (AMF) and Session
N3, N9 Interfaces: The interface between the BP/ULCL UPF and the PSA Management Function (SMF) to assist and select the right entities and
UPF is called N9 [TS.23.501-3GPP]. While in REL15, 3GPP has adopted resources corresponding to the slice requested by the user equipment
GTP-U for the N9 interface, new user plane protocols along with GTP-U (UE). The User Equipment (UE) indicates slice information in the
are being investigated for N9 interface in REL16, as part of Network Slice Selection Assistance Information (NSSAI) field during
[CT4SID]. Concerning to this document another relevant interface is session establishment (Attach). The AMF selects the right SMF and
N3, which is between the 5G-AN and the UPF. N3 interface is similar the SMF in turn selects the User Plane Functions (UPF) so that the
to the user plane interface S1U in LTE [TS.23.401-3GPP]. This QoS and capabilities requested can be fulfilled. UPFs are the data
document: forwarding entities in the 5GC architecture. The architecture allows
the placement of Branching Point (BP) and Uplink Classifier (ULCL)
o Do not need architectural change to[TS.23.501-3GPP] to provide UPFs closer to the access network (5G-AN). The 5G-AN can be a radio
3GPP slice, QoS support in transport plane access network or any non-3GPP access network, for example, WLAN.
The IP address is anchored by a PDU session anchor UPF (PSA UPF).
o and can work with any encapsulation (including GTP-U) for the N9 5GS allows more than one UPF on the path for a PDU (Protocol Data
interface. Unit) session that provides various functionality including session
anchoring, uplink classification and branching point for a multihomed
IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA
UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9
and N3 interface between the various UPF instances and the (R)AN.
3GPP has specified control and user plane aspects in [TS.23.501-3GPP]
to provide slice and QoS support. 3GPP has defined three broad slice
types to cover enhanced mobile broadband (eMBB) communications,
ultra-reliable low latency communications(URLLC) and massive internet
of things (mIoT). ATIS [ATIS075] has defined an additional slice
type for V2X services. There may be multiple instances of a slice
type to satisfy some characteristics like isolation. The slice
details in 3GPP, ATIS or NGMN do not specify how slice
characteristics for QoS, hard /soft isolation, protection and other
aspects should be satisfied in IP transport networks. This is
explored further in this document.
1.1. Problem Statement 1.1. Problem Statement
[TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one
of the core capability of 5GC with slice awareness from Radio and 5G of the core capability of 5GC with slice awareness from Radio and 5G
Core (5GC) network. The 5G System (5GS) as defined, do not consider Core (5GC) network. The 5G System (5GS) as defined, does not
the resources and functionalities needed from transport network for consider the resources and functionalities needed from transport
the selection of UPF. This is seen as independent functionality and network for the selection of UPF. This is seen as independent
currently not part of 5GS. functionality and currently not part of 5GS.
However, the lack of underlying Transport Network (TN) awareness may However, the lack of underlying Transport Network (TN) awareness may
lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS
procedures. This could also lead to inability to meet SLAs for real- various procedures (e.g., session establishment, mobility). Meeting
time, mission-critical or latency sensitive services. 5GS procedures the specific slice characteristics on the N3 and N9 interfaces
including but not limited to Service Request, PDU Session depends on the IP transport underlay providing these resources and
Establishment, or User Equipment (UE) mobility need same service capabilities. This could also lead to the inability in meeting SLAs
level characteristics from the TN for the Protocols Data Unit (PDU) for real-time, mission-critical or latency sensitive services. 5GS
session, similar to as provided in Radio and 5GC for the various procedures including but not limited to Service Request, PDU Session
Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP]. Establishment, or UE mobility need same service level characteristics
from the TN for the Protocols Data Unit (PDU) session, similar to as
provided in Radio and 5GC for the various Slice Service Types (SST)
and 5QI's defined in [TS.23.501-3GPP].
The 5GS provides slices to its clients (UEs). The UE's PDU session
spans the access network (radio) and N3 and N9 transport segments
which have an IP transport underlay. The 5G operator needs to obtain
slice capability from the IP transport provider. Several UE sessions
that match a slice may be mapped to an IP transport segment. Thus
there needs to be a mapping between the slice capability offered to
the UE (NSSAI) and what is provided by the IP transport.
1.2. Solution Approach 1.2. Solution Approach
This document specifies 2 approaches to fulfil the needs of 5GS to This document specifies an approach to fulfil the needs of 5GS to
transport user plane traffic from 5G-AN to UPF for all service transport user plane traffic from 5G-AN to UPF for all service
continuity modes [TS.23.501-3GPP] in an optimized fashion. This is continuity modes [TS.23.501-3GPP] in an optimized fashion. This is
done by, keeping mobility procedures aware of underlying transport done by, keeping mobility procedures aware of underlying transport
network along with slicing requirements. network along with slicing requirements.
Section 2 describes in detail on how TN aware mobility can be built Section 2 describes in detail on how TN aware mobility can be built
irrespective of underlying TN technology used. Using Preferred Path irrespective of underlying TN technology used. Using Preferred Path
Routing (PPR), applicable to any transport network underlay (IPv6, Routing (PPR), applicable to any transport network underlay (IPv6,
MPLS and IPv4) is detailed in Section 3. How other IETF TE MPLS and IPv4) is detailed in Section 3. How other IETF TE
technologies applicable for this draft is specified in Section 4. At technologies applicable for this draft is specified in Section 4. At
skipping to change at page 4, line 49 skipping to change at page 5, line 29
DN - Data Network (5G) DN - Data Network (5G)
eMBB - enhanced Mobile Broadband (5G) eMBB - enhanced Mobile Broadband (5G)
FRR - Fast ReRoute FRR - Fast ReRoute
gNB - 5G NodeB gNB - 5G NodeB
GBR - Guaranteed Bit Rate (5G) GBR - Guaranteed Bit Rate (5G)
GTP-U - GPRS Tunneling Protocol - Userplane (3GPP)
IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)
LFA - Loop Free Alternatives (IP FRR) LFA - Loop Free Alternatives (IP FRR)
mIOT - Massive IOT (5G) mIOT - Massive IOT (5G)
MPLS - Multi Protocol Label Switching MPLS - Multi Protocol Label Switching
QFI - QoS Flow ID (5G) QFI - QoS Flow ID (5G)
PPR - Preferred Path Routing PPR - Preferred Path Routing
PDU - Protocol Data Unit (5G) PDU - Protocol Data Unit (5G)
skipping to change at page 5, line 21 skipping to change at page 6, line 4
PDU - Protocol Data Unit (5G) PDU - Protocol Data Unit (5G)
PW - Pseudo Wire PW - Pseudo Wire
RQI - Reflective QoS Indicator (5G) RQI - Reflective QoS Indicator (5G)
SBI - Service Based Interface (5G) SBI - Service Based Interface (5G)
SID - Segment Identifier SID - Segment Identifier
SMF - Session Management Function (5G) SMF - Session Management Function (5G)
SSC - Session and Service Continuity (5G) SSC - Session and Service Continuity (5G)
SST - Slice and Service Types (5G) SST - Slice and Service Types (5G)
SR - Segment Routing SR - Segment Routing
TE - Traffic Engineering TE - Traffic Engineering
ULCL - Uplink Classifier (5G) ULCL - Uplink Classifier (5G)
UPF - User Plane Function (5G) UPF - User Plane Function (5G)
URLLC - Ultra reliable and low latency communications (5G) URLLC - Ultra reliable and low latency communications (5G)
2. Transport Network and Slice aware Mobility on N3/N9 2. Transport Network and Slice aware Mobility on N3/N9
Currently specified Control Plane (CP) functions - the Access and Currently specified Control Plane (CP) functions - the AMF, the SMF
Mobility Management Function (AMF), the Session Management Function and the User plane (UP) components 5G-AN (e.g. gNB), UPF with N2, N3,
(SMF) and the User plane (UP) components gNB, User Plane Function N4, N6 and N9 interfaces are relevant to this document. Other
(UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to this Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM,
document. Other Virtualized 5G control plane components NRF, AUSF, NEF, and AF are not directly relevant for the discussion in this
PCF, AUSF, UDM, NEF, and AF are not directly relevant for the document and one can see the functionalities of these in
discussion in this document and one can see the functionalities of [TS.23.501-3GPP].
these in [TS.23.501-3GPP].
From encapsulation perspective, N3 interface is similar to S1U in 4G/ From encapsulation perspective, N3 interface is similar to S1U in 4G/
LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to
transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
Unlike S1U, N3 has some additional aspects as there is no bearer Unlike S1U, N3 has some additional aspects as there is no bearer
concept and no per bearer GTP-U tunnels. Instead, QoS information is concept and no per bearer GTP-U tunnels. Instead, QoS information is
carried in the PDU Session Container GTP-U extension header. carried in the PDU Session Container GTP-U extension header.
+------+ +-----+ +-------+ +-----+
| NSSF | | NRF | | NWDAF | | PCF |
+---+--+ +--+--+ +---+---+ +--+--+
| | | |
--+-----+--------+--+-----------+-----+-----+-----
| | Service Based Interfaces (SBI)
| +-----+--------+ |
+--+--+ | +-----+ NSSMF| +--+--+
+-----+ AMF | | | TNF | | | SMF |
| +--+--+ | +--+--+ | +--+--+
| +---+----------+ |
| |ACTN |
| +---+--+ |
N2 | +--------|SDN-C |-------+ |
| | +--+---+ | +----------+
| |Ns _______ Nn| | N4 |
| | ___/ \______|_______|__________|___
| | / | | | \
+------+ +--+---+ IP +-++ +--+---+ +--+----+ +--+
|(R)AN |====|CSR/PE| Backhaul |PE|+++|UP-NF2|+++|PE+UPF2|---|DN|
+------+ +------+ +--+ +------+ +-------+ +--+
\___ _____________________________/
Front/ \ / N3 N9 N6
Midhaul +-----+
Figure 1: 5G Service Based Architecture with Transport Network
TN Aware Mobility with optimized transport network functionality is TN Aware Mobility with optimized transport network functionality is
explained below with approaches specified in Section 2.1 and explained below. How PPR fits in this framework in detail along with
Section 2.2 . How PPR fits in this framework in detail along with
other various TE technologies briefly are in Section 3 and Section 4 other various TE technologies briefly are in Section 3 and Section 4
respectively. respectively.
2.1. Integrated Approach with TNF in SBI 2.1. XHaul Transport Network
Service Based Interfaces (SBI) Figure 1 depicts IP Xhaul network with SDN-C and CSR/PE (Provider
----+-----+-----+----+----+-----+----+--------+-----+----+------ Edge) routers provide IP transport service to 5GS user plane entities
| | | | | | | | | | 5G-AN (e.g. gNB) and UPF. 5GS architecture with key control and user
+---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ plane entities and its interaction with the IP transport plane is
| NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | shown here. When a UE initiates session establishment, it indicates
+-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ the desired slice type in the S-NSSAI (Specific Network Slice
+---+----+ +--+--+ +----++ +--------------+-+ Selection Assistance Information) field. The AMF uses the S-NSSAI,
| AMF | | PCF | | TNF | | SMF | other subscription information and configuration in the NSSF to
+---+--+-+ +-----+ +-+-+-+ +-+-----------+--+ select the appropriate SMF and the SMF in turn selects UPFs (User
N1 | | | | To | Plane Functions) that are able to provide the specified slice
to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4 resources and capabilities. Some of the slice capabilities along the
| | | | | | user plane path between the (R)AM and UPFs (N3, N9 segments) such as
+---+---+ +--++ +-+--+---+ +-+-----+ +----+ a low latency path, jitter, protection and priority needs these to be
|gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN | provided by the IP transport network.
+---+ +---+ +-+------+ +-------+ +----+
| +----+
+-| DN |
N6 +----+
Figure 1: 5G Service Based Architecture Interface between (R)AN/5G-AN and CSR includes fronthaul and midhaul
part of the transport network. In some cases midhaul can also a
layer-2 network. In deployments where virtualized 5G-AN is used, F1U
interface with GTP encapsulation is considered between the
Distributed Unit (DU) and Centralized Unit (CU).
The above diagrams depicts one of the scenarios of the 5G network Slice capability required in IP transport networks is estimated and
specified in [TS.23.501-3GPP] and with a new and virtualized control provisioned by the functionality as specified in Section 2.3 (TNF)
component Transport Network Function (TNF). A Cell Site Router (CSR) with support from various other functions such as the Network Data
is shown connecting to gNB. gNB is an entity in 5G-AN. Though it is Analytics Function (NWDAF), Network Resource Function (NRF) and
shown as a separate block from gNB, in some cases both of these can Policy Control Function (PCF). Figure 1 depicts the PE router, where
be co-located. This document concerns with backhaul TN, from CSR to transport paths are initiated/terminated can be deployed seperately
UPF on N3 interface or from Staging UPF to Anchor UPF on N9 with UPF or both functionalities can be in the same node. The TNF
interface. provisions this in the SDN-C of the IP XHaul network using ACTN
[RFC8453]. When a GTP encapsulated user packet from the (R)AN or UPF
with the slice information traverses the F1U/N3/N9 segment, the PE
router of the IP transport underlay can inspect the slice information
and provide the provisioned capabilities. This is elaborated further
in Section 2.5.
Network Slice Selection Function (NSSF) as defined in 2.2. Mobile Transport Network Context (MTNC) and Scalability
[TS.23.501-3GPP] concerns with multiple aspects including selecting a
network slice instance when requested by AMF based on the requested
SNSSAI, current location of UE, roaming indication etc. It also
notifies NF service consumers (e.g AMF) whenever the status about the
slice availability changes. However, the scope is only in 5GC (both
control and user plane) and NG Radio Access network including the
N3IWF for the non-3GPP access. The network slice instance(s)
selected by the NSSF are applicable at a per PDU session granularity.
An SMF and UPF are allocated from the selected slice instance during
the PDU session establishment procedure.
2.1.1. Transport Network Function and Interfaces The MTNC represents a slice, QoS configuration for a transport path
between two 3GPP user plane functions. The Mobile-Transport Network
Context Identifier (MTNC-ID) is generated by the TNF to be unique for
each path and per traffic class (including QoS and slice aspects).
Thus, there may be more than one MTNC-ID for the same QoS and path if
there is a need to provide isolation (slice) of the traffic. It
should be noted that MTNC are per class/path and not per user session
(nor is it per data path entity). The MTNC-IDs are configured by the
TNF to be unique within a provisioning domain.
To assuage the above situation, TNF is described (Figure 1) as part Since the MTNC-IDs are not generated per user flow or session, there
of control plane. This has the view of the underlying transport is no need for unique MTNC-IDs per flow/session. In addition, since
network with all links and nodes as well as various possible underlay the traffic estimation not performed at the time of session
paths with different characteristics. TNF can be seen as supporting establishment, there is no provisioning delay experienced during
PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get session setup. The MTNC-ID space scales as a square of the number
the TE and topology information of the underlying IGP network. sites between which 3GPP user plane functions require paths. If
there are T traffic classes across N sites, the number of MTNC-IDs in
a fully meshed network is (N*(N-1)/2) * T. For example, if there are
3 traffic classes between 25 sites, there would be at most 900 MTNC-
IDs required. Multiple slices for the same QoS class that need to be
fully isolated, will add to the MTNC provisioning. An MTNC-ID space
of 16 bits (65K+ identifiers) can be expected to be sufficient.
2.3. Transport Network Function (TNF)
Figure 1 shows a view of the functions and interfaces for
provisioning the MTNC-IDs. The focus is on provisioning between the
3GPP management plane (NSSMF), transport network (SDN-C) and carrying
the MTNC-IDs in PDU packets for the transport network to grant the
provisioned resources.
In Figure 1, the TNF (logical functionality within the NSSMF)
requests the SDN-C in the transport domain to program the TE path
using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE)
routers and internal routers according to the underlay transport
technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming
PDU data packets for the MTNC-ID, classifies and provides the VN
service provisioned across the transport network.
The detailed mechanisms by which the NSSMF provides the MTNC-IDs to
the control plane and user plane functions are for 3GPP to specify.
Two possible options are outlined below for completeness. The NSSMF
may provide the MTNC-IDs to the 3GPP control plane by either
providing it to the Session Management Function (SMF), and the SMF in
turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU
session setup. Alternatively, the user plane functions may request
the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case
where user plane entities request the TNF/NSSMF to translate the
Request and get the MTNC-ID (over interface Ns/Nn).
The TNF should be seen as a logical entity that can be part of NSSMF
in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use
network configuration, policies, history, heuristics or some
combination of these to derive traffic estimates that the TNF would
use. How these estimates are derived are not in the scope of this
document. The focus here is only in terms of how the TNF and SDN-C
are programmed given that slice and QoS characteristics across a
transport path can be represented by an MTNC-ID. The TNF requests
the SDN-C in the transport network to provision paths in the
transport domain based on the MTNC-ID. The TNF is capable of
providing the MTNC-ID provisioned to control and user plane functions
in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID
should be part of the 3GPP specifications.
2.4. TNF Interfaces
A south bound interface Ns is shown which interacts with the 5G A south bound interface Ns is shown which interacts with the 5G
Access Network (e.g. gNB/CSR). 'Ns' can use one or more mechanism Access Network (e.g. CSR). 'Ns' can use one or more mechanism
available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF
[RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay
paths from gNB to UPF. Ns and Nn interfaces can be part of the paths from CSR to PE@UPF. Ns and Nn interfaces can be part of the
integrated 3GPP architecture, but the specification/ownership of integrated 3GPP architecture, but the specification/ownership of
these interfaces SHOULD be left out of scope of 3GPP. these interfaces SHOULD be left out of scope of 3GPP.
A north bound interface 'Nn' is shown from one or more of the A north bound interface 'Nn' is shown from one or more of the
transport network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as transport network nodes (or PE @ ULCL/BP UPF, Anchor Point UPF) to
shown in Figure 1. It would enable learning the TE characteristics TNF as shown in Figure 1. It would enable learning the TE
of all links and nodes of the network continuously (through BGP-LS characteristics of all links and nodes of the network continuously
[RFC7752] or through a passive IGP adjacency and PCEP [RFC5440]). (through BGP-LS [RFC7752] or through a passive IGP adjacency and PCEP
[RFC5440]).
These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs
and UPFs concerned to allow mobility of UEs while associated with one and UPFs concerned to allow mobility of UEs while associated with one
of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP].
Proposed TNF as part of the 5GC shown in Figure 1 can be realized 2.5. Transport Provisioning
using Abstraction and Control of TE Networks (ACTN). ACTN
architecture, underlying topology abstraction methods and
manageability considerations of the same are detailed in [RFC8453].
2.1.2. Functionality for E2E Management Functionality of transport provisioning for an engineered IP
transport that supports 3GPP slicing and QoS requirements in
[TS.23.501-3GPP] is described in this section.
With the TNF in 5GS Service Based Interface, the following additional During a PDU session setup, the AMF using input from the NSSF selects
functionalities are required for end-2-end slice management including a network slice and SMF. The SMF with user policy from Policy
the transport network: Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the
path of the PDU session. While QoS and slice selection for the PDU
session can be applied across the 3GPP control and user plane
functions as outlined in Section 2, the IP transport underlay across
N3 and N9 segments do not have enough information to apply the
resource constraints represented by the slicing and QoS
classification. Current guidelines for interconnection with
transport networks [IR.34-GSMA] provide an application mapping into
DSCP. However, these recommendations do not take into consideration
other aspects in slicing like isolation, protection and replication.
IP transport networks have their own slice and QoS configuration
based on domain policies and the underlying network capability.
Transport networks can enter into an agreement for virtual network
services (VNS) with client domains using the ACTN [RFC8453]
framework. An IP transport network may provide such slice instances
to mobile network operators, CDN providers or enterprises for
example. The 3GPP mobile network, on the other hand, defines a slice
instance for UEs as are the the mobile operator's 'clients'. The
Network Slice Selection Management Function (NSSMF) [TS 28.533] that
interacts with a TN controller like an SDN-C (that is out of scope of
3GPP).
The ACTN VN service can be used across the IP transport networks to
provision and map the slice instance and QoS of the 3GPP domain to
the IP transport domain. An abstraction that represents QoS and
slice instance in the mobile domain and mapped to ACTN VN service in
the transport domain is represented here as MTNC-IDs. Details of how
the MTNC-IDs are derived are upto functions that can estimate the
level of traffic demand.
The 3GPP network/5GS provides slices instances to its clients (UE)
that include resources for radio and mobile core segments. The UE's
PDU session spans the access network (radio) and N3 and N9 transport
segments which have an IP transport underlay. The 5G operator needs
to obtain slice capability from the IP transport provider since these
resources are not seen by the 5GS. Several UE sessions that match a
slice may be mapped to an IP transport segment. Thus, there needs to
be a mapping between the slice capability offered to the UE (NSSAI)
and what is provided by the IP transport.
When the 3GPP user plane function (5G-AN, UPF) does not terminate the
transport underlay protocol (e.g., MPLS), it needs to be carried in
the IP protocol header from end-to-end of the mobile transport
connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses
these scenarios in detail.
2.6. MTNC-ID in the Data Packet
When the 3GPP user plane function (5G-AN, UPF) and transport provider
edge is on different nodes, the PE router needs to have the means by
which to classify the PDU packet. The mapping information is
provisioned between the 5G provider and IP transport network and
corresponding information should be carried in each IP packet on the
N3, N9 interface. To allow the IP transport edge nodes to inspect
the transport context information efficiently, it should be carried
in an IP header field that is easy to inspect. It may be noted that
the N3 and N9 interfaces in 5GS are IP interfaces. Thus, Layer 2
alternatives such as VLAN will fail if there are multiple L2 networks
on the N3 or N9 path. Another alternative is to use L3 VPNs.
However, in the 5G architecture, there may be a large number of
smaller UPFs that are dynamically inserted on path. Adding this VPN
information for dynamic UPF insertion is configuration intensive and
error prone. GTP (N3, N9 encapsulation header) field extensions
offer a possibility, however these extensions are hard for a
transport edge router to parse efficiently on a per packet basis.
Other IP header fields like DSCP are not suitable as it only conveys
the QoS aspects (but not other aspects like isolation, protection,
etc.)
IPv6 extension headers like FaST, or SRv6 may be options to carry the
MTNC-ID when such mechanism is a viable (if complete transport
network is IPv6 based). To mininise the protocol changes are
required and make this underlay tranport independed (IPv4/IPv6/MPLS/
L2), an option is to provision a mapping of MTNC-ID to a UDP port
range of the GTP encapsulated user packet. A simple mapping table
between the MTNC-ID and the source UDP port number can be configured
to ensure that ECMP /load balancing is not affected adversely by
encoding the UDP source port with an MTNC-ID mapping. This mapping
is configured in 3GPP user plane functions (5G-AN, UPF) and Provider
Edge (PE) Routers that process MTNC-IDs. PE routers can thus
provision a policy based on the source UDP port number (which
reflects the mapped MTNC-ID) to underlying transport path and then
deliver the QoS/slice resource provisioned in the transport network.
The source UDP port that is encoded is the outer IP (corresponding to
GTP header) while the inner IP packet (UE payload) is unaltered.
2.7. Functionality for E2E Management
With the TNF finctionality in 5GS Service Based Interface, the
following additional functionalities are required for end-2-end slice
management including the transport network:
o The Specific Network Slice Selection Assistance Information o The Specific Network Slice Selection Assistance Information
(SNSSAI) of PDU session's SHOULD be mapped to the assigned (S-NSSAI) of PDU session SHOULD be mapped to the assigned
transport VPN and the TE path information for that slice. transport VPN and the TE path information for that slice.
o For transport slice assignment for various SSTs (eMBB, URLLC, o For transport slice assignment for various SSTs (eMBB, URLLC,
MIoT) corresponding underlay paths need to be created and MIoT) corresponding underlay paths need to be created and
monitored from each transport end point (gNB/CSR and UPF). monitored from each transport end point (CSR and PE@UPF).
o During PDU session creation, apart from radio and 5GC resources, o During PDU session creation, apart from radio and 5GC resources,
transport network resources needed to be verified matching the transport network resources needed to be verified matching the
characteristics of the PDU session traffic type. characteristics of the PDU session traffic type.
o The TNF MUST provide an API that takes as input the source and o The TNF MUST provide an API that takes as input the source and
destination 3GPP user plane element address, required bandwidth, destination 3GPP user plane element address, required bandwidth,
latency and jitter characteristics between those user plane latency and jitter characteristics between those user plane
elements and returns as output a particular TE path's identifier, elements and returns as output a particular TE path's identifier,
that satisfies the requested requirements. that satisfies the requested requirements.
o Mapping of PDU session parameters to underlay SST paths need to be o Mapping of PDU session parameters to underlay SST paths need to be
done. One way to do this to let the SMF install a Forwarding done. One way to do this to let the SMF install a Forwarding
Action Rule (FAR) in the UPF via N4 with the FAR pointing to a Action Rule (FAR) in the UPF via N4 with the FAR pointing to a
"Network Instance" in the UPF. A "Network Instance" is a logical "Network Instance" in the UPF. A "Network Instance" is a logical
identifier for an underlying network. The "Network Instance" identifier for an underlying network. The "Network Instance"
pointed by the FAR can be mapped to a transport path (through L2/ pointed by the FAR can be mapped to a transport path (through L2/
L3 VPN). FARs are associated with Packet Detection Rule (PDR). L3 VPN). FARs are associated with Packet Detection Rule (PDR).
PDRs are used to classify packets in the uplink (UL) and the PDRs are used to classify packets in the uplink (UL) and the
downlink (DL) direction. For UL GTP-U TEID and/or the QFI marked downlink (DL) direction. For UL procedures specified in
in the GTPU packet can be used for classifying a packet belonging Section 2.5, Section 2.6 can be used for classifying a packet
to a particular slice characteristics. For DL, at a PSA UPF, the belonging to a particular slice characteristics. For DL, at a PSA
UE IP address is used to identify the PDU session, and hence the UPF, the UE IP address is used to identify the PDU session, and
slice a packet belongs to and the IP 5 tuple can be used for hence the slice a packet belongs to and the IP 5 tuple can be used
identifying the flow and QoS characteristics to be applied on the for identifying the flow and QoS characteristics to be applied on
packet. the packet at UPF. If a PE is not co-located at the UPF then
mapping to the underlying TE paths at PE happens based on the
encapsulated GTP-US packet as specified in Section 2.6.
o If any other form of encapsulation (other than GTP-U) either on N3 o If any other form of encapsulation (other than GTP-U) either on N3
or N9 corresponding QFI information MUST be there in the or N9 corresponding QFI information MUST be there in the
encapsulation header. encapsulation header.
o In some SSC modes Appendix B, if segmented path (gNB to o In some SSC modes Appendix B, if segmented path (CSR to
staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then
corresponding path characteristics MUST be used. This includes a corresponding path characteristics MUST be used. This includes a
path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF
UPF to eventual UPF access to DN. to eventual UPF access to DN.
o Continuous monitoring of transport path characteristics and o Continuous monitoring of the underlying transport path
reassignment at the endpoints MUST be performed. For all the characteristics should be enabled at the endpoints (technologies
affected PDU sessions, degraded transport paths need to be updated for monitoring depends traffic engineering technique used as
dynamically with similar alternate paths. described in Section 3 and Section 4). If path characteristics
are degraded, reassignment of the paths at the endpoints should be
performed. For all the affected PDU sessions, degraded transport
paths need to be updated dynamically with similar alternate paths.
o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn
based or N2 based), for target gNB selection, apart from radio based or N2 based), for target gNB selection, apart from radio
resources, transport resources MUST be factored. This enables resources, transport resources MUST be factored. This enables
handling of all PDU sessions from the UE to target gNB and this handling of all PDU sessions from the UE to target gNB and this
require co-ordination of gNB, AMF, SMF with the TNF module. require co-ordination of gNB, AMF, SMF with the TNF module.
Integrating the TNF as part of the 5GS Service Based Interfaces, Integrating the TNF as part of the 5GS Service Based Interfaces,
provides the flexibility to control the allocation of required provides the flexibility to control the allocation of required
characteristics from the TN during a 5GS signaling procedure (e.g. characteristics from the TN during a 5GS signaling procedure (e.g.
PDU Session Establishment). If TNF is seen as part of management PDU Session Establishment). If TNF is seen as part of management
plane, this real time flexibility is lost. Changes to detailed plane, this real time flexibility is lost. Changes to detailed
signaling to integrate the above for various 5GS procedures as signaling to integrate the above for various 5GS procedures as
defined in [TS.23.502-3GPP] is beyond the scope of this document. defined in [TS.23.502-3GPP] is beyond the scope of this document.
2.2. TNF as part of existing 5G Control Function
Another solution approach with TNF in Section 2.1 and transport
provisioning for an engineered IP transport that supports 3GPP
slicing and QoS requirements in [TS.23.501-3GPP] is described in this
section.
During a PDU session setup, the 3GPP AMF using input from the NSSF
selects a network slice and SMF. The SMF with user policy from
Policy Control Function (PCF) sets 5QI (QoS parameters) and the UPF
on the path of the PDU session. While QoS and slice selection for
the PDU session can be applied across the 3GPP control and user plane
functions as outlined above, the transport underlay across N3 and N9
segments do not have enough information to apply the resource
constraints represented by the slicing and QoS classification.
Current guidelines for interconnection with transport networks
[IR.34-GSMA] provide an application mapping into DSCP. However,
apart from problems with classification of encrypted packets, these
recommendations do not take into consideration other aspects in
slicing like isolation, protection and replication.
Transport networks have their own slice and QoS configuration based
on domain policies and the underlying network capability. Transport
networks can enter into an agreement for virtual network services
(VNS) with client domains using the ACTN [RFC8453] framework. The
3GPP mobile network, on the other side, defines a Network Slice
Selection Management Function (NSSMF) [TS 28.533] that interacts with
a TN domain manager (that is out of scope of 3GPP).
The ACTN VN service can be used across the 3GPP and transport
networks to provision and map between slices, QoS in the two domains.
An abstraction that represents QoS and slice information in the
mobile domain and mapped to ACTN VN service in the transport domain
is represented here as MTNC (Mobile Transport Network Context)
identifiers. Details of how the 3GPP domain derives the MTNC
identifiers and how it programs it across its control and user plane
functions are for 3GPP standards to define. For completeness, some
minimal outlines are provided in the description below.
When the 3GPP user plane function (gNB, UPF) does not terminate the
transport underlay protocol (e.g., MPLS), it needs to be carried in
the IP protocol header from end-to-end of the mobile transport
connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses
these scenarios in detail.
Figure 2 shows a view of the functions and interfaces for
provisioning the MTNC identifiers. The focus is on provisioning
between the 3GPP management plane (NSSMF), transport network (SDN-C)
and carrying the MTNC identifiers in PDU packets for the transport
network to grant the provisioned resources.
+----------------------------------------------------+
| 3GPP Control/Management Plane |
| +----------------------------------------|-------+
| | +---------------+ | |
| | | +-----+ NSSMF | +---+---+ |
| | | | TNF | | | SMF | |
| | | +--+--+ | +---+---+ |
| | +----|----------+ | |
| +------|---------------------------------|-------+
| |ACTN (RFC8453) |
| +---+---+ |
| | SDN-C +---+ |
| +---+---+ | |
| 3GPP N2/N4 ___^___ |3GPP N2/N4
| _____/ \_____ |
| / \ |
+---+--+ +--+ IP +--+ +---+--+
|UP-NF1|+++++++++++|PE| Backhaul |PE|+++++++++|UP-NF2|
+------+ +--+ +--+ +------+
\_____ _____/
\ /
---v---
Figure 2: 5G Transport Plane Provisioning
In Figure 2, the TNF (logical functionality within the NSSMF)
requests the SDN-C in the transport domain to program the TE path
using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE)
routers and internal routers according to the underlay transport
technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming
PDU data packets for the MTNC identifier, classifies and provides the
VN service provisioned across the transport network.
The detailed mechanisms by which the NSSMF provides the MTNC
identifiers to the control plane and user plane functions are for
3GPP to specify. Two possible options are outlined below for
completeness. The NSSMF may provide the MTNC identifiers to the 3GPP
control plane by either providing it to the Session Management
Function (SMF), and the SMF in turn provisions the user plane
functions (UP-NF1, UP-NF2) during PDU session setup. Alternatively,
the user plane functions may request the MTNC identifiers directly
from the NSSMF.
In this approach, TNF can be seen as a logical entity that can be
part of NSSMF in the 3GPP management plane [TS.28.533-3GPP]. The
NSSMF may use network configuration, policies, history, heuristics or
some combination of these to derive traffic estimates that the TNF
would use. How these estimates are derived are not in the scope of
this document. The focus here is only in terms of how the TNF and
SDN-C are programmed given that slice and QoS characteristics across
a transport path can be represented by an MTNC identifier. The TNF
requests the SDN-C in the transport network to provision paths in the
transport domain based on the MTNC identifier. The TNF is capable of
providing the MTNC identifier provisioned to control and user plane
functions in the 3GPP domain. Detailed mechanisms for programming
the MTNC identifier should be part of the 3GPP specifications.
2.2.1. Mobile Transport Network Context and Scalability
The MTNC (Mobile Transport Network Context) represents a slice, QoS
configuration for a transport path between two 3GPP user plane
functions. The Mobile-Transport Network Context Identifier (MTNC-ID)
is generated by the TNF to be unique for each path and per traffic
class (including QoS and slice aspects). Thus, there may be more
than one MTNC-ID for the same QoS and path if there is a need to
provide isolation (slice) of the traffic. It should be noted that
MTNC are per class/path and not per user session (nor is it per data
path entity). The MTNC identifiers are configured by the TNF to be
unique within a provisioning domain.
Since the MTNC identifiers are not generated per user flow or
session, there is no need for unique MTNC identifiers per flow/
session. In addition, since the traffic estimation not performed at
the time of session establishment, there is no provisioning delay
experienced during session setup. The MTNC identifier space scales
as a square of the number sites between which 3GPP user plane
functions require paths. If there are T traffic classes across N
sites, the number of MTNC identifiers in a fully meshed network is
(N*(N-1)/2) * T. For example, if there are 3 traffic classes between
25 sites, there would be at most 900 MTNC identifiers required.
Multiple slices for the same QoS class that need to be fully
isolated, will add to the MTNC provisioning. An MTNC identifier
space of 16 bits (65K+ identifiers) can be expected to be sufficient.
2.2.2. MTNC Identifier in the Data Packet
When the 3GPP user plane function (gNB, UPF) and transport provider
edge are on different nodes, the PE router needs to have the means by
which to classify the PDU packet. IP header fields such as DSCP
(DiffServ Code Point) or the IPv6 Flow Label do not satisfy the
requirement as they are not immutable.
Different options for carrying the MTNC identifier in the IP data
packet or in the existing user plane overlay like GTP-U
[TS.29.281-3GPP] or a new overlay like GUE
[I-D.ietf-intarea-gue-extensions] are possible. There are various
trade-offs in terms of packet overhead, support in IPv4 and IPv6
networks as well as working across legacy and evolving transport
networks that need to be considered. These considerations will be
addressed in future revisions.
3. Using PPR as TN Underlay 3. Using PPR as TN Underlay
In a network implementing source routing, packets may be transported In a network implementing source routing, packets may be transported
through the use of Segment Identifiers (SIDs), where a SID uniquely through the use of Segment Identifiers (SIDs), where a SID uniquely
identifies a segment as defined in [I-D.ietf-spring-segment-routing]. identifies a segment as defined in [I-D.ietf-spring-segment-routing].
Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out
all SRv6 features along with a few concerns in Section 5.3.7 of the all SRv6 features along with a few concerns in Section 5.3.7 of the
same document. Those concerns are addressed by a new backhaul same document. Those concerns as well as need for underlay agnostic
(L2/Ipv4/IPv6/MPLS) TE requirements are addressed by a new XHaul
routing mechanism called Preferred Path Routing (PPR), of which this routing mechanism called Preferred Path Routing (PPR), of which this
section provides an overview. section provides an overview.
The label/PPR-ID refer not to individual segments of which the path With PPR, the label/PPR-ID refer not to individual segments of which
is composed, but to the identifier of a path that is deployed on the path is composed, but to the identifier of a path that is
network nodes. The fact that paths and path identifiers can be deployed on network nodes. The fact that paths and path identifiers
computed and controlled by a controller, not a routing protocol, can be computed and controlled by a controller, not a routing
allows the deployment of any path that network operators prefer, not protocol, allows the deployment of any path that network operators
just shortest paths. As packets refer to a path towards a given prefer, not just shortest paths. As packets refer to a path towards
destination and nodes make their forwarding decision based on the a given destination and nodes make their forwarding decision based on
identifier of a path, not the identifier of a next segment node, it the identifier of a path, not the identifier of a next segment node,
is no longer necessary to carry a sequence of labels. This results it is no longer necessary to carry a sequence of labels. This
in multiple benefits including significant reduction in network layer results in multiple benefits including significant reduction in
overhead, increased performance and hardware compatibility for network layer overhead, increased performance and hardware
carrying both path and services along the path. compatibility for carrying both path and services along the path.
Details of the IGP extensions for PPR are provided here: Details of the IGP extensions for PPR are provided here:
o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing]
o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing]
3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces
PPR does not remove GTP-U, unlike some other proposals laid out in PPR does not remove GTP-U, unlike some other proposals laid out in
[I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works
with the existing cellular user plane (GTP-U) for both N3 and any with the existing cellular user plane (GTP-U) for both N3 and any
approach selected for N9 (encapsulation or no-encapsulation). In approach selected for N9 (encapsulation or no-encapsulation). In
this scenario, PPR will only help providing TE benefits needed for 5G this scenario, PPR will only help providing TE benefits needed for 5G
slices from transport domain perspective. It does so without adding slices from transport domain perspective. It does so for any
any additional overhead to the user plane, unlike SR-MPLS or SRv6. underlying data plane used in the transport network (L2/IPv4/IPv6/
This is achieved by: MPLS). This is achieved by:
o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in
the transport network. For Uplink traffic, the 5G-AN will choose the transport network. For Uplink traffic, the 5G-AN will choose
the right PPR-ID of the UPF based on the S-NSSAI the PDU Session the right PPR-ID of the UPF based on the S-NSSAI the PDU Session
belongs to and/or the QFI (e.g. 5QI) marking on the GTP-U belongs to and/or the UDP Source port (corresponds to the MTNC-ID
encapsulation header. Similarly in the Downlink direction Section 2.5) of the GTP-U encapsulation header. Similarly in the
matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the Downlink direction matching PPR-ID of the 5G-AN is chosen based on
PDU Session belongs to. The table below shows a typical mapping: the S-NSSAI the PDU Session belongs to. The table below shows a
typical mapping:
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| QFI (Ranges) | SST | Transport Path | Transport Path | |GTP/UDP SRC PORT| SST | Transport Path | Transport Path |
| | in S-NSSAI | Info | Characteristics | | | in S-NSSAI | Info | Characteristics |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Xx - Xy | | | | | Range Xx - Xy | | | |
| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |
| values) | (massive | PPR-ID-A | Bit Rate) | | values) | (massive | PPR-ID-A | Bit Rate) |
| | IOT) | | Bandwidth: Bx | | | IOT) | | Bandwidth: Bx |
| | | | Delay: Dx | | | | | Delay: Dx |
| | | | Jitter: Jx | | | | | Jitter: Jx |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Yx - Yy | | | | | Range Yx - Yy | | | |
skipping to change at page 14, line 28 skipping to change at page 15, line 28
| values) | (ultra-low | PPR-ID-B | Req. | | values) | (ultra-low | PPR-ID-B | Req. |
| | latency) | | Bandwidth: By | | | latency) | | Bandwidth: By |
| | | | Delay: Dy | | | | | Delay: Dy |
| | | | Jitter: Jy | | | | | Jitter: Jy |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Zx - Zy | | | | | Range Zx - Zy | | | |
| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |
| values) | (broadband)| PPR-ID-C | Bandwidth: Bx | | values) | (broadband)| PPR-ID-C | Bandwidth: Bx |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
Figure 3: QFI Mapping with PPR-IDs on N3/N9 Figure 2: Mapping of PPR-IDs on N3/N9
o It is possible to have a single PPR-ID for multiple input points o It is possible to have a single PPR-ID for multiple input points
through a PPR tree structure separate in UL and DL direction. through a PPR tree structure separate in UL and DL direction.
o Same set of PPRs are created uniformly across all needed 5G-ANs o Same set of PPRs are created uniformly across all needed 5G-ANs
and UPFs to allow various mobility scenarios. and UPFs to allow various mobility scenarios.
o Any modification of TE parameters of the path, replacement path o Any modification of TE parameters of the path, replacement path
and deleted path needed to be updated from TNF to the relevant and deleted path needed to be updated from TNF to the relevant
ingress points. Same information can be pushed to the NSSF, and/ ingress points. Same information can be pushed to the NSSF, and/
skipping to change at page 15, line 9 skipping to change at page 16, line 9
o PPR can be supported with any native IPv4 and IPv6 data/user o PPR can be supported with any native IPv4 and IPv6 data/user
planes (Section 3.2) with optional TE features (Section 3.3) . As planes (Section 3.2) with optional TE features (Section 3.3) . As
this is an underlay mechanism it can work with any overlay this is an underlay mechanism it can work with any overlay
encapsulation approach including GTP-U as defined currently for N3 encapsulation approach including GTP-U as defined currently for N3
interface. interface.
3.2. Path Steering Support to native IP user planes 3.2. Path Steering Support to native IP user planes
PPR works in fully compatible way with SR defined user planes (SR- PPR works in fully compatible way with SR defined user planes (SR-
MPLS and SRv6) by reducing the path overhead and other challenges as MPLS and SRv6) by reducing the path overhead and other challenges as
listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or listed in Section 5.3.7 of
Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the
also expands the source routing to user planes beyond SR-MPLS and source routing to user planes beyond SR-MPLS and SRv6 i.e., L2,
SRv6 i.e., native IPv6 and IPv4 user planes. native IPv6 and IPv4 user planes.
This helps legacy transport networks to get the immediate path This helps legacy transport networks to get the immediate path
steering benefits and helps in overall migration strategy of the steering benefits and helps in overall migration strategy of the
network to the desired user plane. It is important to note, these network to the desired user plane. Some of these benefits with PPR
benefits can be realized with no hardware upgrade except control can be realized with no hardware upgrade except control plane
plane software for native IPv6 and IPv4 user planes. software for native IPv6 and IPv4 user planes.
3.3. Service Level Guarantee in Underlay 3.3. Service Level Guarantee in Underlay
PPR also optionally allows to allocate resources that are to be PPR also optionally allows to allocate resources that are to be
reserved along the preferred path. These resources are required in reserved along the preferred path. These resources are required in
some cases (for some 5G SSTs with stringent GBR and latency some cases (for some 5G SSTs with stringent GBR and latency
requirements) not only for providing committed bandwidth or requirements) not only for providing committed bandwidth or
deterministic latency, but also for assuring overall service level deterministic latency, but also for assuring overall service level
guarantee in the network. This approach does not require per-hop guarantee in the network. This approach does not require per-hop
provisioning and reduces the OPEX by minimizing the number of provisioning and reduces the OPEX by minimizing the number of
skipping to change at page 16, line 45 skipping to change at page 17, line 45
9.1. Normative References 9.1. Normative References
[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>.
9.2. Informative References 9.2. Informative References
[ATIS075] Alliance for Telecommunications Industry Solutions (ATIS),
"IOT Categorization: Exploring the Need for Standardizing
Additional Network Slices ATIS-I-0000075", September 2019.
[I-D.bashandy-rtgwg-segment-routing-ti-lfa] [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
lfa-05 (work in progress), October 2018. lfa-05 (work in progress), October 2018.
[I-D.bogineni-dmm-optimized-mobile-user-plane] [I-D.bogineni-dmm-optimized-mobile-user-plane]
Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
Rodriguez-Natal, A., Carofiglio, G., Auge, J., Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
Muscariello, L., Camarillo, P., and S. Homma, "Optimized Muscariello, L., Camarillo, P., and S. Homma, "Optimized
Mobile User Plane Solutions for 5G", draft-bogineni-dmm- Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
optimized-mobile-user-plane-01 (work in progress), June optimized-mobile-user-plane-01 (work in progress), June
2018. 2018.
[I-D.chunduri-lsr-isis-preferred-path-routing] [I-D.chunduri-lsr-isis-preferred-path-routing]
Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
draft-chunduri-lsr-isis-preferred-path-routing-03 (work in draft-chunduri-lsr-isis-preferred-path-routing-04 (work in
progress), May 2019. progress), July 2019.
[I-D.chunduri-lsr-ospf-preferred-path-routing] [I-D.chunduri-lsr-ospf-preferred-path-routing]
Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
Contreras, "Preferred Path Routing (PPR) in OSPF", draft- Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
chunduri-lsr-ospf-preferred-path-routing-03 (work in chunduri-lsr-ospf-preferred-path-routing-03 (work in
progress), May 2019. progress), May 2019.
[I-D.farinacci-lisp-mobile-network] [I-D.farinacci-lisp-mobile-network]
Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
for the Mobile Network", draft-farinacci-lisp-mobile- for the Mobile Network", draft-farinacci-lisp-mobile-
network-05 (work in progress), March 2019. network-06 (work in progress), September 2019.
[I-D.ietf-dmm-5g-uplane-analysis] [I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and d. Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
daniel.voyer@bell.ca, "User Plane Protocol and "User Plane Protocol and Architectural Analysis on 3GPP 5G
Architectural Analysis on 3GPP 5G System", draft-ietf-dmm- System", draft-ietf-dmm-5g-uplane-analysis-02 (work in
5g-uplane-analysis-02 (work in progress), July 2019. progress), July 2019.
[I-D.ietf-dmm-srv6-mobile-uplane] [I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing Voyer, D., and C. Perkins, "Segment Routing IPv6 for
IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-06
uplane-05 (work in progress), July 2019. (work in progress), September 2019.
[I-D.ietf-intarea-gue-extensions] [I-D.ietf-intarea-gue-extensions]
Herbert, T., Yong, L., and F. Templin, "Extensions for Herbert, T., Yong, L., and F. Templin, "Extensions for
Generic UDP Encapsulation", draft-ietf-intarea-gue- Generic UDP Encapsulation", draft-ietf-intarea-gue-
extensions-06 (work in progress), March 2019. extensions-06 (work in progress), March 2019.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
skipping to change at page 20, line 27 skipping to change at page 21, line 32
The management plane functionality also provides the mapping of such The management plane functionality also provides the mapping of such
TE paths to a network instance identifier to the SMF. The SMF uses TE paths to a network instance identifier to the SMF. The SMF uses
this mapping to install appropriate FARs in the UPF. This approach this mapping to install appropriate FARs in the UPF. This approach
provide partial integration of the transport network into 5GS with provide partial integration of the transport network into 5GS with
some benefits. some benefits.
One of the limitations of this approach is the inability of the 5GS One of the limitations of this approach is the inability of the 5GS
procedures to know, if underlying transport resources are available procedures to know, if underlying transport resources are available
for the traffic type being carried in PDU session before making for the traffic type being carried in PDU session before making
certain decisions in the 5G CP. One example scenario/decision could certain decisions in the 5G CP. One example scenario/decision could
be, a target gNB selection during a N2 mobility event, without be, a target 5G-AN selection during a N2 mobility event, without
knowing if the target gNB is having a underlay transport slice knowing if the target 5G-AN is having a underlay transport slice
resource for the S-NSSAI and 5QI of the PDU session. The Integrated resource for the S-NSSAI and 5QI of the PDU session. The Integrated
approach specified below can mitigate this. approach specified below can mitigate this.
Appendix B. PPR with various 5G Mobility procedures Appendix B. PPR with various 5G Mobility procedures
PPR fulfills the needs of 5GS to transport the user plane traffic PPR fulfills the needs of 5GS to transport the user plane traffic
from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This
is done in keeping the backhaul network at par with 5G slicing is done in keeping the backhaul network at par with 5G slicing
requirements that are applicable to Radio and virtualized core requirements that are applicable to Radio and virtualized core
network to create a truly end-to-end slice path for 5G traffic. When network to create a truly end-to-end slice path for 5G traffic. When
UE moves across the 5G-AN (e.g. from one gNB to another gNB), there UE moves across the 5G-AN (e.g. from one gNB to another gNB), there
is no transport network reconfiguration required with the approach is no transport network reconfiguration required with the approach
above. above.
SSC mode would be specified/defaulted by SMF. No change in the mode SSC mode would be specified/defaulted by SMF. No change in the mode
once connection is initiated and this property is not altered here. once connection is initiated and this property is not altered here.
B.1. SSC Mode1 B.1. SSC Mode1
+---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF | +--------------+
+---+--+-+ +-+-+-+ +-+--------------+ +---+----+ |NSSMF +-----+ | +----------------+
N1 | | | | | AMF | | | TNF | | | SMF |
+---+--+-+ | +-+-+-+ | +-+--------------+
N1 | +--------+-+---+ |
| | | | |
+--------+ N2 +----Ns---+ +-Nn-+ N4 +--------+ N2 +----Ns---+ +-Nn-+ N4
| | | | | | | | | |
+ +---+---+ +--++ +-+--+---+ +----+ + +---+---+ +--++ +-+--+---+ +----+
UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN | UE1 |gNB|======|CSR|------N3---- | PE+UPF |-N6--| DN |
== +---+ +---+ +--------+ +----+ == +---+ +---+ +--------+ +----+
Figure 4: SSC Mode1 with integrated Transport Slice Function Figure 3: SSC Mode1 with integrated Transport Slice Function
After UE1 moved to another gNB in the same UPF serving area After UE1 moved to another gNB in the same UPF serving area
+---+----+ +-----+ +----------------+ +--------------+
| AMF | | TNF | | SMF | +---+----+ |NSSMF +-----+ | +----------------+
+---_--+-+ +-+-+-+ +-+--------------+ | AMF | | | TNF | | | SMF |
+---+--+-+ | +-+-+-+ | +-+--------------+
| +--------+-+---+ |
| | | | | | | |
N2 +----Ns---+ +-Nn-+ N4 N2 +----Ns---+ +-Nn-+ N4
| | | | | | | |
+----+--+ +-+-+ ++--+----+ +----+ +----+--+ +-+-+ ++--+----+ +----+
|gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN | |gNB1|======|CSR|------N3-----| PE+UPF |-N6--| DN |
+----+ +---+ +---+----+ +----+ +----+ +---+ +---+----+ +----+
| |
| |
| |
| |
+----+ +--++ | +----+ +--++ |
UE1 |gNB2+======+CSR+------N3--------+ UE1 |gNB2|======|CSR|------N3--------+
== +----+ +---+ == +----+ +---+
Figure 5: SSC Mode1 with integrated Transport Slice Function Figure 4: SSC Mode1 with integrated Transport Slice Function
In this mode, IP address at the UE is preserved during mobility In this mode, IP address at the UE is preserved during mobility
events. This is similar to 4G/LTE mechanism and for respective events. This is similar to 4G/LTE mechanism and for respective
slices, corresponding PPR-ID (TE Path) has to be assigned to the slices, corresponding PPR-ID (TE Path) has to be assigned to the
packet at UL and DL direction. During Xn mobility as shown above, packet at UL and DL direction. During Xn mobility as shown above,
source gNB has to additionally ensure transport path's resources from source gNB has to additionally ensure transport path's resources from
TNF are available at the target gNB apart from radio resources check TNF are available at the target gNB apart from radio resources check
(at decision and request phase of Xn/N2 mobility scenario). (at decision and request phase of Xn/N2 mobility scenario).
B.2. SSC Mode2 B.2. SSC Mode2
skipping to change at page 22, line 28 skipping to change at page 24, line 5
Sessions. Sessions.
o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU
Session. Session.
In the first mode, from user plane perspective, the two PDU sessions In the first mode, from user plane perspective, the two PDU sessions
are independent and the use of PPR-ID by gNB and UPFs is exactly are independent and the use of PPR-ID by gNB and UPFs is exactly
similar to SSC Mode 1 described above. The following paragraphs similar to SSC Mode 1 described above. The following paragraphs
describe the IPv6 multi-homed PDU session case for SSC Mode 3. describe the IPv6 multi-homed PDU session case for SSC Mode 3.
+---+----+ +-----+ +----------------+ +--------------+
| AMF | | TNF | | SMF | +---+----+ |NSSMF +-----+ | +----------------+
+---+--+-+ +-+-+-+ +-+-----------+--+ | AMF | | | TNF | | | SMF |
+---+--+-+ | +-+-+-+ | +-+-----------+--+
| | +--------+-+---+ | |
N1 | | | | | N1 | | | | |
to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4| to-UE+----+ N2 +------Ns---+ +-Nn-+ N4 N4|
| | | | | +---+ | | | |
+-------+--+ +--+-------+--+ +-----+-+ | | | | |
|gNB/CSR +---N3---+ BP UPF +-N9--+ UPF +-N6-- +---+ +---++ +--+-------+--+ +---+---+
+----------+ +----------+--+ +-------+ to DN |gNB|===|CSR |---N3---| PE+BP UPF |-N9--| PE+UPF|-N6->
+---+ +----+ +----------+--+ +-------+ to DN
| +----+ | +----+
+-| DN | +-| DN |
N6 +----+ N6 +----+
Figure 6: SSC Mode3 and Service Continuity Figure 5: SSC Mode3 and Service Continuity
In the uplink direction for the traffic offloading from the Branching In the uplink direction for the traffic offloading from the Branching
Point UPF, packet has to reach to the right exit UPF. In this case Point UPF, packet has to reach to the right exit UPF. In this case
packet gets re-encapsulated by the BP UPF (with either GTP-U or the packet gets re-encapsulated by the BP UPF (with either GTP-U or the
chosen encapsulation) after bit rate enforcement and LI, towards the chosen encapsulation) after bit rate enforcement and LI, towards the
anchor UPF. At this point packet has to be on the appropriate VPN/PW anchor UPF. At this point packet has to be on the appropriate VPN/PW
to the anchor UPF. This mapping is done based on the S-NSSAI the PDU to the anchor UPF. This mapping is done based on the S-NSSAI the PDU
session belongs to and/or the QFI marking in the GTPU encapsulation session belongs to and/or with the UDP source port (corresponds to
header (e.g. 5QI value) to the PPR-ID of the exit node by selecting the MTNC-ID Section 2.5) of the GTP-U encapsulation header to the
the respective TE PPR-ID (PPR path) of the UPF. If it's a non-MPLS PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR
underlay, destination IP address of the encapsulation header would be path) of the UPF. If it's a non-MPLS underlay, destination IP
the mapped PPR-ID (TE path). address of the encapsulation header would be the mapped PPR-ID (TE
path).
In the downlink direction for the incoming packet, UPF has to In the downlink direction for the incoming packet, UPF has to
encapsulate the packet (with either GTP-U or the chosen encapsulate the packet (with either GTP-U or the chosen
encapsulation) to reach the BP UPF. Here mapping is done based on encapsulation) to reach the BP UPF. Here mapping is done based on
the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the
BP UPF. If it's a non-MPLS underlay, destination IP address of the BP UPF. If it's a non-MPLS underlay, destination IP address of the
encapsulation header would be the mapped PPR-ID (TE path). In encapsulation header would be the mapped PPR-ID (TE path). In
summary: summary:
o Respective PPR-ID on N3 and N9 has to be selected with correct o Respective PPR-ID on N3 and N9 has to be selected with correct
skipping to change at page 24, line 4 skipping to change at page 25, line 27
Email: umac.ietf@gmail.com Email: umac.ietf@gmail.com
Richard Li Richard Li
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: richard.li@futurewei.com Email: richard.li@futurewei.com
Sridhar Bhaskaran Sridhar Bhaskaran
Altiostar Altiostar
Email: sridhar.bhaskaran@gmail.com Email: sridharb@altiostar.com
John Kaippallimalil
Futurewei
Email: john.kaippallimalil@futurewei.com
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Sur-3 building, 3rd floor Sur-3 building, 3rd floor
Madrid 28050 Madrid 28050
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
Praveen Muley Praveen Muley
Nokia Nokia
440 North Bernardo Ave 440 North Bernardo Ave
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: praveen.muley@nokia.com Email: praveen.muley@nokia.com
John Kaippallimalil
Futurewei
5700 Tennyson Parkway, Suite 600
Plano, TX 75024
USA
Email: john.kaippallimalil@futurewei.com
 End of changes. 68 change blocks. 
378 lines changed or deleted 448 lines changed or added

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