| < draft-mhkk-dmm-srv6mup-architecture-02.txt | draft-mhkk-dmm-srv6mup-architecture-03.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force S. Matsushima | Internet Engineering Task Force S. Matsushima | |||
| Internet-Draft K. Horiba | Internet-Draft K. Horiba | |||
| Intended status: Standards Track A. Khan | Intended status: Standards Track A. Khan | |||
| Expires: 8 September 2022 Y. Kawakami | Expires: 20 September 2022 Y. Kawakami | |||
| SoftBank | SoftBank | |||
| T. Murakami | T. Murakami | |||
| K. Patel | K. Patel | |||
| Arrcus, Inc | Arrcus, Inc | |||
| M. Kohno | M. Kohno | |||
| T. Kamata | T. Kamata | |||
| P. Camarillo | P. Camarillo | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| D. Voyer | D. Voyer | |||
| Bell Canada | Bell Canada | |||
| S. Zadok | S. Zadok | |||
| I. Meilik | I. Meilik | |||
| Broadcom | Broadcom | |||
| A. Agrawal | A. Agrawal | |||
| K. Perumal | K. Perumal | |||
| Intel | Intel | |||
| J. Horn | J. Horn | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| 7 March 2022 | 19 March 2022 | |||
| Segment Routing IPv6 Mobile User Plane Architecture for Distributed | Segment Routing IPv6 Mobile User Plane Architecture for Distributed | |||
| Mobility Management | Mobility Management | |||
| draft-mhkk-dmm-srv6mup-architecture-02 | draft-mhkk-dmm-srv6mup-architecture-03 | |||
| Abstract | Abstract | |||
| This document defines the Segment Routing IPv6 Mobile User Plane | This document defines the Segment Routing IPv6 Mobile User Plane | |||
| (SRv6 MUP) architecture for Distributed Mobility Management. The | (SRv6 MUP) architecture for Distributed Mobility Management. The | |||
| requirements for Distributed Mobility Management described in | requirements for Distributed Mobility Management described in | |||
| [RFC7333] can be satisfied by routing fashion. | [RFC7333] can be satisfied by routing fashion. | |||
| Mobile services are deployed over several parts of IP networks. A | Mobile services are deployed over several parts of IP networks. A | |||
| Segment Routing over IPv6 (SRv6) network can accommodate all, or part | Segment Routing over IPv6 (SRv6) network can accommodate all, or part | |||
| skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
| 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 8 September 2022. | This Internet-Draft will expire on 20 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 44 ¶ | skipping to change at page 2, line 44 ¶ | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 | 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 6 | 4. Mobile User Plane Segment . . . . . . . . . . . . . . . . . . 6 | |||
| 5. Distribution of Mobile User Plane Segment Information . . . . 7 | 5. Distribution of Mobile User Plane Segment Information . . . . 7 | |||
| 5.1. MUP PE . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 5.1. Direct Segment Discovery Route . . . . . . . . . . . . . 7 | |||
| 5.2. MUP GW . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.2. Interwork Segment Discovery Route . . . . . . . . . . . . 8 | |||
| 6. MUP Controller . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. Distribution of Session Transformed Route . . . . . . . . . . 8 | |||
| 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Type 1 Session Transformed Route . . . . . . . . . . . . 9 | |||
| 6.2. Type 2 Session Transformed Route . . . . . . . . . . . . 9 | ||||
| 6.3. MUP Controller . . . . . . . . . . . . . . . . . . . . . 9 | ||||
| 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 16 | 10.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 1. Introduction | 1. Introduction | |||
| Mobile services require IP connectivity for communication between the | Mobile services require IP connectivity for communication between the | |||
| entities of mobile service architecture [RFC5213][TS.23501]. To | entities of mobile service architecture [RFC5213][TS.23501]. To | |||
| provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a | provide the IP connectivity, Segment Routing (SR) [RFC8402]can be a | |||
| candidate solution. | candidate solution. | |||
| In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be | In PMIPv6 [RFC5213], IP connectivity between LMA and MAG can be | |||
| skipping to change at page 5, line 22 ¶ | skipping to change at page 5, line 26 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| 2. Terminology | 2. Terminology | |||
| MUP: Mobile User Plane | MUP: Mobile User Plane | |||
| MUP Segment: Representation of mobile user plane segment | MUP Segment: Representation of mobile user plane segment | |||
| MUP PE: Provider Edge node in a MUP network | PE: Provider Edge node in an SR network | |||
| MUP GW: Gateway node to interwork with another mobile user plane | ||||
| networks | ||||
| MUP Controller: Controller node for a MUP network | MUP Controller: Controller node for an SR network | |||
| UE: User Equipment, as per [TS.23501] | UE: User Equipment, as per [TS.23501] | |||
| MN: Mobile Node, as per [RFC5213] | MN: Mobile Node, as per [RFC5213] | |||
| 3. Architecture Overview | 3. Architecture Overview | |||
| SRv6 MUP architecture defined in this document introduces a new | SRv6 MUP architecture defined in this document introduces new segment | |||
| segment type of the SR called "Mobile User Plane (MUP) segment" and | types of MUP segment called "Direct segment", and "Interwork | |||
| new routing information called "Segment Discovery route" and "Session | Segment". An SR node of PE accommodates an Interwork Segment and/or | |||
| Transformed route", then 3 new network nodes; MUP PE, MUP GW and MUP | a Direct Segment. Figure 1 depicts the overview. | |||
| Controller. Figure 1 depicts the overview. | ||||
| To carry these new routing information, this architecture requires | * Mobility * | |||
| extending the existing routing protocols. Any routing protocol can | * Management * | |||
| be used to carry this information but this document recommends using | * System * | |||
| BGP. Thus, this document describes extensions on BGP as an example. | *........* | |||
| | | ||||
| Session Information | ||||
| | | ||||
| ______________v______________ | ||||
| _______ / |MUP-C| \ _______ | ||||
| / \ / +-----+ \ / \ | ||||
| /Interwork\__ | | __/ Direct \ | ||||
| \ Segment / \ |----+ +----| / \ Segment / | ||||
| \_______/ \| PE | SRv6 | PE |/ \_______/ | ||||
| _______ /|----+ Network +----|\ _______ | ||||
| / \ / | | \ / \ | ||||
| / Direct \_/ \ / \_/Interwork\ | ||||
| \ Segment / \____________________________/ \ Segment / | ||||
| \_______/ \_______/ | ||||
| * Mobility * | Figure 1: Overview of SRv6 MUP Architecture | |||
| * Management * | ||||
| * System * | ||||
| *........* | ||||
| | | ||||
| Session Information | ||||
| | | ||||
| v | ||||
| +----------------+ | ||||
| --| MUP Controller |-- ___________ | ||||
| / +----------------+ \ / \ | ||||
| ___________ / _______ +--------+ / \ | ||||
| / \ / / \---| MUP PE |---\ MUP Segment / | ||||
| / \ +--------+ / \ +--------+ \___________/ | ||||
| \ MUP Segment /--| MUP GW |--\ SRv6 NW / +--------+ ___________ | ||||
| \___________/ +--------+ \_______/---| MUP PE |----/ \ | ||||
| +--------+ / \ | ||||
| \ MUP Segment / | ||||
| \___________/ | ||||
| Figure 1: Overview of SRv6 MUP Architecture | This document also defines new routing information called "Segment | |||
| Discovery route" and "Session Transformed route". To carry these new | ||||
| routing information, this architecture requires extending the | ||||
| existing routing protocols. Any routing protocol can be used to | ||||
| carry this information but this document recommends using BGP. Thus, | ||||
| this document describes extensions on BGP as an example. | ||||
| 4. Mobile User Plane Segment | 4. Mobile User Plane Segment | |||
| This document defines one new segment type. A Mobile User Plane | This document defines two new types of Mobile User Plane (MUP) | |||
| (MUP) segment may represent a network segment consisting of a mobile | segment. A MUP segment represents a network segment consisting of a | |||
| service. The MUP segment can be created by an SR node which provides | mobile service. The MUP segment can be created by a PE which | |||
| connectivity for the mobile user plane. The MUP segment SID can be | provides connectivity for the mobile user plane. | |||
| any behavior defined in [RFC8986], [I-D.ietf-dmm-srv6-mobile-uplane], | ||||
| or any other extensions for further use cases. | ||||
| The behavior of the MUP segment will be chosen by the role of the | Direct Segment is a type of MUP segment that provides connectivity | |||
| representing mobile network segment. For example, in case of an SR | between MUP segments through the SRv6 network. Interwork Segment is | |||
| node interfaces to 5G user plane on the access side defined as "N3" | another type of MUP segment. It provides connectivity between a user | |||
| in [TS.23501], the behavior of created segment SID will be | plane protocol of existing or future mobile service architecture and | |||
| "End.M.GTP4.E", or "End.M.GTP6.E". In this case, the SR node may | other MUP segments through the SRv6 networks. | |||
| associate the SID to a N3 access network (N3RAN) routing instance. | ||||
| Another example here is the "N6" interface on the core data network | An SRv6 SID (Segment Identifier) can represents a MUP segment. The | |||
| side. The behavior of the created segment SID will be "End.DT4", | SID can be any behavior defined in [RFC8986], | |||
| "End.DT6", or "End.DT2". In this case the SR node may associate the | [I-D.ietf-dmm-srv6-mobile-uplane], or any other extensions for | |||
| SID to a N6 data network (N6DN) routing instance. | further use cases. The behavior of the MUP segment will be chosen by | |||
| the role of the representing MUP segment. | ||||
| For example, in case of a PE interfaces to 5G user plane on the | ||||
| access side defined as "N3" in [TS.23501], the PE accommodates the N3 | ||||
| network as Interwork Segment in a routing instance and then the | ||||
| behavior of created segment SID by the PE will be "End.M.GTP4.E", or | ||||
| "End.M.GTP6.E". In this case, the PE may associate the SID to the | ||||
| routing instance for the N3 access network (N3RAN). | ||||
| Another example here is that a PE interfaces to 5G DN on the core | ||||
| side defined as "N6" in [TS.23501], the PE accommodates the N6 | ||||
| network in a routing instance as Direct Segment and then the behavior | ||||
| of the created segment SID by the PE will be "End.DT4", "End.DT6", or | ||||
| "End.DT2". In this case, the PE may associate the SID to the routing | ||||
| instance for the N6 data network (N6DN). | ||||
| 5. Distribution of Mobile User Plane Segment Information | 5. Distribution of Mobile User Plane Segment Information | |||
| Distribution of MUP segment information can be done by advertising | Distribution of MUP segment information can be done by advertising | |||
| routing information with the MUP segment for mobile service. This | routing information with the MUP segment for mobile service. A PE | |||
| document defines two types of SR node, MUP PE and MUP GW, for | distributes MUP segment information when a MUP segment is connected | |||
| distributing MUP segment information. | to the PE. | |||
| A MUP Segment Discovery route is routing information, of which a MUP | A MUP Segment Discovery route is routing information that associates | |||
| segment is associated with network reachability. This document | the MUP segment with network reachability. This document defines the | |||
| defines the basic discovery route types, Direct Segment Discovery | basic discovery route types, Direct Segment Discovery route, and | |||
| route, and Interwork Segment Discovery route. Other types of segment | Interwork Segment Discovery route. Other types of segment discovery | |||
| discovery route may be mobile service architecture specific. Define | route may be mobile service architecture specific. Defining the | |||
| the architecture specific network reachability is out of scope of | architecture specific network reachability is out of scope of this | |||
| this document and it will be specified in another document. | document and it will be specified in another document. | |||
| 5.1. MUP PE | 5.1. Direct Segment Discovery Route | |||
| A MUP PE accommodates a MUP Segment to a routing instance for MUP | When a PE accommodates a network through an interface or a routing | |||
| Direct Segment. The MUP PE advertises the Direct Segment Discovery | instance as a Direct Segment, the PE advertises the corresponding | |||
| route for the routing instance. The Direct Segment Discovery route | Direct Segment Discovery route for the interface or the routing | |||
| includes an address of the MUP PE in the network reachability | instance. The Direct Segment Discovery route includes an address of | |||
| information with the corresponding Direct Segment indicating | the PE in the network reachability information with an extended | |||
| community, and SID of the routing instance to the SR domain. | community indicating the corresponding Direct Segment, and SID of the | |||
| routing instance to the SR domain. | ||||
| For example in 3GPP 5G specific case, an MUP PE may connect to N6 | For example in 3GPP 5G specific case, an PE may connect to N6 | |||
| interface on a DN side, an MUP Segment Discovery route for the DN | interface on a DN side, an MUP Segment Discovery route for the DN | |||
| will be advertised with an address of the MUP PE, corresponding SID | will be advertised with an address of the PE, corresponding SID and | |||
| and Direct Segment indicating community to the routing instance for | Direct Segment extended community to the routing instance for the DN | |||
| the DN from the MUP PE. | from the PE. | |||
| When a MUP PE receives a Interwork Segment Discovery route, the MUP | When a PE receives a Direct Segment Discovery route from other PEs, | |||
| PE keeps the received Interwork Segment Discovery routes in the RIB. | the PE keeps the received Direct Segment Discovery route in the RIB. | |||
| The MUP PE uses the received Interwork Segment Discovery routes to | The PE uses the received Direct Segment Discovery route to resolve | |||
| resolve the reachability for remote endpoint of Type 1 session | Type 2 session transformed routes reachability, described in | |||
| transformed routes, described in Section 6. If the Interwork Segment | Section 6.2. If the Direct Segment Discovery route resolves | |||
| Discovery route resolves the reachability for Type 1 session | reachability for the endpoints, and match the Direct Segment extended | |||
| transformed routes, the MUP PE updates the FIB entry for the prefix | community of the Type 2 session transformed routes, the PE updates | |||
| of Type 1 session transformed route with the SID of the matched MUP | the FIB entry for the Type 2 session transformed route with the SID | |||
| segment discovery route. | of the matched Direct Segment Discovery route. | |||
| 5.2. Interwork Segment Discovery Route | ||||
| When a PE accommodates a network through an interface or a routing | ||||
| instance for the user plane protocol of the mobile service | ||||
| architecture as an Interwork Segment, the PE advertises the | ||||
| corresponding Interwork Segment Discovery route with the prefixes of | ||||
| the Interwork Segment and the corresponding SID of the prefixes to | ||||
| the SR domain. | ||||
| For example in 3GPP 5G specific case, an Interwork Segment Discovery | ||||
| route for N3 network accommodating RAN will be incorporated in an | ||||
| N3RAN segment discovery route associated with a RAN segment SID. | ||||
| When a PE receives a Interwork Segment Discovery route, the PE keeps | ||||
| the received Interwork Segment Discovery routes in the RIB. The PE | ||||
| uses the received Interwork Segment Discovery routes to resolve the | ||||
| reachability for remote endpoint of Type 1 session transformed | ||||
| routes, described in Section 6.1. If the Interwork Segment Discovery | ||||
| route resolves the reachability for Type 1 session transformed | ||||
| routes, the PE updates the FIB entry for the prefix of Type 1 session | ||||
| transformed route with the SID of the matched MUP segment discovery | ||||
| route. | ||||
| The received Interwork Segment Discovery routes MUST be used only to | The received Interwork Segment Discovery routes MUST be used only to | |||
| resolve reachability for the remote endpoints of Type 1 session | resolve reachability for the remote endpoints of Type 1 session | |||
| transformed routes. The connectivity among the routing instances for | transformed routes. The connectivity among the routing instances for | |||
| Interwork Segments may be advertised as VPN routes. This is to avoid | Interwork Segments may be advertised as VPN routes. This is to avoid | |||
| forwarding entries to the prefixes of Interwork Segment mingled in | forwarding entries to the prefixes of Interwork Segment mingled in | |||
| the other type of routing instance. A SR node MAY discard the | the other type of routing instance. A PE may discard the received | |||
| received Interwork segment discovery route if the Route Target | Interwork segment discovery route if the Route Target extended | |||
| extended communities of the route does not meet the SR node's import | communities of the route does not meet the PE's import policy. | |||
| poilicy. | ||||
| 5.2. MUP GW | 6. Distribution of Session Transformed Route | |||
| A MUP GW interfaces an Interwork Segment with the user plane protocol | SRv6 MUP architecture defines two types of session transformed route. | |||
| for the existing mobile service architecture. The MUP GW | ||||
| accommodates the Interwork Segment to a routing instance for the | 6.1. Type 1 Session Transformed Route | |||
| existing mobile service architecture. The MUP GW advertises the | ||||
| corresponding Interwork Segment Discovery route with the prefixes of | First type route, called Type 1 Session Transformed route, encodes IP | |||
| the Interwork Segment and the corresponding SID of the prefixes to | prefix(es) for a UE or MN in a BGP MP-NLRI attribute with associated | |||
| session information of the tunnel endpoint identifier on the access | ||||
| side. The MUP controller advertises the Type 1 Session Transformed | ||||
| route with the Route Target extended communities for the UE or MN to | ||||
| the SR domain. | the SR domain. | |||
| For example in 3GPP 5G specific case, an Interwork Segment Discovery | A PE may receive the Type 1 Session Transformed routes from the MUP | |||
| route for N3 network accommodating RAN will be incorporated in an | Controller in the SR domain. The PE may keep the received Type 1 | |||
| N3RAN segment discovery route associated with a RAN segment SID. | Session Transformed routes advertised from the MUP Controller. The | |||
| receiving PE will perform the importing of the received Type 1 | ||||
| Session Transformed routes in the configured routing instances based | ||||
| on the Route Target extended communities. A PE may discard the | ||||
| received Type 1 Session Transformed route if the PE fails to import | ||||
| the route based on the Route Target extended communities. | ||||
| When a MUP GW receives a Direct Segment Discovery route from MUP PEs, | 6.2. Type 2 Session Transformed Route | |||
| the MUP GW keeps the received Direct Segment Discovery route in the | ||||
| RIB. The MUP GW uses the received Direct Segment Discovery route to | ||||
| resolve Type 2 session transformed routes reachability, described in | ||||
| Section 6. If the Direct Segment Discovery route resolves | ||||
| reachability for the endpoints, and match the Direct Segment | ||||
| indication community of the Type 2 session transformed routes, the | ||||
| MUP GW updates the FIB entry for the Type 2 session transformed route | ||||
| with the SID of the matched MUP segment discovery route. | ||||
| In case that an SR node accommodates MUP GW and PE simultaneously, | Second type route, called Type 2 Session Transformed route, encodes | |||
| the MUP GW in the SR node uses a local Direct Segment routing | the tunnel endpoint identifier of the session on the core side in a | |||
| instance if a received Type 2 session transformed route indicates the | BGP MP-NLRI attribute with the nature of tunnel decapsulation. | |||
| local Direct Segment routing instance by the Direct Segment | Longest match algorithm for the prefix in this type of session | |||
| indicating community in the Type 2 session transformed route. | transformed route should be applicable to aggregate the routes for | |||
| scale. The MUP controller advertises the Type 2 Session Transformed | ||||
| route with the Route Target and Direct Segment extended communities | ||||
| for the endpoint to the SR domain. | ||||
| 6. MUP Controller | A PE may receive the Type 2 Session Transformed routes from the MUP | |||
| Controller in the SR domain. The PE may keep the received Type 2 | ||||
| Session Transformed routes advertised from the MUP Controller. The | ||||
| receiving PE will perform the importing of the received Type 2 | ||||
| Session Transformed routes in the configured routing instances based | ||||
| on the Route Target extended communities. A PE may discard the | ||||
| received Type 2 Session Transformed route if the PE fails to import | ||||
| the route based on the Route Target extended communities. | ||||
| 6.3. MUP Controller | ||||
| A MUP controller provides a northbound API. A consumer of the API | A MUP controller provides a northbound API. A consumer of the API | |||
| inputs session information for a UE or a MN from mobility management | inputs session information for a UE or a MN from mobility management | |||
| system. The MUP controller transforms the received session | system. The MUP controller transforms the received session | |||
| information to routing information and will advertise the transformed | information to routing information and will advertise the session | |||
| route to the SR domain. | transformed routes with the corresponding extended communities to the | |||
| SR domain. | ||||
| The received session information is expected to include the UE or MN | The received session information is expected to include the UE or MN | |||
| IP prefix(es), tunnel endpoint identifiers for both ends, and any | IP prefix(es), tunnel endpoint identifiers for both ends, and any | |||
| other attributes for the mobile networks. For example in a 3GPP 5G | other attributes for the mobile networks. For example in a 3GPP 5G | |||
| specific case, the tunnel endpoint identifier will be a pair of the | specific case, the tunnel endpoint identifier will be a pair of the | |||
| F-TEIDs on both the N3 access side (RAN) and core side (UPF). | F-TEIDs on both the N3 access side (RAN) and core side (UPF). | |||
| SRv6 MUP architecture defines two types of session transformed route. | ||||
| First type route is that IP prefix(es) for a UE or MN may be encoded | ||||
| in a BGP MP-NLRI attribute with associated session information of the | ||||
| tunnel endpoint identifier on the access side. The MUP controller | ||||
| advertises the UE or MN route to the SR domain. | ||||
| Second type route is that the tunnel endpoint identifier of the | ||||
| session on the core side may also be encoded in another BGP MP-NLRI | ||||
| attribute with the nature of tunnel decapsulation. Longest match | ||||
| algorithm for the prefix in this type of session transformed route | ||||
| should be applicable to aggregate the routes for scale. | ||||
| MUP PE and GW are expected to receive the routes advertised from the | ||||
| MUP controller. A MUP PE imports a Type 1 session transformed route | ||||
| for UE or MN into the corresponding Direct type routing instance. A | ||||
| MUP GW imports a Type 2 session transformed route for core side | ||||
| session tunnel endpoint identifier into the corresponding Interwork | ||||
| type routing instance. | ||||
| 7. Illustration | 7. Illustration | |||
| This section shows an illustration of SRv6 MUP deployment. The | This section shows an illustration of SRv6 MUP deployment. The | |||
| example deployment cases here is 3GPP 5G. | example deployment cases here is 3GPP 5G. | |||
| Before enabling SRv6 MUP, how SRv6 networks can accommodate existing | Before enabling SRv6 MUP, how SRv6 networks can accommodate existing | |||
| mobile network service shown in Figure 2. SR nodes S1, S2, and S3 | mobile network service shown in Figure 2. The PEs of S1, S2, and S3 | |||
| join an SR network. A routing instance is configured to each network | join an SR network. A routing instance is configured to each network | |||
| of the mobile service. N6DN in S1 and S2 are supposed to provide | of the mobile service. N6DN in S1 and S2 are supposed to provide | |||
| connectivity to edge servers and the Internet respectively. | connectivity to edge servers and the Internet respectively. | |||
| VRF (Virtual Routing Forwarding) may be a way to instantiate the | VRF (Virtual Routing Forwarding) is the routing instance to | |||
| routing instance for realizing the routing policy of each instance. | accommodate MUP segments in this section. All example cases in this | |||
| All example cases in this section follow the typical routing policy | section follow the typical routing policy control using the BGP | |||
| control using the BGP extended community described in [RFC4360] and | extended community described in [RFC4360] and [RFC4684] | |||
| [RFC4684] | ||||
| __ N3 /-----------+-----+------------\ | __ N3 /-----------+-----+------------\ | |||
| / \RAN / |MUP-C| \ | / \RAN / |MUP-C| \ | |||
| / V/v\_ | +-----+ | N6 __ | / V/v\_ | +-----+ | N6 __ | |||
| \ / \ |----+ +----| DN / \ | \ / \ |----+ +----| DN / \ | |||
| \__/ \| S1 | | S2 |----/W/w \ | \__/ \| S1 | | S2 |----/W/w \ | |||
| __ /|----+ +----| \ / | __ /|----+ +----| \ / | |||
| / \__/ | +----+ | \__/ | / \__/ | +----+ | \__/ | |||
| / E/e\N6 \ | S3 | / | / E/e\N6 \ | S3 | / | |||
| \ /DN \------------+----+------------/ | \ /DN \------------+----+------------/ | |||
| \__/ N3UPF /\ N6UPF | \__/ N3UPF /\ N6UPF | |||
| skipping to change at page 11, line 11 ¶ | skipping to change at page 11, line 32 ¶ | |||
| - export route Y/y with RT C3 | - export route Y/y with RT C3 | |||
| - import routes which have RT C4 | - import routes which have RT C4 | |||
| Note: The above configurations are just to provide typical IP | Note: The above configurations are just to provide typical IP | |||
| connectivity for 3GPP 5G. When the above configurations have | connectivity for 3GPP 5G. When the above configurations have | |||
| been done, each endpoint in V/v and X/x can communicate through | been done, each endpoint in V/v and X/x can communicate through | |||
| S1 and S3, but they can not communicate with nodes in E/e, W/w | S1 and S3, but they can not communicate with nodes in E/e, W/w | |||
| and Y/y. | and Y/y. | |||
| Here, SR nodes are configured to enable SRv6 MUP as following: | Here, the PEs are configured to enable SRv6 MUP as following: | |||
| * S1 as MUP GW | * S1 | |||
| - advertises Interwork type discovery route: V/v with SID S1:: | - advertises Interwork type discovery route: V/v with SID S1:: | |||
| - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E | - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E | |||
| * S1 as MUP PE | * S1 | |||
| - advertise Direct type discovery route: MUP direct segment | - advertise Direct type discovery route: MUP Direct Segment | |||
| community D1 and SID S1:1:: | community D1 and SID S1:1:: | |||
| - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 | - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 | |||
| * S2 as MUP PE | * S2 | |||
| - advertise Direct type route: MUP direct segment community D1 | - advertise Direct type route: MUP Direct Segment community D1 | |||
| and SID S2:: | and SID S2:: | |||
| - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 | - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 | |||
| S1 here adopts the local N6DN for D1 as long as S1 prioritizes closer | S1 here adopts the local N6DN to prioritize closer segment for the | |||
| segment for the same MUP direct segment. Another MUP GW runs on a SR | same Direct Segment. Another PE may adopt D1 from S2, if the PE has | |||
| node may adopt D1 from S2, if the SR node has no local N6DN for D1 | no local N6DN for D1 and closer to S2 than S1. | |||
| and closer to S2 than S1. | ||||
| U1 | U1 | |||
| | | | | |||
| U/u v | U/u v | |||
| \__ N3 /-----------+-----+------------\ | \__ N3 /-----------+-----+------------\ | |||
| / \RAN / |MUP-C| \ | / \RAN / |MUP-C| \ | |||
| / V/v\_ | +-----+ | N6 __ | / V/v\_ | +-----+ | N6 __ | |||
| \ / \ |----+ +----| DN / \ | \ / \ |----+ +----| DN / \ | |||
| \__/ \| S1 | | S2 |----/W/w \ | \__/ \| S1 | | S2 |----/W/w \ | |||
| __ /|----+ +----| \ / | __ /|----+ +----| \ / | |||
| skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 31 ¶ | |||
| / E/e\N6 \ | S3 | / | / E/e\N6 \ | S3 | / | |||
| \ /DN \------------+----+------------/ | \ /DN \------------+----+------------/ | |||
| \__/ N3UPF /\ N6UPF | \__/ N3UPF /\ N6UPF | |||
| X/x / \ Y/y | X/x / \ Y/y | |||
| +-----+ | +-----+ | |||
| | UPF | | | UPF | | |||
| +-----+ | +-----+ | |||
| Figure 3 | Figure 3 | |||
| Now, session information U1 comes to a MUP Controller, MUP-C, and | Now, session information U1 is put to a MUP Controller, MUP-C, and | |||
| MUP-C is configured to transforms U1 to the routes as follows: | MUP-C is configured to transforms U1 to the routes as follows: | |||
| * MUP-C | * MUP-C | |||
| - attach the RT C3 to the DN in U1 | - attach the RT C3 to the DN in U1 | |||
| - transforms UE's prefix U/u, the F-TEID on access side (gNB) and | - transforms UE's prefix U/u, the F-TEID on access side (gNB) and | |||
| QFI in U1 to the Type 1 session transformed route for the | QFI in U1 to the Type 1 session transformed route for the | |||
| prefix U/u with the F-TEID, the QFI, and RT C3 | prefix U/u with the F-TEID, the QFI, and RT C3 | |||
| skipping to change at page 14, line 23 ¶ | skipping to change at page 14, line 26 ¶ | |||
| - export route Y/y with RT C3 | - export route Y/y with RT C3 | |||
| - import routes which have RT C4 | - import routes which have RT C4 | |||
| * N6DN in S4 | * N6DN in S4 | |||
| - export route E/e with RT C4 | - export route E/e with RT C4 | |||
| - import routes which have RT C3 and C4 | - import routes which have RT C3 and C4 | |||
| Here, SR nodes are configured to enable SRv6 MUP as following: | Here, the PEs are configured to enable SRv6 MUP as following: | |||
| * S1 as MUP GW (same with the previous case) | * S1 (same with the previous case) | |||
| - advertises Interwork type route: V/v with SID S1:: | - advertises Interwork type route: V/v with SID S1:: | |||
| - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E | - set S1:: behavior End.M.GTP4.E or End.M.GTP6.E | |||
| * S1 as MUP PE | * S1 | |||
| - advertise Direct type route: MUP direct segment community D1 | - advertise Direct type route: MUP Direct Segment community D1 | |||
| for the local N6DN | for the local N6DN | |||
| - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 | - set S1:1:: behavior End.DT4 or End.DT6 for the N6DN in S1 | |||
| * S2 as MUP PE (same with the previous case) | * S2 (same with the previous case) | |||
| - advertise Direct type route: MUP direct segment community D1 | - advertise Direct type route: MUP Direct Segment community D1 | |||
| and SID S2:: | and SID S2:: | |||
| - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 | - set S2:: behavior End.DT4 or End.DT6 for the N6DN in S2 | |||
| * S4 as MUP PE | * S4 | |||
| - advertise Direct type route: MUP direct segment community D2 | - advertise Direct type route: MUP Direct Segment community D2 | |||
| and SID S4:: | and SID S4:: | |||
| - set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4 | - set S4:: behavior End.DT4 or End.DT6 for the N6DN in S4 | |||
| As same as the previous case, S1 adopts the local N6DN for D1 as long | As same as the previous case, S1 adopts the local N6DN for D1 as long | |||
| as S1 prioritizes closer segment for the same MUP direct segment. | as S1 prioritizes closer segment for the same MUP Direct Segment. | |||
| The Direct type route from S4 for D2 with SID S4:: will be kept in | The Direct type route from S4 for D2 with SID S4:: will be kept in | |||
| S1. | S1. | |||
| * MUP-C (same with the previous case) | * MUP-C (same with the previous case) | |||
| - attach the RT C3 to the DN in U1 | - attach the RT C3 to the DN in U1 | |||
| - transforms UE's prefix U/u, the F-TEID on access side (gNB) and | - transforms UE's prefix U/u, the F-TEID on access side (gNB) and | |||
| QFI in U1 to the Type 1 session transformed route for the | QFI in U1 to the Type 1 session transformed route for the | |||
| prefix U/u with the F-TEID, the QFI, and RT C3 | prefix U/u with the F-TEID, the QFI, and RT C3 | |||
| - transforms F-TEID on core side (UPF) X in U1 to the Type 2 | - transforms F-TEID on core side (UPF) X in U1 to the Type 2 | |||
| session transformed route for X with MUP direct segment | session transformed route for X with MUP Direct Segment | |||
| community D1 and RT C2 | community D1 and RT C2 | |||
| Then N3RAN and N6DN import route X and U/u respectively. S2 and S4 | Then N3RAN and N6DN import route X and U/u respectively. S2 and S4 | |||
| resolve U/u's remote endpoint with V/v and then install SID S1:: for | resolve U/u's remote endpoint with V/v and then install SID S1:: for | |||
| U/u in FIB. | U/u in FIB. | |||
| As same as the previous case, S1 adopts local N6DN for D1, N3RAN in | As same as the previous case, S1 adopts local N6DN for D1, N3RAN in | |||
| S1 decapsulates GTP-U packets from V/v to X and then lookup the inner | S1 decapsulates GTP-U packets from V/v to X and then lookup the inner | |||
| packets from U/u in N6DN after the decapsulation. | packets from U/u in N6DN after the decapsulation. | |||
| For D2 on the other hand, no corresponding N6DN existed in S1. | For D2 on the other hand, no corresponding N6DN existed in S1. | |||
| However E/e with RT C4 from S4 is imported into N6DN in S1 as a vpn | However E/e with RT C4 from S4 is imported into N6DN in S1 as a vpn | |||
| route, E/e is reachable from U/u via N6DN for D1 in S1. | route, E/e is reachable from U/u via N6DN for D1 in S1. | |||
| If a session U1' includes DN corresponding to D2, MUP-C advertises | If a session U1' includes DN corresponding to D2, MUP-C advertises | |||
| Type 2 session transformed route X' with MUP direct segment community | Type 2 session transformed route X' with MUP Direct Segment community | |||
| D2, and then N3RAN in S1 instantiates H.M.GTP4.D or End.M.GTP6.D for | D2, and then N3RAN in S1 instantiates H.M.GTP4.D or End.M.GTP6.D for | |||
| X with S4:: as the last SID in the received Direct type route from | X with S4:: as the last SID in the received Direct type route from | |||
| S4. | S4. | |||
| Note: When the above configurations have been done, SRv6 MUP is | Note: When the above configurations have been done, SRv6 MUP is | |||
| applied only to the packets from/to U/u. Each endpoint in U/u, | applied only to the packets from/to U/u. Each endpoint in U/u, | |||
| W/w and E/e can communicate through S1, S2 and S4. The rest of | W/w and E/e can communicate through S1, S2 and S4. The rest of | |||
| traffic from/to other UEs go through the usual 3GPP 5G user | traffic from/to other UEs go through the usual 3GPP 5G user | |||
| plane path using UPF via S3. | plane path using UPF via S3. | |||
| End of changes. 52 change blocks. | ||||
| 168 lines changed or deleted | 194 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/ | ||||