BGP Extensions for the Mobile User Plane (MUP) SAFI

This draft defines a new BGP SAFI known as a BGP-MUP SAFI. The value of this SAFI is to be assigned by IANA from the Subsequent Address Family Identifiers (SAFI) registry. This document also defines a new BGP NLRI known as the BGP-MUP NLRI. The following is the format of the BGP-MUP NLRI:

The Architecture Type field defines the encoding of the rest of BGP-MUP NLRI for a given Mobile User Plane architecture. This draft defines the following architecture type for BGP-MUP NLRI:

The Route Type field defines the encoding of the rest of BGP-MUP NLRI (Route Type specific BGP-MUP NLRI) for a given architecture type. The Length field indicates the length in octets of the Route Type specific field of the BGP-MUP NLRI. This document defines the following Route Types for BGP-MUP NLRI.

These Route Types are applicable for the 3gpp-5G architecture type as per . Other new architectures can share them if it is applicable as well. The BGP-MUP NLRI is carried in BGP using BGP Multiprotocol Extensions with an Address Family Identifier (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of BGP-MUP. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the BGP-MUP NLRI (encoded as specified above). The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the BGP-MUP NLRI determines whether the addresses carried in the routes are IPv4 or IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates IPv6 addresses). In order for two BGP speakers to exchange BGP-MUP NLRIs, they must use a BGP Capabilities Advertisement to ensure that they both are capable of properly processing such an NLRI. This is done as specified in , by using capability code 1 (multiprotocol BGP) with an AFI of 1 or 2 and an SAFI of BGP-MUP. This document defines 4 Route Types for 3gpp-5G architecture type. Any other Route Types MUST be silently ignored upon a receipt if a BGP speaker supports only 3gpp-5G architecture type. An implementation MAY log an error when such Route Types are ignored. An implementation MAY considered retrieving any discarded Route Types by simply resetting the session or issuing a Route-REFRESH message if the Route Refresh Capability is successfully negotiated. The following sections describes the format of the Route Type specific BGP-MUP NLRI for various Route Types defined in this document.

A BGP Interwork Segment Discovery route Type specific BGP-MUP NLRI consist of the following:

The Interwork Segment Discovery route Type NLRI consist of RD which is encoded as described in . It also has an prefix associated with Interwork segment connected locally. For the purpose of BGP route key processing, only the RD, Prefix Length and Prefix are considered to be part of the prefix in the NLRI. In 3GPP 5G specific case, a prefix used for a N3 interface of the gNodeB connected locally MAY be used as this prefix. The prefix length of one octet indicating length of the prefix. If the AFI is IPv4, then the maximum value of the Prefix Length is 32 bits otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum value of of the Prefix length is 128 bits otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

A BGP Direct Segment Discovery route Type specific BGP-MUP NLRI consist of the following:

The Direct Segment Discovery route Type NLRI consist of RD which is encoded as described in . It also has an Address of originating BGP speaker. For the purpose of BGP route key processing, only the RD and Address are considered to be part of the prefix in the NLRI. If the AFI is IPv4 then the address length is 4 octets otherwise it is considered as a malformed NLRI. If the AFI is IPv6 then the address length is 16 octets otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

A BGP Type 1 ST Route Type specific BGP-MUP NLRI consist of the following:

The Type 1 ST Route Type NLRI consist of RD which is encoded as described in . It also has Prefix length of one octet indicating length of the Prefix. For the purpose of BGP route key processing, only the RD, Prefix Length and Prefix are considered to be part of the prefix in the NLRI. In 3GPP 5G specific case, Prefix is the prefix allocated to a UE. If the AFI is IPv4, then the maximum value of the Prefix Length field is 32. If the AFI is IPv6, then the maximum value of the Prefix Length field is 128. Any other length field is considered a a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The architecture specific encoding values will follow after the variable length Prefix.

A BGP 3gpp-5g Type 1 ST Route Type specific BGP-MUP NLRI consist of the following:

