idnits 2.17.00 (12 Aug 2021) /tmp/idnits53872/draft-lhan-satellite-instructive-routing-00.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 (6 March 2022) is 69 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 459 -- Looks like a reference, but probably isn't: '1' on line 459 == Outdated reference: A later version (-01) exists of draft-lhan-satellite-semantic-addressing-00 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Han, Ed. 3 Internet-Draft A. Retana 4 Intended status: Informational R. Li 5 Expires: 7 September 2022 Futurewei Technologies, Inc. 6 6 March 2022 8 Semantic Address Based Instructive Routing for Satellite Network 9 draft-lhan-satellite-instructive-routing-00 11 Abstract 13 This document presents a method to do IP routing over satellite 14 network that consists of LEO (Low Earth Orbit) satellites and ground- 15 stations. The method uses the source routing mechanism. The whole 16 routing info is obtained by path calculation. The routing path 17 information is converted to be a list of instructions and embedded 18 into user packet's IPv6 extension header. At each hop or each 19 satellite, the routing process engine will forward the packet based 20 on the specified instruction for the satellite. Until the packet 21 reaches the edge of satellite network, or the last satellite, the 22 packet will be sent to a ground station. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 7 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Review of LEO satellite constellation for future Internet . . 5 60 4. Basics of Instructive Routing . . . . . . . . . . . . . . . . 6 61 5. IPv6 Routing Header for Instructive Routing . . . . . . . . . 9 62 6. Instruction List for Instructive Routing . . . . . . . . . . 10 63 7. Instructive Routing Behaviors . . . . . . . . . . . . . . . . 11 64 7.1. Fwd.Inc.Sat_ID . . . . . . . . . . . . . . . . . . . . . 12 65 7.2. Fwd.Dec.Sat_ID . . . . . . . . . . . . . . . . . . . . . 13 66 7.3. Fwd.Inc.Opb_ID . . . . . . . . . . . . . . . . . . . . . 14 67 7.4. Fwd.Dec.Opb_ID . . . . . . . . . . . . . . . . . . . . . 15 68 7.5. Fwd.Inc.Shl_ID . . . . . . . . . . . . . . . . . . . . . 16 69 7.6. Fwd.Dec.Shl_ID . . . . . . . . . . . . . . . . . . . . . 17 70 7.7. End.Intf_ID . . . . . . . . . . . . . . . . . . . . . . . 18 71 7.8. End.Punt . . . . . . . . . . . . . . . . . . . . . . . . 18 72 7.9. End.Lookup . . . . . . . . . . . . . . . . . . . . . . . 19 73 7.10. End.Lookup.IPv4 . . . . . . . . . . . . . . . . . . . . . 19 74 7.11. End.Lookup.IPv6 . . . . . . . . . . . . . . . . . . . . . 20 75 7.12. Fwd.Sat_Addr . . . . . . . . . . . . . . . . . . . . . . 20 76 7.13. Fwd.Sat_MacAddr . . . . . . . . . . . . . . . . . . . . . 21 77 7.14. 78 Forwarding_API(Packet,Input_Satellite,Input_Direction) . 22 79 7.15. Forwarding_API_SAT(Packet,Input_Satellite,Sat_Addr) . . 22 80 7.16. 81 Forwarding_API_MAC(Packet,Input_Satellite,Sat_MacAddr) . 22 82 7.17. Forwarding_GS_API(Packet,Input_Interface) . . . . . . . . 23 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 89 12.2. Informative References . . . . . . . . . . . . . . . . . 24 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 Massive LEO constellation is expected to be used for future Internet. 96 It has raised challenges to the current IP networking technologies to 97 support such super-fast-moving network. 98 [I-D.lhan-problems-requirements-satellite-net] has analyzed the 99 problems when using the regular routing protocols in such network. 101 Since all satellites in a LEO constellation are well organized and 102 form a kind of multi-layered grid network, each satellite's relative 103 position in the satellite network will be steady during its life 104 time. [I-D.lhan-satellite-semantic-addressing] has proposed to use 105 couple of indexes to identify each satellite in the network. The 106 combination of the indexes is called the satellite semantic address. 107 The semantic address can be embedded into the field of the interface 108 identifier (i.e., the rightmost 64 bits) of the IPv6 address, if IPv6 109 is used in the satellite network. 111 This memo proposes a method for routing for satellite network, it is 112 based on the satellite semantic address. The routing information is 113 embedded into the IPv6 packet as routing extension header defined in 114 [RFC8200]. Unlike the segment routing [RFC8754] and programming 115 [RFC8986], The new method will not use IPv6 SID (Segment Identifier) 116 to represent the segments on the routing path. Instead, it will 117 convert the segments on the path to be a list of instructions since 118 each satellite could be represented by the semantic address. Each 119 instruction can tell each satellite how to forward the packet to a 120 adjacent satellite, either on the same orbit, or on the adjacent 121 orbit. 123 Compared with the traditional IP forwarding, the new method will not 124 use TCAM (Ternary Content-addressable Memory) lookup for IP prefix. 125 Each satellite only needs to store a simple adjacency table. 126 Therefore, the new method can save significant TCAM and the 127 processing time for routing/forwarding tables. 129 It must be noted this memo just describes one aspect of the whole 130 solution for satellite constellation used for Internet access and NTN 131 (Non-Terrestrial Network) integration with 5G, following areas are 132 not covered in this memo and will be addressed in other documents 133 separately: 135 1. IP forwarding path calculation for a LEO constellation. 137 2. Data planes for different scenarios, such as Internet access and 138 NTN integration. 140 3. Other protocols for control plane. 142 2. Terminology 144 LEO Low Earth Orbit with the altitude from 180 km to 145 2000 km. 147 LEO constellation LEO constellation consists of certain number of 148 LEOs. Each LEO has pre-assigned orbit element. 150 ISL Inter Satellite Link 152 GS Ground Station, a device on ground connecting 153 satellite. In the document, GS will hypothetically 154 provide L2 and/or L3 functionality in addition to 155 process/transmit/receive radio wave. It might be 156 different as the reality that the device to 157 process/transmit/receive radio wave and the device 158 to provide L2 and/or L3 functionality could be 159 separated. 161 L2 Layer 2, or Data Link Layer in OSI model 162 [OSI-Model] 164 L3 Layer 3, or Network Layer in OSI model [OSI-Model], 165 it is also called IP layer in TCP/IP model 167 OS Operating System 169 NTN Non-Terrestrial Network 171 SID Segment Identifier 173 Sat-GS Links Wireless links between satellites and ground- 174 stations, it consists of uplink (from ground to 175 satellite) and downlink (from satellite to ground. 177 Link Metrics The cost of the outgoing interface for routing, 178 typically, it may indicate the bandwidth, delay or 179 other costs for the interface. 181 Sat_ID Satellite Index, the Index for the satellite in a 182 orbit plane, see 183 [I-D.lhan-satellite-semantic-addressing] 185 Obp_ID Orbit Plane Index, the Index for the orbit plane in 186 a shell group of satellite, see 187 [I-D.lhan-satellite-semantic-addressing] 189 Shl_ID Shell Index, the Index for the shell group of 190 satellite in a satellite constellation, see 191 [I-D.lhan-satellite-semantic-addressing] 193 Intf_ID Interface Index 195 Sat_Addr Satellite Semantic Address, it consists of indexes 196 Shl_ID, Obp_ID and Sat_ID. It is 32-bit long and 197 is defined in Section 5.4 in 198 [I-D.lhan-satellite-semantic-addressing] 200 Sat_MacAddr The MAC (Media Access Control) Address for a 201 satellite 203 3. Review of LEO satellite constellation for future Internet 205 LEO satellite constellation is expected to be integrated with 206 terrestrial network in future Internet. StarLink project [StarLink] 207 has launched its satellites and provided the beta service in some 208 areas. 3GPP [ThreeGPP] has studied the issues when NTN is integrated 209 with Internet and 5G. 3GPP [TR38-821] has also proposed the 210 Satellite-based NG-RAN architectures for NTN integration. The 211 targets of LEO constellation for future Internet and NTN integration 212 are as follows: 214 1. Global coverage: The Satellite network should cover all places on 215 earth and any flying objects as long as the place or objects are 216 below LEO attitude and within the coverage footprint of satellite 217 constellation, the satellite network should be the complementary 218 to terrestrial network. 220 2. Internet access: The Satellite network can provide the Internet 221 access service for covered areas. 223 3. NTN integration: The Satellite network is fully integrated with 224 Internet including Wireless such as 4G or 5G. 226 4. Competitive service: The Satellite network can provide the 227 services that are competitive to terrestrial network in terms of 228 service stability, Quality of Service, especially the latency for 229 Satellite network is shorter. 231 As a new form of network, LEO constellation has lots of difference 232 with the steady terrestrial network especially in the mobility. 233 [I-D.lhan-problems-requirements-satellite-net] has analyzed the 234 movement and coverage of satellite. For a massive LEO constellation, 235 all satellites are moving on the allocated orbits, and form one or 236 multiple layers of network. Finally, the massive LEO constellation 237 will have the following unprecedented mobility: 239 1. Each LEO moves at the speed of 7.x km/s. 241 2. Ground Stations move at the speed of 463 m/s due to earth 242 rotation. 244 3. Half of LEOs move on the direction that is different with another 245 half of LEOs. 247 4. Huge number of links between satellites and ground-stations, and 248 all of them are constantly flipping within short period of time. 249 All Link Metrics of Sat-GS Links are also constantly changing. 251 5. All Link Metrics of ISL on the Longitude direction are constantly 252 changing. 254 6. All Links of ISL on the Longitude direction may be interrupted at 255 two polar areas. 257 4. Basics of Instructive Routing 259 When using ISL for satellites in a LEO constellation, each layer of 260 network will have satellite nodes connected by limited ISLs. A 261 typical satellite will have about six ISL to connected to its 262 adjacent satellites in 3D space. Additionally, there might have very 263 few numbers of ISL working as un-steady link to connect to other 264 satellites. Un-stead links are those between satellites moving to 265 different directions, see 266 [I-D.lhan-problems-requirements-satellite-net] for the detailed 267 explanation. After using the semantic address for each satellite, 268 the satellite relationship will be static. Figure 1 illustrates one 269 satellite and its six direct connected adjacent satellites, it is 270 easy to determine some indexes of its adjacent satellites: 272 1. S0, S1 and S2 have the same Shl_ID, the difference of Obp_ID 273 between S0 and S1, S0 and S2 are both equal to one. 275 2. S0, S3 and S4 have the same Shl_ID and Obp_ID, the difference of 276 Sat_ID between S0 and S3, S0 and S4 are both equal to one. 278 3. S0, S5 and S6 have different Shl_ID, and the difference of Shl_ID 279 between S0 and S5, S0 and S6 are both equal to one. 281 Another benefit to use the semantic address is that the packet 282 forwarding for routing and switching will be simplified 283 significantly. There will be only six major forwarding directions to 284 the directly connected adjacent satellites described above, plus one 285 or few specified directions probably. The specified direction is to 286 forward packet to a specified adjacent satellite through an un-steady 287 link. The un-steady link can connect to any satellite but only last 288 for a short time. The usage of un-steady links are expected to be 289 limited and are not major scenarios in a LEO constellation. 290 Following are all directions for forwarding: 292 1. Forward to the Sat_ID Incremental or Decremental directions. 294 2. Forward to the Obp_ID Incremental or Decremental directions. 296 3. Forward to the Shl_ID Incremental or Decremental directions. 298 4. Forward to a specified satellite through an un-steady link. 300 ^ Shl_ID Incremental direction 301 | 302 / 303 / 304 S5 ^ Sat_ID Increment direction 305 /| / 306 / | S3 307 / / | / / 308 / / | / / 309 / |/ / 310 S2------S0------S1 -> Obp_ID Increment direction 311 / /| / / 312 / / | / / 313 / / | / / 314 S4 |/ 315 S6 316 / 317 / 318 / 320 Figure 1: The LEO Satellite Relationship in 3D Space 322 Figure 2 illustrates a 2D example. It shows how a packet is 323 forwarded in a grid satellite network. The forwarding path consists 324 of a series of segments, and each segment consists of two satellites 325 at its two ends. One segment could be on either the same orbit plane 326 or crossing adjacent orbit plane. Intuitively, we can obtain the 327 list of instructions to guide the packet and get the forwarding 328 behaviors at different satellites. Following is an example: 330 1. At S1 to S2, forward packet to the Sat_ID Incremental direction, 331 until the packet reaches S2 333 2. At S2 to S3, forward packet to the Obp_ID Incremental direction, 334 until the packet reaches the orbit plane of S3 336 3. At S3 to S4, forward packet to the Sat_ID Incremental direction, 337 until the packet reaches S4 339 4. At S4 to S5, forward packet to the Obp_ID Decremental direction, 340 until the packet reaches the orbit plane of S5 342 5. At S5 to S6, forward packet to the Sat_ID Decremental direction, 343 until the packet reaches S6 345 Obviously, at each satellite, the forwarding logic needs to check if 346 the satellite reaches the end of a segment on the route path. In the 347 regular segment routing, the SID is used to do such indication. But 348 for satellite network, since satellite's semantic address is embedded 349 into the IPv6 address, it is not needed to include the long SID into 350 the packet header. Instead, it will be much saving if we only embed 351 one of three indexes information of the satellite semantic address in 352 the instruction argument, and then we can further simplify the above 353 instructions as: 355 1. At S1 to S2, forward packet to the Sat_ID Incremental direction, 356 until the packet reaches a satellite and the satellite's Sad_ID 357 is equal to the given instruction argument (S2's Satellite Index) 359 2. At S2 to S3, forward packet to the Obp_ID Incremental direction, 360 until the packet reaches a satellite and the satellite's Obp_ID 361 is equal to the given instruction argument (S3's Orbit Plane 362 Index) 364 3. At S3 to S4, forward packet to the Sat_ID Incremental direction, 365 until the packet reaches a satellite and the satellite's Sat_ID 366 is equal to the given instruction argument (S4's Satellite Index) 368 4. At S4 to S5, forward packet to the Obp_ID Decremental direction, 369 until the packet reaches a satellite and the satellite's Obp_ID 370 is equal to the given instruction argument (S5's Orbit Plane 371 Index) 373 5. At S5 to S6, forward packet to the Sat_ID Decremental direction, 374 until the packet reaches a satellite and the satellite's Sat_ID 375 is equal to the given instruction argument (S6's Satellite Index) 376 ^ Sat_ID Incremental Direction 377 | 378 | 379 +----> Obp_ID Incremental Direction 381 x: The ISL is down 383 Obp_ID Obp_ID+1 Obp_ID+2 Obp_ID+3 Obp_ID+4 384 | | | | | 385 ----+-------S5<<<<<>>>>>S>>>>>>>S>>>>>>>S3------+---- 392 ^ | | | | 393 ^ | | | | 394 ----S---x---+-------+-------+-------+---- 395 ^ | | | | 396 ^ | | | | 397 ----S1--x---+-------+-------+-------+---- 398 | | | | | 399 | | | | | 401 Figure 2: Packet Forwarding in 2D LEO satellite constellation network 403 5. IPv6 Routing Header for Instructive Routing 405 For instructive routing, IPv6 routing header is used with a new 406 routing type "Instructive Routing Type". The format of the new 407 routing header is illustrated in Figure 3. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Next Header | Hdr Ext Len | Routing Type | Inst. Offset | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |Remained Inst. | ST | Rsvd | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Inst. List ~ 417 | +-+-+-+-+-+-+-+-+ 418 | ~ paddings | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 3: The IPv6 Routing Hdr for Instructive Routing 423 Routing Type Instructive Routing Type 425 Inst. Offset The offset in the number of octets from the start of 426 Instruction List. The initial value is set to 0 and 427 it points to the 1st instruction to be executed. The 428 value is incremented by the number of octets of the 429 total size of a instruction after the instruction is 430 executed. 432 Remained Inst. Remained Number of Instructions. The initial value 433 is set to the total number of instructions. The 434 value will be decremented by one after one 435 instruction is executed. The minimum number is one, 436 and it indicates that the end of instruction stack is 437 reached. 439 ST The satellite address type, default is 0. 441 Inst. List A list of instructions, the size is variable. 443 Paddings Pad1 or PadN options to make the packet extension 444 header alignment, see [RFC8200] 446 6. Instruction List for Instructive Routing 448 For instructive routing, the instruction list is used to instruct 449 each satellite how to do routing job. The format of the instruction 450 list is illustrated in Figure 4. Each instruction consists of 451 Function Code and Arguments. 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Func. Code | Arguments | Func. Code | Arguments ~ 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 \--------------\/--------------/ \--------------\/--------------/ 459 instruction[0] instruction[1]... 461 Figure 4: The Instruction List for Instructive Routing 463 Funct. Code Function Code, size is 1 octet 465 Arguments Arguments for the function, Variable length 467 7. Instructive Routing Behaviors 469 The behavior for each satellite for instructive routing is described 470 here. Table 1 is the summary of the name, Hex values of all 471 functions, arguments and size. New functions can be defined if 472 needed. 474 The subsections below are the detailed explanation for each function. 476 +======================+=======================+==============+ 477 | Func Name/Hex Value | Arguments/Size(Octet) | Reference | 478 +======================+=======================+==============+ 479 | Fwd.Inc.Sat_ID/0X01 | Sat_ID/1 | Section 7.1 | 480 +----------------------+-----------------------+--------------+ 481 | Fwd.Dec.Sat_ID/0X02 | Sat_ID/1 | Section 7.2 | 482 +----------------------+-----------------------+--------------+ 483 | Fwd.Inc.Obp_ID/0X03 | Obp_ID/1 | Section 7.3 | 484 +----------------------+-----------------------+--------------+ 485 | Fwd.Dec.Obp_ID/0X04 | Obp_ID/1 | Section 7.4 | 486 +----------------------+-----------------------+--------------+ 487 | Fwd.Inc.Shl_ID/0X05 | Shl_ID/1 | Section 7.5 | 488 +----------------------+-----------------------+--------------+ 489 | Fwd.Dec.Shl_ID/0X06 | Shl_ID/1 | Section 7.6 | 490 +----------------------+-----------------------+--------------+ 491 | End.Intf_ID/0X07 | Intf_ID/1 | Section 7.7 | 492 +----------------------+-----------------------+--------------+ 493 | End.Punt/0X08 | 0X0/1 | Section 7.8 | 494 +----------------------+-----------------------+--------------+ 495 | End.Lookup/0X09 | 0X0/1 | Section 7.9 | 496 +----------------------+-----------------------+--------------+ 497 | End.Lookup.IPv4/0X0A | IPv4_Addr/4 | Section 7.10 | 498 +----------------------+-----------------------+--------------+ 499 | End.Lookup.IPv6/0X0B | IPv6_Addr/16 | Section 7.11 | 500 +----------------------+-----------------------+--------------+ 501 | Fwd.Sat_Addr/0X0C | Sat_Addr/4 | Section 7.12 | 502 +----------------------+-----------------------+--------------+ 503 | Fwd.Sat_MacAddr/0X0D | Sat_MacAddr/6 | Section 7.13 | 504 +----------------------+-----------------------+--------------+ 506 Table 1: Functions, Arguments and Reference 508 The functions in Section 7.1 to Section 7.6 are used for the 509 instructions to forward packet to one of the six major directions 510 discussed in Section 4. They will call API in Section 7.14 to 511 forward the packet to the specified direction. 513 The functions in Section 7.12 and Section 7.13 are used for the 514 instructions to forward packet to a specified adjacent satellite 515 discussed in Section 4. They will call APIs in Section 7.15 and 516 Section 7.16 respectively to forward the packet to the specified 517 adjacent satellite. 519 In order to forward packet, each satellite should have an adjacency 520 table stored locally; the table should contain the information about 521 all adjacent satellites, it should at least store: 523 1. Each adjacent satellite's semantic address. 525 2. The ID of local interface connecting to each adjacent satellite. 527 3. The MAC address for the remote interface of each adjacent 528 satellite. 530 7.1. Fwd.Inc.Sat_ID 532 The definition of this function is "Forward the packet on the 533 Satellite Index Incremental Direction until the packet reaches a 534 Satellite whose Satellite Index is equal to the value specified in 535 the argument" 537 This function is used for the instruction to forward packet to one of 538 the six major directions discussed in Section 4. 540 When a satellite receives a packet with new routing header, assume 541 the satellite indexes in the address are Shl_index, Obp_index, 542 Sat_index respectively, the satellite does the following. During the 543 forwarding, the Forwarding_API in Section 7.14 is called to forward 544 the packet to the specified direction. 546 S01. When an IRH is processed { 547 S02. If ((RI > 1) and (Argument != Sat_index)) { 548 S03. Input_Satellite = Current Satellite; 549 S04. Input_Direction = Satellite Index Incremental direction; 550 S05. Forwarding_API(Packet,Input_Satellite,Input_Direction); 551 S06. } else { 552 S07. IOF += 2; 553 S08. RI --; 554 S09. if (RI <= 0) 555 Send an ICMP Parameter Problem to the Source Address 556 with Code 0 (Erroneous header field encountered) 557 and Pointer set to the RI field, 558 interrupt packet processing, and discard the packet; 559 S10. Proceed to execute the next Instruction; 560 S11. } 561 S12.} 563 7.2. Fwd.Dec.Sat_ID 565 The definition of this function is "Forward the packet on the 566 Satellite Index Decremental Direction until the packet reaches a 567 Satellite whose Satellite Index is equal to the value specified in 568 the argument" 570 This function is used for the instruction to forward packet to one of 571 the six major directions discussed in Section 4. 573 When a satellite receives a packet with new routing header, assume 574 the satellite indexes in the address are Shl_index, Obp_index, 575 Sat_index respectively, the satellite does the following. During the 576 forwarding, the Forwarding_API in Section 7.14 is called to forward 577 the packet to the specified direction. 579 S01. When an IRH is processed { 580 S02. If ((RI > 1) and (Argument != Sat_index)) { 581 S03. Input_Satellite = Current Satellite; 582 S04. Input_Direction = Satellite Index Decremental direction; 583 S05. Forwarding_API(Packet,Input_Satellite,Input_Direction); 584 S06. } else { 585 S07. IOF += 2; 586 S08. RI --; 587 S09. if (RI <= 0) 588 Send an ICMP Parameter Problem to the Source Address 589 with Code 0 (Erroneous header field encountered) 590 and Pointer set to the RI field, 591 interrupt packet processing, and discard the packet; 592 S10. Proceed to execute the next Instruction; 593 S11. } 594 S12.} 596 7.3. Fwd.Inc.Opb_ID 598 The definition of this function is "Forward the packet on the Orbit 599 Plane Index Incremental Direction until the packet reaches a 600 Satellite whose Orbit Plane Index is equal to the value specified in 601 the argument" 603 This function is used for the instruction to forward packet to one of 604 the six major directions discussed in Section 4. 606 When a satellite receives a packet with new routing header, assume 607 the satellite indexes in the address are Shl_index, Obp_index, 608 Sat_index respectively, the satellite does the following. During the 609 forwarding, the Forwarding_API in Section 7.14 is called to forward 610 the packet to the specified direction. 612 S01. When an IRH is processed { 613 S02. If ((RI > 1) and (Argument != Obp_index)) { 614 S03. Input_Satellite = Current Satellite; 615 S04. Input_Direction = Orbit Plane Index Incremental direction; 616 S05. Forwarding_API(Packet,Input_Satellite,Input_Direction); 617 S06. } else { 618 S07. IOF += 2; 619 S08. RI --; 620 S09. if (RI <= 0) 621 Send an ICMP Parameter Problem to the Source Address 622 with Code 0 (Erroneous header field encountered) 623 and Pointer set to the RI field, 624 interrupt packet processing, and discard the packet; 625 S10. Proceed to execute the next Instruction; 626 S11. } 627 S12.} 629 7.4. Fwd.Dec.Opb_ID 631 The definition of this function is "Forward the packet on the Orbit 632 Plane Index Decremental Direction until the packet reaches a 633 Satellite whose Orbit Plane Index is equal to the value specified in 634 the argument" 636 This function is used for the instruction to forward packet to one of 637 the six major directions discussed in Section 4. 639 When a satellite receives a packet with new routing header, assume 640 the satellite indexes in the address are Shl_index, Obp_index, 641 Sat_index respectively, the satellite does the following. During the 642 forwarding, the Forwarding_API in Section 7.14 is called to forward 643 the packet to the specified direction. 645 S01. When an IRH is processed { 646 S02. If ((RI > 1) and (Argument != Obp_index)) { 647 S03. Input_Satellite = Current Satellite; 648 S04. Input_Direction = Orbit Plane Index Decremental direction; 649 S05. Forwarding_API(Packet,Input_Satellite,Input_Direction); 650 S06. } else { 651 S07. IOF += 2; 652 S08. RI --; 653 S09. if (RI <= 0) 654 Send an ICMP Parameter Problem to the Source Address 655 with Code 0 (Erroneous header field encountered) 656 and Pointer set to the RI field, 657 interrupt packet processing, and discard the packet; 658 S10. Proceed to execute the next Instruction; 659 S11. } 660 S12.} 662 7.5. Fwd.Inc.Shl_ID 664 The definition of this function is "Forward the packet on the Orbit 665 Shell Index Incremental Direction until the packet reaches a 666 Satellite whose Orbit Shell Index is equal to the value specified in 667 the argument" 669 This function is used for the instruction to forward packet to one of 670 the six major directions discussed in Section 4. 672 When a satellite receives a packet with new routing header, assume 673 the satellite indexes in the address are Shl_index, Obp_index, 674 Sat_index respectively, the satellite does the following. During the 675 forwarding, the Forwarding_API in Section 7.14 is called to forward 676 the packet to the specified direction. 678 S01. When an IRH is processed { 679 S02. If ((RI > 1) and (Argument != Shl_index)) { 680 S03. Input_Satellite = Current Satellite; 681 S04. Input_Direction = Orbit Shell Index Incremental direction; 682 S05. Forwarding_API(Packet,Input_Satellite,Input_Direction); 683 S06. } else { 684 S07. IOF += 2; 685 S08. RI --; 686 S09. if (RI <= 0) 687 Send an ICMP Parameter Problem to the Source Address 688 with Code 0 (Erroneous header field encountered) 689 and Pointer set to the RI field, 690 interrupt packet processing, and discard the packet; 691 S10. Proceed to execute the next Instruction; 692 S11. } 693 S12.} 695 7.6. Fwd.Dec.Shl_ID 697 The definition of this function is "Forward the packet on the Orbit 698 Shell Index Decremental Direction until the packet reaches a 699 Satellite whose Orbit Shell Index is equal to the value specified in 700 the argument" 702 This function is used for the instruction to forward packet to one of 703 the six major directions discussed in Section 4. 705 When a satellite receives a packet with new routing header, assume 706 the satellite indexes in the address are Shl_index, Obp_index, 707 Sat_index respectively, the satellite does the following. During the 708 forwarding, the Forwarding_API in Section 7.14 is called to forward 709 the packet to the specified direction. 711 S01. When an IRH is processed { 712 S02. If ((RI > 1) and (Argument != Shl_index)) { 713 S03. Input_Satellite = Current Satellite; 714 S04. Input_Direction = Orbit Shell Index Decremental direction; 715 S05. Forwarding_API(Packet,Input_Satellite,Input_Direction); 716 S06. } else { 717 S07. IOF += 2; 718 S08. RI --; 719 S09. if (RI <= 0) 720 Send an ICMP Parameter Problem to the Source Address 721 with Code 0 (Erroneous header field encountered) 722 and Pointer set to the RI field, 723 interrupt packet processing, and discard the packet; 724 S10. Proceed to execute the next Instruction; 725 S11. } 726 S12.} 728 7.7. End.Intf_ID 730 The definition of this function is "End of processing for the 731 Instructive routing, remove the Instructive Routing Header, Forward 732 the packet to the interface specified in the argument" 734 This function is normally used on the Dst_Sat to forward packet to 735 Dst_GS. 737 When a satellite receives a packet with new routing header, the 738 satellite does the following, Forwarding_GS_API in Section 7.17 is 739 called to forward the packet to the specified interface. 741 S01. When an IRH is processed { 742 S02. Change the Next header in the packet header to be 743 the Next Header field in the Instructive Routing header; 744 S03. Remove the Instructive Routing Header; 745 S04. Forwarding_GS_API(Packet, Argument); 746 S05.} 748 7.8. End.Punt 750 The definition of this function is "End of processing for the 751 Instructive routing, remove the Instructive Routing Header, Punt the 752 packet to the OS for process" 754 This function is normally used send packet to a satellite. At the 755 destination satellite, the packet is punted to the OS to be processed 756 further. 758 When a satellite receives a packet with new routing header, the 759 satellite does the following: 761 S01. When an IRH is processed { 762 S02. Change the Next header in the packet header to be 763 the Next Header field in the Instructive Routing header; 764 S03. Remove the Instructive Routing Header; 765 S04. Punt packet to the local CPU for process; 766 S05.} 768 7.9. End.Lookup 770 The definition of this function is "End of processing for the 771 Instructive routing, remove the Instructive Routing Header, Lookup 772 the destination address in packet header and forward the packet 773 accordingly" 775 This function is normally used to send packet to Dst_GS. After the 776 packet reaches the Dst_Sat, the packet is forwarded to Dst_GS by 777 looking up the destination address in the IPv6 packet header. 779 When a satellite receives a packet with new routing header, the 780 satellite does the following: 782 S01. When an IRH is processed { 783 S02. Change the Next header in the packet header to be 784 the Next Header field in the Instructive Routing header; 785 S03. Remove the Instructive Routing Header; 786 S04. Lookup the destination address in packet hdr and forward 787 the packet; 788 S05.} 790 7.10. End.Lookup.IPv4 792 The definition of this function is "End of processing for the 793 Instructive routing, remove the Instructive Routing Header, Lookup 794 the IPv4 address specified in the argument and forward the packet 795 accordingly" 797 This function is normally used to send packet to Dst_GS. After the 798 packet reaches the Dst_Sat, the packet is forwarded to Dst_GS by 799 looking up the IPv4 destination address specified in the Function 800 Argument. 802 When a satellite receives a packet with new routing header, the 803 satellite does the following: 805 S01. When an IRH is processed { 806 S02. Fetch the IPv4 addr in the argument; 807 S03. Change the Next header in the packet header to be 808 the Next Header field in the Instructive Routing header; 809 S04. Remove the Instructive Routing Header; 810 S05. Lookup the fetched IPv4 address and forward the packet; 811 S06.} 813 7.11. End.Lookup.IPv6 815 The definition of this function is "End of processing for the 816 Instructive routing, remove the Instructive Routing Header, Lookup 817 the IPv6 address specified in the argument and forward the packet 818 accordingly" 820 This function is normally used to send packet to Dst_GS. After the 821 packet reaches the Dst_Sat, the packet is forwarded to Dst_GS by 822 looking up the IPv6 destination address specified in the Function 823 Argument. 825 When a satellite receives a packet with new routing header, the 826 satellite does the following: 828 S01. When an IRH is processed { 829 S02. Fetch the IPv6 addr in the argument; 830 S03. Change the Next header in the packet header to be 831 the Next Header field in the Instructive Routing header; 832 S04. Remove the Instructive Routing Header; 833 S05. Lookup the fetched IPv6 address and forward the packet; 834 S06.} 836 7.12. Fwd.Sat_Addr 838 The definition of this function is "Forward the packet to the 839 adjacent satellite with the address specified in the argument" 841 This function is normally used for the instruction to forward packet 842 to an adjacent satellite specified by its Satellite Semantic Address. 843 The Satellite Semantic Address is 32-bit long and is defined in 844 Section 5.4 in [I-D.lhan-satellite-semantic-addressing] 846 When a satellite receives a packet with new routing header, assume 847 the satellite semantic address is Sat_Addr, the satellite does the 848 following: 850 S01. When an IRH is processed { 851 S02. If ((RI > 1) and (Argument != Sat_Addr)) { 852 S03. Input_Satellite = Current Satellite; 853 S04. SatAddr = Argument; 854 S05. Forwarding_API_SAT(Packet,Input_Satellite,SatAddr); 855 S06. } else { 856 S07. IOF += 4; 857 S08. RI --; 858 S09. if (RI <= 0) 859 Send an ICMP Parameter Problem to the Source Address 860 with Code 0 (Erroneous header field encountered) 861 and Pointer set to the RI field, 862 interrupt packet processing, and discard the packet. 863 S10. Proceed to execute the next Instruction; 864 S11. } 865 S12.} 867 7.13. Fwd.Sat_MacAddr 869 The definition of this function is "Forward the packet to the 870 adjacent satellite with the MAC address specified as the argument" 872 This function is normally used for the instruction to forward packet 873 to an adjacent satellite specified by its MAC address. 875 When a satellite receives a packet with new routing header, assume 876 the satellite Mac address is Sat_MacAddr, the satellite does the 877 following: 879 S01. When an IRH is processed { 880 S02. If ((RI > 1) and (Argument != Sat_MacAddr)) { 881 S03. Input_Satellite = Current Satellite; 882 S04. SatMacAddr = Argument; 883 S05. Forwarding_API_Mac(Packet,Input_Satellite,SatMacAddr); 884 S06. } else { 885 S07. IOF += 6; 886 S08. RI --; 887 S09. if (RI <= 0) 888 Send an ICMP Parameter Problem to the Source Address 889 with Code 0 (Erroneous header field encountered) 890 and Pointer set to the RI field, 891 interrupt packet processing, and discard the packet. 892 S10. Proceed to execute the next Instruction; 893 S11. } 894 S12.} 896 7.14. Forwarding_API(Packet,Input_Satellite,Input_Direction) 898 This API will forward a packet to the specified direction. When a 899 satellite executes the API, it will do following: 901 S01. Forwarding_API(Packet,Input_Satellite,Input_Direction) { 902 S02. Lookup the local adjacency table to find out 903 1) The adjacent satellite of "Input_Satellite" on the 904 direction equal to "Input_Direction" (The adjacent 905 satellite's semantic address can be inferred by 906 the "Input_Satellite" and "Input_Direction"). 907 2) The L2 address for the adjacent satellite; 908 3) The local interface connecting to the adjacent 909 satellite; 910 S03. Rewrite the L2 header of the Packet by the L2 address; 911 S04. Send the Packet to the local interface; 912 S05.} 914 7.15. Forwarding_API_SAT(Packet,Input_Satellite,Sat_Addr) 916 This API will forward a packet to the specified adjacent satellite 917 with the semantic address as the argument. When a satellite executes 918 the API, it will do following: 920 S01. Forwarding_API_SAT(Packet,Input_Satellite,SatAddr) { 921 S02. Lookup the local adjacency table to find out 922 1) The adjacent satellite of "Input_Satellite" 923 (The adjacent satellite address is SatAddr); 924 2) The L2 address for the adjacent satellite; 925 3) The local interface connecting to the adjacent 926 satellite; 927 S03. Rewrite the L2 header of the Packet by the L2 address; 928 S04. Send the Packet to the local interface; 929 S05.} 931 7.16. Forwarding_API_MAC(Packet,Input_Satellite,Sat_MacAddr) 933 This API will forward a packet to the specified adjacent satellite 934 with the MAC address as the argument. When a satellite executes the 935 API, it will do following: 937 S01. Forwarding_API_MAC(Packet,Input_Satellite,SatMacAddr) { 938 S02. Lookup the local adjacency table to find out 939 1) The adjacent satellite of "Input_Satellite" 940 (The adjacent satellite MAC address is SatMacAddr); 941 2) The L2 address for the adjacent satellite; 942 3) The local interface connecting to the adjacent 943 satellite; 944 S03. Rewrite the L2 header of the Packet by the L2 address; 945 S04. Send the Packet to the local interface; 946 S05.} 948 7.17. Forwarding_GS_API(Packet,Input_Interface) 950 This API will forward a packet to ground station the connected to the 951 specified interface. When a satellite executes the API, it will do 952 following: 954 S01. Forwarding_API(Packet,Input_Interface) { 955 S02. Lookup the local adjacency table to find out 956 1) The connected GS to the interface 957 equal to "Input_Interface"; 958 2) The L2 address for the GS; 959 S03. Rewrite the L2 header of the Packet by the L2 address; 960 S04. Send the Packet to the "Input_Interface"; 961 S05.} 963 8. IANA Considerations 965 This document defines a new IPv6 Routing Type: the "Instructive 966 Routing Header". It needs to be assigned a number by IANA. 968 This document also defines an 8-bit Function Name, for which IANA 969 will create and will maintain a new sub-registry entitled 970 "Instructive Routing Function Name" under the "Internet Protocol 971 Version 6 (IPv6) Parameters" [IPv6_Parameters] registry. Initial 972 values for the subtype registries are given in Table 1. 974 9. Security Considerations 976 The instructive routing is only applicable to a satellite network 977 that is using the satellite semantic address. It will add 978 instructive routing header at a GS and the header will be removed 979 before reaching another GS. Normally, a satellite network including 980 all GS is trusted domain. Traffic will be filtered at the domain 981 boundaries. Non-authorized users cannot access the satellite 982 network. 984 10. Contributors 986 11. Acknowledgements 988 12. References 990 12.1. Normative References 992 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 993 (IPv6) Specification", STD 86, RFC 8200, 994 DOI 10.17487/RFC8200, July 2017, 995 . 997 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 998 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 999 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1000 . 1002 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1003 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1004 (SRv6) Network Programming", RFC 8986, 1005 DOI 10.17487/RFC8986, February 2021, 1006 . 1008 12.2. Informative References 1010 [I-D.lhan-problems-requirements-satellite-net] 1011 Han, L., Li, R., Retana, A., Chen, M., Su, L., and N. 1012 Wang, "Problems and Requirements of Satellite 1013 Constellation for Internet", Work in Progress, Internet- 1014 Draft, draft-lhan-problems-requirements-satellite-net-02, 1015 13 February 2022, . 1018 [I-D.lhan-satellite-semantic-addressing] 1019 Han, L. and R. Li, "Satellite Semantic Addressing for 1020 Satellite Constellation", Work in Progress, Internet- 1021 Draft, draft-lhan-satellite-semantic-addressing-00, 19 1022 October 2021, . 1025 [StarLink] "Star Link", . 1027 [ThreeGPP] "3GPP", . 1029 [OSI-Model] 1030 "OSI Model", . 1032 [TR38-821] "Solutions for NR to support Non-Terrestrial Networks 1033 (NTN)", 1034 . 1037 [IPv6_Parameters] 1038 IANA, "Internet Protocol Version 6 (IPv6) Parameters", 1039 . 1042 Appendix A. Change Log 1044 * Initial version, 02/28/2022 1046 Authors' Addresses 1048 Lin Han (editor) 1049 Futurewei Technologies, Inc. 1050 2330 Central Express Way 1051 Santa Clara, CA 95050, 1052 United States of America 1053 Email: lhan@futurewei.com 1055 Alvaro Retana 1056 Futurewei Technologies, Inc. 1057 2330 Central Express Way 1058 Santa Clara, CA 95050, 1059 United States of America 1060 Email: alvaro.retana@futurewei.com 1062 Richard Li 1063 Futurewei Technologies, Inc. 1064 2330 Central Express Way 1065 Santa Clara, CA 95050, 1066 United States of America 1067 Email: rli@futurewei.com