Segment Routing in Two Dimensional IP Routing

Segment routing (SR) allows a headend node to steer a packet flow into an Segment Routing Policy (SR Policy), which represents the routing path. So that the administrator can specific forwarding path on headend node . The headend node can steers packets into an SR Policy either by matching the destination address or routing policy. However, due to the increasing demands of higher dimensional routing like Multi-homing or Source Related Policy Routing, only directs packets based on destination aspect is limited under those scenarios. Moreover, directing packets into SR Policy by routing policy, which can match other fields in packets like port and source address, needs many access in memory. Considering the high-speed ternary content-addressable memory (TCAM) based solution for routers is limited by its low capacity, simply adding one more dimension on routing policy can easily become undeployable on TCAM-based solution. To achieve higher Dimensional routing objectives, we introduce Two Dimensional-IP (TwoD-IP) routing protocol. The TwoD-IP routing architecture can easily express a routing policy between host to host, or network to network, and have much lower storage and calculation consumption compared to higher dimensional routing. In this document, we extend Segment Routing to support Two Dimensional IP(TwoD-IP) routing to enriches the routing abilities, describe how they cooperate to achieve higher dimensional routing like Multi-homing. To extend Segment Routing to support Two Dimensional IP(TwoD-IP) routing, modification of the data plane and control plane is necessary. In data plane, the TwoD-IP routing protocol needs a TwoD-IP forwarding table to stores the source and destination address information. In control plane, the TwoD-IP routing protocol leverages OSPFv3 Router Information(RI) LSA to broadcast configuration and the SR Policy Dynamic Path Computation to compute optimal forwarding path under setting configuration. With these modifications, the headend node will be able to make forwarding decisions base on both source and destination aspects without damaging existing SR architecture.

Terminology used in this document: SR: Segment Routing. TwoD-IP routing protocol: Two Dimensional IP routing protocol, which makes routing decisions based on both destination and source IP addresses. SID: Segment Identifier. SRv6: Segment Routing over IPv6 data plane. SR Policy: a framework that enables instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node.

This section lists two scenarios which can benefit from TwoD-IP routing protocol with Segment Routing technology. Illustrating that TwoD-IP routing protocol can seamless deployment with SR and combine their advantage to achieve users demands of higher dimensional routing.

Even though Segment Routing is able to steer flows to the destination in different way, it is still limited to process the source-related routing scenario like Multi-homing. Multi-homing is prevalent among ISPs for better traffic distribution and reliability. In this case, a network could be connected to multiple upstream ISPs, Hosts are assigned multiple addresses, one for each ISP. The network is responsible for delivering packets from Hosts to the export exit router that is connected to the corresponding upstream ISP. For example, in Figure 1, a multi-homed site is connected to two ISPs: ISP1 and ISP2. ISP1 has a prefix P1, and ISP2 has a prefix P2. A host connect to the multi-homed site has two addresses, address A that assigned from ISP1, and address B that assigned from ISP2. the multi-homed site should deliver the traffic from A towards the Internet to ISP1, and deliver the traffic from B towards the Internet to ISP2.

Although SR can assign different forwarding paths to different ISP for an incoming packet, it still lacks the ability to classify the packets toward the same destination address with different source addresses A and B. With the help of TwoD-IP and Segment Routing, the administrator can easily implement Multi-homing by modifying the headend node that receives packets from Host, which means that administrator does not need to concern about the intermediate node. After extending SR to support TwoD-IP routing, the headend node can routing packet based on both source and destination address, guides packets from Host through the optimal path to the corresponding ISP.

In this scenario, an ingress edge node wants to forward packets with the same destination address through different kind of paths in order to achieve source related demand. For example, in Figure 2, assume a network has four routers: a, b, c and d, c has a service(such as authentication or encIPherer). The operator wants a packet from a to d to be delivered to service c first and then node c will forward the processed packet to it's destination d.

In Segment Routing Architecture, we can allocate a Service segment associated with node c's service. and can be integrated as part of an SR Policy P1(Headend node: b, color, Endpoint: d) of Segment-List < c > . But SR Policy steers packets to a specific SR Policy only when this packet's destination matching corresponding entry, which means headend node can't only steers packets from a to SR Policy P1. But with TwoD-IP routing, headend node b can easily steer packets matching destination of b and source of a to SR Policy P1, then the packet will be delivered to service c first and then node c will forward the processed packet to it's destination d.