The TEID has a fixed length of 4 octets. The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The QFI has a fixed length of 1 octet. The Endpoint Address Length has a fixed length of 1 octet. Endpoint Address field contains of an IPv4 address, then the value of the Endpoint Address Length field is 32. If the Endpoint Address field contains of an IPv6 Address, then the value of the Endpoint Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 1 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

A BGP Type 2 ST Route Type specific BGP-MUP NLRI consist of the following:

The Type 2 ST Route Type NLRI consist of RD which is encoded as described in . It also has Endpoint length of one octet indicating length of the Endpoint Address and the Architecture specific Endpoint Identifier as per defines aggregation capability by the Type2 ST Route. If the AFI is IPv4 and the Endpoint Length is longer than 32 then the Architecture specific endpoint Identifier field exists with the IPv4 Endpoint Address. If the AFI is IPv6 and the Endpoint Length is longer than 128 then the Architecture specific endpoint Identifier field exists with then the IPv6 Endpoint Address. For the purpose of BGP route key processing, only the RD, Endpoint Address and Architecture specific Endpoint Identifier are considered to be part of the prefix in the NLRI. In 3GPP 5G specific case, the Endpoint Address is a N3 interface address of the UPF. If the AFI is IPv4, then the maximum Endpoint length is 64 otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum Endpoint length is 160 otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The architecture specific encoding values will follow after the variable length Prefix.

A BGP 3gpp-5g Type 2 ST Route Type specific BGP-MUP NLRI consist of the following:

The maximum length of TEID is 4 octets. The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 2 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" . A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.

This document defines a new BGP Extended community known as BGP MUP Extended community as per . This is a BGP MUP specific Extended Community, of an extended type, and is transitive across AS boundaries . The Type value of this Extended community is set to MUP type, to be assigned by IANA from BGP Extended community transtive registry. The Sub-Type value is set to Direct-Type Segment Identifier type, to be assigned by IANA from BGP Extended community transtive registry. The value field of the community is set to the 6 bytes of configurable segment identifier value. The usage of this Extended community is described in the and

BGP speakers acting as a PE, and a MUP Controller MUST establish a BGP session to exchange BGP-MUP NLRIs for both, IPv4 and IPv6 AFIs. Once the session is established successfully, BGP speakers can exchange the Discovery routes as well as Session Transformed routes. This information is specific to a given routing instance. BGP-MUP SAFI is expected to work with routing instances accomodationg MUP segments. In 3GPP 5G specific case, the routing instances are depicted as N3RAN and N6DN instances defined in . The subsequent sections describes procedures of generating and processing of each route types.

The Interwork Segment Discovery route is generated by the PE when a routing instance accommodates an Interwork type MUP Segment, e.g., N3 interfaces or routes on RAN side in 3GPP 5G specific case. It generates route per each N3RAN IP prefix and stores the route in the routing instance of N3RAN. The IP prefix MAY include a gNodeB address which is connecting to the PE. The BGP AFI for BGP MP_REACH_NLRI attribute to carry the Discovery route is decided based on the AFI of the prefix. When advertising the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. When advertising the Interwork Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. The Interwork Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locater followed by a function. In 3GPP 5G specific case, if the BGP AFI is IPv4, the function MUST be GTP4.E , or MUST be GTP6.E if the BGP AFI is IPv6.

The Interwork Segment Discovery route is withdrawn by the PE when it detects that the MUP Segment no longer present for the N3RAN. The BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the Discovery route is decided based on the AFI of the prefix. When withdrawing the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance.

