Segment Routing in Two Dimensional IP Routing
draft-xu-spring-segment-twod-ip-routing-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Mingwei Xu , Bo Wang , Tingfeng Wang , Jianping Wu | ||
| Last updated | 2021-09-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-spring-segment-twod-ip-routing-00
SPRING Working Group M. Xu
Internet-Draft B. Wang
Intended status: Informational Tsinghua University
Expires: 2 April 2022 T. Wang
Beijing University of Posts and Telecommunications
J. Wu
Tsinghua University
September 2021
Segment Routing in Two Dimensional IP Routing
draft-xu-spring-segment-twod-ip-routing-00
Abstract
Segment Routing (SR) allows a headend node to steer traffic into a
Segment Routing Policy (SR Policy), which represents the routing path
by matching the destination address and the corresponding Binding
Segment Identifier (BSID). However, determining the target SR Policy
only based on destination aspect is incapable for demands for higher
dimensional routing. Two Dimensional IP (TwoD-IP) routing is an
Internet routing architecture that makes forwarding decisions based
on source and destination addresses. TwoD-IP routing can easily
express a routing policy between host to host, or network to network,
and have much lower storage and calculation consumption compared to
the higher dimensional routing.
In this document, we extend SR to support TwoD-IP routing, illustrate
some typical scenarios of SR with TwoD-IP routing to express the
advantage of extending SR to support TwoD-IP routing, and describe
the mechanism of how TwoD IP routing protocol cooperates with SR.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Xu, et al. Expires 2 April 2022 [Page 1]
Internet-Draft SR in TwoD-IP Routing September 2021
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 March 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Benefit of extend Segment routing to support TwoD-IP
routing . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Multi-homing . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Source Related Policy Routing . . . . . . . . . . . . . . 5
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7
5. Advertisement of TwoD-IP configuration . . . . . . . . . . . 8
5.1. TwoD-IP configuration TLV . . . . . . . . . . . . . . . . 8
5.2. Optimization Object Sub-TLV . . . . . . . . . . . . . . . 9
5.3. Constraints Sub-TLV . . . . . . . . . . . . . . . . . . . 10
5.4. destination/source address Sub-TLV . . . . . . . . . . . 11
6. TwoD-IP forwarding path computation . . . . . . . . . . . . . 12
6.1. Setting up the SR Policy Dynamic candidate path . . . . . 13
6.2. TwoD-IP forwarding table entry creation . . . . . . . . . 13
7. TwoD-IP forwarding table Design . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Xu, et al. Expires 2 April 2022 [Page 2]
Internet-Draft SR in TwoD-IP Routing September 2021
1. Introduction
Segment routing (SR) [RFC8402] 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
[I-D.ietf-spring-segment-routing-policy].
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.
[I-D.xu-rtgwg-twod-ip-routing] 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.
2. Terminology
Terminology used in this document:
Xu, et al. Expires 2 April 2022 [Page 3]
Internet-Draft SR in TwoD-IP Routing September 2021
* 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.
3. Benefit of extend Segment routing to support TwoD-IP routing
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.
3.1. Multi-homing
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[RFC4177] 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.
Xu, et al. Expires 2 April 2022 [Page 4]
Internet-Draft SR in TwoD-IP Routing September 2021
+--------------------+
| |
| Internet |
| |
+--+---------------+-+
| |
| l3 | l4
| |
+------+----+ +--+--------+
| ISP1 | | ISP2 |
| Prefix P1 | | Prefix P2 |
+--------+--+ +-+---------+
| |
| l1 | l2
+--+------------+--+
| |
| Multi-homed Site | +---------+
| +--------+ Host |
+------------------+ +---------+
ISP1 assign address: A
ISP2 assign address: B
Figure 1: Multi-homing scenario
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.
3.2. Source Related Policy Routing
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.
Xu, et al. Expires 2 April 2022 [Page 5]
Internet-Draft SR in TwoD-IP Routing September 2021
+---------+
+------+ c +-----+
| +(service)+ |
| +---------+ |
| |
+------+ +--+---+ +---+--+
| a +----------+ b +--------------+ d |
+------+ +------+ +------+
Figure 2: TwoD-IP routing for Service
In Segment Routing Architecture, we can allocate a Service segment
associated with node c's
service.[I-D.ietf-spring-sr-service-programming] 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.
4. Framework
The mechanism of how we combine TwoD IP routing and Segment Routing
can be separated into two parts: data plane and control plane.
4.1. Data Plane
TCAM resources are future limited to the higher dimensional routing,
including TwoD-IP routing. [I-D.xu-rtgwg-twod-ip-routing] propose a
novel forwarding table design to increase the TCAM resource
utilizatioin significantly. The data plane of extending SR to
support TwoD-IP routing introduces this Two-D forwarding table design
into the original SR data plane.
Considering Segment Routing leverages the source routing paradigm,
administrator just need to deploy TwoD-IP forwarding table in headend
node, which makes implementing TwoD-IP routing much easier.
Different with traditional destination-based FIB, each entry in the
TwoD-IP forwarding table is a 3-tuple: {destination address, source
address, next hop} [I-D.xu-rtgwg-twod-ip-routing]
Xu, et al. Expires 2 April 2022 [Page 6]
Internet-Draft SR in TwoD-IP Routing September 2021
The next hop in the TwoD-IP forwarding table should steer the packet
into the associated SR Policy, and the SR architecture has provided
an identifier to do that: Binding segment/BSID. The headend of an SR
Policy binds a SID(BSID) to its policy, so the next hop in TwoD-IP
forwarding table should be a BSID, which is associated with the SR
Policy that corresponding to the entry's <destination address, source
address>pairs.
So the TwoD-IP forwarding table tuple is {destination address, source
address, BSID}, when a packet arrive, the headend node can extract
both destination and source addresses from the packet, then lookup
the Two-IP forwarding table, and output a matched entry. Finally,
headend node will forward the packet to the matched entry's next hop,
which is a BSID associated with a SR Policy, to get the dynamic
candidate path that steers it to the destination.
Segment Routing can be instantiated on two data planes: SR over MPLS
(SR-MPLS) and SR over IPv6 (SRv6). Different data plane has
different BSID format, in SR-MPLS, SID are an MPLS label or an index
into an MPLS label space, in SRv6, SID is an IPv6 address. So even
we could deploy TwoD-IP routing on both two data planes, we still
deploy TwoD-IP routing with SR over IPv6(SRv6), so that the next hop
elements in TwoD-IP forwarding table will be SRv6 BSID which is an
IPv6 address.
4.2. Control Plane
Within TwoD-IP routing, the control plane is concerned with user
demands, it focus on providing services that are related with source
addresses. They need to collect demands from users, and compute the
routing table to satisfy these demands. And Segment Routing support
many control plane. So we can extend one of them to achieve
configuration exchange and optimal forwarding path computation
objects..
* TwoD-IP configuration exchange: TwoD-IP routing protocol focus on
transforming users demand for destination and source address pairs
to forwarding action, which mean that we have one more dimension
of source address information to exchange along with headend node,
and 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
Xu, et al. Expires 2 April 2022 [Page 7]
Internet-Draft SR in TwoD-IP Routing September 2021
Element (PCE). So TwoD-IP routing protocol doesn't need to
concern about how the candidate path is computed and what the path
really is.
5. Advertisement of TwoD-IP configuration
TwoD-IP configuration needs to be installed in the headend node so
that the headend node can creates the TwoD-IP forwarding table entry
and the SR Policy with dynamic candidate path corresponding it. The
TwoD-IP configuration can be installed in headend node manually or
automatically by advertising of TwoD-IP configurations between nodes.
A TwoD-IP configuration contains three parts: destination
addresses,source addresses and the user demands of the <destination,
source> pairs, including optimization objective and constraints.
5.1. TwoD-IP configuration TLV
The configurations of TwoD-IP routing is within the TwoD-IP
configuration TLV, the TwoD-IP configuration TLV is a TLV of OSPFv3
Router Information(RI) LSA, TwoD-IP configuration information will be
broadcast by letting An OSPF router advertising an OSPFv3 RI LSA that
include the TwoD-IP configuration TLV.
Because TwoD-IP routing is deployed in SR over IPv6, the OSPF router
will exchange router information with OSPFv3 Router Information(RI)
LSA.
The router may advertise multiple instances of TwoD-IP configuration
TLV within the OSPFv3 Router Information(RI) LSA - one for each of
the TwoD-IP configuration needs to be advertised.
The format of the TwoD-IP configuration TLV is the same as the format
used by[RFC3630]. The variable TLV section consists of one or more
nested TLV tuples. The format of each TLV is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. TwoD-IP configuration TLV Format
Where:
Xu, et al. Expires 2 April 2022 [Page 8]
Internet-Draft SR in TwoD-IP Routing September 2021
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 four Sub-TLVs:
Optimization Object Sub-TLV, Constraint Sub-TLV, destination and
source address Sub-TLV. There could be multiple Sub-TLV of them
to specify the dynamic candidate path of SR Policy and the
<destination address, source address> pairs associated the SR
Policy.
5.2. Optimization Object Sub-TLV
The Optimization and the constraint is basically refer to
[I-D.filsfils-spring-sr-policy-considerations].
The format of Optimization Object Sub-TLV is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Optimization Object Sub-TLV Format
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 TLV.
Reserved (20 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Flags(4 bits): Identify the optimization objective, The following
flags are defined:
0 1 2 3
+-+-+-+-+
|M|N| |
+-+-+-+-+
Where:
Xu, et al. Expires 2 April 2022 [Page 9]
Internet-Draft SR in TwoD-IP Routing September 2021
* 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.
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
5.3. Constraints Sub-TLV
The constrains we use in TwoD-IP routing is Inclusion and/or
exclusion some node/service identified as a IPv6 address.
The format of Optimization Object Sub-TLV is:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| variable |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Constraints Sub-TLV Format
Where:
Type: 16 bit field. The value is 2 for this type.
Length: 16 bit field. The total length of the value portion of
the TLV.
Reserved (20 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Flags(4 bits): Identify the optimization objective, The following
Xu, et al. Expires 2 April 2022 [Page 10]
Internet-Draft SR in TwoD-IP Routing September 2021
flags are defined:
0 1 2 3
+-+-+-+-+
|I|E|D| |
+-+-+-+-+
Where:
* I flag: Inclusion
* E flag: Exclusion
* D flag: Diversity to another service instance (e.g., link,
node)
T (Type - 8 bits): Specifies the metric type. Two values are
currently defined:
* T=1: TE affinity
* T=2: IPv6 address(can be a SRv6 SID)
variable: 128 bit field. Corresponding the variable defined in T.
5.4. destination/source address Sub-TLV
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:
Xu, et al. Expires 2 April 2022 [Page 11]
Internet-Draft SR in TwoD-IP Routing September 2021
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Reserved | PrefixNumbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix2 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
Figure 6: destination/source address Sub-TLV Format
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.
Reserved (8 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.
6. TwoD-IP forwarding path computation
The procedure of transforming the TwoD-IP configuration to a
candidate path has two steps: setting up the SR Policy Dynamic
candidate path and TwoD-IP forwarding table entry creation.
Xu, et al. Expires 2 April 2022 [Page 12]
Internet-Draft SR in TwoD-IP Routing September 2021
6.1. Setting up the SR Policy Dynamic candidate path
The TwoD-IP configuration contains the Optimization object and
constraint information, when the headend node receive TwoD-IP
configuration information(manually or automatically), it will
extracts the Optimization object and constraint information to
generate a SR Policy which enable Dynamic candidate path.
An SR Policy is identified through the tuple<headend, color,
endpoint>,[I-D.ietf-spring-segment-routing-policy] so the headend
node will extract the first destination address in TwoD-IP
configuration TLV - destination address Sub-TLV as the endpoint,
dynamic assign a color value to distinguish the SR Policy from others
with the same endpoint. And the candidate path associated to the SR
Policy is a dynamic candidate path which expresses an optimization
objective and a set of constraints that extract from the TwoD-IP
configuration TLV - Optimization Object Sub-TLV and Constraint Sub-
TLV. Then the headend node(or with the help of a PCE) computes the
solution Segment-List that solve the optimization problem and also
match our TwoD-IP routing demand.
6.2. TwoD-IP forwarding table entry creation
After Setting up the SR Policy dynamic candidate path, the active
dynamic candidate path will be defined with a BSID which can steers
the packets to the dynamic candidate path, and installs the BSID-
keyed entry in the TwoD-IP forwarding table.
The TwoD-IP forwarding table has two dimensions: destination and
source, so TwoD-IP forwarding table has two index: destination
address and source address, a pair of <destination address, source
address> determines a action(next hop) which is a BSID.
The headend node receives a TwoD-IP configuration TLV, generates a SR
Policy depends on it, and also will creates <destination address,
source address> pairs in TwoD-IP forwarding table as a index, and
installs their action(next hop) with the BSID that define the dynamic
candidate path generated with the same TwoD-IP configuration TLV
informations.
7. TwoD-IP forwarding table Design
Traditional forwarding table only supports making forwarding
decisions based on destination IP addresses even in Segment Routing
architecture. TwoD-IP routing needs a new forwarding table structure
that supports making forwarding decisions based on both destination
and source IP addresses.
Xu, et al. Expires 2 April 2022 [Page 13]
Internet-Draft SR in TwoD-IP Routing September 2021
Considering the compatibility with Segment Routing architecture,
There's no need to modify the FIB structure directly. we imitate the
way SR Policy process interacting with the FIB process to install our
TwoD IP process in data plane. we just need to install in FIB with
destination address that in the active TwoD-IP <destination, source>
pair with next-hop = TwoD IP routing process which maintain a TwoD IP
Forwarding table.
The TwoD-IP forwarding table structure is the same as
[I-D.xu-rtgwg-twod-ip-routing] called FIST which is designed to avoid
forwarding table explosion with a new source dimension.
In conclusion, TwoD IP routing procedure maintains a TwoD-IP
forwarding table separate from the headend node's FIB and installs
FIB entries with destination addresses in the chosen <destination
address, source address> pairs with next-hop = TwoD IP routing
interface.
When a headend node receives a packet with destination matching the
destination address of TwoD IP routing pairs, headend node steers the
packet to TwoD IP routing process to the TwoD-IP forwarding table,
then the headend node will lookup the TwoD-IP forwarding table base
on the packet's both destination and source address extracted from
the packet and output a matched entry. Finally, headend node will
forward the packet to the next hop associated with the matched entry,
which is a BSID, after steering the packet to the BSID, the headend
node will insert the Segment-List of the dynamic candidate path of
the BSID to the packet head so that it can be forwarded through this
path
SR Policy process interacts with the RIB/FIB process to install an
active SR Policy in the data
plane.[I-D.filsfils-spring-sr-policy-considerations] TwoD IP routing
protocol doesn't change the FIB structure so Segment Routing's
advanced features like On-Demand Next Hop will still work. (we
allocate higher authority to TwoD IP routing process to install and
modify FIB entries to avoid conflicting)
8. Security Considerations
This document does not introduce additional security requirements and
mechanisms.
9. IANA Considerations
Some newly designed TwoD-IP routing protocols may need new protocol
numbers assigned by IANA.
Xu, et al. Expires 2 April 2022 [Page 14]
Internet-Draft SR in TwoD-IP Routing September 2021
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
10.2. Informative References
[I-D.filsfils-spring-sr-policy-considerations]
Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and
P. Mattes, "SR Policy Implementation and Deployment
Considerations", Work in Progress, Internet-Draft, draft-
filsfils-spring-sr-policy-considerations-07, 4 April 2021,
<https://www.ietf.org/archive/id/draft-filsfils-spring-sr-
policy-considerations-07.txt>.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-13, 28 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-13.txt>.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
service-programming-05, 10 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-sr-
service-programming-05.txt>.
[I-D.xu-rtgwg-twod-ip-routing]
Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP
Routing Architecture", Work in Progress, Internet-Draft,
draft-xu-rtgwg-twod-ip-routing-00, 4 March 2012,
<https://www.ietf.org/archive/id/draft-xu-rtgwg-twod-ip-
routing-00.txt>.
Xu, et al. Expires 2 April 2022 [Page 15]
Internet-Draft SR in TwoD-IP Routing September 2021
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4177] Huston, G., "Architectural Approaches to Multi-homing for
IPv6", RFC 4177, DOI 10.17487/RFC4177, September 2005,
<https://www.rfc-editor.org/info/rfc4177>.
Authors' Addresses
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing
Phone: +86-10-6278-5822
Email: xmw@cernet.edu.cn
Bo Wang
Tsinghua University
Beijing
Email: wangbo2019@tsinghua.edu.cn
Tingfeng Wang
Beijing University of Posts and Telecommunications
Beijing
P.R. China
Email: wangtingfeng@bupt.edu.cn
Jianping
Tsinghua University
Beijing
P.R. China
Email: jianping@cernet.edu.cn
Xu, et al. Expires 2 April 2022 [Page 16]