Internet DRAFT - draft-xu-spring-segment-twod-ip-routing
draft-xu-spring-segment-twod-ip-routing
SPRING Working Group M. Xu
Internet-Draft B. Wang
Intended status: Informational Tsinghua University
Expires: 27 August 2022 T. Wang
Beijing University of Posts and Telecommunications
S. Yang
Shenzhen University
J. Wu
Tsinghua University
February 2022
Segment Routing in Two Dimensional IP Routing
draft-xu-spring-segment-twod-ip-routing-01
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.
Xu, et al. Expires 27 August 2022 [Page 1]
Internet-Draft SR in TwoD-IP Routing February 2022
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/.
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 August 2022.
Copyright Notice
Copyright (c) 2022 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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
5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Forwarding Table Design . . . . . . . . . . . . . . . . . 7
5.1.1. Design Goals . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Forwarding Table Structure . . . . . . . . . . . . . 7
5.1.3. Lookup Action . . . . . . . . . . . . . . . . . . . . 9
5.1.4. Forwarding table Update Action . . . . . . . . . . . 10
6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Advertisement of TwoD-IP configuration . . . . . . . . . 11
6.1.1. TwoD-IP configuration architecture . . . . . . . . . 11
6.1.2. Demands Object Sub-TLV . . . . . . . . . . . . . . . 12
6.1.3. destination/source address Sub-TLV . . . . . . . . . 14
6.2. TwoD-IP forwarding path computation . . . . . . . . . . . 16
6.2.1. Setting up the SR Policy Dynamic candidate path . . . 16
Xu, et al. Expires 27 August 2022 [Page 2]
Internet-Draft SR in TwoD-IP Routing February 2022
6.2.2. TwoD-IP forwarding table entries modification . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
Xu, et al. Expires 27 August 2022 [Page 3]
Internet-Draft SR in TwoD-IP Routing February 2022
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:
* 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.
Xu, et al. Expires 27 August 2022 [Page 4]
Internet-Draft SR in TwoD-IP Routing February 2022
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.
+--------------------+
| |
| 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.
Xu, et al. Expires 27 August 2022 [Page 5]
Internet-Draft SR in TwoD-IP Routing February 2022
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.
+---------+
+------+ 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 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
Xu, et al. Expires 27 August 2022 [Page 6]
Internet-Draft SR in TwoD-IP Routing February 2022
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.
5. Data Plane
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
5.1. Forwarding Table Design
5.1.1. Design Goals
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
5.1.2. Forwarding Table Structure
Xu, et al. Expires 27 August 2022 [Page 7]
Internet-Draft SR in TwoD-IP Routing February 2022
Source +------------+------+------+------+------+
Table |default | 111* | 101* | 100* | 11** |
+------------+------+------+------+------+
| 0 | 1 | 2 | 3 | 4 |
+------------+------+------+------+------+
Destination default Mapping Table
Table | FIB Index | index |
+-------+---+ --+-----------+------+------+------+------+---
| 111* | 0 | | 0 | 0 | | 1 | |
+-------+---+ --+-----------+------+------+------+------+---
| 100* | 1 | | 1 | 2 | | | |
+-------+---+ --+-----------+------+------+------+------+---
| 101* | 2 | | 2 | | | | 2 |
+-------+---+ --+-----------+------+------+------+------+---
| 11** | 3 | | 3 | | | | |
+-------+---+ --+-----------+------+------+------+------+---
| 10** | 4 | | 4 | | | | 3 |
+-------+---+ --+-----------+------+------+------+------+---
| | | | | |
TD-table
+------+---------+ +------+---------+
|Index |Next hop | |prefix|Next hop |
+------+---------+ +------+---------+
| 0 |BSID1 | | 0 |1.0.0.0 |
+------+---------+ +------+---------+
Mapping | 1 |BSID1 | Default | 1 |1.0.0.1 |
Table +------+---------+ FIB +------+---------+
| 2 |BSID2 | | 2 |1.0.0.2 |
+------+---------+ +------+---------+
| 3 |BSID3 | | 3 |1.0.0.3 |
+------+---------+ +------+---------+
Figure 2: SR in Two-Dimensional IP Routing Forwarding Table Structure
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.
Xu, et al. Expires 27 August 2022 [Page 8]
Internet-Draft SR in TwoD-IP Routing February 2022
* 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.
5.1.3. Lookup Action
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.
1. Extract the destination address d and source address s from the
packet;
2. 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;
3. 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;
Xu, et al. Expires 27 August 2022 [Page 9]
Internet-Draft SR in TwoD-IP Routing February 2022
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.
5.1.4. Forwarding table Update Action
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.
6. Control Plane
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:
Xu, et al. Expires 27 August 2022 [Page 10]
Internet-Draft SR in TwoD-IP Routing February 2022
* 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).
6.1. Advertisement of TwoD-IP configuration
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.
6.1.1. TwoD-IP configuration architecture
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.
Xu, et al. Expires 27 August 2022 [Page 11]
Internet-Draft SR in TwoD-IP Routing February 2022
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[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:
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.
6.1.2. Demands Object Sub-TLV
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
[I-D.filsfils-spring-sr-policy-considerations].
The format of Demands Object Sub-TLV is:
Xu, et al. Expires 27 August 2022 [Page 12]
Internet-Draft SR in TwoD-IP Routing February 2022
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 |O Flags| Optimize T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C Flags| Constraint T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Constraint variables |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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:
0 1 2 3
+-+-+-+-+
|M|N| |
+-+-+-+-+
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
Xu, et al. Expires 27 August 2022 [Page 13]
Internet-Draft SR in TwoD-IP Routing February 2022
* 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:
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)
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.
6.1.3. 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 27 August 2022 [Page 14]
Internet-Draft SR in TwoD-IP Routing February 2022
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 |T| 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.
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.
Xu, et al. Expires 27 August 2022 [Page 15]
Internet-Draft SR in TwoD-IP Routing February 2022
6.2. TwoD-IP forwarding path computation
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.
6.2.1. Setting up the SR Policy Dynamic candidate path
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.
6.2.2. TwoD-IP forwarding table entries modification
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.
Xu, et al. Expires 27 August 2022 [Page 16]
Internet-Draft SR in TwoD-IP Routing February 2022
7. Security Considerations
This document does not introduce additional security requirements and
mechanisms.
8. IANA Considerations
This memo asks the IANA for no new parameters.
9. References
9.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>.
9.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-08, 22 October
2021, <https://www.ietf.org/archive/id/draft-filsfils-
spring-sr-policy-considerations-08.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-18, 17 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-18.txt>.
Xu, et al. Expires 27 August 2022 [Page 17]
Internet-Draft SR in TwoD-IP Routing February 2022
[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>.
[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@csnet1.cs.tsinghua.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
Xu, et al. Expires 27 August 2022 [Page 18]
Internet-Draft SR in TwoD-IP Routing February 2022
Shu Yang
Shenzhen University
Guangdong
P.R. China
Email: yang.shu@szu.edu.cn
Jianping Wu
Tsinghua University
Beijing
P.R. China
Email: jianping@cernet.edu.cn
Xu, et al. Expires 27 August 2022 [Page 19]
