idnits 2.17.1 draft-ietf-udlr-lltunnel-03.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 115: '... MUST be a router....' RFC 2119 keyword, line 119: '... communication interfaces. A feed MUST...' RFC 2119 keyword, line 340: '... feed MUST maintain a list of all ot...' RFC 2119 keyword, line 341: '... list MUST indicate which are send-o...' RFC 2119 keyword, line 500: '...integer): DTCP version number. MUST be...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (~~), 2 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 Feb 2000 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 Note to the RFC editor 40 Please replace all references to rfcXXXX with references to the new 41 GRE specification when it is published as Proposed Standard. It 42 currently exists as . The entry in the 43 "References" section may also need updating at this time. 45 Abstract 47 This document describes a mechanism to emulate bidirectional 48 connectivity between nodes that are directly connected by a 49 unidirectional link. The "receiver" uses a link layer tunneling 50 mechanism to forward datagrams to "feeds" over a separate 51 bidirectional IP network. As it is implemented at the link layer, 52 protocols in addition to IP may also be supported by this mechanism. 54 1. Introduction 56 Internet routing and upper layer protocols assume that links are 57 bidirectional, i.e., directly connected hosts can communicate with 58 each other over the same link. 60 This document describes a link layer tunneling mechanism that allows 61 nodes which are directly connected by a unidirectional link (feeds 62 and receivers, see Section 2 for terminology) to send datagrams as if 63 they were connected to a bidirectional link. We present a generic 64 topology with a tunneling mechanism that supports multiple feeds and 65 receivers. 67 The tunneling mechanism requires that all nodes have an additional 68 interface to an IP interconnected infrastructure. 70 The tunneling mechanism is implemented at the link layer of the 71 interface of every node connected to the unidirectional link. The aim 72 is to hide from higher layers, i.e. the network layer and above, the 73 unidirectional nature of the link. The tunneling mechanism also 74 includes an automatic tunnel configuration protocol that allows nodes 75 to come up/down at any time. 77 Generic Routing Encapsulation [rfcXXXX] is suggested as the tunneling 78 mechanism as it provides a means for carrying IP, ARP datagrams, and 79 any other layer-3 protocol between nodes. 81 The tunneling mechanism described in this document was discussed and 82 agreed upon by the UDLR working group. 84 2. Terminology 86 Unidirectional link (UDL): A one way transmission link, e.g. a 87 broadcast satellite link. 89 Receiver: A router that has receive-only connectivity to a UDL. 91 Send-only feed: A router that has send-only connectivity to a UDL. 93 Receive capable feed: A router that has send-and-receive connectivity 94 to a UDL. 96 Feed: A send-only or a receive capable feed. 98 Node: A receiver or a feed. 100 3. Topology 102 Feeds and receivers are connected via a unidirectional link. Send- 103 only feeds can only send data over this unidirectional link, and 104 receivers can only receive data from it. Receive capable feeds have 105 both send and receive capabilities. 107 This mechanism has been designed to work with any topology with any 108 number of receivers and one or more feeds. However, it is expected 109 that the number of feeds will be small. In particular, the special 110 case of a single send-only feed and multiple receivers is among the 111 topologies supported. 113 A receiver has several interfaces, a receive-only interface and one 114 or more additional bidirectional communication interfaces. A receiver 115 MUST be a router. 117 A feed has several interfaces, a send-only or a send-and-receive 118 capable interface connected to the unidirectional link and one or 119 more additional bidirectional communication interfaces. A feed MUST 120 be a router. 122 Tunnels are constructed between the bidirectional interfaces of 123 nodes, so these interfaces must be interconnected by an IP 124 infrastructure. In this document we assume that that infrastructure 125 is the Internet. 127 Figure 1 depicts a generic topology with several feeds and several 128 receivers. 130 Unidirectional Link 132 ---->---------->------------------->------ 133 | | | | 134 |f1u |f2u |r2u |r1u 135 -------- -------- -------- -------- ---------- 136 |Feed 1| |Feed 2| |Recv 2| |Recv 1|---|subnet A| 137 -------- -------- -------- -------- ---------- 138 |f1b |f2b |r2b |r1b | 139 | | | | | 140 ---------------------------------------------------- 141 | Internet | 142 ---------------------------------------------------- 144 Figure 1: Generic topology 146 f1u (resp. f2u) is the IP address of the 'Feed 1' (resp. Feed 2) 147 send-only interface. 149 f1b (resp. f2b) is the IP address of the 'Feed 1' (resp. Feed 2) 150 bidirectional interface connected to the Internet. 152 r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 153 2) receive-only interface. 155 r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 156 2) bidirectional interface connected to the Internet. 158 Subnet A is a local area network connected to recv1. 160 Note that nodes have IP addresses on their unidirectional and their 161 bidirectional interfaces. The addresses on the unidirectional 162 interfaces (f1u, f2u, r1u, r2u) will be drawn from the same IP 163 network. In general the addresses on the bidirectional interfaces 164 (f1b, f2b, r1b, r2b) will be drawn from different IP networks, and 165 the Internet will route between them. 167 4. Problems related to unidirectional links 169 Receive-only interfaces are "dumb" and send-only interfaces are 170 "deaf". Thus a datagram passed to the link layer driver of a 171 receive-only interface is simply discarded. The link layer of a 172 send-only interface never receives anything. 174 The network layer has no knowledge of the underlying transmission 175 technology except that it considers its access as bidirectional. 177 Basically, for outgoing datagrams, the network layer selects the 178 correct first hop on the connected network according to a routing 179 table and passes the packet(s) to the appropriate link layer driver. 181 Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. 182 However, if Recv 1 initiates a 'ping f1u', it cannot get a response 183 from Feed 1. The network layer of Recv 1 delivers the packet to the 184 driver of the receive-only interface, which obviously cannot send it 185 to the feed. 187 Most protocols in the Internet assume that links are bidirectional. 188 In particular, routing protocols used by directly connected routers 189 no longer behave properly in the presence of a unidirectional link. 191 5. Emulating a broadcast bidirectional network 193 The simplest solution is to emulate a broadcast capable link layer 194 network. This will allow the immediate deployment of existing higher 195 level protocols without change. Though other network structures, such 196 as NBMA, could also be emulated, a broadcast network is more 197 generally useful. Though a layer 3 network could be emulated, a link 198 layer network allows the immediate use of any other network layer 199 protocols, and most particularly allows the immediate use of ARP. 201 A link layer (LL) tunneling mechanism which emulates bidirectional 202 connectivity in the presence of a unidirectional link will be 203 described in the next Section. We first consider the various 204 communication scenarios which characterize a broadcast network in 205 order to define what functionalities the link layer tunneling 206 mechanism has to perform in order to emulate a bidirectional 207 broadcast link. 209 Here we enumerate the scenarios which would be feasible on a 210 broadcast network, i.e. if feeds and receivers were connected by a 211 bidirectional broadcast link: 213 Scenario 1: A receiver can send a packet to a feed (point-to-point 214 communication between a receiver and a feed). 216 Scenario 2: A receiver can send a broadcast/multicast packet on the 217 link to all nodes (point-to-multipoint). 219 Scenario 3: A receiver can send a packet to another receiver (point- 220 to-point communication between two receivers). 222 Scenario 4: A feed can send a packet to a send-only feed (point-to- 223 point communication between two feeds). 225 Scenario 5: A feed can send a broadcast/multicast packet on the link 226 to all nodes (point-to-multipoint). 228 Scenario 6: A feed can send a packet to a receiver or a receive 229 capable feed. 231 These scenarios are possible on a broadcast network. Scenario 6 is 232 already feasible on the unidirectional link. The link layer tunneling 233 mechanism should therefore provide the functionality to support 234 scenarios 1 to 5. 236 Note that regular IP forwarding over such an emulated network (i.e. 237 using the emulated network as a transit network) works correctly; the 238 next hop address at the receiver will be the unidirectional link 239 address of another router (a feed or a receiver) which will then 240 relay the packet. 242 6. Link layer tunneling mechanism 244 This link layer tunneling mechanism operates underneath the network 245 layer. Its aim is to emulate bidirectional link layer connectivity. 246 This is transparent to the network layer: the link appears and 247 behaves to the network layer as if it was bidirectional. 249 Figure 2 depicts a layered representation of the link layer tunneling 250 mechanism in the case of Scenario 1. 252 Send-only Feed Receiver 254 decapsulation encapsulation 255 /-----***************----\ /-->---***************--\ 256 | | | | 257 | | | | 258 --|---------------------- | | ---------------------|--- 259 | | f1b | f1u | | | | x r1u | r1b | | 260 | | | ^ | | IP | | | | v | 261 | ^ | | | v | | | | | | 262 | | | | | | | | v | | | 263 |-|---------|-------|---| | | |----|------|--------|--| 264 | | | | | | ^ | | | | | 265 | | | | | | LL | | | | | | 266 | | | | | | | | | | | | 267 | | | O------/ \<------O | | | 268 |-|---------|-----------| |-----------|--------|--| 269 | | | | | | | | 270 | | | | PHY | | | | 271 | | | | | | v | 272 | | | | | | | | | | 273 --|-----------|---------- ----------|----------|--- 274 | Bidir | Send-Only Recv-Only | Bidir | 275 ^ Interf | Interf UDL Interf | Interf | 276 | \------------>------->------------/ | 277 \----------------------<------------------------<--------/ 278 Bidirectional network 280 x : IP layer at the receiver generates a datagram to be forwarded 281 on the receive-only interface. 282 O : Entry point where the link layer tunneling mechanism is 283 triggered. 285 Figure 2: Scenario 1 using the LL Tunneling Mechanism 287 6.1. Tunneling mechanism on the receiver 289 On the receiver, a datagram is delivered to the link layer of the 290 unidirectional interface for transmission (see Figure 2). It is then 291 encapsulated behind a MAC header corresponding to the unidirectional 292 link. This packet cannot be sent directly over the link, so it is 293 then processed by the tunneling mechanism. 295 The packet is encapsulated behind an IP header whose destination is 296 the IP address of a feed bidirectional interface (f1b or f2b). This 297 destination address is also called the tunnel end-point. The 298 mechanism for a receiver to learn these addresses and to choose the 299 feed is explained in Section 7. The type of encapsulation is 300 described in Section 8. 302 In all cases the packet is encapsulated, but the tunnel end-point (an 303 IP address) depends on the encapsulated packet's destination MAC 304 address. If the destination MAC address is: 306 1) the MAC address of a feed interface connected to the 307 unidirectional link (Scenario 1). The datagram is encapsulated, 308 the destination address of the encapsulating datagram is the 309 feed tunnel end-point (f1b referring to Figure 2). 311 2) a MAC broadcast/multicast address (Scenario 2). The datagram is 312 encapsulated, the destination address of the encapsulating 313 datagram is the default feed tunnel end-point. See Section 7.4 314 for further details on the default feed. 316 3) a MAC address that belongs to the unidirectional network but is 317 not a feed address (Scenario 3). The datagram is encapsulated, 318 the destination address of the encapsulating datagram is the 319 default feed tunnel end-point. 321 The encapsulated datagram is passed to the network layer which 322 forwards it according to its destination address. The destination 323 address is a feed bidirectional interface which is reachable via the 324 Internet. In this case, the encapsulated datagram is forwarded via 325 the receiver bidirectional interface (r1b). 327 6.2. Tunneling mechanism on the feed 329 A feed processes unidirectional link related packets in two different 330 ways: 331 - packets generated by a local application or packets routed as 332 usual by the IP layer may have to be forwarded over the 333 unidirectional link (Section 6.2.1) 334 - encapsulated packets received from another receiver or feed need 335 tunnel processing (Section 6.2.2). 337 A feed cannot directly send a packet to a send-only feed over the 338 unidirectional link (Scenario 4). In order to emulate this type of 339 communication, feeds have to tunnel packets to send-only feeds. A 340 feed MUST maintain a list of all other feed tunnel end-points. This 341 list MUST indicate which are send-only feed tunnel end-points. This 342 is configured manually at the feed by the local administrator, as 343 described in Section 7. 345 6.2.1. Forwarding packets over the unidirectional link 347 When a datagram is delivered to the link layer of the unidirectional 348 interface of a feed for transmission, its treatment depends on the 349 packet's destination MAC address. If the destination MAC address is: 351 1) the MAC address of a receiver or a receive capable feed 352 (Scenario 6). The packet is sent over the unidirectional link. 353 This is classical "forwarding". 355 2) the MAC address of a send-only feed (Scenario 4). The packet is 356 encapsulated and sent to the send-only feed tunnel end-point. 357 The type of encapsulation is described in Section 8. 359 3) a broadcast/multicast destination (Scenario 5). The packet is 360 sent over the unidirectional link. Concurrently, a copy of this 361 packet is encapsulated and sent to every feed of the list of 362 send-only feed tunnel end-points. Thus the broadcast/multicast 363 will reach all receivers and all send-only feeds. 365 6.2.2. Receiving encapsulated packets 367 Feeds listen for incoming encapsulated datagrams on their tunnel end- 368 points. Encapsulated packets will have been received on a 369 bidirectional interface, and traversed their way up the IP stack. 370 They will then enter a decapsulation process (See Figure 2). 372 Decapsulation reveals the original link layer packet. Note that this 373 has not been modified in any way by intermediate routers; in 374 particular, the original MAC header will be intact. 376 Further actions depend on the destination MAC address of the link 377 layer packet, which can be: 379 1) the MAC address of the feed interface connected to the 380 unidirectional link, i.e. own MAC address (Scenarios 1 and 4). 381 The packet is passed to the link layer of the interface 382 connected to the unidirectional link which can then deliver it 383 up to higher layers. As a result, the datagram is processed as 384 if it was coming from the unidirectional link, and being 385 delivered locally. Scenarios 1 and 4 are now feasible, a 386 receiver or a feed can send a packet to a feed. 388 2) a receiver address (Scenario 3). The packet is passed to the 389 link layer of the interface connected to the unidirectional 390 link. It is directly sent over the unidirectional link, to the 391 indicated receiver. Note, the packet must not be delivered 392 locally. Scenario 3 is now feasible, a receiver can send a 393 packet to another receiver. 395 3) a broadcast/multicast address, this corresponds to Scenarios 2 396 and 5. We have to distinguish two cases, either (i) the 397 encapsulated packet was sent from a receiver or (ii) from a feed 398 (encapsulated broadcast/multicast packet sent to a send-only 399 feed). These cases are distinguished by examining the source 400 address of the encapsulating packet and comparing it with the 401 configured list of feed IP addresses. The action then taken is: 403 i) the feed was designated as a default feed by a receiver to 404 forward the broadcast/multicast packet. The feed is then in 405 charge of sending the multicast packet to all nodes. Delivery 406 to all nodes is accomplished by executing all 3 of the 407 following actions: 408 - The packet is encapsulated and sent to the list of send- 409 only feed tunnel end-points. 410 - Also, the packet is passed to the link layer of the 411 interface which forwards it directly over the 412 unidirectional link (all receivers and receive capable 413 feeds receive it). 414 - Also, the link layer delivers it locally to higher layers. 415 Caution: a receiver which sends an encapsulated 416 broadcast/multicast packet to a default feed will receive 417 its own packet via the unidirectional link. Correct 418 filtering as described in [rfc1112] must be applied. 420 ii) the feed receives the packet and keeps it for local 421 delivery. The packet is passed to the link layer of the 422 interface connected to the unidirectional link which delivers 423 it to higher layers. 425 Scenario 2 is now feasible, a receiver can send a 426 broadcast/multicast packet over the unidirectional link and it 427 will be heard by all nodes. 429 7. Dynamic Tunnel Configuration Protocol (DTCP) 431 Receivers and feeds have to know the feed tunnel end-points in order 432 to forward encapsulated datagrams (e.g. Scenarios 1 and 4). 434 The number of feeds is expected to be relatively small (Section 3), 435 so at every feed the list of all feeds is configured manually. This 436 list should note which are send-only feeds, and which are receive 437 capable feeds. The administrator sets up tunnels to all send-only 438 feeds. A tunnel end-point is an IP address of a bidirectional link on 439 a send-only feed. 441 For scalability reasons, manual configuration cannot be done at the 442 receivers. Tunnels must be configured and maintained dynamically by 443 receivers, both for scalability, and in order to cope with the 444 following events: 446 1) New feed detection. 447 When a new feed comes up, every receiver must create a tunnel to 448 enable bidirectional communication with it. 450 2) Loss of unidirectional link detection. 451 When the unidirectional link is down, receivers must disable 452 their tunnels. The tunneling mechanism emulates bidirectional 453 connectivity between nodes. Therefore, if the unidirectional 454 link is down, a feed should not receive datagrams from the 455 receivers. Protocols that consider a link as operational if they 456 receive datagrams from it (e.g. the RIP protocol [rfc2453]) 457 require this behavior for correct operation. 459 3) Loss of feed detection. 460 When a feed is down, receivers must disable their corresponding 461 tunnel. This prevents unnecessary datagrams from being tunneled 462 which might overload the Internet. For instance, there is no 463 need for receivers to forward a broadcast message through a 464 tunnel whose end-point is down. 466 The DTCP protocol provides a means for receivers to dynamically 467 discover the presence of feeds and to maintain a list of operational 468 tunnel end-points. Feeds periodically announce their tunnel end-point 469 addresses over the unidirectional link. Receivers listen to these 470 announcements and maintain a list of tunnel end-points. 472 7.1. The HELLO message 474 The DTCP protocol is a 'unidirectional protocol', messages are only 475 sent from feeds to receivers. 477 The packet format is shown in Figure 3. Fields contain binary 478 integers, in normal Internet order with the most significant bit 479 first. Each tick mark represents one bit. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Vers | Com | Interval | Sequence | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Feed BDL IP addr (FBIP1) (32/128 bits) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | ..... | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Feed BDL IP addr (FBIPn) (32/128 bits) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 3: Packet Format 497 Every datagram contains the following fields, note that constants are 498 written in uppercase and are defined in Section 7.5: 500 Vers (4 bit unsigned integer): DTCP version number. MUST be 501 DTCP_VERSION. 503 Com (4 bit unsigned integer): Command field, possible values are 504 1 - JOIN A message announcing that the feed sending this message 505 is up and running. 506 2 - LEAVE A message announcing that the feed sending this message 507 is being shut down. 509 Interval (8 bit unsigned integer): Interval in seconds between HELLO 510 messages for the IP protocol in "IP Vers". Must be > 0. The 511 recommended value is HELLO_INTERVAL. If this value is increased, 512 the feed MUST continue to send HELLO messages at the old rate for 513 at least the old HELLO_LEAVE period. 515 Sequence (16 bit unsigned integer): Random value initialized at boot 516 time and incremented by 1 every time a value of the HELLO message 517 is modified. 519 res (3 bits): Reserved/unused field, MUST be zero. 521 F (1 bit): bit indicating the type of feed: 522 0 = Send-only feed 523 1 = Receive-capable feed 525 IP Vers (4 bit unsigned integer): IP protocol version of the feed 526 bidirectional IP addresses (FBIP): 527 4 = IP version 4 528 6 = IP version 6 530 Tunnel Type (8 bit unsigned integer): tunneling protocol supported by 531 the feed; receivers MUST use this form of tunnel encapsulation when 532 tunneling to the feed. 533 47 = GRE [rfcXXXX] (recommended) 534 Other values may be used, but their interpretation is not specified 535 here. 537 Nb of FBIP (8 bit unsigned integer): Number of bidirectional IP feed 538 addresses which are enumerated in the HELLO message 540 reserved (8 bits): Reserved/unused field, MUST be zero. 542 Feed BDL IP addr (32 or 128 bits). The bidirectional IP address feed 543 is the IP address of a feed bidirectional interface (tunnel end- 544 point) reachable via the Internet. A feed has 'Nb of FBIP' IP 545 addresses which are operational tunnel end-points. They are 546 enumerated in preferred order. FBIP1 being the most suitable tunnel 547 end-point. 549 7.2. DTCP on the feed: sending HELLO packets 551 The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP 552 announcement" multicast address over the unidirectional link on port 553 HELLO_PORT with a TTL of 1. 555 The source address of the HELLO packet is set to the IP address of 556 the feed interface connected to the unidirectional link. In the rest 557 of the document, this value is called FUIP (Feed Unidirectional IP 558 address). 560 The process in charge of sending HELLO packets fills every field of 561 the datagram according to the description given in Section 7.1. 563 As long as a feed is up and running, it periodically announces its 564 presence to receivers. It MUST send HELLO packets containing a JOIN 565 command every HELLO_INTERVAL over the unidirectional link. 567 Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO 568 messages with the FBIP1 field set to f1b (resp. f2b). 570 When a feed is about to be shut down, or when routing over the 571 unidirectional link is about to be intentionally interrupted, it is 572 recommended that feeds: 574 1) stop sending HELLO messages containing a JOIN command. 576 2) send a HELLO message containing a LEAVE command to inform 577 receivers that the feed is no longer performing routing over the 578 unidirectional link. 580 7.3. DTCP on the receiver: receiving HELLO packets 582 Based on the reception of HELLO messages, receivers discover the 583 presence of feeds, maintain a list of active feeds, and keep track of 584 the tunnel end-points for those feeds. 586 For each active feed, and each IP protocol supported, at least the 587 following information will be kept: 588 FUIP - feed unidirectional link IP address 589 FUMAC - MAC address corresponding to the above IP 590 address 591 (FBIP1,...,FBIPn) - list of tunnel end-points 592 tunnel type - tunnel type supported by this feed 593 Sequence - "Sequence" value from the last HELLO received 594 from this feed 595 timer - used to timeout this entry 597 The FUMAC value for an active feed is needed for the operation of 598 this protocol. However, the method of discovery of this value is not 599 specified here. 601 Initially, the list of active feeds is empty. 603 When a receiver is started, it MUST run a process which joins the 604 "DTCP announcement" multicast group and listens to incoming packets 605 on the HELLO_PORT port from the unidirectional link. 607 Upon the reception of a HELLO message, the process checks the version 608 number of the protocol. If it is different from HELLO_VERSION, the 609 packet is discarded and the process waits for the next incoming 610 packet. 612 After successfully checking the version number further action depends 613 on the type of command: 615 - JOIN: 617 The process verifies if the address FUIP already belongs to the 618 list of active feeds. 620 If it does not, a new entry, for feed FUIP, is created and added 621 to the list of active feeds. The number of feed bidirectional IP 622 addresses to read is deduced from the 'Nb of FBID' field. These 623 tunnel end-points (FBIP1,...,FBIPn) can then be added to the new 624 entry. The tunnel type and Seq values are also taken from the 625 HELLO packet and recorded in the new entry. A timer set to 626 HELLO_LEAVE is associated with this entry. 628 If it does, the sequence number is compared to the sequence number 629 contained in the previous HELLO packet sent by this feed. If they 630 are equal, the timer associated with this entry is reset to 631 HELLO_LEAVE. Otherwise all the information corresponding to FUIP 632 is set to the values from the HELLO packet. 634 Referring to Figure 1 in Section 3, both receivers (recv 1 and 635 recv 2) have a list of active feeds containing two entries: Feed 1 636 with a FUIP of f1u and a list of tunnel end-points (f1b); and Feed 637 2 with a FUIP of f2u and a list of tunnel end-points (f2b). 639 - LEAVE: 641 The process checks if there is an entry for FUIP in the list of 642 active feeds. If there is, the timer is disabled and the entry is 643 deleted from the list. The LEAVE message provides a means of 644 quickly updating the list of active feeds. 646 A timeout occurs for either of two reasons: 648 1) a feed went down without sending a LEAVE message. As JOIN 649 messages are no longer sent from this feed, a timeout occurs at 650 HELLO_LEAVE after the last JOIN message. 652 2) the unidirectional link is down. Thus no more JOIN messages are 653 received from any of the feeds, and they will each timeout 654 independently. The timeout of each entry depends on its 655 individual HELLO_LEAVE value, and when the last JOIN message was 656 sent by that feed, before the unidirectional link went down. 658 In either case, bidirectional connectivity can no longer be ensured 659 between the receiver and the feed (FUIP): either the feed is no 660 longer routing datagrams over the unidirectional link, or the link is 661 down. Thus the associated entry is removed from the list of active 662 feeds, whatever the cause. As a result, the list only contains 663 operational tunnel end-points. 665 The HELLO protocol provides receivers with a list of feeds, and a 666 list of usable tunnel end-points (FBIP1,..., FBIPn) for each feed. In 667 the following Section, we describe how to integrate the HELLO 668 protocol into the tunneling mechanism described in Sections 6.1 and 669 6.2. 671 7.4. Tunneling mechanism using the list of active feeds 673 This Section explains how the tunneling mechanism uses the list of 674 active feeds to handle datagrams which are to be tunneled. Referring 675 to Section 6.1, it shows how feed tunnel end-points are selected. 677 The choice of the default feed is made independently at each 678 receiver. The choice is a matter of local policy, and this policy is 679 out of scope for this document. However, as an example, the default 680 feed may be the feed that has the lowest round trip time to the 681 receiver. 683 When a receiver sends a packet to a feed, it must choose a tunnel 684 end-point from within the FBIP list. The 'preferred FBIP' is 685 generally FBIP1 (Section 7.1). For various reasons, a receiver may 686 decide to use a different FBIP, say FBIPi instead of FBIP1, as the 687 tunnel end-point. For example, the receiver may have better 688 connectivity to FBIPi. This decision is taken by the receiver 689 administrator. 691 Here we show how the list of active feeds is involved when a receiver 692 tunnels a link layer packet. Section 6.1 listed the following cases, 693 depending on whether the MAC destination address of the packet is: 695 1) the MAC address of a feed interface connected to the 696 unidirectional link: This is TRUE if the address matches a FUMAC 697 address in the list of active feeds. The packet is tunneled to 698 the preferred FBIP of the matching feed. 700 2) the broadcast address of the unidirectional link or a multicast 701 address: 702 This is determined by the MAC address format rules, and the list 703 of active feeds is not involved. The packet is tunneled to the 704 preferred FBIP of the default feed. 706 3) an address that belongs to the unidirectional network but is not 707 a feed address: 708 This is TRUE if the address is neither broadcast nor multicast, 709 nor found in the list of active feeds. The packet is tunneled to 710 the preferred FBIP of the default feed. 712 In all cases, the encapsulation type depends on the tunnel type 713 required by the feed which is selected. 715 7.5. Constant definitions 717 DTCP_VERSION is 1. 719 HELLO_INTERVAL is 5 seconds. 721 "DTCP announcement" multicast group is 224.0.1.124. 723 HELLO_PORT is 652. It is a reserved system port, no other traffic 724 must be allowed. 726 HELLO_LEAVE is 3*Interval, as advertised in a HELLO packet, i.e. 15 727 seconds if the default HELLO_INTERVAL was advertised. 729 8. Tunnel encapsulation format 731 The tunneling mechanism operates at the link layer and emulates 732 bidirectional connectivity amongst receivers and feeds. We assume 733 that hardware connected to the unidirectional link supports broadcast 734 and unicast MAC addressing. That is, a feed can send a packet to a 735 particular receiver using a unicast MAC destination address or to a 736 set of receivers using a broadcast/multicast destination address. The 737 hardware (or the driver) of the receiver can then filter the incoming 738 packets sent over the unidirectional links without any assumption 739 about the encapsulated data type. 741 In a similar way, a receiver should be capable of sending unicast and 742 broadcast MAC packets via its tunnels. Link layer packets are 743 encapsulated. As a result, after decapsulating an incoming packet, 744 the feed can perform link layer filtering as if the data came 745 directly from the unidirectional link (See Figure 2). 747 Generic Routing Encapsulation (GRE) [rfcXXXX] suits our requirements 748 because it specifies a protocol for encapsulating arbitrary packets, 749 and allows use of IP as the delivery protocol. 751 Other encapsulations are possible, such as directly encapsulating a 752 MAC level packet within an IP datagram. 754 The feed's local administrator decides what encapsulation it will 755 demand that receivers use, and sets the tunnel type field in the 756 HELLO message appropriately. The value 47 (decimal) indicates GRE. 757 Other values can be used, but their interpretation must be agreed 758 upon between feeds and receivers. Such usage is not defined here. 760 8.1. Generic Routing Encapsulation on the receiver 762 A GRE packet is composed of a header in which a type field specifies 763 the encapsulated protocol (ARP, IP, IPX, etc.). See [rfcXXXX] for 764 details about the encapsulation. In our case, only support for the 765 MAC addressing scheme of the unidirectional link MUST be implemented. 767 A packet tunneled with a GRE encapsulation has the following format: 768 the delivery header is an IP header whose destination is the tunnel 769 end-point (FBIP), followed by a GRE header specifying the link layer 770 type of the unidirectional link. Figure 4 presents the entire 771 encapsulated packet. 773 ---------------------------------------- 774 | IP delivery header | 775 | destination addr = FBIP | 776 | IP proto = GRE (47) | 777 ---------------------------------------- 778 | GRE Header | 779 | type = MAC type of the UDL | 780 ---------------------------------------- 781 | Payload packet | 782 | MAC packet | 783 ---------------------------------------- 785 Figure 4: Encapsulated packet 787 8.2. Encapsulation of UDL MAC level packets 789 An alternative is to encapsulate the MAC level packet within IP. The 790 protocol field in the IP datagram is then set to the MAC type of the 791 unidirectional link. Figure 5 presents the entire encapsulated 792 packet. 794 ---------------------------------------- 795 | IP delivery header | 796 | destination addr = FBIP | 797 | IP proto = MAC type of the UDL | 798 ---------------------------------------- 799 | Payload packet | 800 | MAC packet | 801 ---------------------------------------- 803 Figure 5: Encapsulated packet 805 9. Issues 807 9.1. Hardware address resolution 809 Regardless of whether the link is unidirectional or bidirectional, if 810 a feed sends a packet over a non-point-to-point type network, it 811 requires the data link address of the destination. ARP [rfc826] is 812 used on Ethernet networks for this purpose. 814 The link layer mechanism emulates a bidirectional network in the 815 presence of an unidirectional link. However, there are asymmetric 816 delays between every (feed, receiver) pair. The backchannel between a 817 receiver and a feed has varying delays because packets go through the 818 Internet. Furthermore, a typical example of a unidirectional link is 819 a GEO satellite link whose delay is about 250 milliseconds. 821 Because of long round trip delays, reactive address resolution 822 methods such as ARP [rfc826] may not work well. For example, a feed 823 may have to forward packets at high data rates to a receiver whose 824 hardware address is unknown. The stream of packets is passed to the 825 link layer driver of the feed send-only interface. When the first 826 packet arrives, the link layer realizes it does not have the 827 corresponding hardware address of the next hop, and sends an ARP 828 request. While the link layer is waiting for the response (at least 829 250 ms for the GEO satellite case), IP packets are buffered by the 830 feed. If it runs out of space before the ARP response arrives, IP 831 packets will be dropped. 833 This problem of address resolution protocols is not addressed in this 834 document. An ad-hoc solution is possible when the MAC address is 835 configurable, which is possible in some satellite receiver cards. A 836 simple transformation (maybe null) of the IP address can then be used 837 as the MAC address. In this case, senders do not need to "resolve" an 838 IP address to a MAC address, they just need to perform the simple 839 transformation. 841 9.2. Routing protocols 843 The link layer tunneling mechanism hides from the network and higher 844 layers the fact that feeds and receivers are connected by a 845 unidirectional link. Communication is bidirectional, but asymmetric 846 in bandwidths and delays. 848 In order to incorporate unidirectional links in the Internet, feeds 849 and receivers must run routing protocols. These protocols will work 850 fine because the tunneling mechanism results in bidirectional 851 connectivity between all feeds and receivers. Thus routing messages 852 can be exchanged as on any bidirectional network. 854 The tunneling mechanism allows any IP traffic, not just routing 855 protocol messages, to be forwarded between receivers and feeds. 856 Receivers can route datagrams on the Internet using the most suitable 857 feed or receiver as a next hop. Administrators may want to set the 858 metrics used by their routing protocols in order to reflect in 859 routing tables the asymmetric characteristics of the link, and thus 860 direct traffic over appropriate paths. 862 Feeds and receivers can run multicast routing daemons and therefore 863 dynamic multicast routing can be performed over the unidirectional 864 link. However issues related to multicast routing (e.g. protocol 865 configuration) are not addressed in this document. 867 9.3. Scalability 869 The DTCP protocol does not generate a lot of traffic whatever the 870 number of nodes. The problem with a large number of nodes is not 871 related to this protocol but to more general issues such as the 872 maximum number of nodes which can be connected to any link. This is 873 out of scope of this document. 875 10. Security Considerations 877 Confidentiality and integrity concerns may arise from the lower layer 878 technologies employed, e.g. if the unidirectional link is a satellite 879 link and the backchannel is the public internet. Since this protocol 880 aims to support a link layer, link layer confidentiality and 881 integrity mechanisms may be appropriate. In the case of the 882 backchannel only, IPSEC [rfc2401] may provide appropriate services. 884 Theft of service and denial of service attacks become possible to 885 systems which can discover the feed tunnel end-point addresses and 886 can direct packets to them. It may be appropriate for feeds to 887 authenticate tunnel sources, i.e. receivers. Feeds can validate the 888 IP source addresses of tunneled packets, but this can be easily 889 spoofed. MAC layer filtering may also be possible. Adequate 890 protection can be ensured using IPSEC [rfc2401] AH [rfc2402] to 891 provide strong authentication of tunnel sources. For reasons of 892 scalability, no particular mechanism is specified in this protocol. 894 11. Acknowledgments 896 We would like to thank Tim Gleeson (Cisco Japan) for his valuable 897 editing and technical input during the finalization phase of the 898 document. 900 We would like to thank Patrick Cipiere (INRIA) for his valuable input 901 concerning the design of the encapsulation mechanism. 903 We would like also to thank for their participation: Akihiro Tosaka 904 (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi 905 Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), 906 Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu 907 (Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri 908 Hakulinen (Nokia). 910 A. Conformance and interoperability 912 This document describes a mechanism to emulate bidirectional 913 connectivity between nodes that are directly connected by a 914 unidirectional link. Applicability over a variety of equipment and 915 environments is ensured by allowing a choice of several key system 916 parameters. 918 Thus in order to ensure interoperability of equipment it is not 919 enough to simply claim conformance with the mechanism defined here. A 920 usage profile for a particular environment will require the 921 definition of several parameters: 922 - the MAC format used 923 - the tunneling mechanism to be used (GRE is recommended) 924 - the "tunnel type" indication if GRE is not used 926 For example, a system might claim to implement "the link layer 927 tunneling mechanism for unidirectional links, using IEEE 802 LLC, and 928 GRE encapsulation for the tunnels." 930 References 932 [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, 933 November 1982. 935 [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford 936 University, August 1989 938 [rfc2401] 'Security Architecture for the Internet Protocol', S. Kent, 939 BBN Corp, R. Atkinson, @Home Network 941 [rfc2402] 'IP Authentication Header', S. Kent, BBN Corp, R. Atkinson, 942 @Home Network 944 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 946 [rfcXXXX] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li, 947 S. Hanks, D. Meyer, P. Traina. 949 Author's address 951 Emmanuel Duros 952 INRIA Sophia Antipolis 953 2004, Route des Lucioles BP 93 954 06902 Sophia Antipolis 955 France 956 Phone : +33 4 92 38 79 42 957 Fax : +33 4 92 38 79 78 958 Email : Emmanuel.Duros@inria.fr 960 Walid Dabbous 961 INRIA Sophia Antipolis 962 2004, Route des Lucioles BP 93 963 06902 Sophia Antipolis 964 France 965 Phone : +33 4 92 38 77 18 966 Fax : +33 4 92 38 79 78 967 Email : Walid.Dabbous@inria.fr 969 Hidetaka Izumiyama 970 Japan Satellite Systems Inc. 971 Toranomon 17 Mori Bldg.5F 972 1-26-5 Toranomon, Minato-ku 973 Tokyo 105 974 Japan 975 Voice : +81-3-5511-7568 976 Fax : +81-3-5512-7181 977 Email : izu@jcsat.co.jp 979 Noboru Fujii 980 Sony Corporation 981 2-10-14 Osaki, Shinagawa-ku 982 Tokyo 141 983 Japan 984 Voice : +81-3-3495-3092 985 Fax : +81-3-3495-3527 986 Email : fujii@dct.sony.co.jp 988 Yongguang Zhang 989 HRL 990 RL-96, 3011 Malibu Canyon Road 991 Malibu, CA 90265, 992 USA 993 Phone : 310-317-5147 994 Fax : 310-317-5695 995 Email : ygz@hrl.com