idnits 2.17.00 (12 Aug 2021) /tmp/idnits62380/draft-zpm-dmm-mup-bgp-signaling-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...N. The IP prefix MAY include a gNodeB...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 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: 'I-D.mpmz-dmm-mup-safi' is mentioned on line 283, but not defined == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-srv6-services' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC4363' is defined on line 349, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-18 == Outdated reference: A later version (-03) exists of draft-mhkk-dmm-srv6mup-architecture-02 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-12 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dmm Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track K. Patel 5 Expires: 8 September 2022 Arrcus 6 S. Matsushima 7 Softbank 8 7 March 2022 10 BGP Signaling for Mobile User Plane 11 draft-zpm-dmm-mup-bgp-signaling-00 13 Abstract 15 This document specifies BGP signaling for router-based 5G User Plane 16 using Mobile User Plane SAFI and some of its route types as specified 17 in [draft-mpmz-idr-mup-safi]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 8 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Analysis of SRv6 specific aspects of 55 [I-D.mpmz-dmm-mup-safi] . . . . . . . . . . . . . . . . . 3 56 2.1. BGP Discovery Direct Route . . . . . . . . . . . . . . . 3 57 2.2. BGP Discovery Interwork Route . . . . . . . . . . . . . . 3 58 3. Optional Type 3 Session Transform (ST3) Route . . . . . . . . 4 59 4. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. BGP Encodings . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1.1. GTP PW Label Extended Community . . . . . . . . . . . 5 62 4.1.2. Type 3 Session Transform (ST3) route . . . . . . . . 5 63 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Background 73 5G [_3GPP-23.501] User Plane uses N4 signaling between Session 74 Management Function (SMF) and User Plane Function (UPF), and N2 75 signaling between Access & Mobility Management Function (AMF) and 76 Access Nodes (AN). A traditional UPF device is typically centrally 77 deployed and uses GTP tunnels between itself and ANs for data traffic 78 to/from User Equipment (UEs). The GTP tunnels are set up by the N4 79 and N2 signaling, and the forwarding model on a UPF is quite 80 different from that on a typical router. 82 UPFs can also be deployed in distributed fashion and still provide 83 persistent IP address for UEs if needed, as described in 84 [I-D.zzhang-dmm-5g-distributed-upf]. 86 Some operators may desire to deploy UPFs that are implemented more 87 like a router with BGP instead of N4 signaling. GTP tunneling can 88 still be used or it can be partially replaced by SRv6/MPLS tunneling. 89 It does not require any change to the 3GPP architecture, signaling 90 and deployment model, but a controller is used to convert N4 91 signaling to BGP, as described in [I-D.mhkk-dmm-srv6mup-architecture] 92 and [I-D.mpmz-dmm-mup-safi]. 94 The above two drafts are both SRv6 specific. However, BGP signaling 95 from the controller based on N4 signaling can be done without being 96 SRv6 or even SR specific at all. This document specifies 97 corresponding BGP signaling and procedures for both central and 98 distributed deployment models with integration with wireline VPN 99 services as described in [I-D.zzhang-dmm-5g-distributed-upf], 100 [I-D.mhkk-dmm-srv6mup-architecture], and [I-D.mpmz-dmm-mup-safi]. 102 1.1. Terminologies 104 Terminologies of 5G, or those used in [I-D.mpmz-dmm-mup-safi] and 105 [I-D.mhkk-dmm-srv6mup-architecture] are omitted here for now. It is 106 expected that audience of this document are familiar with them or can 107 refer to the relevant documents. 109 2. Analysis of SRv6 specific aspects of [I-D.mpmz-dmm-mup-safi] 111 The goal of this document is to specify encoding and procedures that 112 work for both MPLS, SR-MPLS as well as SRv6. Therefore, we first 113 look at the SRv6 specific aspects of [I-D.mpmz-dmm-mup-safi]. 115 2.1. BGP Discovery Direct Route 117 Per [I-D.mpmz-dmm-mup-safi]: 119 "The Discovery Direct route is generated by the MUP PE when a routing 120 instance accommodates a Direct type MUP Segment, e.g., N6 interface or 121 routes on DN side in 3GPP 5G specific case. It generates the 122 Discovery Direct Route per each routing instance for the MUP Segment." 124 When a MUP GW receives a BGP Type 2 Session Transform (ST2) Route, 125 which advertises the association of PDU Session TEID (on the UPF 126 side) and a DN VPN, a corresponding Direct Route is matched to set up 127 forwarding state on the GW so that it can decapsulate incoming GTP 128 packets from gNB/AN and then send to the advertising MUP PE of the 129 Direct Route using the Prefix SID in the Direct Route. The Prefix 130 SID has an End.DT2/4/6 or End.DX2/4/6 behavior. 132 In the non-SR case (and SR-MPLS or SRv6 as well), this route can be 133 replaced by the "VPN-IP default route" in [RFC7024]. The VRF table 134 label in the route is used to send traffic by the GW to the MUP PE 135 after GTP decapsulation. 137 2.2. BGP Discovery Interwork Route 139 Per [I-D.mpmz-dmm-mup-safi]: 141 "The Discovery Interwork route is generated by the MUP GW when a 142 routing instance accommodates an Interwork type MUP Segment, e.g., N3 143 interfaces or routes on RAN side in 3GPP 5G specific case. It 144 generates route per each N3RAN IP prefix and stores the route in the 145 routing instance of N3RAN. The IP prefix MAY include a gNodeB 146 address which is connecting to the MUP GW." 148 Basically, it is a route for a gNB/AN address in the N3RAN. These 149 routes are put into N3RAN RIB. When a MUP PE receives a BGP Type 1 150 Session Transform (ST1) route, the Endpoint Address in the ST1 NLRI 151 is resolved in the N3RAN RIB, and the Prefix SRv6 SID associated with 152 the Interwork Route, which has the End.GTP4/6.E behavior on the GW, 153 is used send DownLink (DL) traffic from the MUP PE towards the gNB/AN 154 via the GW. 156 In the non-SR case (and SR-MPLS or SRv6 as well), this route can 157 simply be replaced with a regular host route for the gNB/AN. In case 158 of MPLS or SR-MPLS, an "IP/UDP Payload PseudoWire" 159 [I-D.zzhang-pals-pw-for-ip-udp-payload] label for GTP is encoded in 160 an Extended Community so that the MUP PE can use it to send DL 161 traffic with GTP encapsulation but w/o IP/UDP header to the GW, who 162 will add the IP/UDP header and send the resulting GTP packet to the 163 gNB/AN. 165 The PW label is encoded in an EC because only the DL traffic should 166 use the PW label and other traffic towards the gNB/AN should not. 168 In case of SRv6, the same Prefix SID that would be attached to the 169 Interwork Segment route can be attached to the regular gNB/AN host 170 route that replaces the Interwork Segment route. 172 3. Optional Type 3 Session Transform (ST3) Route 174 In [I-D.mpmz-dmm-mup-safi], the ST1 route only has the TEID and 175 endpoint address for the gNB/AN side for DL traffic. For UpLink (UL) 176 traffic, the ST2 route has the TEID prefix and endpoint address for 177 the UPF side, so that the GW can determine which DN the traffic 178 belongs to. 180 It is quite possible that the TEID assigned by the SMF are per- 181 session and do not fall into prefix ranges nicely. Unless the MUP 182 controller intelligently aggregate individual per-session ST2 routes, 183 a MUP GW that also acts as a MUP PE will receive individual per- 184 session ST1 and ST2 routes. For that reason, an optional ST3 route 185 is introduced to combine ST1 and ST2 routes. 187 4. Specifications 188 4.1. BGP Encodings 190 A Type 3 Session Transform (ST3) route, and a GTP PW Label Extended 191 Community are specified in this section. 193 4.1.1. GTP PW Label Extended Community 195 The GTP PW Label Extended Community is a BGP MUP Extended Community 196 of sub-type "GTP PW Label" (value to be assigned by IANA). 198 The encoding is as following: 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type=MUP EC | Sub-Type=TBD | Reserved=0 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Reserved=0 | GTP PW Label | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 4.1.2. Type 3 Session Transform (ST3) route 209 A new Route Type for BGP-MUP NLRI is added: 211 + 5 - Type 3 Session Transform (ST3) route; 213 It is similar to the ST1 route: 215 +-----------------------------------+ 216 | RD (8 octets) | 217 +-----------------------------------+ 218 | Prefix Length (1 octet) | 219 +-----------------------------------+ 220 | Prefix (variable) | 221 +-----------------------------------+ 222 | Architecture specific (variable) | 223 +-----------------------------------+ 225 For 3gpp-5g, the Architecture Specific part of the NLRI encodes the 226 parameters of the 227 session that the route is for: 229 +-----------------------------------+ 230 | QFI (1 octet) | 231 +-----------------------------------+ 232 | AN TEID (4 octets) | 233 +-----------------------------------+ 234 | AN Address Length (1 octet) | 235 +-----------------------------------+ 236 | AN Address (variable) | 237 +-----------------------------------+ 238 | UPF TEID (4 octets) | 239 +-----------------------------------+ 240 | UPF Address Length (1 octet) | 241 +-----------------------------------+ 242 | UPF Address (variable) | 243 +-----------------------------------+ 245 The route is a combination of ST1 and ST2 routes, in that: 247 * The QFI, AN TEID, and AN Address information correspond to the 248 fields in the 3gpp-5g ST1 Route Type specific BGP-MUP NLRI: 250 +-----------------------------------+ 251 | TEID (4 octets) | 252 +-----------------------------------+ 253 | QFI (1 octet) | 254 +-----------------------------------+ 255 | Endpoint Address Length (1 octet) | 256 +-----------------------------------+ 257 | Endpoint Address (variable) | 258 +-----------------------------------+ 260 * The UPF Address info corresponds to the Endpoint fields in ST2 261 route: 263 +-----------------------------------+ 264 | RD (8 octets) | 265 +-----------------------------------+ 266 | Endpoint Length (1 octet) | <--- 267 +-----------------------------------+ 268 | Endpoint Address (variable) | <--- 269 +-----------------------------------+ 270 | Architecture specific Endpoint | 271 | Identifier (variable) | 272 +-----------------------------------+ 274 * The UPF TEID field corresponds to the TEID in the 3gpp-5g ST2 275 Route Type specific BGP-MUP NLRI: 277 +-----------------------------------+ 278 | TEID (0-4 octets) | 279 +-----------------------------------+ 281 4.2. Procedures 283 The procedures are inline with those in [I-D.mpmz-dmm-mup-safi] and 284 [I-D.mhkk-dmm-srv6mup-architecture]. 286 Details will be added a future revision. 288 5. Security Considerations 290 To be provided. 292 6. IANA Considerations 294 Requests to be made for the BGP encodings in Section 4.1. Details 295 will be added in a future revision. 297 7. References 299 7.1. Normative References 301 [I-D.ietf-dmm-srv6-mobile-uplane] 302 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 303 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 304 Mobile User Plane", Work in Progress, Internet-Draft, 305 draft-ietf-dmm-srv6-mobile-uplane-18, 18 February 2022, 306 . 309 [I-D.mhkk-dmm-srv6mup-architecture] 310 Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., 311 Murakami, T., Patel, K., Kohno, M., Kamata, T., Garvia, P. 312 C., Voyer, D., Zadok, S., Meilik, I., Agrawal, A., 313 Perumal, K., and J. Horn, "Segment Routing IPv6 Mobile 314 User Plane Architecture for Distributed Mobility 315 Management", Work in Progress, Internet-Draft, draft-mhkk- 316 dmm-srv6mup-architecture-02, 7 March 2022, 317 . 320 [I-D.zzhang-pals-pw-for-ip-udp-payload] 321 Zhang, Z. and K. Patel, "PW for IP/UDP Payload without IP/ 322 UDP Headers", Work in Progress, Internet-Draft, draft- 323 zzhang-pals-pw-for-ip-udp-payload-01, 4 March 2022, 324 . 327 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 328 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 329 VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, 330 . 332 7.2. Informative References 334 [I-D.ietf-bess-srv6-services] 335 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 336 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 337 Overlay Services", Work in Progress, Internet-Draft, 338 draft-ietf-bess-srv6-services-12, 5 March 2022, 339 . 342 [I-D.zzhang-dmm-5g-distributed-upf] 343 Zhang, Z., Patel, K., and T. Jiang, "5G Distributed UPFs", 344 Work in Progress, Internet-Draft, draft-zzhang-dmm-5g- 345 distributed-upf-00, 6 March 2022, 346 . 349 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed 350 Objects for Bridges with Traffic Classes, Multicast 351 Filtering, and Virtual LAN Extensions", RFC 4363, 352 DOI 10.17487/RFC4363, January 2006, 353 . 355 [_3GPP-23.501] 356 "System architecture for the 5G System (5GS), V17.3.0", 357 December 2021. 359 Authors' Addresses 361 Zhaohui Zhang 362 Juniper Networks 363 Email: zzhang@juniper.net 365 Keyur Patel 366 Arrcus 367 Email: keyur@arrcus.com 369 Satoru Matsushima 370 Softbank 371 Email: satoru.matsushima@g.softbank.co.jp