A BGP speaker acting as a PE MAY keep the received MUP Interwork Segment Discovery routes advertised from other PEs. The receiving BGP speaker will perform the importing of the received MUP Interwork Segment Discovery routes in the configured routing instance based on the Route Target extended communities. The IP prefixes for the received segments are imported into the configured routing instance table. Thereby the receiving BGP speaker can provide network connectivity between the nodes that exist in the segments. A BGP speaker MAY discard the received Interwork Segment Discovery route if the speaker fails to import the route based on the Route Target extended communities. The BGP speaker receiving the Interwork Segment Discovery routes SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. However, the receiving BGP speaker MUST ensure that the value of Address filed in the NLRI is an address of the originator of the locator value in the prefix SID attribute. The originator of the locator value can be resolved from the IPv6 IGP table. If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives the Interwork Segment Dicovery routes with a MP_REACH_NLRI attribute without a prefix SID attribute, then it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Interwork Segment Discovery route from the routing instance table where it was created.

The Direct Segment Discovery route is generated by the PE when a routing instance accommodates a Direct type MUP Segment, e.g., N6 interface or routes on DN side in 3GPP 5G specific case. It generates the Direct Segment Discovery route per each routing instance for the MUP Segment. The address in the BGP-MUP NLRI MUST be a unique PE identifier. The BGP AFI for BGP MP_REACH_NLRI attribute to carry the Direct Segment Discovery route is decided based on the AFI of the PE identifier . When announcing the Direct Segment Discovery route, a PE MUST attach a BGP MUP Extended community of the associated routing instance. The sub-type of the Extended community is Direct-Type Segment Identifier. When advertising the Direct Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. The Direct Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locator followed by a function. The function MAY be End.DT4/6 or End.DX4/6.

The Direct Segment Discovery route is withdrawn by the PE when it detects that the MUP Segment no longer present for the routing instance. The BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the Discovery route is decided based on the AFI of the PE identifier. When withdrawing the Direct Segment Discovery route, a BGP speaker MUST attach a BGP MUP Extended community of the associated routing instance.

A BGP speaker acting as a PE MAY keep the received MUP Direct Segment Discovery routes advertised from other PEs. The receiving BGP speaker will perform the importing of the received MUP Direct Segment Discovery routes in the configured routing instance based on the Route Target extended communities. The IP prefixes for the received segments are imported into the configured routing instance table. Thereby the receiving BGP speaker can provide network connectivity between the nodes that exist in the segments. A BGP speaker MAY discard the received Direct Segment Discovery route if the speaker fails to import the route based on the Route Target extended communities. The BGP speaker receiving the Direct Segment Discovery routes SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. However, the receiving BGP speaker MUST ensure that the received nexthop value in the MP_REACH_NLRI attribute is identical to the originator of the locator value in the prefix SID attribute. The originator of the locator value can be resolved from the IPv6 IGP table. If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives a MP_REACH_NLRI attribute update message with a Direct Segment Discovery route without a prefix SID attribute, than it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Direct Segment Discovery route from the routing instance table where it was created.

A BGP speaker acting as a MUP Controller generates Type 1 ST route from corresponding session information through a northbound API as per . The northbound API definition for ST1 route creation is out of scope of this document. In 3GPP 5G specific case, to compose a Type 1 ST route the controller acquires UE address or prefix, Tunnel Endpoint address of GTP tunnel, TEID, and QFI for access side as input parameters from the northbound API. The controller decides the RD of the Type 1 ST route based on operator policy. When advertising the Type 1 ST route, the controller SHOULD attach a Route Target Extended community which the PEs are importing into the routing instance for the corresponding Direct segment. The MUP Controller MUST set the nexthop of the route to the address of the controller. The controller MUST announce this route using a AFI of the route and the SAFI of BGP-MUP to all other BGP speakers within the SRv6 domain.

A BGP speaker acting as a MUP Controller withdraws Type 1 ST route based on deletion of corresponding session information through a northbound API as per . The northbound API definition for ST1 route withdraw is out of scope of this document. In 3GPP 5G specific case, to withdraw a Type 1 ST route the controller acquires the UE address or prefix, Tunnel Endpoint address of GTP tunnel, TEID,and QFI for access side as input parameters from the northbound API. The controller MUST advertise the withdraws of the Type 1 ST route. When withdrawing the Type 1 ST route, the controller SHOULD attach the Route Target Extended community which the PEs are importing into the routing instance accomodating the corresponding Direct segment to the Route Target Extended community.

