idnits 2.17.1 draft-wei-dmm-source-routing-mobility-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Intended Status: ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (November 19, 2018) is 1984 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming-05' is defined on line 365, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT X. Wei 3 Intended Status: F.Yang 4 Expires: May 23, 2019 Huawei 5 November 19, 2018 7 Mobility Management based on Source Routing 8 draft-wei-dmm-source-routing-mobility-management-00 10 Abstract 12 This document explores how mobility management could be provided 13 based on source routing like solutions and take SRv6 as an example 14 for 5G LAN service. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 56 3. 5G LAN Network Model . . . . . . . . . . . . . . . . . . . . . 4 57 4. SRv6-based mobility management for 5G LAN . . . . . . . . . . . 5 58 4.1 UE Handover . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2 SRv6-based Handover . . . . . . . . . . . . . . . . . . . . 5 60 5. Extensions of SRv6 . . . . . . . . . . . . . . . . . . . . . . 7 61 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 62 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 63 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 65 5.2 Informative References . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1 Introduction 70 The 5G network is designed aims at three scenarios which are eMBB 71 (enhanced Mobile Broad Band), uRLLC (ultra-Reliable Low latency 72 Communication ), and mMTC (massive Machine Type Communication). The 73 goal of 5G is to provide network services for various application 74 scenarios not limited to traditional MBB service. 76 One of the promises of 5G is the convergence of fixed and mobile 77 networks, and providing LAN (Local Area Network) services in 5G 78 networks is a new communication requirement. 5G LAN has many 79 potential application scenarios, for example, provide communication 80 for home service in residential environment which will solve many 81 coverage and QoS problems that home owners are suffering with the 82 current solutions; provide enterprise communication service in 83 enterprise environment to interwork with and enhance existing WLAN 84 and fixed LANs in the enterprise and as a replacement LAN technology 85 that eliminates the need for other WLAN and fixed LAN deployments and 86 provide with a wider area coverage using the cellular radio and 87 greater mobility for UEs. 89 Communication between UEs in a 5G LAN is a full mesh communication 90 mode, and UEs that belong to the same LAN can communicate with each 91 other, and the UE has mobility characteristics and may move between 92 different network locations. The traditional GTP tunnel-based 93 solution needs to establish a tunnel between network nodes in a full 94 mesh manner in order to connect all the UEs in the same LAN, which 95 will result in many tunnels. The maintenance process of the tunnels 96 involves the process of establishing and deleting a tunnel through 97 signaling, which is very complicated, especially when the UE moves, 98 it may involve a large number of tunnel establishment and removal 99 processes. 101 Source routing is an alternative method for packets routing, which 102 allows a sender of a packet to partially or completely specify the 103 route the packet takes through the network, source routing could be a 104 candidate for routing packets in 5G LAN. Currently there are 105 different types of approach for source routing, and SRv6 is one of 106 them. SRv6 (Segment Routing IPv6) [I-D. draft-filsfils-spring-srv6- 107 network-programming-05] uses a source routing idea to forward packets 108 in the network and provides flexible routing features for packet 109 forwarding. SRv6 also defines a number of commands that provide more 110 powerful additional functions based on data forwarding. 112 This document explores how mobility management could be provided 113 based on source routing like solutions and take SRv6 as an example 114 for 5G LAN service. 116 2. Conventions and Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. 5G LAN Network Model 124 This section provides a more detailed description of 5G LAN network. 125 (for simplicity, the control plane entities of 5G core network is 126 eliminated, for more information about 5G core architecture, please 127 refer to [TS 23.501]) 129 +----+ +----+ 130 |UPF1|-------------------|UPF2| 131 +-+--+ ++--++ 132 | | | 133 | -----+ +-------+ 134 | | | 135 +-+--+ +-+--+ +-+--+ 136 |gNB1| |gNB2| |gNB3| 137 +|--+| +--+-+ +|--|+ 138 +----+ || | +--+ +--+ 139 | |+------+ | | | 140 | | | | | | 141 | | | | | | 142 | | | | | | 143 ++--+ ++--+ +-+-+ +-+-+ +-+-+ +-+-+ 144 |UE1| |UE2| |UE3| |UE4| |UE5| |UE6| 145 +---+ +---+ +---+ +---+ +---+ +---+ 147 Figure 1: 5G LAN Network Model 149 UE: User Equipment. 151 gNB: RAN node of 5G system. 153 UPF: User Plane Function. 155 Multiple UEs can be included in the same LAN and different UEs can 156 access the same LAN through different network access point. The 157 data frame can be unicasted, multicasted or broadcasted among UEs 158 as in the traditional layer 2 LAN except that data frames are 159 carried over a 5G network. The UEs may move between different 160 network locations while maintaining continuity of UE services. 162 4. SRv6-based mobility management for 5G LAN 164 4.1 UE Handover 166 The solution of 5G LAN based on SRv6 instead of tunnel can make 167 full use of SRv6 flexibility, and avoid the complexity of tunnel 168 maintenance while meeting the mobility requirements. 170 The UE in the LAN handover from one gNB to another gNB due to 171 reasons such as UE's movement or radio signal quality change. The 172 network side needs to ensure that no packets are lost during the 173 handover process, and no packets re-ordering happens to ensure 174 service continuity. Several requirements that the handover scheme 175 needs to meet: the switching of the forwarding context from S-gNB 176 to T-gNB and distinguish between normal traffic and in-transit 177 traffic. 179 +----+ +----+ 180 +--+ +-----+ | | | | 181 |UE| |S-gNB|-----------------| | 182 +--+ +-----++++++| | | | 183 | +| | | | 184 move| +|UPF1| |UPF2| 185 V +| | | | 186 +--+ +-----++++++| | | | 187 |UE| |T-gNB|-----------------| | 188 +--+ +-----+ | | | | 189 +----+ +----+ 191 Figure 2: UE Handover 193 4.2 SRv6-based Handover 195 When using SRv6 to carry data packets, SRv6 not only needs to 196 identify the transmission path for packets, but also needs to 197 distinguish the in-transit data packets during the handover 198 process, so as to avoid the packets re-ordering received by the 199 UE. The in-transit packets are packets that should be sent to T- 200 gNB but sent to S-gNB for transit after handover. 202 Before the handover occurs, the service flow of the UE is 203 transmitted between the anchor UPF, the S-gNB and the UE based on 204 the SRv6, the data packet is carried between the network entities 205 through SRv6 encapsulation, and the S-gNB and the anchor UPF are 206 respectively responsible for adding SRv6 header for the uplink 207 data packets and the downlink data packets. The SRv6 header 208 encapsulated on the data packet sent by the anchor UPF to the UE 209 carries the "Forward" flag to indicate that the data packet is a 210 data packet from the anchor UPF. 212 The UE periodically sends a channel measurement report to the S- 213 gNB for S-gNB to make decision whether a handover to new gNB is 214 needed. Once the S-gNB decides to initiate the handover procedure, 215 the S-gNB will interact with the target T-gNB so that the T-gNB is 216 ready for UE access. 218 After receiving the handover notification, the Anchor UPF will 219 stop to transmit data on the path used before the handover. At 220 this time, the Anchor UPF will set the "End" flag in the SRv6 221 header of the packet sent on the path before the handover. The 222 "End" flag is used to indicate that the anchor UPF will stop 223 transmitting data packets to the path used before the handover, 224 and then the anchor UPF will transmit the data packet to the T-gNB 225 through the new path established after handover, and in order to 226 avoid packets re-ordering, the packets from the anchor UPF are 227 first cached by T-gNB. 229 The outer layer of the packets that anchor UPF packet sent to the 230 S-gNB uses a SRv6 header as the routing field to carry routing 231 information. The routing information contains one or more path 232 nodes' information through which the packet traverses from anchor 233 UPF to S-gNB.. Each SRv6 header includes one or more IPv6 234 addresses, and each IPv6 address is in one-to-one correspondence 235 with a path node. The 128-bit IPv6 address is divided into a route 236 identifier field and a packet source flag field, where the route 237 identifier field is used to carry path node's information, the 238 packet source flag field is used to carry the packet source flag. 240 After the handover notification is sent, S-gNB creates a temporary 241 forwarding entry for the data transmission path from the S-gNB to 242 the T-gNB. The forwarding entry records the routing information of 243 the forwarding nodes for packets to be forwarded from the S-gNB to 244 the T-gNB. At the same time, the S-gNB receives packet from the 245 anchor UPF on the path before handover, and the "Forward" flag 246 carried in the packet indicates that the packet is directly from 247 the anchor UPF, and the S-gNB obtains routing information from the 248 temporary forwarding entry and the SRv6 header of the received 249 data packet is modified according the routing information, the 250 obtained routing information is carried in the SRv6 header, and 251 the "Forward" flag carried in the previous SRv6 header is changed 252 to "Transit" flag, which is used to indicate that the transmitted 253 data packet is an in-transit packet, and then forward the modified 254 packet to the T-gNB. 256 The packet sent by the S-gNB to the T-gNB is encapsulated using a 257 SRv6 header as the routing field to carry the routing information, 258 similar to the SRv6 header encapsulated on packets sent from the 259 anchor UPF to the S-gNB, where the SRv6 header contains one or 260 more IPv6 addresses, each IPv6 address is in one-to-one 261 correspondence with a path node, and the 128-bit IPv6 address is 262 divided into a route identifier field and a packet source flag 263 field, where the route identifier field is used to carry path 264 node's information, the packet source flag field is used to carry 265 the packet source flag. 267 An alternative method to carry the packet source flag is to carry 268 it in the extension field of the SRv6 header, and not in the IPv6 269 address in the SRv6 header. 271 When the S-gNB receives a packet with the "End" flag from the 272 anchor UPF, it forwards the modified packet to the T-gNB by using 273 a method similar to deal with the "Forward" flag packets. The 274 difference is that the packet is forwarded to the T-gNB with "End" 275 flag set instead of "Transit" flag. The "End" flag indicates 276 anchor UPF will stop transmitting data packets on the path used 277 before the handover. 279 Before receiving packets from S-gNB with "End" flag set, the T-gNB 280 will buffer the packets from anchor UPF transmitted on new path 281 after handover, and will transmit the in-transit packets from the 282 S-gNB to UE. When the T-gNB receives the packet with "End" flag 283 set from the S-gNB, it starts transmitting the packets receiving 284 from the new path established after handover. 286 5. Extensions of SRv6 288 This section describes extensions of SRv6 that are needed when 289 SRv6 is used for 5G LAN, and there are two kinds of options for 290 the extensions. 292 Option 1: IPv6 Address Redefinition 294 Redefine the 128-bit IPv6 address into two parts: a route 295 identifier field and a packet source flag field, where the route 296 identifier field is used to carry path node's information, the 297 packet source flag field is used to carry the packet source flag. 299 +--------------------------------+------+ 300 | RID | Flag | 301 +--------------------------------+------+ 303 Figure 3: IPv6 Address Redefinition 305 RID: 307 Contains path node's information, the information will be used for 308 routing packet to the specific node. 310 Flag: 312 00, "Forward", the default flag that indicates the packet is from 313 UPF. 315 01, "Transit", indicates the packet is an in-transit packet. 317 10, "End", indicating anchor UPF will stop transmitting data 318 packets on the path used before the handover. 320 11, reserved. 322 Option 2: SRv6 Header Extension 324 Because SRv6 header itself contains an "Optional Type Length Value 325 objects" field, so this field can be used to carry packet source 326 flag field, and segment list of IPv6 address in SRv6 header acts 327 as route identifier field. 329 +-----------+--------------+--------------+ 330 | Type | Length | Flag | 331 +-----------+--------------+--------------+ 332 Figure 4: New Optional Type Length Value Object for SRv6 Header 334 Type: TBD1. 336 Length: 1 338 Flag: 340 00, "Forward", the default flag that the packet is from UPF. 342 01, "Transit", indicates the packet is an in-transit packet. 344 10, "End", anchor UPF will stop transmitting data packets to the 345 path used before the handover. 347 11, reserved. 349 3 Security Considerations 351 TBD. 353 4 IANA Considerations 355 TBD. 357 5 References 359 5.1 Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 5.2 Informative References 365 [I-D.filsfils-spring-srv6-network-programming-05] Filsfils, C., 366 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S., 367 and Z. Li, "SRv6 Network Programming", draft-filsfils-spring-srv6- 368 network-programming-05 (work in progress), July 2018. 370 [TS 23.501] 3GPP, "System Architecture for the 5G System", 3GPP 371 TS23.501 15.0.0, November 2017. 373 Authors' Addresses 375 Xinpeng Wei 376 Beiqing Rd. Z-park No.156, Haidian District, 377 Beijing, 100095, P. R. China 378 E-mail: weixinpeng@huawei.com 380 Fei Yang 381 Beiqing Rd. Z-park No.156, Haidian District, 382 Beijing, 100095, P. R. China 383 E-mail: yangfei15@huawei.com