idnits 2.17.1 draft-bonica-6man-comp-rtg-hdr-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2019) is 1885 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 637 -- Looks like a reference, but probably isn't: '1' on line 638 == Missing Reference: 'SL' is mentioned on line 349, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track February 27, 2019 5 Expires: August 31, 2019 7 The IPv6 Compressed Routing Header (CRH) 8 draft-bonica-6man-comp-rtg-hdr-00 10 Abstract 12 This document defines the Compressed Routing Header (CRH). The CRH, 13 like any other Routing header, contains a list of segment identifiers 14 (SID). The CRH differs from other Routing headers in that its 15 segment identifiers can be 8, 16 or 32 bits long. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 31, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. The Compressed Routing Header (CRH) . . . . . . . . . . . . . 3 54 4. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 6 55 5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6 56 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.2. CRH Specific . . . . . . . . . . . . . . . . . . . . . . 7 58 5.2.1. Computing Minimum CRH Length . . . . . . . . . . . . 8 59 6. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Management Considerationsinclude . . . . . . . . . . . . . . 9 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 11.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Appendix A. CRH Processing Examples . . . . . . . . . . . . . . 11 68 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 13 69 A.2. Loose Source Routing Preserving The First SID . . . . . . 13 70 A.3. Strict Source Routing . . . . . . . . . . . . . . . . . . 14 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 An IPv6 [RFC8200] source node can steer a packet through a specific 76 path to its destination. The source node defines the path as an 77 ordered list of segments and encodes the path in an IPv6 Routing 78 header. As per [RFC8200], all Routing headers includes the following 79 fields: 81 o Next Header - Identifies the header immediately following the 82 Routing header. 84 o Hdr Ext Len - Length of the Routing header. 86 o Routing Type - Identifies the particular Routing header variant. 88 o Segments Left - The number of segments still to be traversed 89 before reaching the destination. 91 o Type-specific Data - Syntax and semantics are defined by the 92 Routing Type. 94 The following Routing types are currently defined: 96 o Source Route (i.e., RH0) [RFC5095] (deprecated) 97 o Type 2 Routing Header [RFC6275] 99 o RPL Source Route Header [RFC6554] 101 o Segment Routing Header (SRH) 102 [I-D.ietf-6man-segment-routing-header] 104 In each of the above-mentioned Routing Types, Type-specific Data 105 contains a list of one or more segment identifiers (SID). Typically, 106 a SID is an IPv6 address that identifies a segment endpoint. In the 107 SRH, the SID may carry additional semantics. 109 In all cases, the SID is 128 bits long. Therefore, routing headers 110 can be very large. For example, an 88-byte Source Route header is 111 required to specify a path that contains six segments. The same can 112 be said of the SRH. 114 Large Routing headers are undesirable for the following reasons: 116 o Many ASIC-based forwarders copy the entire IPv6 extension header 117 chain from buffer memory to on-chip memory. As the size of the 118 IPv6 extension header chain increases, so does the cost of this 119 copy. 121 o Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 122 reliable, many IPv6 hosts refrain from sending packets larger than 123 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are 124 small, the overhead imposed by large Routing headers becomes 125 pronounced. 127 This document defines the Compressed Routing Header (CRH). The CRH, 128 like any other Routing header, contains a list of SIDs. The CRH 129 differs from other Routing headers in that its SIDs can be 8, 16, or 130 32 bits long. 132 2. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. The Compressed Routing Header (CRH) 142 Figure 1 depicts the CRH. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Segments |Com| Reserved | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | SID List ........ 152 +-+-+-+-+-+-+-+-+-+-+- 154 Figure 1: Compressed Routing Header (CRH) 156 The CRH contains the following fields: 158 o Next Header - Defined in [RFC8200]. 160 o Hdr Ext Len - Defined in [RFC8200]. 162 o Routing Type - Defined in [RFC8200]. Value TBD by IANA. 164 o Segments Left (SL) - Defined in [RFC8200]. 166 o Segments - 6-bit unsigned integer. Represents the number of 167 entries in the SID List. 169 o Com (Compression) - 2 bits. Represents the length of each entry 170 in the SID List. Values are eight bits (0), sixteen bits (1), 171 thirty-two bits (2), and reserved (3). 173 o Reserved - SHOULD be set to zero by the sender. MUST be ignored 174 by the receiver. 176 o SID List - An zero-indexed list of SIDs. SIDs are listed in 177 reverse order, with SID[0] representing the packet's ultimate 178 destination, SID[1] representing the previous segment endpoint and 179 so forth. See Section 4 for SID details. 181 Figure 2 through Figure 4 illustrate CRH encodings with Com equal to 182 0, 1 and 2. In all cases, the CRH MUST end on a 64-bit boundary. 183 Therefore, the CRH MAY be padded with zeros. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Segments |Com| Reserved | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | SID[0] | SID[1] | ......... 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 195 Figure 2: Eight-bit Encoding (Com equals 0) 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Segments |Com| Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | SID[0] | SID[1] | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 206 | ......... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 209 Figure 3: Sixteen-bit Encoding (Com equals 1) 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Segments |Com| Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 + SID[0] + 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 + SID[1] + 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 // // 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 + SID[n] + 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 4: Thirty-two bit Encoding (Com equals 2) 229 4. Segment Identifiers (SID) 231 This document defines the following SID types: 233 o Loosely routed 235 o Strictly routed 237 All SIDs, regardless of type, map to exactly one IPv6 address. The 238 mapped address identifies an interface or set of interfaces (in the 239 case of multicast) that terminate the segment. The address MUST be 240 one of the following: 242 o A globally scoped IPv6 unicast address [RFC4291]. 244 o A Unique Local IPv6 Unicast Address (ULA) [RFC4193]. 246 o A Multicast address [RFC4291]. 248 A strictly routed SID also maps to a link interface. Nodes send 249 packets through that interface in order to access the segment 250 endpoint. 252 SIDs are instantiated on nodes and their significance is limited to 253 the node upon which they are instantiated. For example, assume that 254 a SID is instantiated on multiple nodes. It can be loosely routed on 255 one node and strictly routed on another. Likewise, it can map to a 256 different globally scoped address on each node. See Appendix A for 257 an example. 259 Forwarding nodes can learn the above-mentioned mappings from a 260 central controller, from a distributed routing protocol or using any 261 other means. The mechanisms that forwarding nodes use to learn the 262 above-mentioned mappings are beyond the scope of this document. 264 5. Processing Rules 266 5.1. General 268 [RFC8200] defines rules that apply to IPv6 extension headers, in 269 general, and IPv6 Routing headers, in particular. All of these rules 270 apply to the CRH. 272 For example: 274 o Extension headers (except for the Hop-by-Hop Options header) are 275 not processed, inserted, or deleted by any node along a packet's 276 delivery path, until the packet reaches the node (or each of the 277 set of nodes, in the case of multicast) identified in the 278 Destination Address field of the IPv6 header. 280 o If, while processing a received packet, a node encounters a 281 Routing header with an unrecognized Routing Type value, the 282 required behavior of the node depends on the value of the Segments 283 Left field. If Segments Left is zero, the node must ignore the 284 Routing header and proceed to process the next header in the 285 packet, whose type is identified by the Next Header field in the 286 Routing header. If Segments Left is non-zero, the node must 287 discard the packet and send an ICMP [RFC4443] Parameter Problem, 288 Code 0, message to the packet's Source Address, pointing to the 289 unrecognized Routing Type. 291 o If, after processing a Routing header of a received packet, an 292 intermediate node determines that the packet is to be forwarded 293 onto a link whose link MTU is less than the size of the packet, 294 the node must discard the packet and send an ICMP Packet Too Big 295 message to the packet's Source Address. 297 5.2. CRH Specific 299 When a node recognizes and processes a CRH, it executes the following 300 procedure: 302 o If the IPv6 Source Address is a link-local address, discard the 303 packet. 305 o If the IPv6 Source Address is a multicast address, discard the 306 packet. 308 o If Segments Left equal 0, skip over the CRH and process the next 309 header in the packet. 311 o If Segments Left is greater than Segments, send an ICMP Parameter 312 Problem, Code 0, message to the Source Address, pointing to the 313 Segments Left field, and discard the packet. 315 o If Com is equal to (3) Reserved, send an ICMP Parameter Problem, 316 Code 0, message to the Source Address, pointing to the Com field, 317 and discard the packet. 319 o If the IPv6 Hop Limit is less than or equal to 1, send an ICMP 320 Time Exceeded -- Hop Limit Exceeded in Transit message to the 321 Source Address and discard the packet. 323 o Compute L, the minimum CRH length (See Section 5.2.1) 324 o If L is greater than Hdr Ext Len, send an ICMP Parameter Problem, 325 Code 0, message to the Source Address, pointing to the Segments 326 field, and discard the packet. 328 o Decrement Segments Left (i.e., SL). 330 o Search for SID[SL] in the table that maps SID's to IPv6 addresses 331 and interfaces. If SID[SL] cannot be found in that table, send an 332 ICMP Parameter Problem, Code 0, message to the Source Address, 333 pointing to SID[SL], and discard the packet. 335 o Copy the address associated with SID[SL] to the IPv6 Destination 336 Address. 338 o If the IPv6 Destination address is a multicast address and SL is 339 greater than zero, send an ICMP Parameter Problem, Code 0, message 340 to the Source Address, pointing to Segment List [SL], and discard 341 the packet. 343 o Decrement the IPv6 Hop Limit. 345 o If SID[SL] is a loosely routed segment, resubmit the packet to the 346 IPv6 module for transmission to the new destination. 348 o If SID[SL] is a strictly routed segment, forward the packet 349 through the interface that is associated with SID[SL]. 351 The above stated rules are demonstrated in Appendix A. 353 5.2.1. Computing Minimum CRH Length 355 The algorithm described in this section accepts the following CRH 356 fields as its input parameters: 358 o Compression (Com). 360 o Segments. 362 It yields L, the minimum CRH length. The minimum CRH length is 363 measured in 8-octet units, not including the first 8 octets. 365 367 if (Com == 0 ) { /* Eight bit encoding */ 368 L = ( Segments / 8 ); 369 if ( Segments % 8 ) 370 L++; 371 } 372 elsif (Com == 1 ) { /* Sixteen bit encoding */ 373 L = ( Segments / 4 ); 374 if ( Segments % 4 ) 375 L++; 376 } 377 elsif (Com == 2 ) { /* Thirty-two bit encoding */ 378 L = ( Segments / 2 ); 379 if ( Segments % 2 ) 380 L++; 381 } 382 else { /* Invalid Com */ 383 L = 0xFF 385 } 387 return(L) 389 391 6. Mutability 393 The Segments Left field is mutable and MAY be decremented by 394 processing nodes. All remaining fields are immutable. 396 7. Management Considerationsinclude 398 PING and TRACEROUTE [RFC2151] both operate correctly in the presence 399 of the CRH. 401 8. Security Considerations 403 The CRH can be used within trusted domains only. In order to enforce 404 this requirement, domain edge routers MUST do one of the following: 406 o Discard all inbound packets that contain a CRH 408 o Authenticate [RFC4302] [RFC4303] all inbound packets that contain 409 a CRH 411 9. IANA Considerations 413 This document makes the following registration in the Internet 414 Protocol Version 6 (IPv6) Parameters "Routing Type" registry 415 maintained by IANA: 417 Value Description Reference 418 ------------------------------------------------------------ 419 TBD Compressed Routing Header (CRH) This document 421 10. Acknowledgements 423 Thanks to Joel Halpern, Gerald Schmidt, Nancy Shaw and Chandra 424 Venkatraman for their comments. 426 11. References 428 11.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 436 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 437 2006, . 439 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 440 DOI 10.17487/RFC4302, December 2005, 441 . 443 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 444 RFC 4303, DOI 10.17487/RFC4303, December 2005, 445 . 447 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 448 Control Message Protocol (ICMPv6) for the Internet 449 Protocol Version 6 (IPv6) Specification", STD 89, 450 RFC 4443, DOI 10.17487/RFC4443, March 2006, 451 . 453 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 454 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 455 May 2017, . 457 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 458 (IPv6) Specification", STD 86, RFC 8200, 459 DOI 10.17487/RFC8200, July 2017, 460 . 462 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 463 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 464 DOI 10.17487/RFC8201, July 2017, 465 . 467 11.2. Informative References 469 [I-D.ietf-6man-segment-routing-header] 470 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 471 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 472 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 473 progress), February 2019. 475 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 476 IP Tools and Utilities", FYI 30, RFC 2151, 477 DOI 10.17487/RFC2151, June 1997, 478 . 480 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 481 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 482 . 484 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 485 of Type 0 Routing Headers in IPv6", RFC 5095, 486 DOI 10.17487/RFC5095, December 2007, 487 . 489 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 490 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 491 2011, . 493 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 494 Routing Header for Source Routes with the Routing Protocol 495 for Low-Power and Lossy Networks (RPL)", RFC 6554, 496 DOI 10.17487/RFC6554, March 2012, 497 . 499 Appendix A. CRH Processing Examples 501 This appendix provides examples of CRH processing in the following 502 applications: 504 o Loose source routing (Appendix A.1) 505 o Loose source routing preserving the first SID (Appendix A.2) 507 o Strict source routing (Appendix A.3) 509 ----------- 510 2001:db8:0:2/64 |Node: I2 | 2001:db8:0:4/64 511 ----------------------|Loopback: |-------------------- 512 | ::2 |2001:db8::2| ::1 | 513 | ----------- | 514 | ::1 :: 2| 515 ----------- ----------- ----------- 516 |Node: S |2001:db8:0:1/64|Node: I1 |2001:db8:0:3/64|Node: I3 | 517 |Loopback |---------------|Loopback: |---------------|Loopback: | 518 |2001:db8::a| ::1 ::2 |2001:db8::1| ::1 ::2 |2001:db8::3| 519 ----------- ----------- ----------- 520 | ::1 521 ----------- | 522 |Node: D | 2001:db8:0:b/64 | 523 |Loopback: |--------------------- 524 |2001:db8::b| ::2 525 ----------- 527 Figure 5: Reference Topology 529 Figure 5 provides a reference topology that is used in all examples. 531 +--------------------+-----+--------------+ 532 | Instantiating Node | SID | IPv6 Address | 533 +--------------------+-----+--------------+ 534 | All | 1 | 2001:db8::1 | 535 | All | 2 | 2001:db8::2 | 536 | All | 3 | 2001:db8::3 | 537 | All | 10 | 2001:db8::a | 538 | All | 11 | 2001:db8::b | 539 +--------------------+-----+--------------+ 541 Table 1: Loosely Routed SIDs 543 Table 1 provides mappings for loosely routed SIDs. These mappings 544 are instantiated on all nodes in the reference topology. 546 +--------------------+-----+-----------------+-----------+ 547 | Instantiating Node | SID | IPv6 Address | Interface | 548 +--------------------+-----+-----------------+-----------+ 549 | S | 129 | 2001:db8:0:1::2 | S -> I1 | 550 | S | 130 | 2001:db8:0:2::2 | S -> I2 | 551 | I1 | 129 | 2001:db8:0:3::2 | I1 -> I3 | 552 | I2 | 129 | 2001:db8:0:4::2 | I2 -> I3 | 553 | I3 | 129 | 2001:db8:0:b::2 | I3 -> D | 554 +--------------------+-----+-----------------+-----------+ 556 Table 2: Strictly Routed SIDs 558 Table 2 provides mappings for strictly routed SIDs. These mappings 559 are available on the instantiating node only. 561 A.1. Loose Source Routing 563 In this example, Node S sends a packet to Node D, specifying loose 564 source route through Node I3. In this example, the first node in the 565 path, I3, does not appear in the CRH segment list. Therefore, the 566 destination node may not be able to send return traffic through the 567 same path. 569 +-------------------------------------+-------------------+ 570 | As the packet travels from S to I3: | | 571 +-------------------------------------+-------------------+ 572 | Source Address = 2001:db8::a | Segments = 1 | 573 | Destination Address = 2001:db8::3 | Segments Left = 1 | 574 | | SID[0] = 11 | 575 +-------------------------------------+-------------------+ 577 +-------------------------------------+-------------------+ 578 | As the packet travels from I3 to D: | | 579 +-------------------------------------+-------------------+ 580 | Source Address = 2001:db8::a | Segments = 1 | 581 | Destination Address = 2001:db8::b | Segments Left = 0 | 582 | | SID[0] = 11 | 583 +-------------------------------------+-------------------+ 585 A.2. Loose Source Routing Preserving The First SID 587 In this example, Node S sends a packet to Node D, specifying loose 588 source route through Node I3. In this example, the first node in the 589 path, I3, appears in the CRH segment list. Therefore, the 590 destination node can send return traffic through the same path. 592 +-------------------------------------+-------------------+ 593 | As the packet travels from S to I3: | | 594 +-------------------------------------+-------------------+ 595 | Source Address = 2001:db8::a | Segments = 2 | 596 | Destination Address = 2001:db8::3 | Segments Left = 1 | 597 | | SID[0] = 11 | 598 | | SID[1] = 3 | 599 +-------------------------------------+-------------------+ 601 +-------------------------------------+-------------------+ 602 | As the packet travels from I3 to D: | | 603 +-------------------------------------+-------------------+ 604 | Source Address = 2001:db8::a | Segments = 2 | 605 | Destination Address = 2001:db8::b | Segments Left = 0 | 606 | | SID[0] = 11 | 607 | | SID[1] = 3 | 608 +-------------------------------------+-------------------+ 610 A.3. Strict Source Routing 612 In this example, Node S sends a packet to Node D, specifying the 613 strict source route through I1 and I3. 615 +---------------------------------------+-------------------+ 616 | As the packet travels from S to I1: | | 617 +---------------------------------------+-------------------+ 618 | Source Address = 2001:db8::a | Segments = 2 | 619 | Destination Address = 2001:db8:0:1::2 | Segments Left = 2 | 620 | | SID[0] = 129 | 621 | | SID[1] = 129 | 622 +---------------------------------------+-------------------+ 624 +---------------------------------------+-------------------+ 625 | As the packet travels from I1 to I3: | | 626 +---------------------------------------+-------------------+ 627 | Source Address = 2001:db8::a | Segments = 2 | 628 | Destination Address = 2001:db8:0:3::2 | Segments Left = 1 | 629 | | SID[0] = 129 | 630 | | SID[1] = 129 | 631 +---------------------------------------+-------------------+ 632 +---------------------------------------+-------------------+ 633 | As the packet travels from I3 to D: | | 634 +---------------------------------------+-------------------+ 635 | Source Address = 2001:db8::a | Segments = 2 | 636 | Destination Address = 2001:db8:0:b::2 | Segments Left = 0 | 637 | | SID[0] = 129 | 638 | | SID[1] = 129 | 639 +---------------------------------------+-------------------+ 641 Author's Address 643 Ron Bonica 644 Juniper Networks 645 2251 Corporate Park Drive 646 Herndon, Virginia 20171 647 USA 649 Email: rbonica@juniper.net