The mechanism of how we combine TwoD IP routing and Segment Routing can be separated into the data plane and the control plane. The data plane is mainly concerned about the forward table. It is the foundation of two-dimensional packets forwarding. It needs to be able to store the two-dimensional information of destination and source address without expanding TCAM resource, and the lookup process needs to be quick to support massive packets routing. Then we describe the lookup process and forwarding table updating based on it. Under SR Two-D IP routing, The control plane is concerned with network status and user demands related to <destination address, source address> pair. It needs to transform the user demand to the Policy routing and integrate the Policy routing to the forwarding table so that the headend node can steers packets to a Policy routing representing user demand by checking the packet's <destination address, source address> pair.

The administrator only need to deploy the TwoD-IP forwarding table in the headend node, which makes implementing TwoD-IP routing is much easier. TwoD-IP routing leverages the Segment Routing to deploy the TwoD-IP forwarding table in the headend, which makes implementing TwoD-IP routing is much easier. To achieve the ability of steering packets' forwarding path to follow our decision, we are not willing to damage the existing segment routing architecture. The fast, massive packets routing required fast forwarding entries searching speed, which required the TCAM to store the forwarding entries. However, the TCAM resource is limited under TwoD-IP routing for the dimensional explosion problem in which two-d forward entries grow exponentially. To routing massive packets as fast as possible, a brand new forwarding table structure needs to be design

Unlike the existing SR Policy architecture that steers packets into matching Binding SID based on destination field in the packet, the TwoD-IP routing should steer packets into a BSID according to both the destination and source IP address. The new forwarding table design should satisfy the following requirements: Compatibility. The forwarding table SHALL NOT be incompatible with the existing Segment Routing deployment to assign the forwarding path according to the two-dimensional IP address in the headend node. Speed requirement. The TCAM must be used for fast searching and should parallel the IP searching for both destination and source address Storage requirement. TCAM resources will be limited for the higher dimensional routing to avoid dimensional explosion problem, the destination and source address needs to be stored seperatelly

To achieve all design goals of the forwarding table, we integrate the TwoD-IP routing forwarding table structure called FIST into Segment Rouitng's FIB. As shown in Figure 3, the forwarding table structure consists of the following components: Destination table: It resides in TCAM for fast lookup, and stores the destination prefixes. Each destination prefix in the destination table corresponds to a row number. Source table: It resides in TCAM for fast lookup, and stores the source prefixes. Each source prefix in the source table corresponds to a column number. Two Dimensional Table (TD-table): A two-dimensional array resides in SRAM. Given a row and column numbers, we can find a cell in TD-table. Each cell in TD-table stores an index value of default FIB or Mapping table, which can be mapped to a next-hop. Mapping table: It resides in SRAM, and maps index values to next hops, and the next hop of mapping table will be the Binding SID, which represents the forwarding path we set. Default FIB: It is the same as the existing FIB, which can reside in TCAM or SRAM. The keys of the entries MUST be in keeping with the Destination Table.

Even though there is a Default FIB in forwarding table structure which is the same as existing FIB, the lookup action is not based on it, it based on the Destination and Source Table. More specific, when a packet arrives at the source router, the lookup action is as follows. Extract the destination address d and source address s from the packet; Perform the following two operations in parallel: Lookup the destination address d in the destination table using the LMF rule, and output the row number n; Lookup the source address s in the source table using the LMF rule, and output the column number m; Lookup the cell that is in the nth row and mth column of the TD-table, and output the index value v of default FIB or Mapping table: If there's TwoD-IP rule corresponding to the <destination, source> pair, the output column number m of the source table will not be default (i.e. 0), so the index value of v will corresponds to the Mapping table. So we lookup v in the mapping table, and output the corresponding next hop; If there is not TwoD-IP rule corresponding to the <destination, source> pair, the output column number m of the source table will be default (i.e. 0), so the index value of v will corresponds to the Default FIB. So we lookup v in the Default FIB, and output the corresponding next hop; The most considerable lookup time is the entries searching for the address. To speed it up, we store the destination and source address IP prefix in TCAM, and look up those tables in parallel. After getting the output index of the entries based on the <destination address, source address> pair, every subsequent lookup action will consume one SRAM clock cycle. The SR TwoD-IP routing should activate the policy routing based on the packet's <destination address, source address> pair in the headend node. Moreover, the SR architecture has provided an identification called Binding segment (BSID) to represent a policy routing. So the next hop in the Mapping table SHOULD steer the packet into the BSID of SR Policy, which represents a Segment-List.

