idnits 2.17.1 draft-ietf-sdr-erp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 88 has weird spacing: '...ion may be al...' == Line 89 has weird spacing: '... taking a uni...' == Line 478 has weird spacing: '...with an impli...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1994) is 10783 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) == Missing Reference: 'IPv6' is mentioned on line 36, but not defined == Unused Reference: 'SIPP-16' is defined on line 709, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1340 (Obsoleted by RFC 1700) -- Possible downref: Non-RFC (?) normative reference: ref. 'SDRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDRP-SETUP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIPP-16' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Demand Routing Working Group Peter Ford 3 INTERNET DRAFT LANL 4 Tony Li 5 cisco Systems 6 Yakov Rekhter 7 T.J. Watson Research Center, IBM Corp. 8 October 1994 10 Explicit Routing Protocol (ERP) for IPv6 11 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 ``working draft'' or ``work in progress.'' 26 Please check the 1id-abstracts.txt listing contained in the 27 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 28 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 29 current status of any Internet Draft. 31 1. Introduction 33 This document specifies the format and processing of the IPv6 34 Explicit Routing Protocol (ERP) Header. The purpose of this header is 35 to provide IPv6 forwarding functionality comparable to SDRP [SDRP]. 36 The reader should be familiar with [IPv6]. 38 2. Acknowledgments 40 This document is based on "Source Demand Routing: Packet Format and 41 Forwarding Specification (Version 1)" [SDRP] and "Source Demand 42 Routing: Route Setup" [SDRP-SETUP]. 44 3. Model of Operation 45 An Internet can be viewed as a collection of routing domains 46 interconnected by means of common subnetworks, and Border Routers 47 (BRs) attached to these subnetworks. A routing domain itself may be 48 composed of further subnetworks, routers interconnecting these 49 subnetworks, and hosts. 51 For the purposes of this document, a BR belongs to only one domain. 52 A pair of BRs, each belonging to a different domain, but attached to 53 a common subnetwork, form an inter-domain connection. By definition, 54 packets that traverse multiple domains must traverse BRs of these 55 domains. Note that a single physical router may act as multiple BRs 56 for the purposes of this model. 58 A connected sets of Routing Domains may be grouped into Routing 59 Domain Confederations. A domain may belong to more than one 60 confederation. The confederations may be nested, disjoint, or 61 overlapped. 63 3.1 Addressing Assumptions 65 Each domain has a globally unique identifier, called a Routing Domain 66 Identifier (RDI). All the BRs within a domain need to know the RDI 67 assigned to the domain. Likewise, each routing domain confederation 68 has a globally unique identifier, called a Routing Domain 69 Confederation Identifier (RDCI). 71 This document assumes that RDIs and RDCIs are expressed as IPv6 72 addresses, and assigned based on the unicast address prefixes 73 assigned to domains and confederations. 75 A subscriber RD should use as its RDI an address taken out of the 76 unicast address prefix assigned to it. A multihomed RD should use as 77 its RDI an address taken out of one of the unicast address prefixes 78 assigned to it. A service provider should use as its RDI an address 79 taken out of the unicast address prefix that the provider uses for 80 assigning addresses to systems within the provider. Finally, an RDI 81 of a domain may be constructed by taking a unicast address out of any 82 unicast address prefix assigned to the domain. 84 If a service provider forms a Routing Domain Confederation with some 85 of its subscribers and the subscribers take their addresses out of 86 the provider, then an address taken out of the unicast address prefix 87 assigned to the provider should be used as the RDCI of the 88 confederation. An RDCI of a confederation may be also constructed 89 by taking a unicast address out of any unicast address prefix 90 assigned to any domain within the confederation, provided that this 91 unicast address is different from any other RDI or RDCI. 93 The address taken out for RDI or RDCI can not be used for unicast 94 address assignment. 96 The assumptions made here, combined with the assumption that unicast 97 addresses are globally unambiguous, guarantee that non-multicast IPv6 98 addresses (except for the block allocated for private use) are 99 globally unambiguous and that each assigned address can represent 100 either (a) unicast address, or (b) RDI, or (c) RDCI. 102 A router may have one or more unicast addresses, one RDI, one or more 103 RDCIs associated with it. It is assumed that at the minimum each 104 router has to have at least one unicast address, but may also have at 105 most one domain identifier and one or more confederation identifiers. 107 For the rest of the document, when we refer to an address of a router 108 this reference may include either a unicast address or RDI or RDCI 109 associated with the router. 111 3.2 ERP Route Definition 113 An ERP route is defined as a sequence of elements (called forwarding 114 hops), where each hop may depict a router, a domain, or a 115 confederation. Each hop is syntactically expressed as a unicast 116 address. Thus, an ERP route is syntactically expressed as a sequence 117 of unicast addresses. Semantically an ERP route is defined as an 118 arbitrary intermix of routers, domains, and confederations. 120 A hop within an ERP route can either be "strict" or "loose". 121 Forwarding to a strict next hop requires that the next hop be 122 adjacent to the current hop. Forwarding to a loose next hop doesn't 123 impose this requirement. 125 The definition of what constitute an "adjacent" hop depends on the 126 type (i.e., unicast address, RDI, RDCI) of the current and the next 127 hop, and is defined as follows. 129 A hop with unicast address A is adjacent to a hop with unicast 130 address B, if there are elements N and M, N with unicast addresses A 131 and X, and M with unicast addresses B and Y, and addresses X and Y 132 share a common subnetwork. 134 A hop with unicast address A is adjacent to a hop with domain 135 identifier B, if there is an element N with domain identifier B and 136 unicast address X, so that A is adjacent to X (as defined above). In 137 this case any element with domain identifier B is adjacent to A. 139 A hop with a unicast address A is adjacent to a hop with 140 confederation identifier B if there is an element N with 141 confederation identifier B and unicast address X, so that A is 142 adjacent to X (as defined above). 144 A hop with domain identifier A is adjacent to a hop with domain 145 identifier B if there exist two elements, M and N, M with domain 146 identifier A and unicast address X, and N with domain identifier B 147 and unicast address Y, such that X is adjacent to Y (as defined 148 above). 150 A hop with domain identifier A is adjacent to a hop with 151 confederation identifier B if there exist two elements, M and N, M 152 with domain identifier A and unicast address X, and N with 153 confederation identifier B and unicast address Y, such that X is 154 adjacent to Y (as defined above). 156 A hop with confederation identifier A is adjacent to a hop with 157 confederation identifier B if there exist two elements, M and N, M 158 with confederation identifier A and unicast address X, and N with 159 confederation identifier B and unicast address Y, such that X is 160 adjacent to Y (as defined above). 162 Note that the notion of "adjacent" is reflexive. That is, if A is 163 adjacent to B, then B is adjacent to A. 165 3.3 Setup 167 In some cases, commonly known as "flows", where the duration of a 168 packet stream is significantly longer than the end-to-end round-trip 169 delay, and particularly where the amount of payload in the packet is 170 small, it may be worthwhile to "set up" the ERP route by saving state 171 information in routers that have to process the route, instead of 172 carrying the full ERP route in every packet. Once this state is 173 established, the originator of the ERP route can use a combination of 174 Source Address and Flow Label carried in the fixed header to refer to 175 the ERP route rather than carrying the full route in each data 176 packet, thereby reducing the ERP Header size and transmission time. 178 It is important to the protocol that it does not impose setup on 179 routers that are short on state space or that otherwise restrict 180 setup. Therefore, the desire for setup is simply flagged by the the 181 originator of the ERP route, and the routers that have to process the 182 ERP route may choose to accept or reject the request. If all of the 183 routers that have to process the ERP route accept, then the 184 originator can begin using a route identifier (as carried by the Flow 185 Label field of the Fixed Header) to refer to the saved state. If any 186 router refuses setup, the originator must continue including the full 187 ERP route in each data packet or else try a different route. 189 When a router rejects a setup request, it sends an ICMP message 190 containing the route identifier to the originator of the request. 191 ICMP messages are also used in this manner if a router loses or is 192 missing state for a particular route identifier. When a router 193 accepts a setup request, it continues forwarding the request along 194 the ERP route. Successful route setup is indicated when the final 195 router on the ERP route sends an ICMP message containing Flow Label 196 to the originator of the route. 198 3.4 Forwarding Information Base (FIB) Model 200 It is assumed that each router maintains a conventional unicast 201 Forwarding Information Base (FIB), where each entry in the FIB is 202 represented as a tuple
. 204 It is assumed that if a router shares a common subnetwork with a BR, 205 then the router has information about all the RDIs and RDCIs the BR 206 belongs to. The mechanisms by which this information is acquired are 207 outside the scope of this document. This information is represented 208 in the FIB as a set of tuples, where the address prefix component of 209 each tuple specifies a particular RDI or RDCI (expressed as a 16 210 octets IPv6 address) of the BR and the next hop component specifies 211 the IPv6 unicast address of the BR. This also applies to the case 212 where the router is a BR itself. 214 If the next hop depicts a router that is not directly connected to 215 the local system (doesn't share a common subnetwork), then it is 216 assumed that the FIB contains an entry that allows to derive the 217 immediate next hop (the next hop on a common subnetwork). 219 In addition to conventional FIB a router may maintain a Flow Label 220 cache. This cache is used to support setups. Each entry in the 221 cache is a triplet . An 222 entry in the cache is uniquely identified by its the first two 223 components of the triplet (Source Address and Flow Label). Each entry 224 in the cache can be timed out at any time, and should be timed out 225 periodically. The particular policy used for timing out cache entries 226 is a local matter. 228 4. Explicit Forwarding Header format 230 An ERP Header is a type of an IPv6 Routing Header. The value of the 231 Routing Type field of the IPv6 Routing Header is set to 1 for an ERP 232 Header. The ERP Header format is defined as following: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Next Header |Routing Type=1 | Flags |NestL| FwdDirLen | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | NextHopPtr | Strict/Loose Bit Mask | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Forwarding Directions, a list of IPv6 addresses | 242 | (integral multiple of 16 octets) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Next Header - 8-bit selector. 247 Identifies the type of the header immediately following the 248 Routing header. Uses the same values as the IPv4 Protocol 249 field [RFC-1340] plus new types defined for IPv6. 251 Routing Type - 1. 253 Flags (5 bits): 255 MRE, Must Report Errors (bit 0). 257 If this bit is set to 1, and a router can not further 258 forward a packet, the router must generate an ICMP error 259 message. If this bit is set to 0, and a router can not 260 further forward a packet the router should not generate an 261 ICMP error message. 263 FFD, Behavior on Failure of Forwarding Directions (bit 1). 265 If this bit it set to 1, it indicates that if a router can 266 not further forward a packet the router must abort the ERP 267 route (as specified in Section 7). 269 SAS, Source Address Swap (bit 2). 271 If this bit is set to 1, it indicates that the entity that 272 added the current ERP Header to a packet placed the source 273 address from the fixed header as the first element in the 274 Forwarding Directions, and placed its own unicast address 275 as the source address in the fixed header. 277 '''.in 14 279 FLS, Flow Label Saved (bit 4) 281 If this bit is set to 1, then the low-order 28 bits of the 282 second element in the Forwarding Directions field contain 283 a Flow Label. 285 Nesting Level (3 bits). 287 The Nesting Level field is used to control the number of 288 ERP Headers carried by a packet. The maximum number of ERP 289 Headers that can be carried by a packet is 8. 291 Forwarding Directions Length (1 octet unsigned integer). 293 The Forwarding Directions Length field contains the number 294 of Forwarding Directions hops in the header. Length of 295 the header can be calculated from this value (length = 296 FwdDirLen * 16 + 8) The value of this field shall not 297 exceed 24. 299 Next Hop Pointer (1 octet unsigned integer). 301 The Next Hop Pointer field contains the index of next hop 302 to be processed. The first element in the Forwarding 303 Directions has index 0. The value of this field shall not 304 exceed 24. 306 Strict/Loose Bit Mask (24 bits). 308 The Strict/Loose Bit Mask is used when making a forwarding 309 decision. If the N-th bit (N not equal 1) in the 310 Strict/Loose Bit Mask field is set to 1, it indicates that 311 the N-th element in the Forwarding Directions is a Strict 312 Hop (with respect to the (N-1) element). If this bit is 313 set to 0, it indicates that the N-th element in the 314 Forwarding Directions is a Loose Hop (with respect to the 315 (N-1) element). The value of the first bit in the 316 Strict/Loose Bit Mask field specifies whether the first 317 element in the Forwarding Directions is a Strict or a 318 Loose Hop with respect to the entity that originated an 319 ERP route. 321 Forwarding Directions (variable length, multiple of 16 octets). 323 The elements of the Forwarding Directions (hops) are 324 syntactically IPv6 addresses. Semantically Forwarding 325 Directions can contain an arbitrary intermix of unicast 326 addresses, RDIs, and RDCIs. 328 5. Originating ERP Routes 330 This document assumes that an entity that attaches an ERP Header to a 331 packet is preconfigured with a set of ERP routes. Procedures for 332 constructing these routes are outside the scope of this document. 333 Use of ERP capabilities may be deployed initially without additional 334 routing information exchange protocol support. 336 An entity that is capable of attaching ERP Headers is expected to use 337 information carried in a packet combined with the local criteria to 338 determine whether the packet should be forwarding along a particular 339 ERP route. Associated with each set of criteria is a set of one or 340 more ERP routes that should be used to route matching packets. The 341 exact nature of the criteria is a local matter. 343 An ERP Header may be attached to a packet by either an entity that 344 originated the packet or by an entity that forwards the packet. For 345 example, either a host that originates a packet, or any router that 346 forwards the packet may attached an ERP Header to the packet. An ERP 347 Header is attached to a packet by placing the Header immediately 348 after the fixed header. 350 A packet may carry more than one ERP Headers. Each such header is 351 referred to by its nesting level (as carried in the Nesting Level 352 field of the header). The first Header attached to a packet is 353 referred to as the level 1 ERP Header. The level 1 ERP Header is 354 identified by the Next Header field in the ERP Header (the value of 355 the field is other than Routing Header). The outermost ERP Header 356 (the one that immediately follows the fixed header) is referred to as 357 the "current" ERP Header. 359 When an entity attaches the level 1 ERP Header to a packet, the 360 entity must put the destination address, as specified in the 361 destination address field of the fixed header of the packet, as the 362 last element in the Forwarding Directions of the ERP Header. Thus, 363 the last element in the Forwarding Directions field of the level 1 364 ERP Header is the destination address of the packet. 366 Any router may attach a level 1 ERP Header to a packet that the 367 router has to forward. Only a router that is identified by the 368 current element in the Forwarding Directions field of the current ERP 369 Header can attach a non-level 1 ERP Header to the packet, and only 370 when the next element in the Forwarding Directions is specified as a 371 Loose Hop. 373 The entity that attaches the level 1 ERP Header to a packet specifies 374 the maximum allowed number of nested ERP Headers. When a router 375 wants to attach an ERP Header to a packet that already has one or 376 more ERP Headers the router decrements the Nesting Level from the 377 current ERP Header by 1 and places it in the Nesting Level field of 378 the ERP Header it wants to attach. No further ERP Headers can be 379 attached to a packet whose current ERP Header carries zero as the 380 value of the Nesting Level field. 382 When an entity other than the one that originates a packet, attaches 383 an ERP Header to the packet, the entity places the source address 384 from the fixed header as the first element in the Forwarding 385 Directions field, places its own unicast address in the source 386 address field of the fixed header, and sets the Source Address Swap 387 flag to 1. If the value of the Flow Label field in the fixed header 388 is non-zero, then this value is placed in the low-order 28 bits of 389 the second element in the Forwarding Directions field, the Flow Label 390 Save flag is set to 1, and the value of the NextHopPtr field is set 391 to 2. Otherwise (the value of the Flow Label field is zero), the 392 value of the NextHopPtr field is set to 1. If the Flow Label is 393 zero, then the actual ERP route starts from the second element of the 394 Forwarding Directions, otherwise the route starts from the third 395 element of the Forwarding Directions. 397 If an entity that originates a packet attaches an ERP Header to the 398 packet, then the entity must set the Source Address Swap flag to 0, 399 Flow Label Save flag to 0, and set the value of the NextHopPtr to 0. 401 We say that a packer carries an implicit ERP Header if the packet's 402 forwarding is done using the setup capabilities, and the actual ERP 403 Header that was used during the setup is omitted. Otherwise, ''we 404 say that the Header is explicit. 406 An entity originating an ERP route (the originator) may request an 407 ERP setup by setting the appropriate bits in the Flow Label field, 408 and setting all other fields as described above. It is suggested to 409 set the Must Report Errors flag to 1. 411 The originator may wait a full round-trip time (provided that this 412 time is know by the originator) for a response to the setup request, 413 in the meantime sending subsequent packets with an explicit ERP 414 Header. There is no limit, however, to the number or frequency of 415 setup requests, thus the entity may repeat the setup. Once the 416 originator receives a response indicating that the setup is 417 successfully completed the originator may start sending packets with 418 an implicit ERP Header. The originator may choose to send packets 419 with the implicit ERP Header immediately after sending the setup 420 request. This may be useful if the packets will be useless after 421 waiting a full round-trip time. In this case, the packets will be 422 delivered if the setup is successful, but may be dropped otherwise. 424 6. Processing packets with ERP routes 426 We say that a router receives a packet with an ERP route if the 427 destination address in the fixed header of the packet that arrives at 428 the router depicts one of the addresses of the router and the packet 429 carries at least one ERP Header. 431 In the case where a router receives a packet with an explicit ERP 432 Header we say that the packet carries a completed ERP route if either 433 (a) the Header is Level 1 and the value of the NextHopPtr field in 434 the Header is one less than the value of the FwdDirLen field, or (b) 435 the Header is other than Level 1 and the value of the NextHopPtr 436 field in the Header is equal to the value of the FwdDirLen field. 437 Otherwise, we say that the received packet carries an incomplete 438 (non-empty) ERP route. 440 In the case where a router receives a packet with an implicit ERP 441 Header the router checks for a presence of an entry in its Flow Label 442 cache whose Source Address is equal to the Source Address field of 443 the fixed header of the packet, and whose Flow Label is equal to the 444 Flow Label field of the fixed header. If no such entry is found, the 445 packet is processed as described in Section 7. If such an entry is 446 found, then we say that the packet carries a completed ERP route if 447 the ERP Header associated with the entry is either (a) a Level 1 and 448 the value of the NextHopPtr field in the Header is one less than the 449 value of the FwdDirLen field, or (b) is other than Level 1 and the 450 value of the NextHopPtr field in the Header is equal to the value of 451 the FwdDirLen field. If such an entry is found, but neither (a) nor 452 (b) are satisfied, then we say that the received packet carries an 453 incomplete (empty) ERP route. 455 6.1 Processing packets with a completed ERP route 457 When a router receives a packet with an explicit ERP Header and the 458 ERP route is completed then the packet is processed as follows. 460 If the current ERP Header is a Level 1 header, then the last element 461 in the Forwarding Directions is placed in the Destination Address 462 field of the fixed header. If the Source Address Swap flag in the 463 current ERP Header is set to 1, then the first element in the 464 Forwarding Directions field is swapped with the Source Address field 465 of the fixed header. If the Flow Label Save flag in the current ERP 466 Header is set to 1, then the low-order 28 bits of the second element 467 in the Forwarding Directions field is placed in the Flow Label field 468 of the fixed header. If the current ERP Header is not a Level 1 469 header, then the current header must be removed from the packet. If 470 the current ERP Header is a Level 1 header, then it may be removed 471 from the packet. In addition, if the Flow Setup Request flag in the 472 Header is set to 1, and the router is willing to accommodate the 473 setup request (as described in Section 6.4) the router generates an 474 ICMP message to the entity depicted by the source address in the 475 fixed header indicating that the setup request has been successfully 476 completed. 478 When a router receives a packet with an implicit ERP Header and the 479 ERP route is completed then the packet is processed as described in 480 the previous paragraph, except that instead of the current ERP Header 481 the router uses the ERP Header associated with the entry in the Flow 482 Label cache identified by the Source Address and Flow Label fields of 483 the packet's fixed header. 485 After the above procedures are completed the packet is submitted for 486 normal forwarding procedure. 488 6.2 Processing packets with an incomplete ERP route and explicit ERP 489 Header 491 If a router receives a packet with an incomplete ERP route, and the 492 destination address in the fixed header is one of the unicast 493 addresses associated with the router, the router must check whether 494 the current element in the Forwarding Directions of the current ERP 495 Header, as pointed by the NextHopPtr, specifies an address associated 496 with the router. If this condition isn't satisfied, then further 497 handling of the packet is done as described in Section 7. If this 498 condition is satisfied, then the packet is processed as follows. 500 If the current ERP Header is a Level 1 header and the value of the 501 NextHopPtr field is two less than the value of the FwdDirLen field, 502 or if the current ERP Header is not a Level 1 header and the value of 503 the NextHopPtr field is one less than the value of the FwdDirLen 504 field, the router increments the value of the NextHopPtr field by 1, 505 and then follows the procedures specified in Section 6.1. 507 Otherwise, the router extracts the next element from the Forwarding 508 Directions (the next element is the element that immediately follows 509 the current element in the Forwarding Directions) and the 510 strict/loose indicator associated with the next element (the 511 indicator is extracted from the Strict/Loose Bit Mask field). Further 512 processing depends on whether the next element specifies a Loose Hop 513 (see Section 6.2.1) or a Strict Hop (see Section 6.2.2). 515 6.2.1 Loose Next Hop 517 If the next element in the Forwarding Directions is a Loose Hop, then 518 the router places the address, as specified in the next element, in 519 the destination address field of the fixed header, increments the 520 value of the Next Hop Pointer by 1, and submits the packet for normal 521 forwarding procedure. If the forwarding procedure can not forward the 522 packet (based on the destination address specified in the fixed 523 header), then further handling of the packet is done as described in 524 Section 7. 526 6.2.2 Strict Next Hop 528 If the next element in the Forwarding Directions is a Strict Hop, 529 then the router performs a lookup in its FIB (using the "longest 530 match" algorithm) using the address specified in the next element as 531 an index. If no matching tuple is found, then further handling of 532 the packet is done as described in Section 7. 534 If the next hop component of the found tuple specifies an entity that 535 shares a common subnetwork with the router, then the router checks 536 whether any of the addresses associated with that entity are equal to 537 the address specified by the next element in the Forwarding 538 Directions. If that is the case, then the value of the Next Hop 539 Pointer field is incremented by 1. 541 The address specified by the next hop component of the found tuple is 542 placed in the destination address field of the fixed header and the 543 packet is then submitted for normal forwarding procedure. If the 544 forwarding procedure can not forward the packet (based on the 545 destination address specified in the fixed header), then further 546 handling of the packet is done as described in Section 7. 548 6.3 Processing packets with an incomplete ERP route and implicit ERP 549 Header 551 If a router receives a packet with an implicit ERP Header that carry 552 an incomplete ERP route, and the destination address in the fixed 553 header is one of the unicast addresses associated with the router, 554 the router extracts from its Flow Label cache an entry identified by 555 the Source Address and Flow Label fields of the packet's fixed 556 header. 558 If the ERP Header associated with the extracted entry is a Level 1 559 header and the value of the NextHopPtr field is two less than the 560 value of the FwdDirLen field, or if the Header is not a Level 1 561 header and the value of the NextHopPtr field is one less than the 562 value of the FwdDirLen field, the router follows the procedures 563 specified in Section 6.1. 565 Otherwise, the router extracts the next element from the Forwarding 566 Directions (the next element is the element that immediately follows 567 the current element in the Forwarding Directions) and the 568 strict/loose indicator associated with the next element (the 569 indicator is extracted from the Strict/Loose Bit Mask field). Further 570 processing depends on whether the next element specifies a Loose Hop 571 (see Section 6.3.1) or a Strict Hop (see Section 6.3.2). 573 6.3.1 Loose Next Hop 575 If the next element in the Forwarding Directions is a Loose Hop, then 576 the router places the address, as specified in the next element, in 577 the destination address field of the fixed header, and submits the 578 packet for normal forwarding procedure. If the forwarding procedure 579 can not forward the packet (based on the destination address 580 specified in the fixed header), then further handling of the packet 581 is done as described in Section 7. 583 6.3.2 Strict Next Hop 585 If the next element in the Forwarding Directions is a Strict Hop, 586 then the router performs a lookup in its FIB (using the "longest 587 match" algorithm) using the address specified in the next element as 588 an index. If no matching tuple is found, then further handling of 589 the packet is done as described in Section 7. 591 If the next hop component of the found tuple specifies an entity that 592 shares a common subnetwork with the router, then the router checks 593 whether any of the addresses associated with that entity are equal to 594 the address specified by the next element in the Forwarding 595 Directions. 597 The address specified by the next hop component of the found tuple is 598 placed in the destination address field of the fixed header and the 599 packet is then submitted for normal forwarding procedure. If the 600 forwarding procedure can not forward the packet (based on the 601 destination address specified in the fixed header), then further 602 handling of the packet is done as described in Section 7. 604 6.4 Processing packets with Setup Request 606 If a router receives a packet with an ERP route and the packet 607 carries a setup request, then in addition to the procedures described 608 in Sections 6.1 and 6.2 (including 6.2.1 and 6.2.2), the router 609 performs the following procedures. 611 If the router is willing to accommodate the setup request, then the 612 router constructs a triplet , 613 where the value of the first element (Source Address) is set to the 614 value of the Source Address from the fixed header, the value of the 615 second element (Flow Label) is set to the value of the Flow Label 616 field of the fixed header, and the value of the third element is set 617 to the value of all the ERP Headers carried by the packet. The 618 router then checks whether the triplet is present in its Flow Label 619 cache, and if not then adds to the cache an entry that contains the 620 triplet. 622 If the router is unwilling to accommodate the setup request, and Must 623 Report Error flag is set to 1, then the router generates an ICMP 624 message to the entity depicted by the source address in the fixed 625 header indicating that the setup request can not be accommodated. 627 The rules by which a router decides whether to accommodate a setup 628 request are outside the scope of this document. 630 7 Error Handling 632 If the MRE is set to 1, then the router generates an ICMP error 633 message back to the entity specified in the source address of the 634 fixed header. If the MRE is set to 0, then no ICMP error messages 635 should be generated. 637 If the Behavior on Failure of Forwarding Directions bit in the 638 current ERP Header of a packet is set to 1, and the Header carries a 639 non-empty ERP route then the packet is processed as follows. If the 640 current ERP Header is a Level 1 header, then the value of the 641 NextHopPtr field is set to one less than the value of the FwdDirLen 642 field. Otherwise, the value of the NextHopPtr field is set to the 643 value of the FwdDirLen field. The packet is then processed as 644 described in Section 6.1. 646 If the Behavior on Failure of Forwarding Directions bit in the 647 current ERP Header of a packet is set to 1, the Header carries an 648 empty ERP route, and the Header is not a level 1 Header, then the 649 packet is processed as described in Section 6.1. If the Behavior on 650 Failure of Forwarding Directions bit in the current ERP Header of a 651 packet is set to 1, the Header carries an empty ERP route, and the 652 Header is a level 1 Header, then the packet is discarded. 654 If the Behavior on Failure of Forwarding Directions bit in the 655 current ERP Header of a packet is set to 0, then the packet is 656 discarded. 658 8 Path MTU Handling 660 9. ERP ICMP Message Format 662 [Need to define format of an ICMP message associated with ERP. The 663 message should be able to carry one of the following indications: 665 (a) Setup Request completed 667 (b) Setup Request refused 669 (c) Can't satisfy Forwarding Directions 671 (d) No Flow Label cache entry found 673 In addition to the indication the message should carry as much of the 674 original packet as possible, but at the minimum the fixed header and 675 all the ERP Headers.] 677 10. Authors' Address 679 Peter Ford 680 Los Alamos National Laboratory 681 Los Alamos 682 Phone: (505) 665-0058 683 e-mail: peter@goshawk.lanl.gov 685 Tony Li 686 cisco Systems, Inc. 687 1525 O'Brien Drive 688 Menlo Park, CA 94025 689 email: tli@cisco.com 691 Yakov Rekhter 692 T.J. Watson Research Center IBM Corporation 693 P.O. Box 704 694 Yorktown Heights, NY 10598 695 Phone: (914) 784-7361 696 email: yakov@watson.ibm.com 698 7. References 699 [RFC-1340] Reynolds, J. and Postel, J. "Assigned Numbers". July 1992. 700 RFC 1340. 702 [SDRP] Estrin, D., Li, T. , Rekhter, Y., and Varadhan K., "Source Demand 703 Routing: Packet Format and Forwarding Specification (Version 1)" 22 704 March, 1994. Internet Draft. 706 [SDRP-SETUP] Estrin, D., Zappala, D., Li, T., "Source Demand Routing: 707 Route Setup", June 1993, Internet Draft. 709 [SIPP-16] Deering, S., "Simple Internet Protocol Plus (SIPP) 710 Specification (128 bit address version)". 17 July 1994. Internet Draft.