idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-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. -- The document date (November 30, 2017) is 2339 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) == Missing Reference: 'MN' is mentioned on line 215, but not defined == Missing Reference: 'SL' is mentioned on line 334, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-09 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING and DMM S. Matsushima 3 Internet-Draft SoftBank 4 Intended status: Standards Track C. Filsfils 5 Expires: June 3, 2018 M. Kohno 6 Cisco Systems, Inc. 7 D. Voyer 8 Bell Canada 9 C. Perkins 10 Futurewei 11 November 30, 2017 13 Segment Routing IPv6 for Mobile User-Plane 14 draft-ietf-dmm-srv6-mobile-uplane-00 16 Abstract 18 This document discusses the applicability of SRv6 (Segment Routing 19 IPv6) to user-plane of mobile networks that SRv6 source routing 20 capability with its programmability can fulfill the user-plane 21 functions, such as access and anchor functions. It takes advantage 22 of underlying layer awareness and flexibility to deploy user-plane 23 functions that enables optimizing data-path for applications. 24 Network slicing and an interworking way between SRv6 and existing 25 mobile user-plane are also discussed in this document. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 63 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Supporting Mobile User-Plane Functions . . . . . . . . . . . 5 66 5.1. Access Point . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2. Layer-2 Anchor . . . . . . . . . . . . . . . . . . . . . 6 68 5.3. Layer-3 Anchor . . . . . . . . . . . . . . . . . . . . . 6 69 5.4. Stateless Interworking . . . . . . . . . . . . . . . . . 7 70 5.4.1. End.TM: End point function with encapsulation for 71 mapped tunnel . . . . . . . . . . . . . . . . . . . . 7 72 5.4.2. T.Tmap: Transit behavior with tunnel decapsulation 73 and mapping an SRv6 Policy . . . . . . . . . . . . . 8 74 5.5. Rate Limit . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Segment Routing IPv6 Functions and Behaviors by Use Cases . . 9 76 6.1. Basic Mode . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.1.1. Uplink . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.1.2. Downlink . . . . . . . . . . . . . . . . . . . . . . 10 79 6.2. Aggregate Mode . . . . . . . . . . . . . . . . . . . . . 11 80 6.2.1. Uplink . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.2.2. Downlink . . . . . . . . . . . . . . . . . . . . . . 13 82 6.3. Stateless Interworking with Legacy Access Network . . . . 14 83 6.3.1. Uplink: Lagacy Access to SRv6 . . . . . . . . . . . . 14 84 6.3.2. Downlink: SRv6 to Legacy Access . . . . . . . . . . . 15 85 7. Network Slicing Considerations . . . . . . . . . . . . . . . 16 86 8. Control Plane Considerations . . . . . . . . . . . . . . . . 16 87 8.1. Existing Control Plane . . . . . . . . . . . . . . . . . 16 88 8.2. Aggregate Mode . . . . . . . . . . . . . . . . . . . . . 17 89 8.3. User-Plane Sepalated Control Plane . . . . . . . . . . . 17 90 8.4. Centralized Controller . . . . . . . . . . . . . . . . . 17 91 8.5. Stateless Interworking . . . . . . . . . . . . . . . . . 18 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 12.2. Informative References . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 In mobile networks, mobility management systems provide connectivity 103 while mobile nodes move around. While the control-plane of the 104 system signals movements of a mobile node, user-plane establishes 105 tunnel between the mobile node and anchor node over IP based backhaul 106 and core networks. 108 This document discusses the applicability of SRv6 (Segment Routing 109 IPv6) to those mobile networks. SRv6 provides source routing to 110 networks where operators can explicitly indicate route for the 111 packets from and to the mobile node. SRv6 endpoint nodes act as 112 roles of anchor of mobile user-plane. 114 2. Conventions and Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 All segment routing and SRv6 network programming terms are defined in 121 [I-D.ietf-spring-segment-routing] and 122 "[I-D.filsfils-spring-srv6-network-programming]. 124 3. Motivations 126 Today's and future applications are requiring highly optimized data- 127 path between mobile nodes and the entities of those applications in 128 perspectives of latency, bandwidth, etc,. However current 129 architecture of mobile management is agnostic about underlying 130 topologies of transport layer. It rigidly fragments the user-plane 131 in radio access, core and service networks and connects them by 132 tunneling techniques through the user-plane functions such as access 133 and anchor nodes. Those agnostic and rigidness make it difficult for 134 the operator to optimize the data-path. 136 While the mobile network industry has been trying to solve that, 137 applications shift to use IPv6 data-path and network operators adopt 138 it as their IP transport as well. SRv6 integrates both application 139 data-path and underlying transport layer in data-path optimization 140 aspects that does not require any other techniques. 142 SRv6 source routing capability with programmable functions 143 [I-D.filsfils-spring-srv6-network-programming] could fulfills the 144 user-plane functions of mobility management. It takes advantage of 145 underlying layer awareness and flexibility to deploy user-plane 146 functions. Those are the motivations to adopt SRv6 for mobile user- 147 plane. 149 4. Mobile User-Plane 151 This section describes user-plane using SRv6 for mobile networks. 152 This clarifies mobile user-plane functions to which SRv6 endpoint 153 applied. 155 Figure 1 shows mobile user-plane functions which are connected 156 through IPv6-only networks. In the Figure 1, an mobile node (MN) 157 connects to an SRv6 endpoint serving access point role for the MN. 158 When the endpoint receives packets from the MN, it pushes SRH to the 159 packets. The segment list in the SRH indicates the rest of user- 160 plane segments which are L2 and L3 anchors respectively. Then the 161 endpoint send the packets to the IPv6 network. In opposite 162 direction, when an SRv6 endpoint serving L3 anchor role for the MN 163 receives packets to it, the endpoint push SRH consist of the L2 164 anchor and access point segments to the packets. 166 User-plane 167 Function 168 169 O------O 170 | SRv6 | 171 | End | 172 | Point| 173 O------O 174 User-plane || User-plane 175 [MN] Function _____||_____ Function 176 | / \ 177 ___v___ O------O / \ O------O ________ 178 / Radio \ | SRv6 | / \ | SRv6 | / \ 179 / Access \==| End |===/ IPv6-Only \===| End |===/ Service \ 180 \ NW / | Point| \ Network / | Point| \ NW / 181 \________/ O------O \ / O------O \________/ 182 \ / 183 \____________/ 185 Figure 1: Mobile User-plane with SRv6 187 An SRv6 segment represents those each function, such as Access Point, 188 Layer-2 (L2) Anchor and Layer-3 (L3) Anchor. This makes mobile 189 networks highly flexible to deploy any user-plane functions to which 190 nodes in user flow basis. An SRv6 segment can represent a set of 191 flows in any granularity of aggregation even though it is just for a 192 single flow. 194 Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile 195 user-plane, which is defined in [RFC5213] and [TS.29281]. An SRv6 196 segment in the endpoint represents interworking function which 197 enables interworking between existing access point and SRv6 anchor 198 segment, or SRv6 access point segment and existing anchor node. 200 Existing mobile user-plane with IPv6 underlay is expected to be 201 widely deployed. As IPv6 network should be interoperable with SRv6 202 endpoints can be accommodated on it, interworking with existing IPv6 203 network is out of scope of this document. 205 ________ _______ 206 / \ O------O / \ 207 / Service \===|L2/L3 | / Service \ 208 \ NW / |Anchor| User-plane \ NW / 209 \________/ |Node | Function \_______/ 210 O------O || 211 \\_______ O------O ________ O------O 212 / \ | SRv6 | / \ | SRv6 | 213 / Existing \===| End |===/ IPv6-Only\===| End | 214 \ IPv4 NW / | Point| \ Network / | Point| 215 [MN] \________/ O------O \________/ O------O 216 | // || 217 ___v____ O------O ___||__ 218 / Radio \ |Access| / Radio \ 219 / Access \==|Point | [MN]~~~/ Access \ 220 \ NW / |Node | \ NW / 221 \________/ O------O \________/ 223 Figure 2: Interworking with Existing Mobile Networks 225 The detail of SRv6 segments representing user-plane functions are 226 described in Section 5. 228 5. Supporting Mobile User-Plane Functions 230 This section describes mobile user-plane functions to which an SRv6 231 node can apply SRv6 functions and behaviors. The SRv6 node 232 configured with those segments thereby fulfills the user-plane 233 functions. Each function consist of two segments which are uplink 234 (UL) from mobile node to the correspondent node, and downlink (DL) 235 from the correspondent node to mobile node. 237 An SRv6 node may be configured with multiple type of user-plane 238 functions. Each function may also be configured with multiple sets 239 of the segments for one type of function that to purpose of 240 separating tenants, resources and service policies, etc. 242 5.1. Access Point 244 Access Point function provides SRv6 node the role to which mobile 245 node is connected directly. eNodeB could be referenced as an entity 246 implementing the access point in 3GPP term. 248 When an SRv6 node is configured for an Access Point function, the 249 SRv6 node allocates one DL access-point segment SID per session, or 250 per Access Point function which represents one policy that is shared 251 by multiple sessions. 253 Applicable SRv6 functions and behaviors are determined by use cases 254 described in Section 6. 256 5.2. Layer-2 Anchor 258 Layer-2 anchor function provides SRv6 node the role to be anchor 259 point while mobile node move around within a serving area which could 260 be assumed as a layer-2 network. Serving Gateway (SGW) could be 261 referenced as an entity implementing the layer-2 anchor in 3GPP term. 263 When an SRv6 node is configured for a Layer-2 anchor function, the 264 SRv6 node allocates UL L2-anchor segment SID per SRv6 policy, which 265 is bound to next L3-anchor function and specific service if needed. 266 The SRv6 node also allocates one DL L2-anchor segment SID per SRv6 267 policy, which is bound to serving access point SID and specific 268 service if needed. 270 Applicable SRv6 functions and behaviors are determined by use cases 271 described in Section 6. 273 5.3. Layer-3 Anchor 275 Layer-3 anchor function provides SRv6 node the role to be anchor 276 point across a mobile network consists of multiple serving areas. 277 Packet data network gateway (PGW) could be referenced as an entity 278 implementing the layer-3 anchor. 280 When an SRv6 node is configured for a Layer-3 Anchor function, the 281 SRv6 node allocates one UL L3-anchor segment SID per L3-anchor 282 function. Each L3-anchor SID represents one policy which is shared 283 by multiple sessions, such as a routing table, or a service policy 284 with in the table. The routing table should maintain forwarding 285 entries of the belonging MNs. 287 Applicable SRv6 functions and behaviors are determined by use cases 288 described in Section 6. 290 5.4. Stateless Interworking 292 Stateless interworking function provides SRv6 node a role to 293 interworking between existing mobile user-plane and SRv6 mobile user- 294 plane. Figure 3 shows the SRv6 SID format for stateless interworking 295 function that is encoding identifiers of corresponding tunnel in 296 existing network as argument of the SID. 298 +----------------------+-------+-------+-------+ 299 | IW-IPv6-Prefix |IPv4DA |IPv4SA |TUN-ID | 300 +----------------------+-------+-------+-------+ 301 128-a-b-c a b c 303 Figure 3: Stateless Interworking SID Encoding 305 Stateless interworking function introduce following SRv6 end function 306 and transit behavior. 308 End.TM: End point function with encapsulation for 309 mapped tunnel 310 T.Tmap: Transit behavior with tunnel decapsulation 311 and mapping an SRv6 Policy 313 Stateless interworking function is associated with the following 314 mandatory parameters: 316 IW-IPv4-Prefix: IPv4 prefix representing network of SRv6 317 user-plane for legacy mobile user-plane 318 IW-IPv6-Prefix: IPv6 prefix representing network of legacy 319 mobile user-plane for SRv6 user-plane 320 TUN-PROTO: Tunnel protocol type, such as GTP-U or GRE 321 for PMIP 323 5.4.1. End.TM: End point function with encapsulation for mapped tunnel 325 The "End point to encapsulate for mapped tunnel" function (End.TM for 326 short) is used to the direction from SRv6 user-plane to legacy user- 327 plane network. 329 When interworking node N receives a packet destined to S and S is a 330 local End.TM SID, N does: 332 1. IF NH=SRH & SL > 0 THEN 333 2. decrement SL 334 3. update the IPv6 DA with SRH[SL] 335 4. push header of TUN-PROTO with tunnel ID from S ;; Ref1 336 5. push outer IPv4 header with SA, DA from S 337 6. ELSE 338 7. Drop the packet 340 Ref1: TUN-PROTO indicates target tunnel type. 342 5.4.2. T.Tmap: Transit behavior with tunnel decapsulation and mapping 343 an SRv6 Policy 345 The "Transit with tunnel decapsulation and map to an SRv6 policy" 346 function (T.Tmap for short) is used to the direction from legacy 347 user-plane to SRv6 user-plane network. 349 When interworking node N receives a packet destined to a IW- 350 IPv4-Prefix, N does: 352 1. IF P.PLOAD == TUN-PROTO & T.PLOAD == IPv6 THEN ;; Ref1, Ref1bis 353 2. pop the outer IPv4 header and tunnel headers 354 3. copy IPv4 DA, SA, TUN-ID to form SID B with IW-IPv6-Prefix 355 4. insert the SRH (D, B; SL=1) ;; Ref2, Ref2bis 356 5. set the IPv6 DA = B 357 6. forward along the shortest path to B 358 7. ELSE 359 8. Drop the packet 361 Ref1: P.PLOAD and T.PLOAD represent payload protocol of the receiving 362 packet, and payload protocol of the tunnel respectively. 364 Ref1bis: First nibble of payload is used to determine payload 365 protocol in GTP-U case due to it has no payload protocol indicator in 366 the header. 368 Ref2: The received IPv6 DA is placed as last SID of the inserted SRH. 370 Ref2bis: The SRH is inserted before any other IPv6 Routing Extension 371 Header. 373 5.5. Rate Limit 375 Mobile user-plane requires rate-limit feature. SID is able to encode 376 limiting rate as an argument in SID. Multiple flows of packets 377 should have same group identifier in SID when those flows are in an 378 same AMBR group. This helps to keep user-plane stateless. That 379 enables SRv6 endpoint nodes which are unaware from the mobile 380 control-plane information. Encoding format of rate limit segment SID 381 is following: 383 +----------------------+----------+-----------+ 384 | Locater of rate-limit| group-id | limit-rate| 385 +----------------------+----------+-----------+ 386 128-i-j i j 388 Figure 4: Stateless Interworking SID Encoding 390 In case of j bit length is zero in SID, the node should not do rate 391 limiting unless static configuration or control-plane sets the limit 392 rate associated to the SID. 394 6. Segment Routing IPv6 Functions and Behaviors by Use Cases 396 This section describes SRv6 functions and behavior applied to mobile 397 user-plane functions by use cases. Terminology of SRv6 endpoint 398 functions refers to [I-D.filsfils-spring-srv6-network-programming]. 400 6.1. Basic Mode 402 In the basic mode, we assume that mobile user-plane functions are as 403 same as existing ones except using SRv6. This means that there is no 404 impact to rest part of mobile system should be expected while no 405 advanced segment routing features are introduced to it. 407 +---------------------+----------+----------+ 408 | User-plane Function | Uplink | Downlink | 409 +---------------------+----------+----------+ 410 | Access Point | T.Insert | End.X | 411 | L2-anchor | End.B6 | End.B6 | 412 | L3-anchor | End.T | T.Insert | 413 +---------------------+----------+----------+ 415 Table 1: SRv6 Functions for Basic Mode 417 6.1.1. Uplink 419 In uplink, SRv6 node applies following SRv6 end point functions and 420 transit behavior. SIDs are allocated per L3-anchor function in the 421 SRv6 nodes of both L2 and L3-anchor functions in basic mode. 423 Access Point: 425 When the access point node receives a packet destine to "D::1" 426 from a mobile node "S::1", it does T.Insert process for the 427 receiving packets to push a SRH with SID list 428 with SL=1. The access point node update DA to next UL 429 L2-anchor SID "A2::1" which the SL indicates and forward the 430 packet. 432 Layer-2 Anchor: 434 The L2-anchor node of "A2::1" segment does End.B6 process for 435 the receiving packet according to the SRH. The node updates DA 436 to next UL L3-anchor SID "A3::1" bound to "A2::1" and forward 437 the packet. In this basic use case, just one UL L3-anchor SID 438 with SL=0 is enough to do it so that there is no need to push 439 another SRH to the packet in that PSP (Penultimate Segment Pop) 440 operation. 442 Layer-3 Anchor: 444 The L3-anchor node of "A3::1" segment does End.T process for 445 the receiving packet according to the SRH. The node decrement 446 SL to 0, updates DA to D::1 which the SL indicates and lookup 447 IPv6 table associated with "A3::1". In this basic use case, 448 the decremented SL is 0 so that the node does PSP operation of 449 popped out the SRH from the packet and forward it. 451 6.1.2. Downlink 453 In downlink, SRv6 node applies following SRv6 end point functions and 454 transit behavior. SIDs are allocated per session in the SRv6 nodes 455 of both L2-anchor and access point functions in basic mode. 457 Layer-3 Anchor: 459 When the L3-anchor node receives a packet destine to "S::1" 460 from a correspondent node "D::1", it does T.Insert process for 461 the receiving packets to push a SRH with SID list 462 with SL=1. The L3-anchor node update DA to next DL L2-anchor 463 SID "A2::2" which the SL indicates and forward the packet. 465 Layer-2 Anchor: 467 The L2-anchor node of "A2::2" segment does End.B6 process for 468 the receiving packet according to the SRH. The node updates DA 469 to next DL access point segment "A1::1" bound to "A2::2" and 470 forward the packet. In this basic use case, just one DL access 471 point SID with SL=0 is enough to do it so that there is no need 472 to push another SRH to the packet in that PSP (Penultimate 473 Segment Pop) operation. 475 Access Point: 477 The access point node of "A1::1" segment does End.X process for 478 the receiving packet according to the segment. The node 479 decrement SL to 0, updates DA to S::1 which the SL indicates 480 and forward the packet to the mobile node of "S::1" through 481 radio channel associated with "A1::1". In this use case, the 482 decremented SL is 0 so that the node does PSP operation of 483 popped out the SRH from the packet and forward it. 485 6.2. Aggregate Mode 487 In the aggregate mode, user-plane function is able to steer multiple 488 mobile sessions per service policy. This means that mobile sessions 489 paths are aggregated into a service path which includes not only 490 mobile user-plane functions but also other nodes, links or service 491 functions. SIDs are allocated per service policy in the SRv6 nodes 492 of user-plane functions in the aggregate mode. 494 Aggregate mode user-plane can take advantage of SRv6 that enables 495 seamless mobile user-plane deployment with service chaining, VPNs, 496 traffic-engineering by computed path to fulfil the policy. 498 +---------------------+---------------+---------------+ 499 | User-plane Function | Uplink | Downlink | 500 +---------------------+---------------+---------------+ 501 | Access Point | T.Insert | End | 502 | L2-anchor | End or End.B6 | End or End.B6 | 503 | L3-anchor | End.T | T.Insert | 504 +---------------------+---------------+---------------+ 506 Table 2: SRv6 Functions for Aggregate Mode 508 6.2.1. Uplink 510 In uplink, SRv6 node applies following SRv6 end point functions and 511 transit behavior. 513 Access Point: 515 When the access point node receives a packet destine to "D::1" 516 from a mobile node "S::1", it does T.Insert process for the 517 receiving packets. 519 First scenario is that the service policy for "D::1" is via 520 service function S1 and node C1 before reach to L2-anchor 521 "A2::1" so that the node pushes a SRH with SID list with SL=3. The node updates DA to service 523 function S1 which the SL indicates and forward the packet. 525 Second case is that the access point function directly 526 indicates the path beyond the L2-anchor, service function S2 527 and L3-anchor "A3::1" for example, the SID list shoud be with SL=5. 530 Layer-2 Anchor: 532 It is assumed that the packet successfully traversed S1 and C1 533 segments so that the SL was decremented 3 to 1 in the first 534 scenario, and 5 to 3 in the second scenario before arriving the 535 node of "A2::1" or "A2::" segment. 537 In the first scenario that the L2-anchor node of "A2::1" 538 segment is bound to a service policy which indicates path via 539 service function S2 and L3-anchor function A3::1, the node does 540 End.B6 process for the receiving packet to push a new SRH with 541 SID list with SL=1. The node updates DA to next 542 service function SID S2 which the SL indicates and forward the 543 packet. 545 In the second scenario that one SRH with SIDs , the L2-anchor node of "A2::" segment is bound 547 to just End function. The node does End process for the 548 receiving packet according to the SRH that decrements SL to 2, 549 updates DA to next service function SID S2 which the SL 550 indicates and forward the packet. 552 Layer-3 Anchor: 554 The L3-anchor node of "A3::1" segment does End.T process for 555 the receiving packet according to the SRH(s). 557 In the first scenario that outer SRH with SIDs , it 558 is assumed that the SL is decremented to 0 at service function 559 S2 so that the node pops outer SRH. Then the node processes 560 second SRH with SIDs that decrements SL 561 to 0, updates DA to D::1 which the SL indicates and lookup IPv6 562 table associated with "A3::1". In this case, the decremented 563 SL is 0 so that the node does PSP operation of popped out the 564 SRH from the packet and forward it. 566 In the second scenario that one SRH with SIDs , L3-anchor node of "A3::" segment does End.T 568 process for the receiving packet according to the SRH. Rest 569 part of processes are as same as previous case. 571 6.2.2. Downlink 573 In downlink, SRv6 node applies following SRv6 end point functions and 574 transit behavior. 576 Layer-3 Anchor: 578 When the L3-anchor node receives a packet destine to "S::1" 579 from a mobile node "D::1", it does T.Insert process for the 580 receiving packets. 582 First scenario is that the service policy for "S::1" is via 583 service function S2 before reach to L2-anchor "A2::2" so that 584 the node pushes a SRH with SID list with 585 SL=2. The node updates DA to service function S2 which the SL 586 indicates and forward the packet. 588 Second scenario is that the L3-anchor function directly 589 indicates the path beyond the L2-anchor, service function S1, 590 node C3 and access point "A1::" for example, the SID list shoud 591 be with SL=5. 593 Layer-2 Anchor: 595 It is assumed that the packet successfully traversed S2 segment 596 so that the SL was decremented 2 to 1 in the former case, and 5 597 to 4 in the latter case before arriving the node of "A2::2" or 598 "A2::" segment. 600 In the first scenario that the L2-anchor node of "A2::2" 601 segment is bound to a service policy which indicates path via 602 node C1, service function S1 and access point function A1::, 603 the node does End.B6 process for the receiving packet to push a 604 new SRH with SID list with SL=1. The node 605 updates DA to next service function SID C1 which the SL 606 indicates and forward the packet. 608 In the second scenario that one SRH with SIDs , the L2-anchor node of "A2::" segment is bound 610 to just End function. The node does End process for the 611 receiving packet according to the SRH that decrements SL to 2, 612 updates DA to next node C1 which the SL indicates and forward 613 the packet. 615 Access Point: 617 The access point node of "A1::1" segment does End process for 618 the receiving packet according to the SRH(s). 620 In the first scenario that outer SRH with SIDs , 621 it is assumed that the SL is decremented 2 to 0 at node C1 and 622 service function S1 so that the outer SRH is popped out by PSP 623 at S1. Thus the node processes second SRH with SIDs that decrements SL to 0, updates DA to S::1 which 625 the SL indicates and forward the packet to the mobile node 626 through radio channel associated with "S::1". In this case, 627 the decremented SL is 0 so that the node does PSP operation of 628 popped out the SRH from the packet and forward it. 630 In the second scenario that one SRH with SIDs , access node of "A1::1" segment does End 632 process for the receiving packet according to the SRH. Rest 633 part of processes are as same as previous case. 635 6.3. Stateless Interworking with Legacy Access Network 637 This section describes an use case where user-plane functions are 638 interworking in stateless between SRv6 and legacy access networks. 639 Here stateless means that there's no need to be aware any states of 640 mobility sessions in the node. 642 As some types of interworking scenarios could be considered, we will 643 describe other cases in the future versions of this document. 645 6.3.1. Uplink: Lagacy Access to SRv6 647 Legacy Access Point: 649 When a legacy access point node receives a packet destined to 650 "D::1" from a mobile node "S::1" through associated radio 651 channel, it does tunnel encapsulation with the tunneling 652 parameters, IPv4 DA, SA and tunnel header with ID, and sends 653 out the packet to the network. 655 Stateless Interworking: 657 The stateless interworking node of corresponding to the IPv4 DA 658 does T.Tmap process for the receiving packet to pop the tunnel 659 headers and push a SRH to the packet. The SRH consists of SIDs 660 with SL=1, where "B1" encodes IW-IPv6-Prefix, tunnel 661 IPv4 DA, SA and TUN-ID in it as Figure 3 defined. The 662 stateless interworking node updates DA to "B1" and forward the 663 packet. SA of the packet must be kept as "S::1". 665 Layer-2 or Layer-3 Anchor: 667 The receiving node of the packet destine to B1 either be 668 Layer-2 anchor, or Layer-3 anchor node. Which type of anchor 669 function bound to B1 depends on operational policy. 671 In case of B1 to an L2-anchor node, the L2-anchor node does 672 End.B6 process for the receiving packet as same as previous 673 section. 675 In case of B1 to an L3-anchor node, the L3-anchor node does 676 End.T process for the receiving packet as same as previous 677 section. 679 6.3.2. Downlink: SRv6 to Legacy Access 681 Layer-2 or Layer-3 Anchor: 683 In case of an L3-anchor node receives a packet destine to S::1 684 from the correspondent node "D::1", and stateless interworking 685 SID is bound to the next segment of S::1 , the L3-anchor node 686 does T.Insert process for the receiving packet to push a SRH 687 with SID list with SL=1, where "B2" which encodes 688 IW-IPv6-Prefix, tunnel IPv4 DA, SA and TUN-ID in it as Figure 3 689 defined. The L3-anchor node updates DA to "B2" and forward the 690 packet. 692 In case of an L2-anchor node receives a packet destine to SID 693 "A2::B2" and the SID is bound to "B2", the L2-anchor node does 694 End.B6 process for the receiving packet as same as previous 695 section. The node updates DA to B2 and forward the packet. 697 Stateless Interworking: 699 The stateless interworking node of "B2" End.TM process for the 700 receiving packet according to the SRH. The node decrement SL 701 to 0, updates DA to "D::1" which the SL indicates, push IPv4 702 and tunnel headers with IPv4 DA, SA and TUN-ID extracted from 703 "B2", and forward the packet to the legacy network. 705 In this use case, decremented SL is 0 so that the node does PSP 706 operation of popped out the SRH from the packet and forward it. 708 Legacy Access Point: 710 The legacy access point node of the IPv4 DA does tunnel 711 termination process for the receiving packet according to the 712 tunnel header. The node pop the IPv4 and tunnel header and 713 forward the packet to the mobile node through radio channel 714 associated with the tunnel. 716 7. Network Slicing Considerations 718 Mobile network may be required to create a network slicing that 719 represent a set of network resources and isolate those resource from 720 other slices. User-plane functions represented as SRv6 segments 721 would be part of a slice. 723 To represent a set of user-plane function segments for a slice, 724 sharing same prefix through those SIDs within the slice could be a 725 straightforward way. SIDs in a network slice may include other type 726 of functions in addition to the mobile user-plane functions described 727 in this document, and underlay integration to meet SLA and quality 728 requirements. 730 While network slicing has been discussed in the IETF and other 731 standardization bodies, what functionalities are required for network 732 slicing in mobile user-plane is further study item and to be 733 discussed. 735 8. Control Plane Considerations 737 8.1. Existing Control Plane 739 A mobile control-plane entity may allocate SIDs to the node of 740 corresponding user-plane function. In this case, the control-plane 741 entity must signal allocated SIDs to other side of entity. 743 If the control-plane entity needs to employ existing mobile control- 744 plane protocol to signal, GTP-C or PMIP for example, it must require 745 not to impact the control-plane protocols. In this case, tunnel 746 endpoint IPv6 address field in the control-plane message can be used 747 to signal a SID. 749 The basic mode described in Section 6.1 should be adopted. In the 750 basic mode, SID indicates unique session so that tunnel identifier is 751 not required to SRv6 user-plane. But the mobile control-plane may be 752 assumed that one user-plane entity has one IPv6 address and it 753 allocates tunnel identifier per session. In this case, SRv6 node of 754 user-plane can form SID with the IPv6 address and the tunnel 755 identifier. 757 When an IPv6 prefix "A::/64" is allocated to an user-plane, and the 758 control-plane allocate one 32bits tunnel identifier of "0x12345678" 759 for a mobile session, the user-plane node forms a 128bits SID 760 "A::1234:5678". 762 In this way, there is no impact to the control-plane. 764 8.2. Aggregate Mode 766 To support aggregate mode described in Section 6.2 in control-plane 767 protocol, allocated SIDs for service policies can be signaled as 768 tunnel endpoint IPv6 address too. In this case, SRv6 policy 769 associated to the SID should be configured in the user-plane node 770 through other means. 772 Aggregate mode user-plane can take advantage of SRv6 that enables 773 seamless mobile user-plane deployment with service chaining, VPNs, 774 traffic-engineering by computed path to fulfil the policy. 776 In case of a mobile control-plane is aware those policies and is 777 capable to advertise them, the mobile control-plane can integrate 778 SRv6 advanced features. 780 8.3. User-Plane Sepalated Control Plane 782 In an user-plane separated control-plane system, a mobile user-plane 783 entity may allocate SIDs to an user-plane function instead of the 784 control-plane. In this case, the user-plane entity should inform 785 allocated SIDs back to the control-plane entity. 787 If the control- and user-plane entities need to employ existing user- 788 plane control protocol in between, such as PFCP for example, it may 789 be required not to impact that protocol. In this case, the control- 790 plane entity is only allowed to signal SID in a tunnel endpoint IPv6 791 address field. 793 8.4. Centralized Controller 795 When a centralized controller interfaces to mobile control-planes is 796 capable to allocate SIDs to the controlling SRv6 nodes, the mobile 797 control-planes just need to indicate nodes and their user-plane 798 functions to the controller. In this case, the controller must 799 allocate appropriate SIDs for the user-plane functions to the SRv6 800 nodes. The controller must configure allocated SIDs to the nodes. 802 To indicate nodes and their user-plane functions from mobile control- 803 plane to user-plane, the centralized controller could take advantage 804 of [I-D.ietf-dmm-fpc-cpdp]. It provides interface to the control- 805 plane to manage the user-plane of mobile networks. To build 806 centralized controller for mobile user-plane is out of scope of this 807 document. 809 8.5. Stateless Interworking 811 A mobile control-plane is not required to configure statless 812 interworking function in interworking node. This benefits operators 813 to gradually migrate from legacy to advanced mobile user-plane with 814 no impact to the legacy system. 816 SID allocating entity of SRv6 user-plane nodes needs to be aware of 817 IW-IPv6-Prefix to form interworking SID. Legacy user-plane network 818 allocate IPv4 address space routed to SRv6 user-plane network. The 819 mobile control-plane of legacy user-plane also need to allocate 820 tunnel endpoint IPv4 addresses from that address space for mobile 821 sessions which is usual operation for it and no difference from 822 legacy system. 824 9. Security Considerations 826 TBD 828 10. IANA Considerations 830 This document has no actions for IANA. 832 11. Acknowledgements 834 TBD 836 12. References 838 12.1. Normative References 840 [I-D.filsfils-spring-srv6-network-programming] 841 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 842 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 843 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 844 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 845 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 846 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 847 Camarillo, "SRv6 Network Programming", draft-filsfils- 848 spring-srv6-network-programming-02 (work in progress), 849 October 2017. 851 [I-D.ietf-spring-segment-routing] 852 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 853 Litkowski, S., and R. Shakir, "Segment Routing 854 Architecture", draft-ietf-spring-segment-routing-13 (work 855 in progress), October 2017. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, 859 DOI 10.17487/RFC2119, March 1997, . 862 12.2. Informative References 864 [I-D.ietf-dmm-fpc-cpdp] 865 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 866 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 867 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09 868 (work in progress), October 2017. 870 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 871 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 872 RFC 5213, DOI 10.17487/RFC5213, August 2008, 873 . 875 [TS.29281] 876 3GPP, , "General Packet Radio System (GPRS) Tunnelling 877 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 878 September 2011. 880 Authors' Addresses 882 Satoru Matsushima 883 SoftBank 884 Tokyo 885 Japan 887 Email: satoru.matsushima@g.softbank.co.jp 889 Clarence Filsfils 890 Cisco Systems, Inc. 891 Belgium 893 Email: cf@cisco.com 894 Miya Kohno 895 Cisco Systems, Inc. 896 Japan 898 Email: mkohno@cisco.com 900 Daniel Voyer 901 Bell Canada 902 Canada 904 Email: daniel.voyer@bell.ca 906 Charles E. Perkins 907 Futurewei Inc. 908 2330 Central Expressway 909 Santa Clara, CA 95050 910 USA 912 Phone: +1-408-330-4586 913 Email: charliep@computer.org