In Segment Routing in Two Dimensional IP Routing architecture, not only TwoD-IP routing will modify the forwarding table FIST to satisfy its routing policy, but the existing Segment Routing Policy will also deploy its routing Policy. We do not want to damage the existing Segment Routing architecture, so it is still available for Segment Routing to modify the FIB to steer packets into specific SID such as SR Policy On-Demand next hop. However, any modification of FIB in Segment Routing MUST reside in FIST Default FIB, and if there are any modifications of keys in FIST Default FIB, the Destination Table must be in keeping with it for correcting lookup. The reason any modification of SR Policy MUST resides in FIST Default FIB is that under segment Routing in Two Dimensional IP Routing architecture, the TwoD-IP routing policy is priority-first. The routing Policy located in FIST Default FIB will be matched only when there is no TwoD-IP policy corresponding to incoming packet's <destination, source> pair.

Under SR Two-D IP routing, The control plane is concerned with network status and user demands. Furthermore, The Two-D IP routing can offload the network status like topology or reachability to the SR framework. However, the Two-D IP routing is still responsible for transforming the user demand of two-dimensional destination and source addresses to the forwarding Policy and integrating it to the forwarding table. The control plane of SR Two-D IP routing is consists of the following parts: TwoD-IP configuration exchange: TwoD-IP routing protocol focus on transforming users demand for destination and source address pairs to forwarding action, which means we have one more dimension of source address information to exchange along with headend node, along with the forwarding configurations corresponding to the destination and source address pairs. TwoD-IP forwarding path computation: We leverage the SR Policy Dynamic Path Computation to achieve forwarding path computation, transferring our demand for <destination, source> pair to optimization object and constraint source format which can specify a dynamic candidate path of SR Policy, then the dynamic candidate path can be computed by either the headend or a Path Computation Element (PCE).

The headend node needs to transform the TwoD-IP configuration to the Policy routing and install it into the forwarding table to achieve the two-dimensional IP routing. We need to be concerned about how to notification these TwoD-IP configurations to the headend node. There are two practical ways to achieve this object: install the headend node manually or advertise these TwoD-IP configurations from other nodes to the headend node. When advertising TwoD-IP configurations between nodes, three parts needs to be carried: destination addresses, source addresses, and the user demands of the <destination, source> pairs. Because we leverage the SR Policy to represent the routing policy and SR Policy Dynamic Path Computation to compute the target forwarding path, the user demand will be expressed as an optimization objective and constraints.

The configurations of TwoD-IP routing is organized as TwoD-IP configuration TLV. For example, this brand new TLV can be a TLV of OSPFv3 Router Information(RI) LSA, which introduce the ability to broadcast the TwoD-IP configuration information between OSPF nodes by advertising an OSPFv3 RI LSA that carries the TwoD-IP configuration TLV. More specifically, all three kinds of TwoD-IP configuration, including destination addresses, source addresses, and the user demands of the <destination, source> pairs are all included within the TwoD-IP configuration TLV as three kinds of Sub-TLVs. The TwoD-IP configuration TLV is the same as the format used by. The variable TLV section consists of one or more nested TLV tuples. The format of each TLV is:

Where: Type is TBD Length: 16 bit field. The total length of the value portion(Sub-TLVs) of the TLV Sub-TLVs: Each TwoD-IP configuration TLV has three kinds of Sub-TLVs: Demands Sub-TLV, destination address Sub-TLV and source address Sub-TLV. These Sub-TLVs represent the two-dimensional information of destination and source addresses and corresponding user demands of <destination address, source address> pairs.

