idnits 2.17.00 (12 Aug 2021) /tmp/idnits36162/draft-xu-spring-segment-twod-ip-routing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (February 2022) is 88 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 -- No information found for draft-xu-rtgwg-twod-IP-routing - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group M. Xu 3 Internet-Draft B. Wang 4 Intended status: Informational Tsinghua University 5 Expires: 27 August 2022 T. Wang 6 Beijing University of Posts and Telecommunications 7 S. Yang 8 Shenzhen University 9 J. Wu 10 Tsinghua University 11 February 2022 13 Segment Routing in Two Dimensional IP Routing 14 draft-xu-spring-segment-twod-ip-routing-01 16 Abstract 18 Segment Routing (SR) allows a headend node to steer traffic into a 19 Segment Routing Policy (SR Policy), which represents the routing path 20 by matching the destination address and the corresponding Binding 21 Segment Identifier (BSID). However, determining the target SR Policy 22 only based on destination aspect is incapable for demands for higher 23 dimensional routing. Two Dimensional IP (TwoD-IP) routing is an 24 Internet routing architecture that makes forwarding decisions based 25 on source and destination addresses. TwoD-IP routing can easily 26 express a routing policy between host to host, or network to network, 27 and have much lower storage and calculation consumption compared to 28 the higher dimensional routing. 30 In this document, we extend SR to support TwoD-IP routing, illustrate 31 some typical scenarios of SR with TwoD-IP routing to express the 32 advantage of extending SR to support TwoD-IP routing, and describe 33 the mechanism of how TwoD IP routing protocol cooperates with SR. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 5 August 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Benefit of extend Segment routing to support TwoD-IP 77 routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.1. Multi-homing . . . . . . . . . . . . . . . . . . . . . . 4 79 3.2. Source Related Policy Routing . . . . . . . . . . . . . . 5 80 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 5.1. Forwarding Table Design . . . . . . . . . . . . . . . . . 7 83 5.1.1. Design Goals . . . . . . . . . . . . . . . . . . . . 7 84 5.1.2. Forwarding Table Structure . . . . . . . . . . . . . 7 85 5.1.3. Lookup Action . . . . . . . . . . . . . . . . . . . . 9 86 5.1.4. Forwarding table Update Action . . . . . . . . . . . 10 87 6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 10 88 6.1. Advertisement of TwoD-IP configuration . . . . . . . . . 11 89 6.1.1. TwoD-IP configuration architecture . . . . . . . . . 11 90 6.1.2. Demands Object Sub-TLV . . . . . . . . . . . . . . . 12 91 6.1.3. destination/source address Sub-TLV . . . . . . . . . 14 92 6.2. TwoD-IP forwarding path computation . . . . . . . . . . . 16 93 6.2.1. Setting up the SR Policy Dynamic candidate path . . . 16 94 6.2.2. TwoD-IP forwarding table entries modification . . . . 16 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 9.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 Segment routing (SR) [RFC8402] allows a headend node to steer a 105 packet flow into an Segment Routing Policy (SR Policy), which 106 represents the routing path. So that the administrator can specific 107 forwarding path on headend node 108 [I-D.ietf-spring-segment-routing-policy]. 110 The headend node can steers packets into an SR Policy either by 111 matching the destination address or routing policy. However, due to 112 the increasing demands of higher dimensional routing like Multi- 113 homing or Source Related Policy Routing, only directs packets based 114 on destination aspect is limited under those scenarios. Moreover, 115 directing packets into SR Policy by routing policy, which can match 116 other fields in packets like port and source address, needs many 117 access in memory. Considering the high-speed ternary content- 118 addressable memory (TCAM) based solution for routers is limited by 119 its low capacity, simply adding one more dimension on routing policy 120 can easily become undeployable on TCAM-based solution. 122 To achieve higher Dimensional routing objectives, we introduce Two 123 Dimensional-IP (TwoD-IP) routing protocol. 124 [I-D.xu-rtgwg-twod-IP-routing] The TwoD-IP routing architecture can 125 easily express a routing policy between host to host, or network to 126 network, and have much lower storage and calculation consumption 127 compared to higher dimensional routing. 129 In this document, we extend Segment Routing to support Two 130 Dimensional IP(TwoD-IP) routing to enriches the routing abilities, 131 describe how they cooperate to achieve higher dimensional routing 132 like Multi-homing. 134 To extend Segment Routing to support Two Dimensional IP(TwoD-IP) 135 routing, modification of the data plane and control plane is 136 necessary. In data plane, the TwoD-IP routing protocol needs a TwoD- 137 IP forwarding table to stores the source and destination address 138 information. In control plane, the TwoD-IP routing protocol 139 leverages OSPFv3 Router Information(RI) LSA to broadcast 140 configuration and the SR Policy Dynamic Path Computation to compute 141 optimal forwarding path under setting configuration. With these 142 modifications, the headend node will be able to make forwarding 143 decisions base on both source and destination aspects without 144 damaging existing SR architecture. 146 2. Terminology 148 Terminology used in this document: 150 * SR: Segment Routing. 152 * TwoD-IP routing protocol: Two Dimensional IP routing protocol, 153 which makes routing decisions based on both destination and source 154 IP addresses. 156 * SID: Segment Identifier. 158 * SRv6: Segment Routing over IPv6 data plane. 160 * SR Policy: a framework that enables instantiation of an ordered 161 list of segments on a node for implementing a source routing 162 policy with a specific intent for traffic steering from that node. 164 3. Benefit of extend Segment routing to support TwoD-IP routing 166 This section lists two scenarios which can benefit from TwoD-IP 167 routing protocol with Segment Routing technology. Illustrating that 168 TwoD-IP routing protocol can seamless deployment with SR and combine 169 their advantage to achieve users demands of higher dimensional 170 routing. 172 3.1. Multi-homing 174 Even though Segment Routing is able to steer flows to the destination 175 in different way, it is still limited to process the source-related 176 routing scenario like Multi-homing. 178 Multi-homing[RFC4177] is prevalent among ISPs for better traffic 179 distribution and reliability. In this case, a network could be 180 connected to multiple upstream ISPs, Hosts are assigned multiple 181 addresses, one for each ISP. The network is responsible for 182 delivering packets from Hosts to the export exit router that is 183 connected to the corresponding upstream ISP. 185 For example, in Figure 1, a multi-homed site is connected to two 186 ISPs: ISP1 and ISP2. ISP1 has a prefix P1, and ISP2 has a prefix P2. 187 A host connect to the multi-homed site has two addresses, address A 188 that assigned from ISP1, and address B that assigned from ISP2. the 189 multi-homed site should deliver the traffic from A towards the 190 Internet to ISP1, and deliver the traffic from B towards the Internet 191 to ISP2. 193 +--------------------+ 194 | | 195 | Internet | 196 | | 197 +--+---------------+-+ 198 | | 199 | l3 | l4 200 | | 201 +------+----+ +--+--------+ 202 | ISP1 | | ISP2 | 203 | Prefix P1 | | Prefix P2 | 204 +--------+--+ +-+---------+ 205 | | 206 | l1 | l2 207 +--+------------+--+ 208 | | 209 | Multi-homed Site | +---------+ 210 | +--------+ Host | 211 +------------------+ +---------+ 212 ISP1 assign address: A 213 ISP2 assign address: B 215 Figure 1: Multi-homing scenario 217 Although SR can assign different forwarding paths to different ISP 218 for an incoming packet, it still lacks the ability to classify the 219 packets toward the same destination address with different source 220 addresses A and B. With the help of TwoD-IP and Segment Routing, the 221 administrator can easily implement Multi-homing by modifying the 222 headend node that receives packets from Host, which means that 223 administrator does not need to concern about the intermediate node. 224 After extending SR to support TwoD-IP routing, the headend node can 225 routing packet based on both source and destination address, guides 226 packets from Host through the optimal path to the corresponding ISP. 228 3.2. Source Related Policy Routing 230 In this scenario, an ingress edge node wants to forward packets with 231 the same destination address through different kind of paths in order 232 to achieve source related demand. 234 For example, in Figure 2, assume a network has four routers: a, b, c 235 and d, c has a service(such as authentication or encIPherer). The 236 operator wants a packet from a to d to be delivered to service c 237 first and then node c will forward the processed packet to it's 238 destination d. 240 +---------+ 241 +------+ c +-----+ 242 | +(service)+ | 243 | +---------+ | 244 | | 245 +------+ +--+---+ +---+--+ 246 | a +----------+ b +--------------+ d | 247 +------+ +------+ +------+ 249 Figure 2: TwoD-IP routing for Service 251 In Segment Routing Architecture, we can allocate a Service segment 252 associated with node c's 253 service.[I-D.ietf-spring-sr-service-programming] and can be 254 integrated as part of an SR Policy P1(Headend node: b, color, 255 Endpoint: d) of Segment-List < c > . But SR Policy steers packets to 256 a specific SR Policy only when this packet's destination matching 257 corresponding entry, which means headend node can't only steers 258 packets from a to SR Policy P1. 260 But with TwoD-IP routing, headend node b can easily steer packets 261 matching destination of b and source of a to SR Policy P1, then the 262 packet will be delivered to service c first and then node c will 263 forward the processed packet to it's destination d. 265 4. Framework 267 The mechanism of how we combine TwoD IP routing and Segment Routing 268 can be separated into the data plane and the control plane. 270 The data plane is mainly concerned about the forward table. It is 271 the foundation of two-dimensional packets forwarding. It needs to be 272 able to store the two-dimensional information of destination and 273 source address without expanding TCAM resource, and the lookup 274 process needs to be quick to support massive packets routing. Then 275 we describe the lookup process and forwarding table updating based on 276 it. 278 Under SR Two-D IP routing, The control plane is concerned with 279 network status and user demands related to pair. It needs to transform the user demand to the 281 Policy routing and integrate the Policy routing to the forwarding 282 table so that the headend node can steers packets to a Policy routing 283 representing user demand by checking the packet's pair. 286 5. Data Plane 288 The administrator only need to deploy the TwoD-IP forwarding table in 289 the headend node, which makes implementing TwoD-IP routing is much 290 easier. TwoD-IP routing leverages the Segment Routing to deploy the 291 TwoD-IP forwarding table in the headend, which makes implementing 292 TwoD-IP routing is much easier. To achieve the ability of steering 293 packets' forwarding path to follow our decision, we are not willing 294 to damage the existing segment routing architecture. 296 The fast, massive packets routing required fast forwarding entries 297 searching speed, which required the TCAM to store the forwarding 298 entries. However, the TCAM resource is limited under TwoD-IP routing 299 for the dimensional explosion problem in which two-d forward entries 300 grow exponentially. To routing massive packets as fast as possible, 301 a brand new forwarding table structure needs to be design 303 5.1. Forwarding Table Design 305 5.1.1. Design Goals 307 Unlike the existing SR Policy architecture that steers packets into 308 matching Binding SID based on destination field in the packet, the 309 TwoD-IP routing should steer packets into a BSID according to both 310 the destination and source IP address. The new forwarding table 311 design should satisfy the following requirements: 313 * Compatibility. The forwarding table SHALL NOT be incompatible 314 with the existing Segment Routing deployment to assign the 315 forwarding path according to the two-dimensional IP address in the 316 headend node. 318 * Speed requirement. The TCAM must be used for fast searching and 319 should parallel the IP searching for both destination and source 320 address 322 * Storage requirement. TCAM resources will be limited for the 323 higher dimensional routing to avoid dimensional explosion problem, 324 the destination and source address needs to be stored seperatelly 326 5.1.2. Forwarding Table Structure 327 Source +------------+------+------+------+------+ 328 Table |default | 111* | 101* | 100* | 11** | 329 +------------+------+------+------+------+ 330 | 0 | 1 | 2 | 3 | 4 | 331 +------------+------+------+------+------+ 332 Destination default Mapping Table 333 Table | FIB Index | index | 334 +-------+---+ --+-----------+------+------+------+------+--- 335 | 111* | 0 | | 0 | 0 | | 1 | | 336 +-------+---+ --+-----------+------+------+------+------+--- 337 | 100* | 1 | | 1 | 2 | | | | 338 +-------+---+ --+-----------+------+------+------+------+--- 339 | 101* | 2 | | 2 | | | | 2 | 340 +-------+---+ --+-----------+------+------+------+------+--- 341 | 11** | 3 | | 3 | | | | | 342 +-------+---+ --+-----------+------+------+------+------+--- 343 | 10** | 4 | | 4 | | | | 3 | 344 +-------+---+ --+-----------+------+------+------+------+--- 345 | | | | | | 346 TD-table 348 +------+---------+ +------+---------+ 349 |Index |Next hop | |prefix|Next hop | 350 +------+---------+ +------+---------+ 351 | 0 |BSID1 | | 0 |1.0.0.0 | 352 +------+---------+ +------+---------+ 353 Mapping | 1 |BSID1 | Default | 1 |1.0.0.1 | 354 Table +------+---------+ FIB +------+---------+ 355 | 2 |BSID2 | | 2 |1.0.0.2 | 356 +------+---------+ +------+---------+ 357 | 3 |BSID3 | | 3 |1.0.0.3 | 358 +------+---------+ +------+---------+ 360 Figure 2: SR in Two-Dimensional IP Routing Forwarding Table Structure 362 To achieve all design goals of the forwarding table, we integrate the 363 TwoD-IP routing forwarding table structure called FIST into Segment 364 Rouitng's FIB. As shown in Figure 3, the forwarding table structure 365 consists of the following components: 367 * Destination table: It resides in TCAM for fast lookup, and stores 368 the destination prefixes. Each destination prefix in the 369 destination table corresponds to a row number. 371 * Source table: It resides in TCAM for fast lookup, and stores the 372 source prefixes. Each source prefix in the source table 373 corresponds to a column number. 375 * Two Dimensional Table (TD-table): A two-dimensional array resides 376 in SRAM. Given a row and column numbers, we can find a cell in 377 TD-table. Each cell in TD-table stores an index value of default 378 FIB or Mapping table, which can be mapped to a next-hop. 380 * Mapping table: It resides in SRAM, and maps index values to next 381 hops, and the next hop of mapping table will be the Binding SID, 382 which represents the forwarding path we set. 384 * Default FIB: It is the same as the existing FIB, which can reside 385 in TCAM or SRAM. The keys of the entries MUST be in keeping with 386 the Destination Table. 388 5.1.3. Lookup Action 390 Even though there is a Default FIB in forwarding table structure 391 which is the same as existing FIB, the lookup action is not based on 392 it, it based on the Destination and Source Table. More specific, 393 when a packet arrives at the source router, the lookup action is as 394 follows. 396 1. Extract the destination address d and source address s from the 397 packet; 399 2. Perform the following two operations in parallel: 401 * Lookup the destination address d in the destination table 402 using the LMF rule, and output the row number n; 404 * Lookup the source address s in the source table using the LMF 405 rule, and output the column number m; 407 3. Lookup the cell that is in the nth row and mth column of the TD- 408 table, and output the index value v of default FIB or Mapping 409 table: 411 * If there's TwoD-IP rule corresponding to the pair, the output column number m of the source table 413 will not be default (i.e. 0), so the index value of v will 414 corresponds to the Mapping table. So we lookup v in the 415 mapping table, and output the corresponding next hop; 417 * If there is not TwoD-IP rule corresponding to the 418 pair, the output column number m of the 419 source table will be default (i.e. 0), so the index value of v 420 will corresponds to the Default FIB. So we lookup v in the 421 Default FIB, and output the corresponding next hop; 423 The most considerable lookup time is the entries searching for the 424 address. To speed it up, we store the destination and source address 425 IP prefix in TCAM, and look up those tables in parallel. After 426 getting the output index of the entries based on the pair, every subsequent lookup action will 428 consume one SRAM clock cycle. 430 The SR TwoD-IP routing should activate the policy routing based on 431 the packet's pair in the 432 headend node. Moreover, the SR architecture has provided an 433 identification called Binding segment (BSID) to represent a policy 434 routing. So the next hop in the Mapping table SHOULD steer the 435 packet into the BSID of SR Policy, which represents a Segment-List. 437 5.1.4. Forwarding table Update Action 439 In Segment Routing in Two Dimensional IP Routing architecture, not 440 only TwoD-IP routing will modify the forwarding table FIST to satisfy 441 its routing policy, but the existing Segment Routing Policy will also 442 deploy its routing Policy. We do not want to damage the existing 443 Segment Routing architecture, so it is still available for Segment 444 Routing to modify the FIB to steer packets into specific SID such as 445 SR Policy On-Demand next hop. However, any modification of FIB in 446 Segment Routing MUST reside in FIST Default FIB, and if there are any 447 modifications of keys in FIST Default FIB, the Destination Table must 448 be in keeping with it for correcting lookup. 450 The reason any modification of SR Policy MUST resides in FIST Default 451 FIB is that under segment Routing in Two Dimensional IP Routing 452 architecture, the TwoD-IP routing policy is priority-first. The 453 routing Policy located in FIST Default FIB will be matched only when 454 there is no TwoD-IP policy corresponding to incoming packet's 455 pair. 457 6. Control Plane 459 Under SR Two-D IP routing, The control plane is concerned with 460 network status and user demands. Furthermore, The Two-D IP routing 461 can offload the network status like topology or reachability to the 462 SR framework. However, the Two-D IP routing is still responsible for 463 transforming the user demand of two-dimensional destination and 464 source addresses to the forwarding Policy and integrating it to the 465 forwarding table. 467 The control plane of SR Two-D IP routing is consists of the following 468 parts: 470 * TwoD-IP configuration exchange: TwoD-IP routing protocol focus on 471 transforming users demand for destination and source address pairs 472 to forwarding action, which means we have one more dimension of 473 source address information to exchange along with headend node, 474 along with the forwarding configurations corresponding to the 475 destination and source address pairs. 477 * TwoD-IP forwarding path computation: We leverage the SR Policy 478 Dynamic Path Computation to achieve forwarding path computation, 479 transferring our demand for pair to 480 optimization object and constraint source format which can specify 481 a dynamic candidate path of SR Policy, then the dynamic candidate 482 path can be computed by either the headend or a Path Computation 483 Element (PCE). 485 6.1. Advertisement of TwoD-IP configuration 487 The headend node needs to transform the TwoD-IP configuration to the 488 Policy routing and install it into the forwarding table to achieve 489 the two-dimensional IP routing. We need to be concerned about how to 490 notification these TwoD-IP configurations to the headend node. There 491 are two practical ways to achieve this object: install the headend 492 node manually or advertise these TwoD-IP configurations from other 493 nodes to the headend node. 495 When advertising TwoD-IP configurations between nodes, three parts 496 needs to be carried: destination addresses, source addresses, and the 497 user demands of the pairs. Because we leverage 498 the SR Policy to represent the routing policy and SR Policy Dynamic 499 Path Computation to compute the target forwarding path, the user 500 demand will be expressed as an optimization objective and 501 constraints. 503 6.1.1. TwoD-IP configuration architecture 505 The configurations of TwoD-IP routing is organized as TwoD-IP 506 configuration TLV. For example, this brand new TLV can be a TLV of 507 OSPFv3 Router Information(RI) LSA, which introduce the ability to 508 broadcast the TwoD-IP configuration information between OSPF nodes by 509 advertising an OSPFv3 RI LSA that carries the TwoD-IP configuration 510 TLV. 512 More specifically, all three kinds of TwoD-IP configuration, 513 including destination addresses, source addresses, and the user 514 demands of the pairs are all included within 515 the TwoD-IP configuration TLV as three kinds of Sub-TLVs. The TwoD- 516 IP configuration TLV is the same as the format used by[RFC3630]. The 517 variable TLV section consists of one or more nested TLV tuples. The 518 format of each TLV is: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type | Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Sub-TLVs | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Figure 3. TwoD-IP configuration TLV Format 530 Where: 532 Type is TBD 534 Length: 16 bit field. The total length of the value portion(Sub- 535 TLVs) of the TLV 537 Sub-TLVs: Each TwoD-IP configuration TLV has three kinds of Sub- 538 TLVs: Demands Sub-TLV, destination address Sub-TLV and source 539 address Sub-TLV. These Sub-TLVs represent the two-dimensional 540 information of destination and source addresses and corresponding 541 user demands of pairs. 543 6.1.2. Demands Object Sub-TLV 545 To leverage the ability of SR Policy Dynamic Path Computation, the 546 user demand MUST be represented by the formation of Optimization 547 object and constraints. So each user demand carried by Demands 548 Object Sub-TLV is consists of Optimization object and constraints 549 information. And the Optimization and the constraint is refer to the 550 [I-D.filsfils-spring-sr-policy-considerations]. 552 The format of Demands Object Sub-TLV is: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Reserved |O Flags| Optimize T | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Reserved |C Flags| Constraint T | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Constraint variables | 564 | ... | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 4: Optimization Object Sub-TLV Format 569 Where: 571 Type: 16 bit field. The value is 1 for this type. 573 Length: 16 bit field. The total length of the value portion of 574 the Sub-TLV. 576 Reserved (20 bits): This field MUST be set to zero on transmission 577 and MUST be ignored on receIPt. 579 O Flags(4 bits): Optimization object Flags, identify the 580 optimization objective, The following flags are defined: 582 0 1 2 3 583 +-+-+-+-+ 584 |M|N| | 585 +-+-+-+-+ 587 Where: 589 * M flag: Min-Metric - requests computation of a solution 590 Segment-List optimized for a selected metric. 592 * N flag: Min-Metric with margin and maximum number of SIDs - Min 593 Metric with two changes: a margin of by which two paths with 594 similar metrics would be considered equal, a constraint on the 595 max number of SIDs in the Segment-List. 597 Optimize T (Type - 8 bits): Specifies the metric type. Three 598 values are currently defined: 600 * T=1: IGP metric 601 * T=2: TE metric 603 * T=3: Hop Counts 605 * T=4: Delay 607 C Flags(4 bits): Constraints Flags, iIdentify the Constraints of 608 forwarding path computation, The following flags are defined: 610 0 1 2 3 611 +-+-+-+-+ 612 |I|E|D| | 613 +-+-+-+-+ 615 Where: 617 * I flag: Inclusion 619 * E flag: Exclusion 621 * D flag: Diversity to another service instance (e.g., link, 622 node) 624 Constraint T (Type - 8 bits): Specifies the metric type. Two 625 values are currently defined: 627 * T=1: TE affinity 629 * T=2: IPv6 address(can be an SRv6 SID) 631 variable: 128 bit field. Corresponding to the type defined in 632 Constraint T. 634 6.1.3. destination/source address Sub-TLV 636 A TwoD-IP routing demand corresponding a pair, 637 so the Optimization object and constraint define a TwoD-IP demand and 638 naturally need to bind a pair. The pair's 639 information is carried in destination/source address Sub-TLV, and 640 it's format is: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type | Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | PrefixLength |T| Reserved | PrefixNumbers | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Address Prefix1 | 650 | ... | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Address Prefix2 | 653 | ... | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | ... | 656 | | 658 Figure 6: destination/source address Sub-TLV Format 660 Where: 662 Type: 16 bit field. The value is 3 for destination address, 4 for 663 source address. 665 Length: 16 bit field. The total length of the value 666 portion(addresses information) of the TLV. 668 PrefixLength: 8 bit field. The length of IPv6 address. The IPv6 669 address information is transferring in Prefix format in order to 670 reduce packet length and all the addresses needed to transferring 671 is group by same prefix length. 673 T (dimensional type): 1 bit. 0 for destination addresses, 1 for 674 source addresses. 676 Reserved (7 bits): This field MUST be set to zero on transmission 677 and MUST be ignored on receIPt. 679 PrefixNumbers: 16 bit field. The number of address prefix in the 680 length of PrefixLength. 682 Address Prefix: The address prefix in the length of PrefixLength 683 and will be padded with 0 to fit the multiple 32 bit length. 685 6.2. TwoD-IP forwarding path computation 687 The procedure of transforming the TwoD-IP configuration to a 688 forwarding path and steering corresponding packets through it 689 consists of two steps: Calling the SR Policy Dynamic candidate path 690 and TwoD-IP forwarding table entries modification. 692 6.2.1. Setting up the SR Policy Dynamic candidate path 694 In keeping with SR Policy Dynamic Path Computation, the TwoD-IP 695 configuration contains the Optimization object and constraint 696 information. when the headend node receives TwoD-IP configuration 697 information(manually or automatically), it will extract the 698 Optimization object and constraint information to generate a 699 corresponding SR Policy . 701 The candidate path associated of an SR Policy is a dynamic candidate 702 path that is expressed by optimization objective and a set of 703 constraints extracted from the TwoD-IP Demands Sub-TLV. Then the 704 headend node(or with the help of a PCE) computes the solution 705 Segment-List that solves the optimization problem to match our TwoD- 706 IP routing demand. After path computation, the SR Policy can 707 represent the forwarding path that satisfies the TwoD-IP Demand. Any 708 packets steered to this SR Policy can be forwarded to the destination 709 following the target path. After offloading the path computation to 710 SR without private custom, TwoD-IP routing can achieve higher 711 compatibility and easier deployment. 713 6.2.2. TwoD-IP forwarding table entries modification 715 an SR Policy can be represented by the identifier called Binding 716 segment (BSID) under Segment Routing architecture. So after path 717 computation under user demands, we can get the SR policy which 718 represents the target forwarding path and the BSID associated with 719 it. Then we need to install this BSID into the TwoD-IP forwarding 720 table so that the TwoD-IP forwarding table can match and steer 721 packets into target BSID, and forward them through SR Policy dynamic 722 path. 724 More specifically, The control plane will install the BSID into the 725 Mapping Table and get the index of entry that stores it. then for all 726 the pairs associated with this 727 BSID, the control plane will update the TD-table cells of these pairs 728 to the Mapping Table index or update entries to the source or 729 destination table if there is an uninstalled pair. 731 7. Security Considerations 733 This document does not introduce additional security requirements and 734 mechanisms. 736 8. IANA Considerations 738 This memo asks the IANA for no new parameters. 740 9. References 742 9.1. Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, 746 DOI 10.17487/RFC2119, March 1997, 747 . 749 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 750 Decraene, B., Litkowski, S., and R. Shakir, "Segment 751 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 752 July 2018, . 754 9.2. Informative References 756 [I-D.filsfils-spring-sr-policy-considerations] 757 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 758 P. Mattes, "SR Policy Implementation and Deployment 759 Considerations", Work in Progress, Internet-Draft, draft- 760 filsfils-spring-sr-policy-considerations-08, 22 October 761 2021, . 764 [I-D.ietf-spring-segment-routing-policy] 765 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 766 P. Mattes, "Segment Routing Policy Architecture", Work in 767 Progress, Internet-Draft, draft-ietf-spring-segment- 768 routing-policy-18, 17 February 2022, 769 . 772 [I-D.ietf-spring-sr-service-programming] 773 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 774 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 775 S. Salsano, "Service Programming with Segment Routing", 776 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 777 service-programming-05, 10 September 2021, 778 . 781 [I-D.xu-rtgwg-twod-IP-routing] 782 Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP 783 Routing Architecture", Work in Progress, Internet-Draft, 784 draft-xu-rtgwg-twod-IP-routing-00, 4 March 2012, 785 . 788 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 789 (TE) Extensions to OSPF Version 2", RFC 3630, 790 DOI 10.17487/RFC3630, September 2003, 791 . 793 [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for 794 IPv6", RFC 4177, DOI 10.17487/RFC4177, September 2005, 795 . 797 Authors' Addresses 799 Mingwei Xu 800 Tsinghua University 801 Department of Computer Science, Tsinghua University 802 Beijing 803 Phone: +86-10-6278-5822 804 Email: xmw@csnet1.cs.tsinghua.edu.cn 806 Bo Wang 807 Tsinghua University 808 Beijing 809 Email: wangbo2019@tsinghua.edu.cn 811 Tingfeng Wang 812 Beijing University of Posts and Telecommunications 813 Beijing 814 P.R. China 815 Email: wangtingfeng@bupt.edu.cn 816 Shu Yang 817 Shenzhen University 818 Guangdong 819 P.R. China 820 Email: yang.shu@szu.edu.cn 822 Jianping Wu 823 Tsinghua University 824 Beijing 825 P.R. China 826 Email: jianping@cernet.edu.cn