idnits 2.17.1 draft-ietf-udlr-lltunnel-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 104: '... communication interfaces. A feed MUST...' RFC 2119 keyword, line 320: '... feed MUST maintain a list of send-o...' RFC 2119 keyword, line 471: '... version number. MUST be DTCP_VERSION....' RFC 2119 keyword, line 481: '...RVAL. This field MUST not be changed w...' RFC 2119 keyword, line 487: '...: Reserved/unused field, MUST be zero....' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Interval (8 bit unsigned integer): Interval in seconds between HELLO messages for the same layer-3 protocol. The recommended value is HELLO_INTERVAL. This field MUST not be changed while sending. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Duros 2 Internet-Draft W. Dabbous 3 June 1999 INRIA Sophia-Antipolis 4 H. Izumiyama 5 N. Fujii 6 WIDE 7 Y. Zhang 8 HRL 10 A Link Layer Tunneling Mechanism for Unidirectional Links 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 A version of this draft document is intended for submission to the 35 RFC editor as a Proposed Standard for the Internet Community. 37 Abstract 39 This document describes a mechanism to emulate bidirectional 40 connectivity between nodes that are directly connected by a 41 unidirectional link. The "receiver" uses a link layer tunneling 42 mechanism to forward datagrams to "feeds" over a bidirectional 43 network. As it is implemented at link layer, other protocols than IP 44 may also use this tunneling mechanism. 46 1. Introduction 48 Internet routing and upper layer protocols assume that links are 49 bidirectional, i.e., directly connected hosts can communicate with 50 each other over the same link. 52 This document describes a link layer tunneling mechanism that allows 53 nodes which are directly connected by a unidirectional link (feeds 54 and receivers, see section 2 for terminology) to send datagrams as if 55 they were connected to a bidirectional link. We present a generic 56 topology with a tunneling mechanism that supports multiple feeds and 57 receivers. 59 The tunneling mechanism is implemented at the link layer of the 60 interface connected to the unidirectional link on every feed and 61 every receiver. The aim is to hide from higher layers, i.e. network 62 layer and above, the unidirectional feature of the link. The 63 tunneling mechanism also includes an automatic tunnel configuration 64 protocol that allows feeds and receivers to come up/down at any time. 66 The tunneling mechanism proposes to use Generic Routing Encapsulation 67 [rfc1701] and provides a means for carrying IP, ARP datagrams and any 68 layer-3 protocol from receivers to feeds. 70 The tunneling mechanism described in this document was discussed and 71 agreed upon by the UDLR working group. 73 2. Terminology 75 Unidirectional link (UDL): A one way transmission link, e.g. a 76 broadcast satellite link. 78 Receiver: A router that has receive-only connectivity to an UDL. 80 Send-only feed: A router that has send-only connectivity to an UDL. 82 Receive capable feed: A router that has send-and-receive connectivity 83 to an UDL. 85 Feed: A send-only or a receive capable feed. 87 Node: A receiver or a feed. 89 3. Topology 91 In general, feeds and receivers are connected via a unidirectional 92 link. Send-only feeds can only send data over this unidirectional 93 link, and receivers can only receive data from it. Receive capable 94 feeds have both send and receive capabilities. In this document, we 95 consider the case of several feeds (send-only and/or receive capable) 96 and many receivers. 98 A receiver has several interfaces, a receive-only interface and one 99 or more additional bidirectional communication interfaces. A receiver 100 is required to be a router. 102 A feed has several interfaces, a send-only or a send-and-receive 103 capable interface connected to the unidirectional link and one or 104 more additional bidirectional communication interfaces. A feed MUST 105 be a router. 107 In the entire document we assume that feeds and receivers are 108 connected to the Internet via one of their bidirectional interfaces. 109 A receiver and a feed can then communicate with each other using this 110 specific bidirectional interface (Ethernet interface, PPP connection, 111 etc.). 113 Figure 1 depicts a generic topology with several feeds and several 114 receivers. 116 Unidirectional Link 118 ---->---------->------------------->------ 119 | | | | 120 |f1u |f2u |r2u |r1u 121 -------- -------- -------- -------- ---------- 122 |Feed 1| |Feed 2| |Recv 2| |Recv 1|---|subnet A| 123 -------- -------- -------- -------- ---------- 124 |f1b |f2b |r2b |r1b | 125 | | | | | 126 ---------------------------------------------------- 127 | Internet | 128 ---------------------------------------------------- 130 Figure 1: Generic topology 132 f1u (resp. f2u) is the IP address of the 'Feed 1' (resp. Feed 2) 133 send-only interface. 135 f1b (resp. f2b) is the IP address of the 'Feed 1' (resp. Feed 2) 136 bidirectional interface connected to the Internet. 138 r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 139 2) receive-only interface. 141 r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 142 2) bidirectional interface connected to the Internet. 143 Subnet A is a local area network connected to recv1 145 4. Problems related to unidirectional links 147 Most protocols in the Internet assume that links are bidirectional. 148 In particular, routing protocols used by directly connected routers 149 no longer behave properly in the presence of a unidirectional link. 150 Indeed, receivers cannot send requests/responses or routing messages 151 to feeds through their receive-only interface. 153 The network layer has no knowledge of the underlying transmission 154 technology except that it considers its access as bidirectional. 155 Basically, for outgoing datagrams, the network layer selects the 156 correct first hop on the connected network according to a routing 157 table and passes the packet(s) to the appropriate link-layer driver. 159 Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. 160 However, if Recv 1 initiates a 'ping f1u', it cannot get a response 161 from Feed 1. Recv 1 network layer delivers the packet to the driver 162 of the receive-only interface, which obviously cannot send it to the 163 feed. 165 More generally, a datagram of any protocol that passes from the 166 network layer to the driver of a receive-only interface is simply 167 discarded. 169 5. Emulating a broadcast bidirectional network 171 Some unidirectional links (e.g., satellite links) allow by nature 172 communication from a feed to a set of receivers: a feed can send 173 packets to a particular receiver and it can send broadcast packets. 174 However, any other communication is simply impossible: a receiver 175 cannot send packets to a receiver or a feed, a feed cannot send a 176 packet to a send-only feed. 178 A solution to this problem based on a link layer (LL) tunneling 179 mechanism which emulates a bidirectional connectivity in the presence 180 of a unidirectional link will be described in the next section. We 181 first consider the various communication scenarios which characterize 182 a broadcast network in order to define what functionalities the link 183 layer tunneling mechanism has to perform to emulate a bidirectional 184 broadcast link. 186 Here follows the scenarios which would be feasible on a broadcast 187 network, i.e if feeds and receivers were connected by a bidirectional 188 broadcast link: 190 Scenario 1: A receiver can send a packet to a feed (point-to-point 191 communication between a feed and a receiver). 193 Scenario 2: A receiver can send a broadcast/multicast packet on the 194 unidirectional link to all nodes (point-to-multipoint). 196 Scenario 3: A receiver can send a packet to another receiver (point- 197 to-point communication between two receivers). 199 Scenario 4: A feed can send a packet to a send-only feed (point-to- 200 point communication between two feeds). 202 Scenario 5: A feed can send a broadcast/multicast packet on the 203 unidirectional link to all nodes (point-to-multipoint). 205 Scenario 6: A feed can send a packet to receiver or a receive capable 206 feed. This is the default communication over a unidirectional link. 208 These scenarios are possible on a broadcast network. Scenario 6 is 209 already feasible on the unidirectional link. The link layer tunneling 210 mechanism should therefore provide the functionalities to permit 211 scenarios 1 to 5 to happen. Note that the scenarios above allow a 212 node to send a packet to any destination IP address on the Internet. 213 The next hop address at the receiver will be in this case the address 214 of another router (a feed or a receiver) which will relay the packet. 216 6. Link layer tunneling mechanism 218 This section describes a link layer tunneling mechanism allowing 219 bidirectional communication between feeds and receivers in the 220 presence of a unidirectional link. This mechanism has been designed 221 to work with any topology regardless of the number of feeds and 222 receivers. In particular, the special case of a single send-only feed 223 and multiple receivers is among the topologies supported. 225 This link layer tunneling mechanism operates underneath the network 226 layer. Its aim is to emulate a bidirectional connectivity. It is 227 transparent to the network layer: the link appears and behaves with 228 the network layer as if it was bidirectional. 230 Figure 2 depicts a layered representation of the link layer tunneling 231 mechanism in the case of Scenario 1. 233 Send-only Feed Receiver 235 decapsulation encapsulation 236 /-----***************----\ /-->---***************--\ 237 | | | | 238 | | | | 239 --|---------------------- | | ---------------------|--- 240 | | f1b | f1u | | | | x r1u | r1b | | 241 | | | ^ | | IP | | | | v | 242 | ^ | | | v | | | | | | 243 | | | | | | | | v | | | 244 |-|---------|-------|---| | | |----|------|--------|--| 245 | | | | | | ^ | | | | | 246 | | | | | | LL | | | | | | 247 | | | | | | | | | | | | 248 | | | O------/ \<------O | | | 249 |-|---------|-----------| |-----------|--------|--| 250 | | | | | | | | 251 | | | | PHY | | | | 252 | | | | | | v | 253 | | | | | | | | | | 254 --|-----------|---------- ----------|----------|--- 255 | Bidir | Send-Only Recv-Only | Bidir | 256 ^ Interf | Interf UDL Interf | Interf | 257 | \------------>------->------------/ | 258 \----------------------<------------------------<--------/ 259 Bidirectional network 261 x : IP layer at the receiver generates a datagram to be forwarded 262 on the receive-only interface. 263 O : Entry point where the link layer tunneling mechanism is 264 triggered. 266 Figure 2: Scenario 1 using the LL Tunneling Mechanism 268 6.1. Tunneling mechanism on the receiver 270 A datagram is delivered from the network layer to the link layer of 271 the unidirectional interface (see Figure 2). It is then encapsulated 272 behind a MAC header corresponding to the unidirectional link. This 273 packet cannot be sent over the link and is then processed by the 274 tunneling mechanism. 276 The packet is encapsulated behind an IP header whose destination is 277 the IP address of a feed bidirectional interface (f1b or f2b), also 278 called the tunnel end-point. The mechanism for a receiver to learn 279 these addresses and to choose the feed is explained in Section 6.3. 280 The type of encapsulation is described in Section 7. 282 The new datagram is passed to the network layer that forwards it 283 according to its destination address. The destination address of the 284 encapsulated datagram is a feed bidirectional interface which is 285 reachable via the Internet. The datagram is then forwarded via the 286 receiver bidirectional interface (r1b). 288 We have to distinguish several cases as the datagram is to be 289 tunneled according to the destination MAC address. If the destination 290 MAC address is: 292 1) the MAC address of a feed interface connected to the 293 unidirectional link (scenario 1): the datagram is encapsulated, 294 the destination address of the new datagram is the feed tunnel 295 end-point (f1b referring to Figure 2). 297 2) a MAC broadcast/multicast address (Scenario 2): the datagram is 298 encapsulated, the destination address of the new datagram is the 299 default feed tunnel end-point. See Section 6.3.4 for further 300 details on the default feed. 302 3) a MAC address that belongs to the unidirectional network but is 303 not a feed address (Scenario 3): the datagram is encapsulated 304 and sent to the tunnel end-point of the default feed. 306 At this point, the network layer passes a datagram to the link layer 307 of the receive-only interface, it is encapsulated and sent to a feed 308 via its bidirectional interface. 310 6.2. Tunneling mechanism on the feed 312 A feed processes packets in two different ways: packets must be 313 forwarded over the unidirectional link (e.g. packets generated by a 314 local application or a packet routed by the IP layer, see section 315 6.2.1) and encapsulated packets received from one of the receivers or 316 the feeds that need particular processing (section 6.2.2). 318 A feed cannot send directly over the unidirectional link a packet to 319 a send-only feed. In order to emulate this type of communication, a 320 feed MUST maintain a list of send-only feed tunnel end-points. This 321 is configured manually at the feed by the local administrator. In 322 fact, as stated in Section 3, the number of feeds is expected to be 323 relatively small, therefore a manual configuration can be envisaged. 324 How to use this list is detailed in the next section. 326 6.2.1. Forwarding packets over the unidirectional link 328 The way a packet is forwarded depends on its destination MAC address, 329 if it is: 331 1) the MAC address of a receiver or a receive capable feed 332 (Scenario 6). The packet is sent over the unidirectional link. 333 This is the classical "forwarding". 335 2) the MAC address of a send-only feed (Scenario 4). The packet is 336 encapsulated and sent to the send-only feed tunnel end-point. 337 The type of encapsulation is described in Section 7. 339 3) a broadcast/multicast destination (Scenario 5). The packet is 340 sent over the unidirectional link with a link layer header 341 corresponding to the broadcast/multicast addressing scheme. 342 Currently, a copy of this packet is encapsulated and sent to 343 every feed of the list of send-only feed tunnel end-points. 345 6.2.2. Receiving encapsulated packets 347 Feeds listen to incoming encapsulated datagrams on their tunnel end- 348 point. An encapsulated packet which is received from the 349 bidirectional interface, traverses the IP stack and enters a 350 decapsulation process (See Figure 2). Note that the original datagram 351 was encapsulated and therefore its payload (especially MAC and IP 352 header) has not been modified by intermediate routers. It is 353 decapsulated and further actions depend on the destination MAC 354 address which can be: 356 1) the MAC address of the feed interface connected to the 357 unidirectional link, this corresponds to Scenarios 1 and 4. The 358 packet is passed to the link layer of the interface connected to 359 the unidirectional link which then delivers it to the network 360 layer. As a result, the datagram is processed as if it was 361 coming from the unidirectional link. At this point, Scenarios 1 362 and 4 are now feasible, a receiver or a feed can send a packet 363 to a feed. 365 2) a receiver address, this corresponds to Scenario 3. The packet 366 is passed to the link layer of the interface connected to the 367 unidirectional link. It is directly sent over the unidirectional 368 link with the proper link layer encapsulation to the receiver 369 (note, the packet must not be delivered to the network layer). 370 Scenario 5 is now feasible, a receiver can send a packet to 371 another receiver. 373 3) a broadcast/multicast address, this corresponds to Scenario 2. 375 We have to distinguish two cases, either (i) the encapsulated 376 packet was sent from a receiver or (ii) from a feed 377 (encapsulated broadcast/multicast packet sent to a send-only 378 feed): 380 i) the feed was designed as a default feed by a receiver to 381 forward the broadcast/multicast packet. The feed is then in 382 charge of sending the multicast packet to all nodes. An 383 encapsulation process at the feed encapsulates the packet and 384 sends a copy to the list of send-only feed tunnel end-points. 385 The packet is also passed to the link layer of the interface 386 which forwards it directly over the unidirectional link (all 387 receivers and receive capable feeds receive it). The link 388 layer also delivers it locally to the network layer. Caution: 389 a receiver which sends an encapsulated broadcast/multicast 390 packet to a default feed will receive its own packet via the 391 unidirectional link. Correct filtering as described in 392 [rfc1112] must be applied. 394 ii) the feed receives the packet and keeps it for local 395 delivery. The packet is passed to the link layer of the 396 interface connected to the unidirectional link which delivers 397 it to the network layer. 399 Scenario 2 is now feasible, a receiver can send a 400 broadcast/multicast packet over the unidirectional link and it 401 will be heard by all nodes. 403 6.3. Dynamic Tunnel Configuration Protocol (DTCP) 405 Receivers and feeds have to know the feed tunnel end-points in order 406 to forward encapsulated datagrams (e.g, Scenarios 1 and 4). 408 The configuration of the send-only feeds list is performed manually 409 at the feed. The administrator sets up tunnels to all send-only 410 feeds. A tunnel end-point is an IP address of a send-only feed. 412 For scalability reasons this cannot be done at the receivers. Tunnels 413 must be configured and maintained dynamically in order to cope with 414 the following events: 416 1) when a new feed comes up, every receiver must create a tunnel to 417 enable a bidirectional communication with it. Static tunneling 418 configuration is not appropriate, as new feeds can be connected 419 to the unidirectional link at any time. 421 2) when the unidirectional link is down, receivers must disable 422 their tunnels. The tunneling mechanism emulates bidirectional 423 connectivity between nodes. Therefore, if the unidirectional 424 link is down, a feed should not receive datagrams from the 425 receivers. Indeed there are protocols that consider a link as 426 operational if they receive datagrams from it (e.g., the RIP 427 protocol [rfc2453]). 429 3) when a feed is down, receivers must disable their corresponding 430 tunnel. This prevents unnecessary datagrams from being tunneled 431 which would overload Internet. For instance, there is no need 432 for receivers to forward a broadcast message through a tunnel 433 whose end-point is down. 435 Note that these tunnels have no existence at the IP layer and are not 436 considered as tunnel interfaces. The DTCP protocol provides a means 437 for receivers to discover dynamically the presence of feeds and to 438 maintain a list of operational tunnel end-points. It is based on feed 439 periodical announcements over the unidirectional link that contain 440 tunnel end-point addresses. Receivers listen to these announcements 441 and maintain a list of tunnel end-points. 443 6.3.1. The HELLO message 445 The DTCP protocol is a 'unidirectional protocol', messages are only 446 sent from feeds to receivers. 448 The packet format is shown in Figure 2. Fields contain binary 449 integers, in normal Internet order with the most significant byte 450 first. Each tick mark represents one bit. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Vers | Com | Interval | Sequence | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Feed BDL IP addr (FBIP1) (32/128 bits) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | ..... | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Feed BDL IP addr (FBIPn) (32/128 bits) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 3: Packet Format 468 Every datagram contains the following fields, note that constants are 469 written in uppercase and are defined in section 6.3.5: 471 Vers (4 bits): DTCP version number. MUST be DTCP_VERSION. 473 Com (4 bits): Command field, possible values are 474 1 - JOIN A message announcing that the feed sending this message 475 is up and running. 476 2 - LEAVE A message announcing that the feed sending this message 477 is being shut down. 479 Interval (8 bit unsigned integer): Interval in seconds between HELLO 480 messages for the same layer-3 protocol. The recommended value is 481 HELLO_INTERVAL. This field MUST not be changed while sending. 483 Sequence (16 bit unsigned integer): Random value initialized at boot 484 time and incremented by 1 every time a value of the HELLO message 485 is modified. 487 res (3 bits): Reserved/unused field, MUST be zero. 489 F (1 bit): bit indicating the type of feed: 490 0 = Send-only feed 491 1 = Receive-capable feed 493 IP Vers (4 bits): IP protocol version of the feed bidirectional IP 494 addresses (FBIP): 495 4 = IP version 4 496 6 = IP version 6 498 Tunnel Type (8 bits): tunneling protocol supported by feed, 499 corresponds to the type of encapsulation used by receivers to 500 encapsulate packets which are tunneled: 501 47 = GRE [rfc1701] (recommended) 502 x = any other tunneling supporting the UDL MAC packets. 504 Nb of FBIP (8 bits): Number of bidirectional IP feed addresses which 505 are enumerated in the HELLO message 507 reserved (8 bits): Reserved/unused field, MUST be zero. 509 Feed BDL IP addr: 32 or 128 bit field. The feed bidirectional IP 510 address is the IP address of a feed bidirectional interface (tunnel 511 end-point) reachable via the Internet. A feed has 'Nb of FBIP' IP 512 addresses which are operational tunnel end-points. They are 513 enumerated in preferred order. FBIP1 being the most suitable tunnel 514 end-point. 516 6.3.2. DTCP on the feed: sending HELLO packets 518 The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP 519 announcement" multicast address over the unidirectional link on port 520 HELLO_PORT with a TTL of 1. 522 The source address of the HELLO packet is set to the IP address of 523 the feed interface connected to the unidirectional link. In the rest 524 of the document, this value is called FUIP (Feed Unidirectional IP 525 address). 527 The process in charge of sending HELLO packets fills every field of 528 the datagram according to the description given in Section 6.3.1. 530 As long as a feed is up and running, it periodically announces its 531 presence to receivers. It MUST send HELLO packets containing a JOIN 532 command every HELLO_INTERVAL over the unidirectional link. 534 Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO 535 messages with the FBIP1 field set to f1b (resp. f2b). 537 When a feed is about to be shut down, or when routing over the 538 unidirectional link is about to be intentionally interrupted, it is 539 recommended to: 541 1) stop sending HELLO messages containing a JOIN command. 543 2) send a HELLO message containing a LEAVE command to inform 544 receivers that the feed is no longer performing routing over the 545 unidirectional link. 547 6.3.3. DTCP on the receiver: receiving HELLO packets 549 Based on the reception of HELLO messages, receivers discover the 550 presence of feeds, maintain a list of active feeds, and keep track of 551 the tunnel end-points. The list of tunnel end-points is the entries 552 (FUIP,FBIP1,...,FBIPn) and is initially empty. 554 When a receiver is started, it MUST run a process which joins the 555 "DTCP announcement" multicast group and listens to incoming packets 556 on the HELLO_PORT port from the unidirectional link. 558 Upon the reception of a HELLO message, the process checks the version 559 number of the protocol. If it is different from HELLO_VERSION, the 560 packet is discarded and the process waits for the next incoming 561 packet. 563 After successfully checking the version number, further action 564 depends on the type of command: 566 - JOIN: 568 The process verifies if the address FUIP already belongs to the 569 list of active feeds. 571 If it does not, the entry (FUIP,FBIP1,...,FBIPn) is added to the 572 list of active feeds. The number of feed bidirectional IP 573 addresses to read is deduced from the 'Nb of FBID' field. The 574 tunnel type is also read and recorded for this FUIP. A timer set 575 to HELLO_LEAVE is associated with this entry. 577 If it does, the sequence number is compared to the sequence number 578 contained in the previous HELLO packet sent by this feed. If it is 579 equal the timer associated with this entry is reset to 580 HELLO_LEAVE. Otherwise all the information corresponding to FUIP 581 is reset. 583 Referring to Figure 1 in Section 3, both receivers (recv 1 and 584 recv 2) have a list of active feeds containing two entries which 585 are (f1u,(f1b)) and (f2u,(f2b)). 587 - LEAVE: 589 The process checks if there is an entry with the value FUIP that 590 belongs to the list of active feeds. If it does, the entry 591 (FUIP,FBIP1,...,FBIPn) is deleted from the list and the 592 corresponding timer is disabled. The LEAVE message provides a 593 means of quickly updating the list of active feeds. 595 A timeout occurs for two reasons: 597 1) a feed went down without sending a LEAVE message. As JOIN 598 messages are no longer sent from this feed, a timeout occurs at 599 HELLO_LEAVE after the last JOIN message. 601 2) the unidirectional link is down. Thus, no more JOIN messages are 602 received from the feeds. All the timeouts associated with 603 entries (FUIP,FBIP1,...,FBIPn) expire at HELLO_LEAVE after the 604 last JOIN message from the unidirectional link. 606 In both cases, the associated (FUIP,FBIP1,...,FBIPn) entries are 607 removed from the list of active feeds. As either the feed does not 608 route datagrams over the unidirectional link or the link is down, 609 bidirectional connectivity can no longer be ensured between the 610 receiver and the feed (FUIP). As a result, the list only contains 611 operational tunnel end-points. 613 The HELLO protocol provides the receivers with the list of usable 614 tunnel end-points (FBIP1,..., FBIPn) per feed. In the following 615 section, we describe how to integrate the HELLO protocol into the 616 tunneling mechanism described in Sections 6.1 and 6.2. 618 6.3.4. Tunneling mechanism using the list of active feeds 620 This section explains how the tunneling mechanism uses the list of 621 active feeds to handle datagrams which are to be tunneled. Referring 622 to Section 6.1, it shows how feed tunnel end-points are selected. 624 The choice of the default feed is done by the receiver administrator 625 according to a local policy. This policy is out of scope of in this 626 document. However, as an example, the default feed may be the feed 627 that has the lowest round trip time to the receiver. 629 When a receiver sends a packet to a feed it chooses the tunnel end- 630 point within the FBIP list. The 'preferred FBIP' is generally FBIP1 631 (see 6.3.1). However, for some reasons, a receiver may have a better 632 connectivity to another FBIPi of this feed. In that case, it is 633 possible to use FBIPi instead of FBIP1 as tunnel end-point. This 634 decision is taken by the receiver administrator. 636 Several cases are enumerated in Section 6.1 to determine where to 637 forward a MAC packet according to its destination address. If the 638 destination address is: 640 1) the MAC address of a feed interface connected to the 641 unidirectional link: this is TRUE if the address matches with 642 the MAC address of an FUIP in the list of active feeds. The 643 datagram is encapsulated and sent the preferred FBIP of the 644 feed. The encapsulation type depends on the tunnel type required 645 by the feed FUIP. 647 2) the broadcast address of the unidirectional link or a multicast 648 address: a copy of the datagram is encapsulated and sent to the 649 preferred FBIP of the default feed. The encapsulation type 650 depends on the tunnel type required by the default feed. 652 3) an address that belongs to the unidirectional network but is not 653 a feed address (i.e., it does not match a MAC address of any 654 FUIP in the list of active feeds): the datagram is encapsulated 655 and sent to the preferred FBIP of the default feed. The 656 encapsulation type depends on the tunnel type required by the 657 default feed. 659 6.3.5. Constant definitions 661 DTCP_VERSION is 1. 663 HELLO_INTERVAL is 5 seconds. 665 "DTCP announcement" multicast group is 224.0.1.124. 667 HELLO_PORT is 652. It is a reserved system port, no other traffic 668 must be allowed. 670 HELLO_LEAVE is 3*HELLO_INTERVAL, i.e. 15 seconds. 672 7. Tunnel encapsulation format 674 The tunneling mechanism operates at the link layer level and emulates 675 bidirectional connectivity between receivers and feeds. We assume 676 that hardware connected to the unidirectional link supports broadcast 677 and unicast MAC addressing. That is, a feed can send a packet to a 678 particular receiver using a unicast MAC destination address or to a 679 set of receivers using a broadcast/multicast destination address. The 680 hardware (or the driver) of the receiver can then filter the incoming 681 packets sent over the unidirectional links without any assumption of 682 the encapsulated data type. 684 In a similar way, a receiver should be capable of sending unicast and 685 broadcast MAC packets over the unidirectional link via its tunnels. 686 The encapsulation process should encapsulate link layer level 687 packets. As a result, after decapsulating an incoming packet, the 688 feed can perform link layer filtering as if data was directly coming 689 from the unidirectional link (See Figure 2). 691 The Generic Routing Encapsulation (GRE) [rfc1701] suits our 692 requirements because it specifies a protocol for encapsulating 693 arbitrary packets within IP as the delivery protocol. Alternatively, 694 we can also encapsulate directly a MAC level packet within an IP 695 datagram. 697 It is the feed's local administrator who decides what encapsulation 698 is used by a receiver to send a packet via a tunnel to this feed. The 699 tunnel type field in the HELLO message is either set to GRE or to any 700 other encapsulation supporting UDL MAC level packets. 702 7.1. Generic Routing Encapsulation on the receiver 704 A GRE packet is composed of a header in which a type field specifies 705 the encapsulated protocol (ARP, IP, IPX, etc.). See 706 [rfc1701][rfc1702] for details about the encapsulation. In our case, 707 only the support of the MAC addressing scheme of the unidirectional 708 link MUST be implemented. 710 A packet tunneled with a GRE encapsulation has the following format: 712 the delivery header is an IP header whose destination is the tunnel 713 end-point (FBIP), followed by a GRE header specifying the link layer 714 type of the unidirectional link. Figure 4 presents the entire 715 encapsulated packet. 717 ---------------------------------------- 718 | IP delivery header | 719 | destination addr = FBIP | 720 | IP proto = GRE (47) | 721 ---------------------------------------- 722 | GRE Header | 723 | type = MAC level of the UDL | 724 ---------------------------------------- 725 | Payload packet | 726 | MAC packet | 727 ---------------------------------------- 729 Figure 4: Encapsulated packet 731 7.2. Encapsulation of UDL MAC level packets 733 An alternative is to encapsulate the MAC level packet within IP. The 734 protocol field in the IP datagram is then set to the MAC level type 735 of the unidirectional link. Figure 5 presents the entire encapsulated 736 packet. 738 ---------------------------------------- 739 | IP delivery header | 740 | destination addr = FBIP | 741 | IP proto = MAC level of the UDL | 742 ---------------------------------------- 743 | Payload packet | 744 | MAC packet | 745 ---------------------------------------- 747 Figure 5: Encapsulated packet 749 8. Issues 751 8.1. Hardware address resolution 753 Regardless of unidirectional or bidirectional links, if a feed sends 754 a packet over a broadcast type network it requires the data link 755 address of the destination. ARP [rfc826] is used on an Ethernet 756 network for that purpose. 758 The link layer mechanism emulates a bidirectional network in the 759 presence of an unidirectional link. However, there are asymmetric 760 delays between every (feed, receiver) pair. The back-channel between 761 a receiver and a feed has varying delays because packets go through 762 the Internet. Furthermore, a typical example of a unidirectional 763 link is a GEO satellite link whose delay is about 250 milliseconds. 765 Because of long round trip delays, current address resolution such as 766 [rfc826] may not be efficient. E.g., a feed has to forward packets at 767 high data rates to a receiver whose hardware address is unknown. The 768 stream of packets is passed to the link layer driver of the feed 769 send-only interface. When the first packet arrives, the link layer 770 realizes it does not have the corresponding hardware address of the 771 next hop, and sends an ARP request. While the link layer is waiting 772 for the response (at least 250 ms for GEO satellite), IP packets are 773 buffered by the feed. If it runs out of space before the ARP response 774 arrives, IP packets will be dropped. 776 The inefficiency of address resolution protocols is not addressed in 777 this document. An ad-hoc solution is proposed when the MAC address is 778 configurable (which is the case in some satellite receiver cards). It 779 consists in mapping the IP address on a MAC address. In this case, no 780 address resolution protocol is required. 782 8.2. Routing protocols 784 The link layer tunneling mechanism hides from the network layer and 785 above layers the fact that feeds and receivers are connected by a 786 unidirectional link. Communication is bidirectional but asymmetric in 787 bandwidths and delays. 789 In order to incorporate unidirectional links in the Internet, feeds 790 and receivers have to run routing protocols. They will work fine 791 because feeds and receivers consider themselves as directly 792 connected, and can exchange routing messages over the unidirectional 793 link. 795 The tunneling mechanism allows one to forward all the IP traffic, and 796 not only routing protocol messages from receivers to feeds. Receivers 797 can route datagrams on the Internet using the most suitable feed or 798 receiver as a next hop. 800 Feeds and receivers can run multicast routing daemon and therefore 801 dynamic multicast routing can be performed over the unidirectional 802 link. However issues related to multicast routing (e.g. protocol 803 configuration) are not addressed in this document. 805 8.3. Scalability 806 The DTCP protocol does not generate a lot of traffic whatever the 807 number of nodes. The problem with a large number of nodes is not 808 related to this protocol but to a more general issue such as the 809 maximum number of nodes which can be connected to a link. This is out 810 of scope of this document. 812 9. Security Considerations 814 Receivers send packets through tunnels to feeds. Because of 815 scalability reasons, there is no specific mechanism in this document 816 to ensure that a receiver is allowed to set a tunnel to a feed. Any 817 malicious individual that gains access to the unidirectional link can 818 get full connectivity to feeds. Therefore it is highly recommended on 819 the feed site to have some firewall capabilities. 821 10. Acknowledgments 823 We would like to thank Patrick Cipiere (INRIA) for his valuable input 824 concerning the design of the encapsulation mechanism. 826 We would like also to thank for their participation: Akihiro Tosaka 827 (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi 828 Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), 829 Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu 830 (Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri 831 Hakulinen (Nokia). 833 11. References 835 [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, 836 November 1982. 838 [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford 839 University, August 1989 841 [rfc1702] 'Generic Routing Encapsulation over IPv4 networks', S. 842 Hanks, NetSmiths, Ltd., T. Li, D. Farinacci, P. Traina, 843 Cisco System, October 1994. 845 [rfc1701] 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths, 846 Ltd., T. Li, D. Farinacci, P. Traina, Cisco System, October 847 1994. 849 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 851 Author's address 853 Emmanuel Duros 854 INRIA Sophia Antipolis 855 2004, Route des Lucioles BP 93 856 06902 Sophia Antipolis 857 France 858 Phone : +33 4 92 38 79 42 859 Fax : +33 4 92 38 79 78 860 Email : Emmanuel.Duros@inria.fr 862 Walid Dabbous 863 INRIA Sophia Antipolis 864 2004, Route des Lucioles BP 93 865 06902 Sophia Antipolis 866 France 867 Phone : +33 4 92 38 77 18 868 Fax : +33 4 92 38 79 78 869 Email : Walid.Dabbous@inria.fr 871 Hidetaka Izumiyama 872 Japan Satellite Systems Inc. 873 Toranomon 17 Mori Bldg.5F 874 1-26-5 Toranomon, Minato-ku 875 Tokyo 105 876 Japan 877 Voice : +81-3-5511-7568 878 Fax : +81-3-5512-7181 879 Email : izu@jcsat.co.jp 881 Noboru Fujii 882 Sony Corporation 883 2-10-14 Osaki, Shinagawa-ku 884 Tokyo 141 885 Japan 886 Voice : +81-3-3495-3092 887 Fax : +81-3-3495-3527 888 Email : fujii@dct.sony.co.jp 890 Yongguang Zhang 891 HRL 892 RL-96, 3011 Malibu Canyon Road 893 Malibu, CA 90265, 894 USA 895 Phone : 310-317-5147 896 Fax : 310-317-5695 897 Email : ygz@hrl.com