To leverage the ability of SR Policy Dynamic Path Computation, the user demand MUST be represented by the formation of Optimization object and constraints. So each user demand carried by Demands Object Sub-TLV is consists of Optimization object and constraints information. And the Optimization and the constraint is refer to the . The format of Demands Object Sub-TLV is:

Where: Type: 16 bit field. The value is 1 for this type. Length: 16 bit field. The total length of the value portion of the Sub-TLV. Reserved (20 bits): This field MUST be set to zero on transmission and MUST be ignored on receIPt. O Flags(4 bits): Optimization object Flags, identify the optimization objective, The following flags are defined:

Where: M flag: Min-Metric - requests computation of a solution Segment-List optimized for a selected metric. N flag: Min-Metric with margin and maximum number of SIDs - Min Metric with two changes: a margin of by which two paths with similar metrics would be considered equal, a constraint on the max number of SIDs in the Segment-List. Optimize T (Type - 8 bits): Specifies the metric type. Three values are currently defined: T=1: IGP metric T=2: TE metric T=3: Hop Counts T=4: Delay C Flags(4 bits): Constraints Flags, iIdentify the Constraints of forwarding path computation, The following flags are defined:

Where: I flag: Inclusion E flag: Exclusion D flag: Diversity to another service instance (e.g., link, node) Constraint T (Type - 8 bits): Specifies the metric type. Two values are currently defined: T=1: TE affinity T=2: IPv6 address(can be an SRv6 SID) variable: 128 bit field. Corresponding to the type defined in Constraint T.

A TwoD-IP routing demand corresponding a <destination, source> pair, so the Optimization object and constraint define a TwoD-IP demand and naturally need to bind a <destination, source> pair. The pair's information is carried in destination/source address Sub-TLV, and it's format is:

Where: Type: 16 bit field. The value is 3 for destination address, 4 for source address. Length: 16 bit field. The total length of the value portion(addresses information) of the TLV. PrefixLength: 8 bit field. The length of IPv6 address. The IPv6 address information is transferring in Prefix format in order to reduce packet length and all the addresses needed to transferring is group by same prefix length. T (dimensional type): 1 bit. 0 for destination addresses, 1 for source addresses. Reserved (7 bits): This field MUST be set to zero on transmission and MUST be ignored on receIPt. PrefixNumbers: 16 bit field. The number of address prefix in the length of PrefixLength. Address Prefix: The address prefix in the length of PrefixLength and will be padded with 0 to fit the multiple 32 bit length.

The procedure of transforming the TwoD-IP configuration to a forwarding path and steering corresponding packets through it consists of two steps: Calling the SR Policy Dynamic candidate path and TwoD-IP forwarding table entries modification.

In keeping with SR Policy Dynamic Path Computation, the TwoD-IP configuration contains the Optimization object and constraint information. when the headend node receives TwoD-IP configuration information(manually or automatically), it will extract the Optimization object and constraint information to generate a corresponding SR Policy . The candidate path associated of an SR Policy is a dynamic candidate path that is expressed by optimization objective and a set of constraints extracted from the TwoD-IP Demands Sub-TLV. Then the headend node(or with the help of a PCE) computes the solution Segment-List that solves the optimization problem to match our TwoD-IP routing demand. After path computation, the SR Policy can represent the forwarding path that satisfies the TwoD-IP Demand. Any packets steered to this SR Policy can be forwarded to the destination following the target path. After offloading the path computation to SR without private custom, TwoD-IP routing can achieve higher compatibility and easier deployment.

an SR Policy can be represented by the identifier called Binding segment (BSID) under Segment Routing architecture. So after path computation under user demands, we can get the SR policy which represents the target forwarding path and the BSID associated with it. Then we need to install this BSID into the TwoD-IP forwarding table so that the TwoD-IP forwarding table can match and steer packets into target BSID, and forward them through SR Policy dynamic path. More specifically, The control plane will install the BSID into the Mapping Table and get the index of entry that stores it. then for all the <destination address, source address> pairs associated with this BSID, the control plane will update the TD-table cells of these pairs to the Mapping Table index or update entries to the source or destination table if there is an uninstalled pair.

This document does not introduce additional security requirements and mechanisms.

This memo asks the IANA for no new parameters.