A BGP speaker acting as a PE MAY keep the received MUP Type 1 ST routes advertised from the MUP Controller. The receiving BGP speaker will perform the importing of the received MUP Type 1 ST routes in the configured N6DN routing instance based on the Route Target extended communities. A BGP speaker MAY discard the received Type 1 ST route if the speaker fails to import the route based on the Route Target extended communities. In case of a BGP speaker receiving a Type 1 ST routes is a PE, the PE SHOULD use the received Tunnel Endpoint Address in this NLRI as a key to lookup the associated Interwork Segment Discovery route and extract the locator and the function in the prefix SID attribute of the Interwork route. In 3GPP 5G specific case, the PE extracts TEID, QFI and Tunnel Endpoint address from the NLRI. Then the PE SHOULD generate the forwarding SID for GTP4/6.E based on the procedures mentioned in the . If the PE cannot generate the prefix SID, then it SHOULD mark the received Type 1 ST route as an invalid route. The PE MAY hold such an invalid route until the route as a valid route upon successful generation of prefix SID. The PE receiving Type 1 ST routes SHOULD ignore the received nexthop in the MP_REACH_NLRI attribute. The PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute MUST delete all the routes from the associated routing instance.

A BGP speaker acting as a MUP Controller generates Type 2 ST route from corresponding session information through a northbound API, or pre-defined configuration as per . The northbound API definition for ST2 route creation is out of scope of this document. In 3GPP 5G specific case, to compose a Type 2 ST route the controller acquires the Endpoint consists of Endpoint address of GTP tunnel and TEID for core side with the effective length of the Endpoint as input parameters. The controller decides the RD of the Type 2 ST route based on operator policy. When advertising the Type 2 ST route, the controller SHOULD attach a BGP MUP Extended community corresponding to the Direct segment. The sub-type of the Extended community is Direct-Type Segment Identifier. This Segment Identifier is generated from the information received through a northbound API, or a pre-defined configuration as per . The northbound API definition for receving this information is out of scope of this document. The controller MUST also attach a Route Target Extended community of the routing instances in the PE accomodating the corresponding Interwork segment. The controller MUST set the nexthop of the route to the address of the MUP Controller.

A BGP speaker acting as a MUP Controller withdraws Type 2 ST route based on deletion of corresponding session information through a northbound API as per . The northbound API definition for ST2 route withdraw is out of scope of this document. In 3GPP 5G specific case, to withdraw a Type 2 ST route the controller acquires the Endpoint consists of Endpoint address of GTP tunnel and TEID for core side with the effective length of the Endpoint as input parameters. The controller MUST advertise the withdraws of the Type 2 ST route. When withdrawing the Type 2 ST route, the controller SHOULD attach the BGP MUP Extended community corresponding to the Direct segment, and the Route Target Extended community which the PEs are importing into the routing instance accomodating the corresponding Interwork segment to the Route Target Extended community.

A BGP speaker acting as a PE MAY keep the received MUP Type 2 ST routes advertised from the MUP Controller. The receiving BGP speaker will perform the importing of the received MUP Type 2 ST routes in the configured N3RAN routing instance based on the Route Target extended communities. A BGP speaker MAY discard the received Type 2 ST route if the speaker fails to import the route based on the Route Target extended communities. The BGP speaker receiving the Type 2 ST routes SHOULD ignore the received nexthop in the MP_REACH_NLRI attribute. A PE receiving the Type 2 ST routes in a MP_REACH_NLRI attribute without a BGP MUP Extended community SHOULD consider the route as a malformed route. The PE MUST handle such a malformed NLRI as a "Treat-as-withdraw" . The PE receiving Type 2 ST route with a BGP MUP Extended Community should extract the received segment identifier from the community. The segment identifier is used to resolve an appropriate Direct segment routing instance.