idnits 2.17.1 draft-ietf-udlr-lltunnel-01.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 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 319: '... feed MUST maintain a list of send-o...' RFC 2119 keyword, line 468: '... version number. MUST be DTCP_VERSION....' RFC 2119 keyword, line 477: '...lue is HELLO_INTERVAL. This field MUST...' RFC 2119 keyword, line 484: '...: 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. 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 (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Duros 3 Internet-Draft W. Dabbous 4 April 1999 INRIA Sophia-Antipolis 5 H. Izumiyama 6 N. Fujii 7 WIDE 8 Y. Zhang 9 HRL 11 A Link Layer Tunneling Mechanism for Unidirectional Links 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 A version of this draft document is intended for submission to the 36 RFC editor as a Proposed Standard for the Internet Community. 38 Abstract 40 This document describes a mechanism to emulate bidirectional 41 connectivity between nodes that are directly connected by a 42 unidirectional link. The "receiver" uses a link layer tunneling 43 mechanism to forward datagrams to "feeds" over a bidirectional 44 network. 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 and ARP datagrams from 68 receivers to feeds. 70 The tunneling mechnism 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 The tunneling mechanism is inserted at the link layer of the 271 receive-only interface. As a datagram is delivered to the link layer 272 from the network layer, it is encapsulated (See Figure 2). 274 The datagram is encapsulated behind an IP header whose destination is 275 the IP address of a feed bidirectional interface (f1b or f2b), also 276 called the tunnel end-point. The mechanism for a receiver to learn 277 these addresses and to choose the feed is explained in Section 6.3. 279 The type of encapsulation is described in Section 7. 281 The new datagram is passed to the network layer that forwards it 282 according to its destination address. The destination address of the 283 encapsulated datagram is a feed bidirectional interface which is 284 reachable via the Internet. The datagram is then forwarded via the 285 receiver bidirectional interface (r1b). 287 We have to distinguish several cases as the datagram is to be 288 tunneled according to the next hop address. If the next hop address 289 is: 291 1) the IP address of a feed interface connected to the 292 unidirectional link (scenario 1): the datagram is encapsulated, 293 the destination address of the new datagram is the feed tunnel 294 end-point (f1b referring to Figure 2). 296 2) a broadcast/multicast address (Scenario 2): the datagram is 297 encapsulated, the destination address of the new datagram is the 298 default feed tunnel end-point. See Section 6.3.4 for further 299 details on the default feed. 301 3) an IP address that belongs to the unidirectional network but is 302 not a feed address (Scenario 3): the datagram is encapsulated 303 and sent to the tunnel end-point of the default feed. 305 At this point, the network layer passes a datagram to the link layer 306 of the receive-only interface, it is encapsulated and sent to a feed 307 via its bidirectional interface. 309 6.2. Tunneling mechanism on the feed 311 A feed processes packets in two different ways: packets must be 312 forwarded over the unidirectional link (e.g. packets generated by a 313 local application or a packet routed by the IP layer, see section 314 6.2.1) and encapsulated packets received from one of the receivers or 315 the feeds that need particular processing (section 6.2.2). 317 A feed cannot send directly over the unidirectional link a packet to 318 a send-only feed. In order to emulate this type of communication, a 319 feed MUST maintain a list of send-only feed tunnel end-points. This 320 is configured manually at the feed by the local administrator. In 321 fact, as stated in Section 3, the number of feeds is expected to be 322 relatively small, therefore a manual configuration can be envisaged. 323 How to use this list is detailed in the next section. 325 6.2.1. Forwarding packets over the unidirectional link 326 The way a packet is forwarded depends on its next hop IP address, if 327 it is: 329 1) the IP address of a receiver or a receive capable feed (Scenario 330 6). The packet is encapsulated behind a link layer header with 331 the corresponding MAC address of the destination. It is then 332 sent over the unidirectional link. 334 2) the IP address of a send-only feed (Scenario 4). The packet is 335 encapsulated and sent to the send-only feed tunnel end-point. 337 3) a broadcast/multicast destination (Scenario 5). The packet is 338 sent over the unidirectional link with a link layer header 339 corresponding to the broadcast/multicast addressing scheme. 340 Currently, a copy of this packet is encapsulated and sent to 341 every feed of the list of send-only feed tunnel end-points. 343 6.2.2. Receiving encapsulated packets 345 Feeds listen to incoming encapsulated datagrams on their tunnel end- 346 point. An encapsulated packet which is received from the 347 bidirectional interface, traverses the IP stack and enters a 348 decapsulation process (See Figure 2). Note that the original datagram 349 was encapsulated and therefore its IP header has not been modified by 350 intermediate routers. It is decapsulated and further actions depend 351 on the next hop IP address which can be: 353 1) the address of the feed interface connected to the 354 unidirectional link, this corresponds to Scenarios 1 and 4. The 355 packet is passed to the link layer of the interface connected to 356 the unidirectional link which then delivers it to the network 357 layer. As a result, the datagram is processed as if it was 358 coming from the unidirectional link. At this point, Scenarios 1 359 and 4 are now feasible, a receiver or a feed can send a packet 360 to a feed. 362 2) a receiver address, this corresponds to Scenario 3. The packet 363 is passed to the link layer of the interface connected to the 364 unidirectional link. It is directly sent over the unidirectional 365 link with the proper link layer encapsulation to the receiver 366 (note, the packet must not be delivered to the network layer). 367 Scenario 5 is now feasible, a receiver can send a packet to 368 another receiver. 370 3) a broadcast/multicast address, this corresponds to Scenario 2. 371 We have to distinguish two cases, either (i) the encapsulated 372 packet was sent from a receiver or (ii) from a feed 373 (encapsulated broadcast/multicast packet sent to a send-only 374 feed): 376 i) the feed was designed as a default feed by a receiver to 377 forward the broadcast/multicast packet. The feed is then in 378 charge of sending the multicast packet to all nodes. An 379 encapsulation process at the feed encapsulates the packet and 380 sends a copy to the list of send-only feed tunnel end-points. 381 The packet is also passed to the link layer of the interface 382 which forwards it directly over the unidirectional link (all 383 receivers and receive capable feeds receive it). The link 384 layer also delivers it locally to the network layer. Caution: 385 a receiver which sends an encapsulated broadcast/multicast 386 packet to a default feed will receive its own packet via the 387 unidirectional link. Correct filtering as described in 388 RFC1112 must be applied. 390 ii) the feed receives the packet and keeps it for local 391 delivery. The packet is passed to the link layer of the 392 interface connected to the unidirectional link which delivers 393 it to the network layer. 395 Scenario 2 is now feasible, a receiver can send a 396 broadcast/multicast packet over the unidirectional link and it 397 will be heard by all nodes. 399 6.3. Dynamic Tunnel Configuration Protocol (DTCP) 401 Receivers and feeds have to know the feed tunnel end-points in order 402 to forward encapsulated datagrams (e.g, Scenarios 1 and 4). 404 The configuration of the send-only feeds list is performed manually 405 at the feed. The administator sets up tunnels to all send-only feeds. 406 A tunnel end-point is an IP address (FBIP) of a send-only feed. 408 For scalability reasons this cannot be done at the receivers. Tunnels 409 must be configured and maintained dynamically in order to cope with 410 the following events: 412 1) when a new feed comes up, every receiver must create a tunnel to 413 enable a bidirectional communication with it. Static tunneling 414 configuration is not appropriate, as new feeds can be connected 415 to the unidirectional link at any time. 417 2) when the unidirectional link is down, receivers must disable 418 their tunnels. The tunneling mechanism emulates bidirectional 419 connectivity between nodes. Therefore, if the unidirectional 420 link is down, a feed should not receive datagrams from the 421 receivers. Indeed there are protocols that consider a link as 422 operational if they receive datagrams from it (e.g., the RIP 423 protocol [rfc2453]). 425 3) when a feed is down, receivers must disable their corresponding 426 tunnel. This prevents unnecessary datagrams from being tunneled 427 which would overload Internet. For instance, there is no need 428 for receivers to forward a broadcast message through a tunnel 429 whose end-point is down. 431 The DTCP protocol provides a means for receivers to discover 432 dynamically the presence of feeds and to maintain a list of 433 operational tunnel end-points. It is based on feed periodical 434 announcements over the unidirectional link that contain tunnel end- 435 point addresses. Receivers listen to these announcements and maintain 436 a list of tunnel end-points. 438 6.3.1. The HELLO message 440 The DTCP protocol is a 'unidirectional protocol', messages are only 441 sent from feeds to receivers. 443 The packet format is shown in Figure 2. Fields contain binary 444 integers, in normal Internet order with the most significant byte 445 first. Each tick mark represents one bit. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Vers | Com | Interval | Sequence | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Feed UDL IP addr (32/128 bits) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Feed BDL IP addr (FBIP1) (32/128 bits) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | ..... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Feed BDL IP addr (FBIPn) (32/128 bits) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 3: Packet Format 465 Every datagram contains the following fields, note that constants are 466 written in uppercase and are defined in section 6.3.5: 468 Vers (4 bits): DTCP version number. MUST be DTCP_VERSION. 470 Com (4 bits): Command field, possible values are 471 1 - JOIN A message announcing that the feed sending this message 472 is up and running. 473 2 - LEAVE A message announcing that the feed sending this message 474 is being shut down. 476 Interval (8 bit unsigned integer): Interval in seconds between HELLO 477 messages. The recommended value is HELLO_INTERVAL. This field MUST 478 not be changed while sending. 480 Sequence (16 bit unsigned integer): Random value initialized at boot 481 time and incremented by 1 every time a value of the HELLO message 482 is modified. 484 res (3 bits): Reserved/unused field, MUST be zero. 486 F (1 bit): bit indicating the type of feed: 487 0 = Send-only feed 488 1 = Receive-capable feed 490 IP Vers (4 bits): IP protocol version of the feed bidirectional IP 491 addresses (FBIP): 492 4 = IP version 4 493 6 = IP version 6 495 Tunnel Type (8 bits): tunneling protocol supported by feed, 496 correponds to the type of encapsulation used by receivers to 497 encapsulate packets which are tunneled: 498 47 = GRE [rfc1701] (recommended) 499 x = any other tunneling supporting the UDL MAC packets. 501 Nb of FBIP (8 bits): Number of bidirectional IP feed addresses which 502 are enumerated in the HELLO message 504 reserved (8 bits): Reserved/unused field, MUST be zero. 506 Feed UDL IP addr: 32 or 128 bit field. The value is the IP address of 507 the feed interface connected to the unidirectional link which sends 508 the HELLO packet. 510 Feed BDL IP addr: 32 or 128 bit field. The bidirectional IP address 511 feed is the IP address of a feed bidirectional interface (tunnel 512 end-point) reachable via the Internet. A feed has 'Nb of FBIP' IP 513 addresses which are operational tunnel end-points. They are 514 enumerated in prefered order. FBIP1 being the most suitable tunnel 515 end-point. 517 6.3.2. DTCP on the feed: sending HELLO packets 519 The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP 520 announcement" multicast address over the unidirectional link on port 521 HELLO_PORT with a TTL of 1. 523 The source address of the HELLO packet is set to the IP address of 524 the feed interface connected to the unidirectional link. 526 The process in charge of sending HELLO packets fills every field of 527 the datagram according to the description given in Section 6.3.1. 529 As long as a feed is up and running, it periodically announces its 530 presence to receivers. It MUST send HELLO packets containing a JOIN 531 command every HELLO_INTERVAL over the unidirectional link. 533 Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO 534 messages with the FUIP field set to f1u (resp. f2u) and the FBIP1 535 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 it is recommended to 564 check that the FUIP contained in the packet is the same as the source 565 address of the HELLO packet. Further action depends on the type of 566 command: 568 - JOIN: 570 The process verifies if the address FUIP contained in the HELLO 571 packet already belongs to the list of active feeds. 573 If it does not, the entry (FUIP,FBIP1,...,FBIPn) is added to the 574 list of active feeds. The number of feed bidirectional IP 575 addresses to read is deduced from the 'Nb of FBID' field. The 576 tunnel type is also read and recorded for this FUIP. A timer set 577 to HELLO_LEAVE is associated with this entry. 579 If it does, the sequence number is compared to the sequence number 580 contained in the previous HELLO packet sent by this feed. If it is 581 equal the timer associated with this entry is reset to 582 HELLO_LEAVE. Otherwise all the information corresponding to FUIP 583 is reset. 585 Referring to Figure 1 in Section 3, both receivers (recv 1 and 586 recv 2) have a list of active feeds containing two entries which 587 are (f1u,(f1b)) and (f2u,(f2b)). 589 - LEAVE: 591 The process checks if there is an entry with the value FUIP 592 contained in the HELLO packet that belongs to the list of active 593 feeds. If it does, the entry (FUIP,FBIP1,...,FBIPn) is deleted 594 from the list and the corresponding timer is disabled. The LEAVE 595 message provides a means of quickly updating the list of active 596 feeds. 598 A timeout occure for two reasons: 600 1) a feed went down without sending a LEAVE message. As JOIN 601 messages are no longer sent from this feed, a timeout occures at 602 HELLO_LEAVE after the last JOIN message. 604 2) the unidirectional link is down. Thus, no more JOIN messages are 605 received from the feeds. All the timeouts associated with 606 entries (FUIP,FBIP1,...,FBIPn) expire at HELLO_LEAVE after the 607 last JOIN message from the unidirectional link. 609 In both cases, the associated (FUIP,FBIP1,...,FBIPn) entries are 610 removed from the list of active feeds. As either the feed does not 611 route datagrams over the unidirectional link or the link is down, 612 bidirectional connectivity can no longer be ensured between the 613 receiver and the feed (FUIP). As a result, the list only contains 614 operational tunnel end-points. 616 The HELLO protocol provides the receivers with the list of usable 617 tunnel end-points (FBIP1,..., FBIPn) per feed. In the following 618 section, we describe how to integrate the HELLO protocol into the 619 tunneling mechanism described in Sections 6.1 and 6.2. 621 6.3.4. Tunneling mechanism using the list of active feeds 623 This section explains how the tunneling mechanism uses the list of 624 active feeds to handle datagrams which are to be tunneled. Referring 625 to Section 6.1, it shows how feed tunnel end-points are selected. 627 The choice of the default feed is done by the receiver administrator 628 according to a local policy. This policy is out of scope of this 629 document. 631 Several cases are enumerated in Section 6.1 to determine where to 632 forward an IP datagram according to the next hop address. If the next 633 hop address is: 635 1) the IP address of a feed interface connected to the 636 unidirectional link: this is TRUE if the address matches with an 637 FUIP in the list of active feeds. The datagram is encapsulated 638 and sent to the corresponding FBIP1. The encapsulation type 639 depends on the tunnel type required by the feed FUIP. 641 2) the broadcast address of the unidirectional link or a multicast 642 address: a copy of the datagram is encapsulated and sent to the 643 default feed if it belongs to the list of active feeds. 644 Otherwise the packet is discarded. The encapsulation type 645 depends on the tunnel type required by the default feed. 647 3) an address that belongs to the unidirectional network but is not 648 a feed address (i.e., it does not match any FUIP in the list of 649 active feeds): the datagram is encapsulated and sent to the 650 default feed if it belongs to the list of active feeds. 651 Otherwise the packet is discarded. The encapsulation type 652 depends on the tunnel type required by the default feed. 654 6.3.5. Constant definitions 656 DTCP_VERSION is 1. 658 HELLO_INTERVAL is 5 seconds. 660 "DTCP announcement" multicast group is 224.0.1.124. 662 HELLO_PORT is 652. It is a reserved system port, no other traffic 663 must be allowed. 665 HELLO_LEAVE is 3*HELLO_INTERVAL, i.e. 15 seconds. 667 7. Tunnel encapsulation format 669 The tunneling mechanism operates at the link layer level and emulates 670 bidirectional connectivity between receivers and feeds. We assume 671 that hardware connected to the unidirectional link supports broadcast 672 and unicast MAC addressing. That is, a feed can send a packet to a 673 particular receiver using a unicast MAC destination address or to a 674 set of receivers using a broadcast/multicast destination address. The 675 hardware (or the driver) of the receiver can then filter the incoming 676 packets sent over the unidirectional links without any assumption of 677 the encapsulated data type. 679 In a similar way, a receiver should be capable of sending unicast and 680 broadcast MAC packets over the unidirectional link via its tunnels. 681 The encapsulation process should encapsulate link layer level 682 packets. As a result, after decapsulating an incoming packet, the 683 feed can perform link layer filtering as if data was directly coming 684 from the unidirectional link (See Figure 2). 686 The Generic Routing Encapsulation (GRE) [rfc1701] suits our 687 requirements because it specifies a protocol for encapsulating 688 arbitrary packets within IP as the delivery protocol. Alternatively, 689 we can also encapsulate directly a MAC level packet within an IP 690 datagram. Other encapsultion mechanisms can be chosen. 692 It is the feed's local administrator who decides what encapsulation 693 is used by a receiver to send a packet via a tunnel to this feed. The 694 tunnel type field in the HELLO message is either set to GRE or to any 695 other encapsulaton supporting UDL MAC level packets. 697 7.1. Generic Routing Encapsultation on the receiver 699 A GRE packet is composed of a header in which a type field specifies 700 the encapsulated protocol (ARP, IP, IPX, etc.). See 701 [rfc1701][rfc1702] for details about the encapsulation. In our case, 702 only the support of the MAC addressing scheme of the unidirectional 703 link MUST be implemented. 705 A packet tunneled with a GRE encapsulation has the following format: 706 the delivery header is an IP header whose destination is the tunnel 707 end-point (FBIP), followed by a GRE header specifying the link layer 708 type of the unidirectional link. Figure 4 presents the entire 709 encapsulated packet. 711 ---------------------------------------- 712 | IP delivery header | 713 | destination addr = FBIP | 714 | IP proto = GRE (47) | 715 ---------------------------------------- 716 | GRE Header | 717 | type = MAC level of the UDL | 718 ---------------------------------------- 719 | Payload packet | 720 | MAC packet | 721 ---------------------------------------- 723 Figure 4: Encapsulated packet 725 7.2. Encapsulation of UDL MAC level packets 727 An alternative is to encapsultate the MAC level packet within IP. The 728 protocol field in the IP datagram is then set to the MAC level type 729 of the unidirectional link. Figure 5 presents the entire encapsulated 730 packet. 732 ---------------------------------------- 733 | IP delivery header | 734 | destination addr = FBIP | 735 | IP proto = MAC level of the UDL | 736 ---------------------------------------- 737 | Payload packet | 738 | MAC packet | 739 ---------------------------------------- 741 Figure 5: Encapsulated packet 743 8. Issues 745 8.1. Hardware address resolution 747 Regardless of unidirectional or bidirectional links, if a feed sends 748 a packet over a broadcast type network it requires the data link 749 address of the destination. ARP [rfc826] is used on an Ethernet 750 network for that purpose. 752 The link layer mechanism emulates a bidirectional network in the 753 presence of an unidirectional link. However, there are asymmetric 754 delays between every (feed, receiver) pair. The back-channel between 755 a receiver and a feed has varying delays because packets go through 756 the Internet. Furthermore, a typical example of a unidirectional 757 link is a GEO satellite link whose delay is about 250 milliseconds. 759 Because of long round trip delays, current address resolution such as 760 [rfc826] may not be efficient. E.g., a feed has to forward packets at 761 high data rates to a receiver whose hardware address is unknown. The 762 stream of packets is passed to the link layer driver of the feed 763 send-only interface. When the first packet arrives, the link layer 764 realizes it does not have the corresponding hardware address of the 765 next hop, and sends an ARP request. While the link layer is waiting 766 for the response (at least 250 ms for GEO satellite), IP packets are 767 buffered by the feed. If it runs out of space before the ARP response 768 arrives, IP packets will be dropped. 770 The inefficiency of address resolution protocols is not addressed in 771 this document. An ad-hoc solution is proposed when the MAC address is 772 configurable (which is the case in some satellite receiver cards). It 773 consists in mapping the IP address on a MAC address. In this case, no 774 address resolution protocol is required. 776 8.2. Routing protocols 778 The link layer tunneling mechanism hides from the network layer and 779 above layers the fact that feeds and receivers are connected by a 780 unidirectional link. Communication is bidirectional but asymmetric in 781 bandwidths and delays. 783 In order to incorporate unidirectional links in the Internet, feeds 784 and receivers have to run routing protocols. They will work fine 785 because feeds and receivers consider themselves as directly 786 connected, and can exchange routing messages over the unidirectional 787 link. 789 The tunneling mechanism allows one to forward all the IP traffic, and 790 not only routing protocol messages from receivers to feeds. Receivers 791 can route datagrams on the Internet using the most suitable feed or 792 receiver as a next hop. 794 Feeds and receivers can run multicast routing daemon and therefore 795 dynamic multicast routing can be performed over the unidirectional 796 link. However issues related to multicast routing (e.g. protocol 797 configuration) are not addressed in this document. 799 8.3. Scalability 801 The DTCP protocol does not generate a lot of traffic whatever the 802 number of nodes. The problem with a large number of nodes is not 803 related to this protocol but to a more general issue such as the 804 maximum number of nodes which can be connected to a link. This is out 805 of scope of this document. 807 9. Security Considerations 809 Receivers send packets through tunnels to feeds. Because of 810 scalability reasons, there is no specific mechanism in this document 811 to ensure that a receiver is allowed to set a tunnel to a feed. Any 812 malicious individual that gains access to the unidirectional link can 813 get full connectivity to feeds. Therefore it is higly recommended on 814 the feed site to have some firewall capabilities. 816 10. Acknowledgments 818 We would like to thank Patrick Cipiere (INRIA) for his valuable input 819 concerning the design of the encapsulation mechanism. 821 We would like also to thank for their participation: Akihiro Tosaka 822 (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi 823 Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), 824 Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu 825 (Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri 826 Hakulinen (Nokia). 828 11. References 830 [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, 831 November 1982. 833 [rfc1702] 'Generic Routing Encapsulation over IPv4 networks', S. 834 Hanks, NetSmiths, Ltd., T. Li, D. Farinacci, P. Traina, 835 Cisco System, October 1994. 837 [rfc1701] 'Generic Routing Encapsulation (GRE)', S. Hanks, NetSmiths, 838 Ltd., T. Li, D. Farinacci, P. Traina, Cisco System, October 839 1994. 841 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 843 Author's address 845 Emmanuel Duros 846 INRIA Sophia Antipolis 847 2004, Route des Lucioles BP 93 848 06902 Sophia Antipolis 849 France 850 Phone : +33 4 92 38 79 42 851 Fax : +33 4 92 38 79 78 852 Email : Emmanuel.Duros@inria.fr 854 Walid Dabbous 855 INRIA Sophia Antipolis 856 2004, Route des Lucioles BP 93 857 06902 Sophia Antipolis 858 France 859 Phone : +33 4 92 38 77 18 860 Fax : +33 4 92 38 79 78 861 Email : Walid.Dabbous@inria.fr 863 Hidetaka Izumiyama 864 Japan Satellite Systems Inc. 865 Toranomon 17 Mori Bldg.5F 866 1-26-5 Toranomon, Minato-ku 867 Tokyo 105 868 Japan 869 Voice : +81-3-5511-7568 870 Fax : +81-3-5512-7181 871 Email : izu@jcsat.co.jp 873 Noboru Fujii 874 Sony Corporation 875 2-10-14 Osaki, Shinagawa-ku 876 Tokyo 141 877 Japan 878 Voice : +81-3-3495-3092 879 Fax : +81-3-3495-3527 880 Email : fujii@dct.sony.co.jp 882 Yongguang Zhang 883 HRL 884 RL-96, 3011 Malibu Canyon Road 885 Malibu, CA 90265, 886 USA 887 Phone : 310-317-5147 888 Fax : 310-317-5695 889 Email : ygz@hrl.com